[continued from previous message]
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,
Martin
On Saturday, July 27th, 2024 at 1:14 AM, Dave Hibberd <[email protected]> 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.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` <
http://deb.debian.org/debian/pool/main/q/qsstv/qsstv_9.5.8-3.dsc%60> (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
[1] https://wiki.debian.org/sbuild
[2] https://wiki.debian.org/UsingQuilt
--
Hibby
Debian Developer
Packet Radioist
MM0RFN
*Attachments:*
• signature.asc
*Attachments:*
• signature.asc
--064c787f0a3f4404bb57f6db0f2c9947
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)