Skip to content

Fix debian packaging, add fobos-tools package, misc fixes#38

Merged
rigexpert merged 10 commits into
rigexpert:mainfrom
ka9q:main
Jun 18, 2026
Merged

Fix debian packaging, add fobos-tools package, misc fixes#38
rigexpert merged 10 commits into
rigexpert:mainfrom
ka9q:main

Conversation

@ka9q

@ka9q ka9q commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

I merged your upstream revisions into my fork, fixed the debian packaging and did some miscellaneous source cleanups. I had to change the cmake config file, eg, setting SONAME 0 (is that right?) and installing the udev rule file with a numerical prefix in the proper place for a package build (usr/lib/udev/rules.d). I have built packages with this tree and put them on my personal website at http://www.ka9q.net/debian. I'm using my package for amd64 with my own fobos and it seems to work like before.

I removed the DATE and TIME macros from the library version string in accordance with the "reproducible builds" guidelines that make it easier for people to verify that the distributed binary libraries match the source code.

@rigexpert

Copy link
Copy Markdown
Owner
  • do not remove the DATE and TIME
  • do not remove anything
  • do not do source cleanups
  • do not make me do cleanups after your cleanups
  • see README.md [https://github.com/rigexpert/libfobos#for-contributors]

@rigexpert rigexpert merged commit 49b0440 into rigexpert:main Jun 18, 2026
7 checks passed
@ka9q

ka9q commented Jun 18, 2026

Copy link
Copy Markdown
Contributor Author

I'm still learning about Debian requirements for packages that will become part of the standard distributions, and I'm trying to meet them. I know I will have to make changes to ka9q-radio too. "Reproducible builds" is a broad effort to improve security by making it easy for anyone to mechanize the rebuilding of source code to see if the results match the distributed binaries, making it harder to hide malware. I've had to make those same changes in my own code. The recommended alternative to the compilation date and time is to include a git commit hash or something else that won't change when you simply do "make clean && make all" again.

@rigexpert

Copy link
Copy Markdown
Owner

Date and time are the most human-readable and distinguishable feature rather then hash code or even library version. Everything is opensource, so malware is far away. Everyone is free to compile their own binaries and use it.
Anyways thank you for contributing.

@ka9q

ka9q commented Jun 19, 2026

Copy link
Copy Markdown
Contributor Author

"Debian policy strictly discourages the use of DATE and TIME macros because they inject the exact time of compilation into binaries, which breaks reproducible build requirements. Instead, Debian and the Reproducible Builds initiative enforce the use of SOURCE_DATE_EPOCH for build timestamps." See https://reproducible-builds.org/docs/timestamps/

It doesn't have to be a opaque hash. If you want a timestamp, extract it from the last git commit. That's more meaningful than the precise time that you ran make. The important thing is that re-running 'make' on the same source tree with the same options produces bit-identical binaries. Then lots of people can run automated verifications.

Yes, in theory open source can be vetted but that's not the point here. Even if that were standard practice (which it isn't), without reproducible binaries there's no easy way to know that the source matches the distributed binaries (like a Debian .deb) that might have deliberate vulnerabilities not found in the source. The vast majority of open source users (including me) don't recompile everything they use from source, much less carefully scrutinize all the sources first.

The Fobos is a very good SDR. I'd like to see it used much more widely, and that requires prebuilt libraries in all the standard Linux distributions. Prebuilt Debian ka9q-radio packages are also essential if it is ever to go mainstream. That's why I've been spending all this time lately on learning Debian's policies and procedures for making packages.

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.

2 participants