This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------69bd14b0144b6038ab88661bc954abff
Content-Type: multipart/alternative;boundary=---------------------6af89baf5b18ac20e546eca9174f4fda

-----------------------6af89baf5b18ac20e546eca9174f4fda Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hello all,
Currently the udev rules for the BladeRFs (`SUBSYSTEM=="usb", ATTR{idVendor}=="2cf0", ATTR{idProduct}=="5250", ENV{ID_SOFTWARE_RADIO}="1", TAG+="uaccess"`) do two things:
- Set the ENV ID_SOFTWARE_RADIO to 1
- Add the uaccess TAG

The second action is redundant with the first, as the rule in `/usr/lib/udev/rules.d/70-uaccess.rules`: `ENV{ID_SOFTWARE_RADIO}=="?*", TAG+="uaccess"`, already adds the uaccess TAG when ID_SOFTWARE_RADIO is set to 1.

I see 3 problems:
- There is no way to give a remote user or an automated non-root script access to the device without overriding the udev rule
- The uaccess TAG only gives access if the device is already connected on login - It is not aligned with the udev rules for other SDR devices

Aligning the BladeRF2 rules to  how it is done for rtl-sdr or hackrf devices for example:

```
❯ diff -ruN /usr/lib/udev/rules.d/88-nuand-bladerf2.rules.orig /usr/lib/udev/rules.d/88-nuand-bladerf2.rules
--- /usr/lib/udev/rules.d/88-nuand-bladerf2.rules.orig 2024-07-02 22:29:58.082122124 +0200
+++ /usr/lib/udev/rules.d/88-nuand-bladerf2.rules 2024-07-02 22:30:11.938186142 +0200
@@ -1,2 +1,2 @@
 # Nuand bladeRF 2.0 micro
-SUBSYSTEM=="usb", ATTR{idVendor}=="2cf0", ATTR{idProduct}=="5250", ENV{ID_SOFTWARE_RADIO}="1", TAG+="uaccess"
+SUBSYSTEM=="usb", ATTR{idVendor}=="2cf0", ATTR{idProduct}=="5250", ENV{ID_SOFTWARE_RADIO}="1", MODE="0660", GROUP="plugdev"
```

Would solve my issues. It still works the same as before for the currently logged in user, in addition we can put any user into the plugdev group to give access.

I'd happily propose a merge request on https://salsa.debian.org/debian-hamradio-team/bladerf/-/blob/debian/debian/patches/update-bladerf-udev-rules?ref_type=heads
if I had access.
Also I expect this proposal might not make everyone happy so I prefer start the discussion here.


Thanks and best regards,

Martin Herren
-----------------------6af89baf5b18ac20e546eca9174f4fda
Conte

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------1e4559b4ced1386d801d54a4cc72070b Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

On Wednesday, July 3rd, 2024 at 3:32 PM, Daniele Forsi <[email protected]> wrote:

if you are referring to the 88-nuand-*.rules then I think that at this
time TAG+="uaccess"` is needed because those rules are executed after
the rule 70-uaccess.rules so you would also need to change the
filename of the rule

True. The hackrf and rtl-sdr rules are in the 60- range for the names.

What would be the cleanest option ? Rename the 88-nuand- rules to 60-nuand-xxx and align them with the other rules, or keep the name (the original name comes from upstream) and keep the `TAG+="uaccess"` rule and add the `MODE="0660", GROUP="plugdev"`
rule in addition ?

I'd say keeping the original name is cleaner.

I'm lurking on this list for some time, first time i try to bring a concrete suggestion so really a newbie.

you should be able to create an account on salsa, then fork the
repository and finally create a merge request from the new commits in
your fork.

Thanks, managed to create an account, it just got approved.

73s de Martin HB9FXX
-----------------------1e4559b4ced1386d801d54a4cc72070b--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmaFWCUJkPTeIqF3bHf4FiEEgYKeoMEDRL5Fcz/L9N4ioXds d/gAAEZ6AP9xj3hDbSpSnbWWMM5Av6nFrvh1yJ/Opk32D6jI8lxi0gEA7T8G sRA1njlvbJlZ+RiETquNIQrFnLEojSORI9mG2wc=
=I8tv
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------497b3dcb48fe469d81e46ca153348b3f Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hej,

Still on it.

On Saturday, July 6th, 2024 at 12:39 PM, Daniele Forsi <[email protected]> wrote:

I would drop the 88-* rules and add the 60-* rules with the changes
that you suggested and add a note to README.Debian

The issue with the bladerf being recognized/authorized by uaccess when already connected on login, but not when connected after or disconnected/reconnected was a little trickier than thought.
It is a bug that's already present in bookworm, maybe earlier (don't know when the uaccess mechanism was introduced).

Just adding the `TAG=uaccess` is not enough, there must be something else in the systemd provided udev rules in the 60-xxx to 88-xxx range that makes it work properly, not only `70-uaccess.rules`.

Renaming the rules to `60-nuand-xxx` makes it work well so it is the right way to go. Better than keep systemd udev rules aligned inside the bladerf's specific udev rules.

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.

Yes, have my work-in-progress commit on https://salsa.debian.org/MartinHerren/bladerf/-/compare/debian...udev_rules_update

Maybe better separate the commits in one fixing the udev rules (renaming of the files) and the one adding the plugdev group.

Currently mostly struggling to build the .deb package, guess i haven't found where and how i must extract the bladerf_0.2023.02.orig-drivers.tar.xz archive.

I'm continuing and will open an MR asap !

73s de Martin HB9FXX
-----------------------497b3dcb48fe469d81e46ca153348b3f--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmaJs+oJkPTeIqF3bHf4FiEEgYKeoMEDRL5Fcz/L9N4ioXds d/gAAB9PAQDSZ56wCOfKes5wCu4IVvLmPDd2cFRDHlMzQvrM9KMUjQEAoPCf HjB0tbwUXA3jDE1mfoXwk23Kp+oaD/QgpB8LTwo=
=nWDL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------15e89fff6f530a639a0f8d2b7c04878c Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hej,

I'm still stuck on this issue.

On Saturday, July 6th, 2024 at 12:39 PM, Daniele Forsi <[email protected]> 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
-----------------------15e89fff6f530a639a0f8d2b7c04878c--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmakH/gJkPTeIqF3bHf4FiEEgYKeoMEDRL5Fcz/L9N4ioXds d/gAAIJTAP0QN/n9X8frS0DnHuHrUUuqrVZ2AcowLBtaejKa9CbrSAD/Xc/s ElGZsEpvJL4JYjyrK0jK/7cPn3QkgNDArG/vIwM=
=FSUB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <[email protected]> wrote:

Hej,

I'm still stuck on this issue.

On Saturday, July 6th, 2024 at 12:39 PM, Daniele Forsi <[email protected]> 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.&nbsp;</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);">&nbsp;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 &lt;repo&gt;</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><

```&nbsp;</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&nbsp;<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>&nbsp;(for example) now happens quite a lot in&nbsp;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&nbsp;<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&nbsp;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.&nbsp;</font></div><div><span>You’ll be looking to push the
relevant patch on to the stack with `quilt push&nbsp;</span><span>update-bladerf-udev-rules`</span><span>&nbsp;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&nbsp;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]&nbsp;<a href="https://wiki.debian.org/UsingQuilt">https://wiki.debian.org/UsingQuilt</a></span><div><div>
--<br>&nbsp; Hibby<br>&nbsp;&nbsp;Debian Developer<br>&nbsp;&nbsp;Packet Radioist<br>&nbsp;&nbsp;MM0RFN<br>
</div>

