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!
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
--
Hibby
Debian Developer
Packet Radioist
MM0RFN