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` <
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
On 26 Jul 2024, at 23:15, Martin Herren - HB9FXX <hb9fxx@protonmail.com> wrote:
Hej,
I'm still stuck on this issue.
On Saturday, July 6th, 2024 at 12:39 PM, Daniele Forsi <iu5hkx@gmail.com> wrote:
but in any case do open a merge
request as soon as you can, so other people can give feedback on a
specific change; otherwise if the discussion remains only in this
mailing list we risk forgetting this issue.
I just opened an MR at https://salsa.debian.org/debian-hamradio-team/bladerf/-/merge_requests/1
I'm still stuck building the .deb. Seems to be a problem with building the firmware.
Hoped this would be an easy and simple first contribution to a package. Underestimated the issue and overestimated my ability.
Still motivated to learn how to do it so maybe next time it will be easier.
73s de Martin HB9FXX
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Martin!<div><br></div><div>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.</div><div><br></div><div>I managed to make it build on a VM at my end, so the PR isn’t fundamentally broken. </div><div><
</div><div>As a quick set of pointers, I did the following:</div><div><br></div><div>Entered my `~/Dev/Debian/` dir where all work happens made a new bladerf folder and entered it. I then r<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">
an `apt source bladerf`</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> so the upstream tarball was present.</span></div><div>From there, I git cloned your repo to `bladerf`, entered and checked out udev_rules_update</div><div>``
``</div><div>cd ~/Dev/Debian</div><div>mkdir bladerf</div><div>cd bladerf</div><div>git clone <repo></div><div>git checkout udev_rules_update</div><div>```</div><div>I checked I had your source by scanning the changelog and then built a Debian
source package</div><div>`dpkg-source -b .`</div><div><br></div><div>This placed a `bladerf_0.2023.02-6.dsc` file one level up. To build I hopped up one level and ran sbuild:</div><div>```</div><div>cd ..</div><div>sbuild bladerf_0.2023.02-6.dsc</div><
``` </div><div>This generated a valid deb. It also ran Lintian which complained as usual but nothing that stands out as a blocker for build.</div><div><br></div><div>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:</div><div><div>```</div><div>dpkg-source: info: unpacking bladerf_0.2023.02.orig.tar.gz</div><div>dpkg-source: info:
unpacking bladerf_0.2023.02.orig-drivers.tar.xz</div></div><div>```</div><div>Maybe that’s part of your firmware issue?</div><div><br></div><div>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 <a href="
http://deb.debian.org/
debian/pool/main/q/qsstv/qsstv_9.5.8-3.dsc%60">
http://deb.debian.org/debian/pool/main/q/qsstv/qsstv_9.5.8-3.dsc`</a> (for example) now happens quite a lot in my house!</div><div><br></div><div><br></div><span>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/</span><span>update-bladerf-udev-rules? Did you edit the patch file directly?</span><div><br></div><div>I notice lines like <font color="#
000000">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.</font></div><div><span style="caret-color: rgb(0, 0, 0);
color: rgb(0, 0, 0);"><br></span></div><div><font color="#000000">I use quilt[2] for patching generally. It’s worth installing quilt and setting up a .quiltrc as the wiki page suggests. </font></div><div><span>You’ll be looking to push the
relevant patch on to the stack with `quilt push </span><span>update-bladerf-udev-rules`</span><span> 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.</span><span></span></div><div><br></div><span>Hopefully this helps - you’re welcome to reach out and ask for help any time!</span><span><br></span><span><br>Cheers</span><div><span>Hibby<br></span><span><br></span><span>[1]&
nbsp;</span><a href="
https://wiki.debian.org/sbuild">https://wiki.debian.org/sbuild</a><span><br></span><span>[2] <a href="
https://wiki.debian.org/UsingQuilt">https://wiki.debian.org/UsingQuilt</a></span><div><div>
--<br> Hibby<br> Debian Developer<br> Packet Radioist<br> MM0RFN<br>
</div>
<br><blockquote type="cite">On 26 Jul 2024, at 23:15, Martin Herren - HB9FXX <
hb9fxx@protonmail.com> wrote:<br><br class="Apple-interchange-newline">Hej,<br><br>I'm still stuck on this issue.<br><br>On Saturday, July 6th, 2024 at 12:39 PM, Daniele
Forsi <
iu5hkx@gmail.com> wrote:<br><br><blockquote type="cite">but in any case do open a merge<br>request as soon as you can, so other people can give feedback on a<br>specific change; otherwise if the discussion remains only in this<br>mailing
list we risk forgetting this issue.<br></blockquote><br>I just opened an MR at
https://salsa.debian.org/debian-hamradio-team/bladerf/-/merge_requests/1<br><br>I'm still stuck building the .deb. Seems to be a problem with building the firmware.<br>Hoped
this would be an easy and simple first contribution to a package. Underestimated the issue and overestimated my ability.<br><br>Still motivated to learn how to do it so maybe next time it will be easier.<br><br>73s de Martin HB9FXX</blockquote><br><br></
</div></body></html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)