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!
CheersHibby
[1] https://wiki.debian.org/sbuild
[2] https://wiki.debian.org/UsingQuilt--
Hibby
Debian Developer
Packet Radioist
MM0RFN
Attachment:
signature.asc
Description: OpenPGP digital signature