| Hi Martin! Thanks for stepping up and trying to help out! Don’t panic! There’s lots of tooling and ways to do things in Debian and it’s not always immediately obvious. I managed to make it build on a VM at my end, so the PR isn’t fundamentally broken. As a quick set of pointers, I did the following: Entered my `~/Dev/Debian/` dir where all work happens made a new bladerf folder and entered it. I then ran `apt source bladerf` so the upstream tarball was present. From there, I git cloned your repo to `bladerf`, entered and checked out udev_rules_update ```` cd ~/Dev/Debian mkdir bladerf cd bladerf git clone <repo> git checkout udev_rules_update ``` I checked I had your source by scanning the changelog and then built a Debian source package `dpkg-source -b .` This placed a `bladerf_0.2023.02-6.dsc` file one level up. To build I hopped up one level and ran sbuild: ``` cd .. sbuild bladerf_0.2023.02-6.dsc ``` This generated a valid deb. It also ran Lintian which complained as usual but nothing that stands out as a blocker for build. 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.gz dpkg-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! 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. Cheers Hibby [1] https://wiki.debian.org/sbuild [2] https://wiki.debian.org/UsingQuilt
--
Hibby Debian Developer Packet Radioist MM0RFN On 26 Jul 2024, at 23:15, Martin Herren - HB9FXX <hb9fxx@protonmail.com> wrote: |