-
Notifications
You must be signed in to change notification settings - Fork 24
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
Introduce Debian Bookworm support #24
Conversation
9db908c
to
219425d
Compare
I currently built a wireguard tunnel between the CAX11 and my productive feeder. Via socat I am simulating a local readsb etc. - the data is coming from my real feeder via the tunnel. So far so good. Normal ADS-B as well as faup is working flawless. Only the MLAT client is not starting. It fails with the following error:
|
The mentioned error was caused by an incompatibility between the mlat-client and Python 3.11. See also this issue in the upstream repository. In fact, i took the patch from the mentioned issue and applied it via a patch in our build process. On my test system, this is working flawless. Many thanks to @wiedehopf at that point! :) |
Just successfully build your PR and can confirm that MLAT-Client is now working on Bookworm.
Is it possible not to use PIP? As from my experience it creates more of a Headache, but I am not a progammer by any means.
|
I am also just a DevOps engineer lol
I really don't know. What I know is the fact, that we need to go away from the The MlatClient is problematic, yes - but not because of pip. It's because it's in fact not maintained anymore / a legacy project. The patch that i needed to apply... yeah, i don't think that I need to write anything more about that. In my opinion, the mlat-client should be replaced with the fork from wiedehopf. But thats more something like a long term task. |
I had used PIP in the past too, but the constant changes and requirements it puts on the user, I found frustrating and it is another package manager which needs maintaining and depedencies sorting out. |
This is absolutely understandable. In this case, i just worked with the given structure in this project, which in fact installs all python3 depdencies from source - and i wouldn't change that behavior completely. |
Yeah would be nice if the team at FlightAware could be more closer to the way Debian is doing things, so that in the end just some .deb files need distributing..... :-) And thank you very much indeed for spending your time on this issue and pushing a PR for this. |
From today, Armbian is not delivering any Debian Bullseye updates anymore for my Odroid XU4. I am currently doing the Bookworm upgrade. Nine days are gone, since I created my PR and there is still absolutely no reaction from the maintainers. Appreciation looks slightly different. @eric1tran @mutability |
Unfortunately I'm not willing to blindly apply this PR without digging into the details, and it suffers from the "doing more than one thing" problem which makes it a larger task to review:
Our support generally tracks what the Pi Foundation supports, and they're still on bullseye, so it's hard to justify prioritizing a review of this at the moment. But I certainly do appreciate the effort you made here -- thanks! -- and I'll do a review as soon as I can find the time. If you're willing to break it out into one-functional-change-per-PR then that would make it easier to apply the more obviously-correct parts. |
That's exactly what we do for Raspbian. |
I also do not want you to do that! Its just... nine days of hearing nothing (also not a "I will take a look on it, but i need a few days or weeks") feels like no appreciation. But now we clarified that - thanks for your statement, makes me very happy!
This is actually just some beauty stuff that was suggested by shellcheck. Idk whether this is worth a extra PR, but if you want it that way, i will create another PR.
I guess that we don't achieve anything with creating an PR there... i have written something according to that in my comment above.
I already tried that, since resolving all that dependencies by hand was my last option. But there was no success on my side. There is no cx-freeze in the system repositories (see screenshot) and mixing apt and pip dependencies together... hmm, i don't think that thats a good idea. What I personally don't understand is the fact, that the internet access at built time is forbidden/prevented. I just accepted that fact and kept that, since I was very sure that theres a good reason for doing it that way. According to splitting the Debian Bookworm things and the mlat-client patch in two different PR's - the mlat-client patch is required to get the Debian Bookworm package working. In my mind, this should be in one PR since it belongs together. |
You are aware that Raspberry Pi OS for arm64 and armhf is just Debian, where Raspberry Pi Foundation only provides firmware blobs, rpi-update etc. and only for Legacy Raspbian (armhf) they provide a full repo. http://raspbian.raspberrypi.org/raspbian/dists/
https://archive.raspberrypi.org/debian/dists/
|
I just saw, that you, @mutability, are the maintainer of the mlat-client. Didn't seen that before. I created an PR with the fix there and will remove the patch now from this PR. |
Done. I assumed, that you will release the mlat-client fix as version 0.2.13. |
Thanks! I hope to find some time to look at this in the next couple of weeks.
It's not pip depenencies so much as "can you install cxfreeze from source while satisfying its dependencies via the system python packaging". In the past the answer was "no" because the system packages were too old for the version of cxfreeze we needed, so you ended up going down the rabbit-hole of satisfying all the transitive dependencies by hand. But maybe now the answer is "yes"?
It's mostly from trying to follow Debian policy:
There are various good reasons for wanting this (stability/reproducibility of builds, privacy, etc) so I try to at least get to the point where you can prepare a standalone package build tree that can be (re-)built on a build machine predictably with no network access. |
(a) rpi armhf binary packages are not the same as upstream Debian packages (as you will discover if you try to use a Debian armhf binary package on a Pi Zero / ZeroW) (b) we target support for the Pi OS images which include the Pi Foundation specific packages and system configuration, rather than Debian directly. The changes in this image versus upstream Debian are not merely hardware support. The litmus test for OS support is "is it on the download page as compatible-with-all-Raspberry-Pi-Models" |
One more note here -- the whole reason why cxfreeze is in the mix is that, at the time, the Raspbian/Debian python dependencies weren't stable enough to reliably package against; I had a constant stream of bug reports where a binary package with apparently-correct dependencies would be broken by an upstream Python update. Maybe that has improved enough in current versions that we don't even need cxfreeze any more, which would make life easier.. |
That absolutely makes sense. Never had an reason to read that policy before. :) |
I've used this to build for my pi and it's back online and reporting to FA, would like to see a bookworm package released |
I'm working through this now and cxfreeze looks like it should be fine building against the system python packages in bookworm, so I'll probably go with that approach rather than pulling in all the dependencies. |
(32-bit arm userspace with 64-bit kernel may be broken; I fixed it up for bullseye but haven't had a chance to test that combination on bookworm yet) |
Build on arm64/Bookworm and experienced no issues. |
GNU nano 7.2 piaware_9.0-dev_arm64.buildinfo NB: replaced "~" with "-" in package name for readabilty. |
Check your path, this apt error typically means "I can't read the file / file doesn't exist" Failing that try installing with |
Thanks, idiot me hadn't updated it's notes. All working now :-) |
9.0 was released with bookworm support. |
This should fix #23 and introduce support for the new Debian Bookworm release.
Currently, my tests of the implementation are quite poor:
My actual feeder, an Odroid XU4 with Armbian, is currently still on bullseye.
May somebody can review my changes and test them on their hardware?
Additionally, i do not have a Jenkins instance, which is why cannot check whether compiling via CI works.