[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [libbladerf2] Change udev rule to add plugdev group

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,

Martin

On 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.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

[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

Reply to: