Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolved Issue #3 (Cannot build with libgmime 3 or Debian 11/Bullseye) #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Levitator1
Copy link

Technically, at the previous commit, you could build it, but it would segfault due to a type safety failure
and incompatibility.

  • Removed the override which forces gmime version detection to v2
  • Fixed the transfer of the message date between Winlink and MIME header for gmime 3
  • That seemed to be the last thing missing for gmime 3 to work, but I have not tested the serial transport
  • Doubled the fork process timeout to avoid spurious timeouts
  • Added a missing close() call in the forked process which appeared to be leaking sockets into the operating system

The last item is especially weird, since I don't think it's supposed to be possible; the OS is supposed to close
all file handles (including sockets) upon process exit, so maybe it represents a kernel or driver bug. Anyway, I
find it a valuable workaround, as I would otherwise have to restart the radio stack after every run.
This leak may happen anyway if the program closes abnormally, but at least it's fixed for the more common cases.
If it persists, we might want to put the socket close in a signal or termination handler.

…an 11/Bullseye)

- Removed the override which forces gmime version detection to v2
- Fixed the transfer of the message date between Winlink and MIME header for gmime 3
- That seemed to be the last thing missing for gmime 3 to work, but I have not tested the serial transport
- Doubled the fork process timeout to avoid spurious timeouts
- Added a missing close() call in the forked process which appeared to be leaking sockets into the operating system

The last item is especially weird, since I don't think it's supposed to be possible; the OS is supposed to close
all file handles (including sockets) upon process exit, so maybe it represents a kernel or driver bug. Anyway, I
find it a valuable workaround, as I would otherwise have to restart the radio stack after every run.
This leak may happen anyway if the program closes abnormally, but at least it's fixed for the more common cases.
If it persists, we might want to put the socket close in a signal or termination handler.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant