Hi Dave,Thanks for your answer.Things have changed a little now. A new .deb package has been released with the new upstream release and thus my MR is now in conflict.As suggested by Mait it is probably better to try to open my MR against upstream directly.If that doesn't work there is still time to adapt my MR again.So i'll open an new MR directly to upstream as this makes sense and the issue can also affect other distributions.I'd like to thanks all of you that helped and guided my over the last 2 months, i learned a lot, including about sbuild and quilt and the packaging process in general. So the time was not waisted and i hope to find other opportunities to contribute to Debian !Cheers,Martin - HB9FXXOn Tuesday, August 27th, 2024 at 12:51 PM, Dave Hibberd <d@vehibberd.com> wrote:Hi Martin!Things have been a little hectic here but this is still on my radar to look at!Aa a quick reply -For filing a bug - if you feel it's not desired behaviour, go ahead and file a bug. The bugtracker is a default method of interacting and discussing things with each other in Debian, so don't be shy. The worst that happens is it gets reassigned, merged with another or closed after discussion.For the dpkg-divert, it's all fairly recent and tied to the usrmerge change, so it's probably best to look to mait for guidance on that. As you've changed the name of the rules, something will need to change at least!Cheers,--HibbyMM0RFNOn Sun, 4 Aug 2024, at 2:02 PM, Martin Herren - HB9FXX wrote:Hi all,Thanks to all the help I received so far.I updated my MR at https://salsa.debian.org/debian-hamradio-team/bladerf/-/merge_requests/1 as i managed to build and test the .deb using sbuild and now used quilt to adapt the udev patch.The 2 questions now are:
- As the issue with udev uaccess could be considered a bug, should i still open an bug report ? I can confirm the bug is already present in Bookworm
- I don't understand the `dpkg-divert` stuff, from my understanding as there are now new udev rules files with new names, all the dpkg-divert postinstall/preremove stuff could now be removed ?
Thanks and best regards,/MartinOn Monday, July 29th, 2024 at 12:48 AM, Martin Herren - HB9FXX <hb9fxx@protonmail.com> wrote:Hi,Thanks Dave, what a huge amount of help and pointers you just provided.Previously i tried to build the .deb using `debuild`. While it succeeded to produce a .dsc it failed generating a .deb with the same error as in the salsa ci/cd pipeline as in https://salsa.debian.org/MartinHerren/bladerf/-/jobs/6029130.I had both original tarballs available. With some manual hacking i managed to get a little further without succeeding.I then followed your procedure and managed to set up an initial unstable sbuild environment and it managed to build a .deb !Now i'll validate the 2 issues i'm trying to solve with my MR by installing the new .deb.Yes, the patch has been somewhat manually generated by modifying the .orig folder and generating a diff out of it that i used to update the patch. Next will be to look at quilt and i'll update my MR.Thanks a lot, this helps a lot to go forward with this MR !Cheers,MartinOn Saturday, July 27th, 2024 at 1:14 AM, Dave Hibberd <hibby@debian.org> wrote:I always have sbuild[1] set up and an unstable chroot for building ready to go. Sbuild will always fail if you don’t have the orig.tar.gz matching the level - I notice this one relies on two original tarballs:```dpkg-source: info: unpacking bladerf_0.2023.02.orig.tar.gzdpkg-source: info: unpacking bladerf_0.2023.02.orig-drivers.tar.xz```Maybe that’s part of your firmware issue?I strongly recommend playing with sbuild, it’s a fantastic tool. I’ve been using it to do cross builds for different architectures and all kinds of funky stuff this year. Recently I learned you can feed it the url to a .dsc and it will download everything from the remote server required to build that package! `sbuild http://deb.debian.org/debian/pool/main/q/qsstv/qsstv_9.5.8-3.dsc` (for example) now happens quite a lot in my house!One thing I notice after a quick look at the commits is that your patch format looks odd to me - how did you generate updates to d/patches/update-bladerf-udev-rules? Did you edit the patch file directly?I notice lines like diff --git a/host/misc/udev/60-nuand-bladerf1.rules.in b/host/misc/udev/60-nuand-bladerf1.rules.in are a bit unusual to my eyes (someone else, of course, may correct me - there’s many ways to interact with Debian!). It clearly still builds, so presumably it’s just a style difference! I tend to ship upstream’s code in my repos, not just the Debian folder so there may be a packing style difference between mait and I there too.I use quilt[2] for patching generally. It’s worth installing quilt and setting up a .quiltrc as the wiki page suggests.You’ll be looking to push the relevant patch on to the stack with `quilt push update-bladerf-udev-rules` make changes directly to the code, run `quilt refresh` and then `quilt pop -a` to pull the patches off the stack, but it assumes the code is adjacent to the folder.Hopefully this helps - you’re welcome to reach out and ask for help any time!
Cheers--HibbyDebian DeveloperPacket RadioistMM0RFNAttachments:
- signature.asc
Attachments:
- signature.asc