<br><blockquote type="cite">On 26 Jul 2024, at 23:15, Martin Herren - HB9FXX &lt;[email protected]&gt; 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 &lt;[email protected]&gt; 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)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------9f67016aac6a02104ee177886d0bef1b
Content-Type: multipart/alternative;boundary=---------------------12b5f793218ae3dd70a11afc64f63f5e

-----------------------12b5f793218ae3dd70a11afc64f63f5e Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

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 <[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` (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!

CheersHibby

[1] https://wiki.debian.org/sbuild
[2] https://wiki.debian.org/UsingQuilt--
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

-----------------------12b5f793218ae3dd70a11afc64f63f5e
Content-Type: multipart/related;boundary=---------------------1a466164a13a1151d9390c6b6241af3d

-----------------------1a466164a13a1151d9390c6b6241af3d
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPkhpLDxicj48YnI+VGhhbmtzIERhdmUsIHdoYXQgYSBodWdlIGFtb3VudCBvZiBoZWxw IGFuZCBwb2ludGVycyB5b3UganVzdCBwcm92aWRlZC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAw LCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPlByZXZpb3Vz bHkgaSB0cmllZCB0byBidWlsZCB0aGUgLmRlYiB1c2luZyBgZGVidWlsZGAuIFdoaWxlIGl0IHN1 Y2NlZWRlZCB0byBwcm9kdWNlIGEgLmRzYyBpdCBmYWlsZWQgZ2VuZXJhdGluZyBhIC5kZWIgd2l0 aCB0aGUgc2FtZSBlcnJvciBhcyBpbiB0aGUgc2Fsc2EgY2kvY2QgcGlwZWxpbmUgYXMgaW4gPHNw YW4+PGEgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIg aHJlZj0iaHR0cHM6Ly9zYWxzYS5kZWJpYW4ub3JnL01hcnRpbkhlcnJlbi9ibGFkZXJmLy0vam9i cy82MDI5MTMwIj5odHRwczovL3NhbHNhLmRlYmlhbi5vcmcvTWFydGluSGVycmVuL2JsYWRlcmYv LS9qb2JzLzYwMjkxMzA8L2E+PC9zcGFuPi48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+SSBoYWQgYm90aCBvcmlnaW5h bCB0YXJiYWxscyBhdmFpbGFibGUuIFdpdGggc29tZSBtYW51YWwgaGFja2luZyBpIG1hbmFnZWQg dG8gZ2V0IGEgbGl0dGxlIGZ1cnRoZXIgd2l0aG91dCBzdWNjZWVkaW5nLjxicj48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Y29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7Ij5JIHRoZW4gZm9sbG93ZWQgeW91ciBwcm9jZWR1cmUgYW5kIG1h bmFnZWQgdG8gc2V0IHVwIGFuIGluaXRpYWwgdW5zdGFibGUgc2J1aWxkIGVudmlyb25tZW50IGFu ZCBpdCBtYW5hZ2VkIHRvIGJ1aWxkIGEgLmRlYiAhPGJyPk5vdyBpJ2xsIHZhbGlkYXRlIHRoZSAy IGlzc3VlcyBpJ20gdHJ5aW5nIHRvIHNvbHZlIHdpdGggbXkgTVIgYnkgaW5zdGFsbGluZyB0aGUg bmV3IC5kZWIuPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlllcywgdGhlIHBhdGNo IGhhcyBiZWVuIHNvbWV3aGF0IG1hbnVhbGx5IGdlbmVyYXRlZCBieSBtb2RpZnlpbmcgdGhlIC5v cmlnIGZvbGRlciBhbmQgZ2VuZXJhdGluZyBhIGRpZmYgb3V0IG9mIGl0IHRoYXQgaSB1c2VkIHRv IHVwZGF0ZSB0aGUgcGF0Y2guIE5leHQgd2lsbCBiZSB0byBsb29rIGF0IHF1aWx0IGFuZCBpJ2xs IHVwZGF0ZSBteSBNUi48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5UaGFua3MgYSBsb3Qs IHRoaXMgaGVscHMgYSBsb3QgdG8gZ28gZm9yd2FyZCB3aXRoIHRoaXMgTVIgITxicj48YnI+Q2hl ZXJzLDxicj48YnI+TWFydGluPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9InBy b3Rvbm1haWxfcXVvdGUiPgogICAgICAgIE9uIFNhdHVyZGF5LCBKdWx5IDI3dGgsIDIwMjQgYXQg MToxNCBBTSwgRGF2ZSBIaWJiZXJkICZsdDtoaWJieUBkZWJpYW4ub3JnJmd0OyB3cm90ZTo8YnI+ CiAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiIHR5cGU9ImNpdGUi PjxkaXY+SSBhbHdheXMgaGF2ZSBzYnVpbGRbMV0gc2V0IHVwIGFuZCBhbiB1bnN0YWJsZSBjaHJv b3QgZm9yIGJ1aWxkaW5nIHJlYWR5IHRvIGdvLiBTYnVpbGQgd2lsbCBhbHdheXMgZmFpbCBpZiB5 b3UgZG9u4oCZdCBoYXZlIHRoZSBvcmlnLnRhci5neiBtYXRjaGluZyB0aGUgbGV2ZWwgLSBJIG5v dGljZSB0aGlzIG9uZSByZWxpZXMgb24gdHdvIG9yaWdpbmFsIHRhcmJhbGxzOjwvZGl2PjxkaXY+ PGRpdj5gYGA8L2Rpdj48ZGl2PmRwa2ctc291cmNlOiBpbmZvOiB1bnBhY2tpbmcgYmxhZGVyZl8w LjIwMjMuMDIub3JpZy50YXIuZ3o8L2Rpdj48ZGl2PmRwa2ctc291cmNlOiBpbmZvOiB1bnBhY2tp bmcgYmxhZGVyZl8wLjIwMjMuMDIub3JpZy1kcml2ZXJzLnRhci54ejwvZGl2PjwvZGl2PjxkaXY+ YGBgPC9kaXY+PGRpdj5NYXliZSB0aGF04oCZcyBwYXJ0IG9mIHlvdXIgZmlybXdhcmUgaXNzdWU/ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHN0cm9uZ2x5IHJlY29tbWVuZCBwbGF5aW5nIHdp dGggc2J1aWxkLCBpdOKAmXMgYSBmYW50YXN0aWMgdG9vbC4gSeKAmXZlIGJlZW4gdXNpbmcgaXQg dG8gZG8gY3Jvc3MgYnVpbGRzIGZvciBkaWZmZXJlbnQgYXJjaGl0ZWN0dXJlcyBhbmQgYWxsIGtp bmRzIG9mIGZ1bmt5IHN0dWZmIHRoaXMgeWVhci4gUmVjZW50bHkgSSBsZWFybmVkIHlvdSBjYW4g ZmVlZCBpdCB0aGUgdXJsIHRvIGEgLmRzYyBhbmQgaXQgd2lsbCBkb3dubG9hZCBldmVyeXRoaW5n IGZyb20gdGhlIHJlbW90ZSBzZXJ2ZXIgcmVxdWlyZWQgdG8gYnVpbGQgdGhhdCBwYWNrYWdlISBg c2J1aWxkJm5ic3A7PGEgaHJlZj0iaHR0cDovL2RlYi5kZWJpYW4ub3JnL2RlYmlhbi9wb29sL21h aW4vcS9xc3N0di9xc3N0dl85LjUuOC0zLmRzYyU2MCIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93 IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RlYi5kZWJpYW4ub3JnL2RlYmlhbi9w b29sL21haW4vcS9xc3N0di9xc3N0dl85LjUuOC0zLmRzY2A8L2E+Jm5ic3A7KGZvciBleGFtcGxl KSBub3cgaGFwcGVucyBxdWl0ZSBhIGxvdCBpbiZuYnNwO215IGhvdXNlITwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxzcGFuPk9uZSB0aGluZyBJIG5vdGljZSBhZnRlciBhIHF1 aWNrIGxvb2sgYXQgdGhlIGNvbW1pdHMgaXMgdGhhdCB5b3VyIHBhdGNoIGZvcm1hdCBsb29rcyBv ZGQgdG8gbWUgLSBob3cgZGlkIHlvdSBnZW5lcmF0ZSB1cGRhdGVzIHRvIGQvcGF0Y2hlcy88L3Nw YW4+PHNwYW4+dXBkYXRlLWJsYWRlcmYtdWRldi1ydWxlcz8gRGlkIHlvdSBlZGl0IHRoZSBwYXRj aCBmaWxlIGRpcmVjdGx5Pzwvc3Bhbj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkkgbm90aWNlIGxpbmVz IGxpa2UmbmJzcDs8Zm9udCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPmRpZmYgLS1naXQg YS9ob3N0L21pc2MvdWRldi82MC1udWFuZC1ibGFkZXJmMS5ydWxlcy5pbiBiL2hvc3QvbWlzYy91 ZGV2LzYwLW51YW5kLWJsYWRlcmYxLnJ1bGVzLmluIGFyZSBhIGJpdCB1bnVzdWFsIHRvIG15IGV5 ZXMgKHNvbWVvbmUgZWxzZSwgb2YgY291cnNlLCBtYXkgY29ycmVjdCBtZSAtIHRoZXJl4oCZcyBt YW55IHdheXMgdG8gaW50ZXJhY3Qgd2l0aCZuYnNwO0RlYmlhbiEpLiBJdCBjbGVhcmx5IHN0aWxs IGJ1aWxkcywgc28gcHJlc3VtYWJseSBpdOKAmXMganVzdCBhIHN0eWxlIGRpZmZlcmVuY2UhIEkg dGVuZCB0byBzaGlwIHVwc3RyZWFt4oCZcyBjb2RlIGluIG15IHJlcG9zLCBub3QganVzdCB0aGUg RGViaWFuIGZvbGRlciBzbyB0aGVyZSBtYXkgYmUgYSBwYWNraW5nIHN0eWxlIGRpZmZlcmVuY2Ug YmV0d2VlbiBtYWl0IGFuZCBJIHRoZXJlIHRvby48L2ZvbnQ+PC9kaXY+PGRpdj48c3BhbiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPjxicj48 L3NwYW4+PC9kaXY+PGRpdj48Zm9udCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPkkgdXNl IHF1aWx0WzJdIGZvciBwYXRjaGluZyBnZW5lcmFsbHkuIEl04oCZcyB3b3J0aCBpbnN0YWxsaW5n IHF1aWx0IGFuZCBzZXR0aW5nIHVwIGEgLnF1aWx0cmMgYXMgdGhlIHdpa2kgcGFnZSBzdWdnZXN0 cy4mbmJzcDs8L2ZvbnQ+PC9kaXY+PGRpdj48c3Bhbj5Zb3XigJlsbCBiZSBsb29raW5nIHRvIHB1 c2ggdGhlIHJlbGV2YW50IHBhdGNoIG9uIHRvIHRoZSBzdGFjayB3aXRoIGBxdWlsdCBwdXNoJm5i c3A7PC9zcGFuPjxzcGFuPnVwZGF0ZS1ibGFkZXJmLXVkZXYtcnVsZXNgPC9zcGFuPjxzcGFuPiZu YnNwO21ha2UgY2hhbmdlcyBkaXJlY3RseSB0byB0aGUgY29kZSwgcnVuIGBxdWlsdCByZWZyZXNo YCBhbmQgdGhlbiBgcXVpbHQgcG9wIC1hYCB0byBwdWxsIHRoZSBwYXRjaGVzIG9mZiB0aGUgc3Rh Y2ssIGJ1dCBpdCBhc3N1bWVzIHRoZSBjb2RlIGlzIGFkamFjZW50IHRvIHRoZSBmb2xkZXIuPC9z cGFuPjxzcGFuPjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48c3Bhbj5Ib3BlZnVsbHkmbmJz cDt0aGlzIGhlbHBzIC0geW914oCZcmUgd2VsY29tZSB0byByZWFjaCBvdXQgYW5kIGFzayBmb3Ig aGVscCBhbnkgdGltZSE8L3NwYW4+PHNwYW4+PGJyPjwvc3Bhbj48c3Bhbj48YnI+Q2hlZXJzPC9z cGFuPjxkaXY+PHNwYW4+SGliYnk8YnI+PC9zcGFuPjxzcGFuPjxicj48L3NwYW4+PHNwYW4+WzFd Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd2lraS5kZWJpYW4ub3JnL3NidWlsZCIgcmVs PSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 aWtpLmRlYmlhbi5vcmcvc2J1aWxkPC9hPjxzcGFuPjxicj48L3NwYW4+PHNwYW4+WzJdJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93aWtpLmRlYmlhbi5vcmcvVXNpbmdRdWlsdCIgcmVsPSJub3JlZmVy cmVyIG5vZm9sbG93IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93aWtpLmRlYmlh bi5vcmcvVXNpbmdRdWlsdDwvYT48L3NwYW4+PGRpdj48ZGl2PgotLTxicj4mbmJzcDsgSGliYnk8 YnI+Jm5ic3A7Jm5ic3A7RGViaWFuIERldmVsb3Blcjxicj4mbmJzcDsmbmJzcDtQYWNrZXQgUmFk aW9pc3Q8YnI+Jm5ic3A7Jm5ic3A7TU0wUkZOCiAgICA8L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9kaXY+
-----------------------1a466164a13a1151d9390c6b6241af3d-- -----------------------12b5f793218ae3dd70a11afc64f63f5e-- -----------------------9f67016aac6a02104ee177886d0bef1b--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmamyrYJkPTeIqF3bHf4FiEEgYKeoMEDRL5Fcz/L9N4ioXds d/gAABqZAQDsZufSs6etopXfAjz9oI9TrWGegpBu6ken72osyqQiHAD+J3mF 9ni/UB/hSNHPf09Bs/wPLaHC6clrYvbACrzj9gY=
=7LEF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------c79ba95fbb1a64bc96c7817fffe5a058
Content-Type: multipart/alternative;boundary=---------------------a1eb703dc4e33d4024f38202a7faebd5

-----------------------a1eb703dc4e33d4024f38202a7faebd5 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hi all,

Thanks to all the help I received so far.

I updated my MR at https://salsa.debian.org/debian-hamradio-team/bladerf/-/merge_requests/1 as i managed to build and test the .deb using sbuild and now used quilt to adapt the udev patch.

The 2 questions now are:

- As the issue with udev uaccess could be considered a bug, should i still open an bug report ? I can confirm the bug is already present in Bookworm
- I don't understand the `dpkg-divert` stuff, from my understanding as there are now new udev rules files with new names, all the dpkg-divert postinstall/preremove stuff could now be removed ?




Thanks and best regards,

/Martin
On Monday, July 29th, 2024 at 12:48 AM, Martin Herren - HB9FXX <[email protected]> wrote:

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 <[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` (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!

CheersHibby

[1] https://wiki.debian.org/sbuild [2] https://wiki.debian.org/UsingQuilt--
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

-----------------------a1eb703dc4e33d4024f38202a7faebd5
Content-Type: multipart/related;boundary=---------------------48ef0250896dba134fc21f5f038b38df

-----------------------48ef0250896dba134fc21f5f038b38df
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPkhpIGFsbCw8YnI+PGJyPlRoYW5rcyB0byBhbGwgdGhlIGhlbHAgSSByZWNlaXZlZCBz byBmYXIuPGJyPjxicj5JIHVwZGF0ZWQgbXkgTVIgYXQgPHNwYW4+PGEgdGFyZ2V0PSJfYmxhbmsi IHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgaHJlZj0iaHR0cHM6Ly9zYWxzYS5k ZWJpYW4ub3JnL2RlYmlhbi1oYW1yYWRpby10ZWFtL2JsYWRlcmYvLS9tZXJnZV9yZXF1ZXN0cy8x Ij5odHRwczovL3NhbHNhLmRlYmlhbi5vcmcvZGViaWFuLWhhbXJhZGlvLXRlYW0vYmxhZGVyZi8t L21lcmdlX3JlcXVlc3RzLzE8L2E+PC9zcGFuPiBhcyBpIG1hbmFnZWQgdG8gYnVpbGQgYW5kIHRl c3QgdGhlIC5kZWIgdXNpbmcgc2J1aWxkIGFuZCBub3cgdXNlZCBxdWlsdCB0byBhZGFwdCB0aGUg dWRldiBwYXRjaC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDAp OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5UaGUgMiBxdWVzdGlvbnMg bm93IGFyZTo8YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjx1bCBkYXRhLWVkaXRpbmctaW5mbz0ieyZxdW90O29y ZGVyZWRTdHlsZVR5cGUmcXVvdDs6MSwmcXVvdDt1bm9yZGVyZWRTdHlsZVR5cGUmcXVvdDs6Mn0i PjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBlOiAmcXVvdDstICZxdW90OzsiPjxzcGFuPkFzIHRo ZSBpc3N1ZSB3aXRoIHVkZXYgdWFjY2VzcyBjb3VsZCBiZSBjb25zaWRlcmVkIGEgYnVnLCBzaG91 bGQgaSBzdGlsbCBvcGVuIGFuIGJ1ZyByZXBvcnQgPyBJIGNhbiBjb25maXJtIHRoZSBidWcgaXMg YWxyZWFkeSBwcmVzZW50IGluIEJvb2t3b3JtPC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0 eWxlLXR5cGU6ICZxdW90Oy0gJnF1b3Q7OyI+PHNwYW4+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSBg ZHBrZy1kaXZlcnRgIHN0dWZmLCBmcm9tIG15IHVuZGVyc3RhbmRpbmcgYXMgdGhlcmUgYXJlIG5v dyBuZXcgdWRldiBydWxlcyBmaWxlcyB3aXRoIG5ldyBuYW1lcywgYWxsIHRoZSBkcGtnLWRpdmVy dCBwb3N0aW5zdGFsbC9wcmVyZW1vdmUgc3R1ZmYgY291bGQgbm93IGJlIHJlbW92ZWQgPzxicj48 L3NwYW4+PC9saT48L3VsPjxkaXY+PGJyPlRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLDxicj48YnI+ L01hcnRpbjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj4KICAg ICAgICBPbiBNb25kYXksIEp1bHkgMjl0aCwgMjAyNCBhdCAxMjo0OCBBTSwgTWFydGluIEhlcnJl biAtIEhCOUZYWCAmbHQ7aGI5Znh4QHByb3Rvbm1haWwuY29tJmd0OyB3cm90ZTo8YnI+CiAgICAg ICAgPGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiIHR5cGU9ImNpdGUiPgogICAg ICAgICAgICA8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+SGksPGJyPjxicj5UaGFua3MgRGF2ZSwgd2hhdCBhIGh1Z2UgYW1vdW50 IG9mIGhlbHAgYW5kIHBvaW50ZXJzIHlvdSBqdXN0IHByb3ZpZGVkLjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjog cmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+ UHJldmlvdXNseSBpIHRyaWVkIHRvIGJ1aWxkIHRoZSAuZGViIHVzaW5nIGBkZWJ1aWxkYC4gV2hp bGUgaXQgc3VjY2VlZGVkIHRvIHByb2R1Y2UgYSAuZHNjIGl0IGZhaWxlZCBnZW5lcmF0aW5nIGEg LmRlYiB3aXRoIHRoZSBzYW1lIGVycm9yIGFzIGluIHRoZSBzYWxzYSBjaS9jZCBwaXBlbGluZSBh cyBpbiA8c3Bhbj48YSBocmVmPSJodHRwczovL3NhbHNhLmRlYmlhbi5vcmcvTWFydGluSGVycmVu L2JsYWRlcmYvLS9qb2JzLzYwMjkxMzAiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5l ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vc2Fsc2EuZGViaWFuLm9yZy9NYXJ0aW5IZXJyZW4v YmxhZGVyZi8tL2pvYnMvNjAyOTEzMDwvYT48L3NwYW4+LjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAs IDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5JIGhhZCBib3Ro IG9yaWdpbmFsIHRhcmJhbGxzIGF2YWlsYWJsZS4gV2l0aCBzb21lIG1hbnVhbCBoYWNraW5nIGkg bWFuYWdlZCB0byBnZXQgYSBsaXR0bGUgZnVydGhlciB3aXRob3V0IHN1Y2NlZWRpbmcuPGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkkgdGhlbiBmb2xsb3dlZCB5b3VyIHByb2NlZHVy ZSBhbmQgbWFuYWdlZCB0byBzZXQgdXAgYW4gaW5pdGlhbCB1bnN0YWJsZSBzYnVpbGQgZW52aXJv bm1lbnQgYW5kIGl0IG1hbmFnZWQgdG8gYnVpbGQgYSAuZGViICE8YnI+Tm93IGknbGwgdmFsaWRh dGUgdGhlIDIgaXNzdWVzIGknbSB0cnlpbmcgdG8gc29sdmUgd2l0aCBteSBNUiBieSBpbnN0YWxs aW5nIHRoZSBuZXcgLmRlYi48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+WWVzLCB0 aGUgcGF0Y2ggaGFzIGJlZW4gc29tZXdoYXQgbWFudWFsbHkgZ2VuZXJhdGVkIGJ5IG1vZGlmeWlu ZyB0aGUgLm9yaWcgZm9sZGVyIGFuZCBnZW5lcmF0aW5nIGEgZGlmZiBvdXQgb2YgaXQgdGhhdCBp IHVzZWQgdG8gdXBkYXRlIHRoZSBwYXRjaC4gTmV4dCB3aWxsIGJlIHRvIGxvb2sgYXQgcXVpbHQg YW5kIGknbGwgdXBkYXRlIG15IE1SLjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlRoYW5r cyBhIGxvdCwgdGhpcyBoZWxwcyBhIGxvdCB0byBnbyBmb3J3YXJkIHdpdGggdGhpcyBNUiAhPGJy Pjxicj5DaGVlcnMsPGJyPjxicj5NYXJ0aW48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBj bGFzcz0icHJvdG9ubWFpbF9xdW90ZSI+CiAgICAgICAgT24gU2F0dXJkYXksIEp1bHkgMjd0aCwg MjAyNCBhdCAxOjE0IEFNLCBEYXZlIEhpYmJlcmQgJmx0O2hpYmJ5QGRlYmlhbi5vcmcmZ3Q7IHdy b3RlOjxicj4KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0icHJvdG9ubWFp bF9xdW90ZSI+PGRpdj5JIGFsd2F5cyBoYXZlIHNidWlsZFsxXSBzZXQgdXAgYW5kIGFuIHVuc3Rh YmxlIGNocm9vdCBmb3IgYnVpbGRpbmcgcmVhZHkgdG8gZ28uIFNidWlsZCB3aWxsIGFsd2F5cyBm YWlsIGlmIHlvdSBkb27igJl0IGhhdmUgdGhlIG9yaWcudGFyLmd6IG1hdGNoaW5nIHRoZSBsZXZl bCAtIEkgbm90aWNlIHRoaXMgb25lIHJlbGllcyBvbiB0d28gb3JpZ2luYWwgdGFyYmFsbHM6PC9k aXY+PGRpdj48ZGl2PmBgYDwvZGl2PjxkaXY+ZHBrZy1zb3VyY2U6IGluZm86IHVucGFja2luZyBi bGFkZXJmXzAuMjAyMy4wMi5vcmlnLnRhci5nejwvZGl2PjxkaXY+ZHBrZy1zb3VyY2U6IGluZm86 IHVucGFja2luZyBibGFkZXJmXzAuMjAyMy4wMi5vcmlnLWRyaXZlcnMudGFyLnh6PC9kaXY+PC9k aXY+PGRpdj5gYGA8L2Rpdj48ZGl2Pk1heWJlIHRoYXTigJlzIHBhcnQgb2YgeW91ciBmaXJtd2Fy ZSBpc3N1ZT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkkgc3Ryb25nbHkgcmVjb21tZW5kIHBs YXlpbmcgd2l0aCBzYnVpbGQsIGl04oCZcyBhIGZhbnRhc3RpYyB0b29sLiBJ4oCZdmUgYmVlbiB1 c2luZyBpdCB0byBkbyBjcm9zcyBidWlsZHMgZm9yIGRpZmZlcmVudCBhcmNoaXRlY3R1cmVzIGFu ZCBhbGwga2luZHMgb2YgZnVua3kgc3R1ZmYgdGhpcyB5ZWFyLiBSZWNlbnRseSBJIGxlYXJuZWQg eW91IGNhbiBmZWVkIGl0IHRoZSB1cmwgdG8gYSAuZHNjIGFuZCBpdCB3aWxsIGRvd25sb2FkIGV2 ZXJ5dGhpbmcgZnJvbSB0aGUgcmVtb3RlIHNlcnZlciByZXF1aXJlZCB0byBidWlsZCB0aGF0IHBh Y2thZ2UhIGBzYnVpbGQmbmJzcDs8YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5v Zm9sbG93IG5vb3BlbmVyIiBocmVmPSJodHRwOi8vZGViLmRlYmlhbi5vcmcvZGViaWFuL3Bvb2wv bWFpbi9xL3Fzc3R2L3Fzc3R2XzkuNS44LTMuZHNjJTYwIj5odHRwOi8vZGViLmRlYmlhbi5vcmcv ZGViaWFuL3Bvb2wvbWFpbi9xL3Fzc3R2L3Fzc3R2XzkuNS44LTMuZHNjYDwvYT4mbmJzcDsoZm9y IGV4YW1wbGUpIG5vdyBoYXBwZW5zIHF1aXRlIGEgbG90IGluJm5ic3A7bXkgaG91c2UhPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PHNwYW4+T25lIHRoaW5nIEkgbm90aWNlIGFm dGVyIGEgcXVpY2sgbG9vayBhdCB0aGUgY29tbWl0cyBpcyB0aGF0IHlvdXIgcGF0Y2ggZm9ybWF0 IGxvb2tzIG9kZCB0byBtZSAtIGhvdyBkaWQgeW91IGdlbmVyYXRlIHVwZGF0ZXMgdG8gZC9wYXRj aGVzLzwvc3Bhbj48c3Bhbj51cGRhdGUtYmxhZGVyZi11ZGV2LXJ1bGVzPyBEaWQgeW91IGVkaXQg dGhlIHBhdGNoIGZpbGUgZGlyZWN0bHk/PC9zcGFuPjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBub3Rp Y2UgbGluZXMgbGlrZSZuYnNwOzxmb250IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+ZGlm ZiAtLWdpdCBhL2hvc3QvbWlzYy91ZGV2LzYwLW51YW5kLWJsYWRlcmYxLnJ1bGVzLmluIGIvaG9z dC9taXNjL3VkZXYvNjAtbnVhbmQtYmxhZGVyZjEucnVsZXMuaW4gYXJlIGEgYml0IHVudXN1YWwg dG8gbXkgZXllcyAoc29tZW9uZSBlbHNlLCBvZiBjb3Vyc2UsIG1heSBjb3JyZWN0IG1lIC0gdGhl cmXigJlzIG1hbnkgd2F5cyB0byBpbnRlcmFjdCB3aXRoJm5ic3A7RGViaWFuISkuIEl0IGNsZWFy bHkgc3RpbGwgYnVpbGRzLCBzbyBwcmVzdW1hYmx5IGl04oCZcyBqdXN0IGEgc3R5bGUgZGlmZmVy ZW5jZSEgSSB0ZW5kIHRvIHNoaXAgdXBzdHJlYW3igJlzIGNvZGUgaW4gbXkgcmVwb3MsIG5vdCBq dXN0IHRoZSBEZWJpYW4gZm9sZGVyIHNvIHRoZXJlIG1heSBiZSBhIHBhY2tpbmcgc3R5bGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIG1haXQgYW5kIEkgdGhlcmUgdG9vLjwvZm9udD48L2Rpdj48ZGl2Pjxz cGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDAp OyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2Pjxmb250IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyI+SSB1c2UgcXVpbHRbMl0gZm9yIHBhdGNoaW5nIGdlbmVyYWxseS4gSXTigJlzIHdvcnRoIGlu c3RhbGxpbmcgcXVpbHQgYW5kIHNldHRpbmcgdXAgYSAucXVpbHRyYyBhcyB0aGUgd2lraSBwYWdl IHN1Z2dlc3RzLiZuYnNwOzwvZm9udD48L2Rpdj48ZGl2PjxzcGFuPllvdeKAmWxsIGJlIGxvb2tp bmcgdG8gcHVzaCB0aGUgcmVsZXZhbnQgcGF0Y2ggb24gdG8gdGhlIHN0YWNrIHdpdGggYHF1aWx0 IHB1c2gmbmJzcDs8L3NwYW4+PHNwYW4+dXBkYXRlLWJsYWRlcmYtdWRldi1ydWxlc2A8L3NwYW4+ PHNwYW4+Jm5ic3A7bWFrZSBjaGFuZ2VzIGRpcmVjdGx5IHRvIHRoZSBjb2RlLCBydW4gYHF1aWx0 IHJlZnJlc2hgIGFuZCB0aGVuIGBxdWlsdCBwb3AgLWFgIHRvIHB1bGwgdGhlIHBhdGNoZXMgb2Zm IHRoZSBzdGFjaywgYnV0IGl0IGFzc3VtZXMgdGhlIGNvZGUgaXMgYWRqYWNlbnQgdG8gdGhlIGZv bGRlci48L3NwYW4+PHNwYW4+PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxzcGFuPkhvcGVm dWxseSZuYnNwO3RoaXMgaGVscHMgLSB5b3XigJlyZSB3ZWxjb21lIHRvIHJlYWNoIG91dCBhbmQg YXNrIGZvciBoZWxwIGFueSB0aW1lITwvc3Bhbj48c3Bhbj48YnI+PC9zcGFuPjxzcGFuPjxicj5D aGVlcnM8L3NwYW4+PGRpdj48c3Bhbj5IaWJieTxicj48L3NwYW4+PHNwYW4+PGJyPjwvc3Bhbj48 c3Bhbj5bMV0mbmJzcDs8L3NwYW4+PGEgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciBu b2ZvbGxvdyBub29wZW5lciIgaHJlZj0iaHR0cHM6Ly93aWtpLmRlYmlhbi5vcmcvc2J1aWxkIj5o dHRwczovL3dpa2kuZGViaWFuLm9yZy9zYnVpbGQ8L2E+PHNwYW4+PGJyPjwvc3Bhbj48c3Bhbj5b Ml0mbmJzcDs8YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3Bl bmVyIiBocmVmPSJodHRwczovL3dpa2kuZGViaWFuLm9yZy9Vc2luZ1F1aWx0Ij5odHRwczovL3dp a2kuZGViaWFuLm9yZy9Vc2luZ1F1aWx0PC9hPjwvc3Bhbj48ZGl2PjxkaXY+Ci0tPGJyPiZuYnNw OyBIaWJieTxicj4mbmJzcDsmbmJzcDtEZWJpYW4gRGV2ZWxvcGVyPGJyPiZuYnNwOyZuYnNwO1Bh Y2tldCBSYWRpb2lzdDxicj4mbmJzcDsmbmJzcDtNTTBSRk4KICAgIDwvZGl2PjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48L2Rpdj4KICAgICAgICA8L2Jsb2NrcXVvdGU+PGJyPgogICAgPC9kaXY+ -----------------------48ef0250896dba134fc21f5f038b38df-- -----------------------a1eb703dc4e33d4024f38202a7faebd5-- -----------------------c79ba95fbb1a64bc96c7817fffe5a058--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmave8MJkPTeIqF3bHf4FiEEgYKeoMEDRL5Fcz/L9N4ioXds d/gAAOmGAQCKsSp/JHrOSW1VFmM70RAmcOuKPLLkjkw70sqbjpdtYQD/e3IZ iQrv6bAYgivci08hjbXgGyHoRNNelM1GphbABwY=
=00cs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--064c787f0a3f4404bb57f6db0f2c9947
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I saw the discussion on salsa!

I'm sure there's plenty of bugs to dig into at https://udd.debian.org/dmd/?email1=debian-hams%40lists.debian.org&email2=&email3=&packages=&ignpackages=&format=html#todo

I know at least uronode is struggling on some 32bit architectures, there are some ftbfs issues, there are some upstream updates outstanding and more!

Cheers
H

--
Hibby
Debian Developer
Packet Radioist
MM0RFN

On Mon, 9 Sep 2024, at 9:09 PM, Martin Herren - HB9FXX wrote:

Hi Dave,

Thanks for your answer.

Things have changed a little now. A new .deb package has been released with the new upstream release and thus my MR is now in conflict.

As suggested by Mait it is probably better to try to open my MR against upstream directly.
If that doesn't work there is still time to adapt my MR again.

So i'll open an new MR directly to upstream as this makes sense and the issue can also affect other distributions.

I'd like to thanks all of you that helped and guided my over the last 2 months, i learned a lot, including about sbuild and quilt and the packaging process in general. So the time was not waisted and i hope to find other opportunities to contribute to

Debian !

Cheers,

Martin - HB9FXX

On Tuesday, August 27th, 2024 at 12:51 PM, Dave Hibberd <[email protected]> wrote:

Hi Martin!

Thing

From: [email protected]

Martin Herren - HB9FXX wrote:

Currently the udev rules for the BladeRFs (`SUBSYSTEM=="usb", ATTR{idVendor}=="2cf0", ATTR{idProduct}=="5250", ENV{ID_SOFTWARE_RADIO}="1", TAG+="uaccess"`) do two things:
- Set the ENV ID_SOFTWARE_RADIO to 1
- Add the uaccess TAG

The second action is redundant with the first, as the rule in `/usr/lib/udev/rules.d/70-uaccess.rules`: `ENV{ID_SOFTWARE_RADIO}=="?*", TAG+="uaccess"`, already adds the uaccess TAG when ID_SOFTWARE_RADIO is set to 1.

if you are referring to the 88-nuand-*.rules then I think that at this
time TAG+="uaccess"` is needed because those rules are executed after
the rule 70-uaccess.rules so you would also need to change the
filename of the rule

I'd happily propose a merge request on https://salsa.debian.org/debian-hamradio-team/bladerf/-/blob/debian/debian/patches/update-bladerf-udev-rules?ref_type=heads
if I had access.

you should be able to create an account on salsa, then fork the
repository and finally create a merge request from the new commits in
your fork.
If it doesn't work, I can do that for you if you can send a git
format-patch preferably to this mailing list so others can check it,
or privately to me.


--
73 de IU5HKX Daniele

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

Martin Herren - HB9FXX wrote:

What would be the cleanest option ? Rename the 88-nuand- rules to 60-nuand-xxx and align them with the other rules,
or keep the name (the original name comes from upstream) and keep the `TAG+="uaccess"` rule and
add the `MODE="0660", GROUP="plugdev"` rule in addition ?

I'd say keeping the original name is cleaner.

maintaining a patch requires the same effort in both cases, but having

I would drop the 88-* rules and add the 60-* rules with the changes
that you suggested and add a note to README.Debian

If you think differently, fine, 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.
At any time you can amend an open merge request, even doing "git push
--force" if you really want to forget something (a rare case where
--force can be useful on a public repository).

--
73 de IU5HKX Daniele

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)