• Re: [libbladerf2] Change udev rule to add plugdev group (1/2)

    From Martin Herren - HB9FXX@1:229/2 to Dave Hibberd on Mon Sep 9 22:30:01 2024
    From: [email protected]

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

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

    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!


    Things have been a little hectic here but this is still on my radar to look at!


    Aa a quick reply -


    For filing a bug - if you feel it's not desired behaviour, go ahead and file a bug. The bugtracker is a default method of interacting and discussing things with each other in Debian, so don't be shy. The worst that happens is it gets reassigned, merged
    with another or closed after discussion.


    For the dpkg-divert, it's all fairly recent and tied to the usrmerge change, so it's probably best to look to mait for guidance on that. As you've changed the name of the rules, something will need to change at least!


    Cheers,


    -- 
      Hibby
      MM0RFN


    On Sun, 4 Aug 2024, at 2:02 PM, Martin Herren - HB9FXX wrote:


    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?



    [continued in next message]

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