1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1109233: kpipewire: bad backport of 0ac4aa41

    From =?UTF-8?B?QXVyw6lsaWVu?= COUDERC@21:1/5 to All on Mon Jul 14 23:30:02 2025
    Dear Antonio,

    Le lundi 14 juillet 2025, 05:16:52 heure d’été d’Europe centrale Antonio Russo a écrit :
    Control: reassign -1 src:kpipewire
    Control: retitle -1 kpipewire: bad backport of 0ac4aa41

    After more investigation of the issue, it seems clear to me that the
    backport of 0ac4aa41 was incomplete. Looking at the parent of that
    commit, the role of the started() signal changed, and the spawned
    threads are quite different.

    Hmm yes, you seem to be right although I cannot make sense of how that happened.
    I’m using some automated scripts to pick the changes from upstream’s gitlab and I have a hard time figuring out how I can end-up with a commit message referencing an upstream sha1 and the contents not matching…

    Anyway I’ve reimported said upstream commit and rebuilt the packages.

    Could you please try the packages here [1] and confirm it fixes your issue before I upload ?
    Do verify that the changes file has my signature and that the checksums for the deb match.

    I think it’s a kind of change we can get into trixie.


    [1] https://people.debian.org/~coucouf/kpipewire_6.3.6-1/


    Thanks !
    --
    Aurléine

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?QXVyw6lsaWVu?= COUDERC@21:1/5 to All on Tue Jul 15 14:10:01 2025
    Le mardi 15 juillet 2025, 08:27:44 heure d’été d’Europe centrale Antonio Russo a écrit :
    On 2025-07-14 15:18, Aurélien COUDERC wrote:

    Could you please try the packages here [1] and confirm it fixes your issue before I upload ?
    Do verify that the changes file has my signature and that the checksums for the deb match.

    I think it’s a kind of change we can get into trixie.


    [1] https://people.debian.org/~coucouf/kpipewire_6.3.6-1/

    Thanks for looking at this. Unfortunately, the packages there do not
    resolve the issue for me.

    I think I’ve found where the issue is, in the location where
    Q_EMIT started();
    needs to be inserted at the end of the setupStream() method and not as it was previously appearing for some reason at the end of the deactivate() method. Maybe an incorrect update of the patch on my side.
    Could you give it another try. (The new packages have the same name and are in the same location.)

    The previous message I sent contains a modified patch that minimally addresses the issue.

    Yes, but it wasn’t immediately clear to me how close your proposal was to the upstream source, and I want to mirror upstream commits as much as possible.


    Thanks for your help,
    --
    Aurélien

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