Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x

[Dylan Aïssi]

Hello,

Le dim. 31 mars 2024 à 15:41, Andreas Henriksson  a écrit :
>
> PLEASE NOTIFY US WHEN YOU UPLOAD wireplumber 0.5.x to UNSTABLE, so we
> can do a coordinated transition (uploading asahi-audio 2.x to unstable).
> (You might also want to contact release-team to set up a transition
> tracker, even if this might not be a normal transition where binNMUs are
> useful etc.)
>

The autogenerated tracker for transition was removed (don't know why).
I asked for a new one (#1070043). The only other package (waybar)
affected by this transition has now a compatible version in unstable.
So, I think except the t64 transition nothing else is blocking, I am
waiting the green light from the release team for next step, and I
will ping here before uploading wireplumber 0.5 in unstable.

Best regards,
Dylan

Bug#1060785: libspa-audioconvert: Crash sometimes due to misaligned load to YMM register.

[Dylan Aïssi]

Hello,

Le lun. 15 janv. 2024 à 22:00, K.Ohta  a écrit :
>
> I forwarded to upstream.
> See, https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3790 .
> Thank you for your suggestion.

This bug is marked as fixed upstream, so can we close it here as well
or is it still an issue?

Best regards,
Dylan

Bug#1070043: transition: wireplumber 0.5

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:wireplumber

Dear Release Team,

Please schedule a transition slot for wireplumber 0.5.

The auto-generated ben tracker was deleted (not sure why),
but here is a new ben file:

Ben file:
-
title = "wireplumber-0.5";
is_affected = .build-depends ~ /libwireplumber-0.4-dev|libwireplumber-0.5-dev/;
is_good = .depends ~ "libwireplumber-0.5-0";
is_bad = .depends ~ "libwireplumber-0.4-0";
-

I identified two packages affected by this transition:
- waybar, but last upload has mistakenly dropped the support of
  wireplumber (#1070041), but anyway the version in unstable is compatible
  with wireplumber 0.5.
- asahi-audio which only provides config for wireplumber, but the new
  version compatible with wireplumber is already in experimental (#1067660).

Thanks.

Best regards,
Dylan

Bug#1070041: waybar: wireplumber support disabled in 0.10.2-1

[Dylan Aïssi]

Source: waybar
Version: 0.10.2-1
Severity: important

Hello,

Since 0.10.2-1 the support of wireplumber in waybar got disabled.

Indeed, since 0.10.1 waybar requires wirpelumber >= 0.5 whereas
previous versions are only compatible with wireplumber <= 0.4.X.
So, the current dependency on libwireplumber-0.4-dev has no effect
as confirmed by its build log:

Run-time dependency wireplumber-0.5 found: NO (tried pkgconfig and cmake)

Currently, wireplumber 0.5 is only available in experimental waiting for his
transition slot. Could you either drop the dependency on libwireplumber-0.4-dev
in unstable/testing or do an upload to experimental with a build-dep
on libwireplumber-0.5-dev?

I will fill a bug for the wireplumber-0.5 transition and will mark this bug
as blocker to make thing easier for release team.

Thank you.

Best,
Dylan

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Dylan Aïssi]

Hi,

Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> Meanwhile, I pinged upstream to ask for their opinion about
> that to make sure we are not going to break stuff.

launcher-libseat has an higher priority than launcher-logind,
that means enabling launcher-libseat will change the default
behavior for all users. Although this should be harmless
because libseat should contact logind, it doesn't work for
whatever reason. I just tested with a VM without a
graphical login. I can launch weston 10.0.1-1, but
it fails with 10.0.1-1+deb12u1. So, I guess it would
require more changes unsuitable for bookworm :-(

Best,
Dylan

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Dylan Aïssi]

Hi Charles,

Sorry for not answering before.

Le jeu. 4 avr. 2024 à 16:04, Carlos Henrique Lima Melara
 a écrit :
>
> > So, I have good and bad news, but I guess they are mostly good.
> >
> > THe bad news first, when I was checking the upstream commits, I saw some
> > changes in libweston.h which raised some flags about ABI incompatibilty
> > because they introduced some members in a publicly exposed struct. So I
> > set my feet on testing abi changes with abi-dumper +
> > abi-compliance-checker (it was my first time, that's why it took so
> > long).
> >
> > The actually bad new is 08979a1 (from 10.0.4) [1] makes some problematic
> > changes in libweston.h:
> >
> > --- a/include/libweston/libweston.h
> > +++ b/include/libweston/libweston.h
> > @@ -1289,6 +1289,7 @@ struct weston_view {
> > struct weston_surface *surface;
> > struct wl_list surface_link;
> > struct wl_signal destroy_signal;
> > +   struct wl_signal unmap_signal;
> >
> > /* struct weston_paint_node::view_link */
> > struct wl_list paint_node_list;
> > @@ -1441,6 +1442,7 @@ struct weston_pointer_constraint {
> > bool hint_is_pending;
> >
> > struct wl_listener pointer_destroy_listener;
> > +   struct wl_listener view_unmap_listener;
> > struct wl_listener surface_commit_listener;
> > struct wl_listener surface_activate_listener;
> >  };
> >
> > This introduces an ABI incompatibility in libweston as caught by
> > abi-compliance-checker (report attached):
> >
> > Comparing ABIs ...¬
> > Comparing APIs ...¬
> > Creating compatibility report ...¬
> > Binary compatibility: 77.8%¬
> > Source compatibility: 100%¬
> > Total binary compatibility problems: 1, warnings: 1¬
> > Total source compatibility problems: 0, warnings: 1¬
> > Report: compat_reports/libweston-10.so.dump/0_to_1/compat_report.html¬
> >
> > I think this would get a solid NO from the release team (although I'm
> > not sure). Since the whole 10.0.4 release (the 4 commits) are related to
> > each other, I think we won't be able to pick it.
> >
> > That said, I started testing with the 10.0.3 release (because if we
> > can't get the latest, let's try to get something at least). And the
> > results are good, we have 100% abi and api compatibility for all DSOs,
> > even internal ones.
> >
> > Also, building the 10.0.3 (always with libseat launcher support
> > enabled), the build time tests give the same results (with 10.0.5 I was
> > getting slightly different results).
> >
> > I also tested the libseat launcher and normal launcher and they both
> > work.
> >
> > Finally, since the 10.0.5 patch release is only 1 commit, we can grab it
> > as a patch in the packaging side, so we would just miss the 10.0.4 patch
> > release.
> >
> > Well, it was a long email, but the main takeway is 10.0.4 introduces an
> > ABI incompatibility and would be unsuitable for a proposed-update to
> > bookworm. But we can use the 10.0.3 release plus the only commit in
> > 10.0.5 with libseat launcher support with 100% abi and api
> > compatibility.

Thanks a lot for your analysis and testing.

This ABI incompatibility it's unfortunate :-( In this case, I would
instead focus our request to your initial request, i.e. only enabling
the support of libseat without trying to push a new version. It would
make our request simpler and I hope easier to accept.
Initially, the next release point for Bookworm was planned tomorrow,
but due to the xz issue, it's postponed to a later date. I guess we are
too late for it anyway.

I pushed a new branch "debian-bookworm-updates" with only
10.0.1-1+deb12u1, could you please test this one, especially
with logind to make sure we are not introducing any regressions?
Meanwhile, I pinged upstream to ask for their opinion about
that to make sure we are not going to break stuff. I also
drafted a bug report for release team.

> Would you be okay of using 10.0.3 instead of 10.0.5?
>
> Also, if you need any help, please let me know.
>
> Maybe a disclaimer I should have sent in the first email, I do work at
> Toradex which is an embedded systems company and we are rebuilding
> weston with libseat-launcher support for a while. I'm also a Debian
> contributor and maintainer (DM) and I suggested to our management to try
> to send this change to Debian as a contribution. They were very
> supportive about contributing back to Debian, so here we are :-)

That is nice! Thank you for pushing your changes upstream :-)
Let's try to make it a success for more contributions.

Best,
Dylan

Bug#1067958: ruy: FTBFS on armel, armhf

[Dylan Aïssi]

Control: severity -1 important

Hello,

Severity serious because it ftbfs on architectures where
 it has never successfully built seems a bit excessive.

Best,
Dylan


Le ven. 29 mars 2024 à 14:24, Kentaro HAYASHI  a écrit :
>
> Source: ruy
> Severity: serious
> Tags: ftbfs
> Control: found -1 0.0.0~git20230215.21a85fe-1
> X-Debbugs-Cc: ken...@xdump.org
>
> Dear Maintainer,
>
> ruy fails to build on armel, armhf.
>
> FYI:
>
> https://buildd.debian.org/status/fetch.php?pkg=ruy=armel=0.0.0%7Egit20230215.21a85fe-1=1688810281=0
> https://buildd.debian.org/status/fetch.php?pkg=ruy=armhf=0.0.0%7Egit20230215.21a85fe-1=1688810272=0
>
> Regards,
>

Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x

[Dylan Aïssi]

Control: reassign -1 asahi-audio
Control: notfound -1 0.4.17-1
Control: found -1 1.7-1
Control: affects -1 wireplumber

Hello,
Thanks for this bug report, I reassign it to asahi-audio since the versioned
dependency is on it and not on wireplumber.

Le lun. 25 mars 2024 à 09:45, Thomas Renard  a écrit :
>
> According to the new api in wireplumber asahi-audio 1.x breaks. The asahi
> developer tries to fix this upstream in asahi-audio during this week but 
> because of the
> api change asahi-audio 2.x will break with wireplumber <0.5.0.
>
> So there is/will be a direct dependency:
>
> wireplumber 0.4.x compatible to asahi-audio 1.x
> wireplumber >= 0.5.0 comaptible to asahi-audio 2.x
>
> Source; fedora-asahi-dev channel on matrix 24.03.2024, @chadmed around 01.24.
> https://matrix.to/#/#asahi-devel:fedoraproject.org
>
> Please consider this

I don't plan to upload wireplumber 0.5.0 to unstable soon because it's
kind of blocked
by waybar which is not yet compatible with it, it's fixed in git
upstream but no release
and also because of the t64 transition. So, since asahi-audio seems to
want to fix this
bug this week, we should have a new compatible version of asahi-audio
in due course.

Best,
Dylan

Bug#1066836: libcamera: ftbfs with 64-bit time_t

[Dylan Aïssi]

Hi Kieran,

I guess this task is for me ;-)
Yes, I will submit it.

Best,
Dylan


On 3/14/24 13:04, Kieran Bingham wrote:

Hi Steve,

do you also plan to submit this to the libcamera-devel mailing list?

--
Kieran

Quoting Steve Langasek (2024-03-14 05:35:04)

Package: libcamera
Version: 0.2.0-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear maintainers,

libcamera fails to build from source on 32-bit architectures under 64-bit
time_t, because it has a module that legitimately un-sets _FILE_OFFSET_BITS
for building but this is not allowed without also unsetting _TIME_BITS:

[...]
[267/430] c++ -Isrc/v4l2/v4l2-compat.so.p -Isrc/v4l2 -I../src/v4l2 -Iinclude -I../include -Iinclude/libcamera/ipa 
-Iinclude/libcamera -fdiagnostics-color=always -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -Wno-redundant-move 
-Wno-psabi -Wshadow -include /<>/obj-arm-linux-gnueabihf/config.h -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security 
-fno-stack-clash-protection -fdebug-prefix-map=/<>=/usr/src/libcamera-0.2.0-1ubuntu3 
-Wno-error -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC 
-DLIBCAMERA_BASE_PRIVATE -U_FILE_OFFSET_BITS -D_FILE_OFFSET_BITS=32 -D_LARGEFILE64_SOURCE -fvisibility=hidden -MD 
-MQ src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -MF src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o.d -o 
src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -c ../src/v4l2/v4l2_camera.cpp
FAILED: src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o
c++ -Isrc/v4l2/v4l2-compat.so.p -Isrc/v4l2 -I../src/v4l2 -Iinclude -I../include -Iinclude/libcamera/ipa 
-Iinclude/libcamera -fdiagnostics-color=always -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -Wno-redundant-move 
-Wno-psabi -Wshadow -include /<>/obj-arm-linux-gnueabihf/config.h -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security 
-fno-stack-clash-protection -fdebug-prefix-map=/<>=/usr/src/libcamera-0.2.0-1ubuntu3 
-Wno-error -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC 
-DLIBCAMERA_BASE_PRIVATE -U_FILE_OFFSET_BITS -D_FILE_OFFSET_BITS=32 -D_LARGEFILE64_SOURCE -fvisibility=hidden -MD 
-MQ src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -MF src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o.d -o 
src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -c ../src/v4l2/v4l2_camera.cpp
In file included from /usr/include/features.h:394,
  from 
/usr/include/arm-linux-gnueabihf/c++/13/bits/os_defines.h:39,
  from 
/usr/include/arm-linux-gnueabihf/c++/13/bits/c++config.h:679,
  from /usr/include/c++/13/bits/requires_hosted.h:31,
  from /usr/include/c++/13/deque:60,
  from ../src/v4l2/v4l2_camera.h:10,
  from ../src/v4l2/v4l2_camera.cpp:8:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only 
with _FILE_OFFSET_BITS=64"
26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
   | ^
[...]

   
(https://launchpad.net/ubuntu/+source/libcamera/0.2.0-1ubuntu3/+build/27902670)

Since this is a legitimate un-setting of _FILE_OFFSET_BITS in order to get
access to the necessary libc6 prototypes and macros, and since the functions
being intercepted are not sensitive to time_t, the simplest solution is to
also unset _TIME_BITS.

Please see the attached patch, which has been uploaded to Ubuntu to fix this
build failure.

Thanks for considering,
--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com     vor...@debian.org


--
Dylan Aïssi
Software Engineer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Dylan Aïssi]

Hi,

Le mer. 13 mars 2024 à 16:05, Carlos Henrique Lima Melara
 a écrit :
>
> > I can try this week to prepare an updated package in a dedicated branch
> > in salsa, so you can test it. Then, if everything is okay, we could fill
> > the request to the release team.
>
> Sure, just let me know if you need help with anything and/or when the
> packaging is ready for testing.

Ready for testing at:
https://salsa.debian.org/xorg-team/wayland/weston/-/tree/debian-10.0
I just realized the branch name is confusing...

Best,
Dylan

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Dylan Aïssi]

Hello,

Le mar. 12 mars 2024 à 20:45, Carlos Henrique Lima Melara
 a écrit :
>
> Taking this into consideration and the outcome of Init systems and
> systemd GR [3], I'd like to check with you the possibility of enabling the
> support for libseat launcher in stable via a proposed-updates upload to
> bookworm.

I'm not against that, but we will have to convince the release team that
it won't introduce new bugs. That means we have to fill a bug report
against the pseudo-package "release.debian.org".

If we are going to touch the package in Bookworm, I would like to try
pushing the last bugfix release of the serie 10.0. It was a private
request from upstream but I didn't realized that there were very few
changes in the bugfix releases, it's worth a try. What do you think?

I can try this week to prepare an updated package in a dedicated branch
in salsa, so you can test it. Then, if everything is okay, we could fill
the request to the release team.

> I did rebuild bookworm's version with the option enabled and tested it a
> bit in my notebook. I've also used abi-compliance-checker to check if
> this could have caused any ABI change in libweston and it didn't. I'll
> provide the debdiff output for you to check.
>
> Also, should you answer positively, I can do a more exhaustive testing
> and check if we don't introduce any errors when running with elogind and
> systemd-logind.

This will be very useful to convince the release team.

Best regards,
Dylan

Bug#1065345: pipewire-jack: Improve package description

[Dylan Aïssi]

Hello,

Le dim. 3 mars 2024 à 10:24, Chris Joelly  a écrit :
> In my point of view it is not clearly understandable fromthe package
> desciptions or package docs how pipewire-jack and libspa-0.2-jack relate. I
> understood that pipewire-jack, aside from being a plugin, is a implementation
> of a JACK server based on JACK API and pipewire. And, I understood
> libspa-0.2-jack is a lib which is needed for pipewire to connect to a JACK
> server. These are two different things imho.

Looks like a duplicate of https://bugs.debian.org/1062262
Now, we have (only in git for now):

pipewire-jack:
This package contains a plugin for JACK applications to output via PipeWire.

libspa-0.2-jack:
This package contains a plugin to make PipeWire able to connect to a
JACK server, which will be used for audio playback and recording.

I guess it makes things clearer? Feel free to create a merge request to
improve the description.

> But I learned that JACK client applications can not connect to pipewire-jack
> when libspa-0.2-jack is not installed. Thus, libspa-0.2-jack is too needed 
> when
> JACK clients want to connect to pipewire-jack, basically making it a
> dependency?

Heu no, I just tried to remove libspa-0.2-jack, then run (after a reboot)
$ pw-jack sndfile-jackplay my_random_wave_file
and it works.


Best,
Dylan

Bug#1063088: weston: NMU diff for 64-bit time_t transition

[Dylan Aïssi]

Hello,

Le lun. 5 févr. 2024 à 02:54, Steve Langasek  a écrit :
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
>

I am wondering what is the plan with this package/bug? I noticed that changes
related to the 64-bit time_t transition were not uploaded to unstable and
because I uploaded several versions in unstable after your NMU in exp, I
wonder if I haven't interfered with this transition.

Best regards,
Dylan

Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged

[Dylan Aïssi]

Le jeu. 15 févr. 2024 à 16:03, Sander van Grieken
 a écrit :
>
> Using dpkg-divert is fine. Maybe adding a single comment line mentioning 
> dpkg-divert in /usr/share/alsa-card-profile/mixer/profile-sets/default.conf, 
> just above the include of -custom.conf would be helpful.
>

Patching files always has a maintenance cost that I would like to avoid and
since dpkg-divert is something specific to Debian, I am not sure upstream is
interested by adding such comment. But, we can install a -custom.conf.README
explaining how to use dpkg-divert on it. What do you think?

Best,
Dylan

Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged

[Dylan Aïssi]

Hi,

Le mer. 14 févr. 2024 à 13:45, Sander van Grieken
 a écrit :
>
> The file /usr/share/alsa-card-profile/mixer/profile-sets/-custom.conf,
> which is packaged as part of pipewire-bin and intended to be customized by the
> user, is packaged in a way that it is overwritten by upgrades.
>
> The file -custom.conf should not be included, or included with a different
> name, e.g. -custom.conf.example
>

This file/feature was implemented with the idea of using dpkg-divert on it, see
https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1686

Any reason of not using dpkg-divert?

Best regards,
Dylan

Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1

[Dylan Aïssi]

Control: tag -1 patch

> While doing a rebuild of some node packages in Bookworm, it appears several
> packages (at least ~ 50 pkgs) no longer build with nodejs 
> 18.19.0+dfsg-6~deb12u1
> (from bookworm-security repo) while they still successfully build with nodejs
> 18.13.0+dfsg1-1 (from the main bookworm repo). They all fail with the
> same error:
> error TS2307: Cannot find module 'undici-types' or its corresponding
> type declarations.

A fix for this issue has been proposed:
 https://salsa.debian.org/js-team/node-undici/-/merge_requests/2/

Thanks Ryan!

Best regards,
Dylan

Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1

[Dylan Aïssi]

Source: node-undici
Version:  5.15.0+dfsg1+~cs20.10.9.3-1+deb12u3
Severity: serious
Tags: bookworm
Usertags: apertis-ftbfs
Justification: FTBFS

Hello,

While doing a rebuild of some node packages in Bookworm, it appears several
packages (at least ~ 50 pkgs) no longer build with nodejs 18.19.0+dfsg-6~deb12u1
(from bookworm-security repo) while they still successfully build with nodejs
18.13.0+dfsg1-1 (from the main bookworm repo). They all fail with the
same error:
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

Since, I am not sure which package need to be fixed (nodejs, node-undici or
all of them), I fill this bug against the package referred by the error message,
please reassign to the relevent package.

Below is the relevant part of the log:

   dh_auto_build --buildsystem=nodejs
Found debian/nodejs/additional_components
Adding component(s): types
/!\ types/package.json not found
/!\ types/package.json not found
Unable to load types
No build command found, searching known files
Found debian/nodejs/llparse-builder/build
cd ./llparse-builder && sh -ex ../debian/nodejs/llparse-builder/build
+ tsc
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:325:84 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

325 type _Request = typeof globalThis extends { onmessage: any
} ? {} : import("undici-types").Request;

~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:326:85 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

326 type _Response = typeof globalThis extends { onmessage:
any } ? {} : import("undici-types").Response;

 ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:327:85 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

327 type _FormData = typeof globalThis extends { onmessage:
any } ? {} : import("undici-types").FormData;

 ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:328:84 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

328 type _Headers = typeof globalThis extends { onmessage: any
} ? {} : import("undici-types").Headers;

~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:330:22 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

330 : import("undici-types").RequestInit;
 ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:336:35 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

336 type RequestInfo = import("undici-types").RequestInfo;
  ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:337:35 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

337 type HeadersInit = import("undici-types").HeadersInit;
  ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:338:32 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

338 type BodyInit = import("undici-types").BodyInit;
   ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:339:39 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

339 type RequestRedirect = import("undici-types").RequestRedirect;
  ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:340:42 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

340 type RequestCredentials = import("undici-types").RequestCredentials;
 ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:341:35 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

341 type RequestMode = import("undici-types").RequestMode;
  ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:342:38 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

342 type ReferrerPolicy = import("undici-types").ReferrerPolicy;
 ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:343:34 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.

343 type Dispatcher = import("undici-types").Dispatcher;
 ~~

../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:344:37 -
error TS2307: Cannot find module 

Bug#1061071: transition: libcamera 0.2.0

[Dylan Aïssi]

Hi Sebastian,

Le dim. 21 janv. 2024 à 16:56, Sebastian Ramacher
 a écrit :
>
> > Please schedule a transition slot for libcamera 0.2.0.
>
> Please go ahead.
>

Thanks!

Both libcamera 0.2 and pipewire were uploaded to unstable yesterday.

Best regards,
Dylan

Bug#988337: weston: Fails to start with `environment variable XDG_RUNTIME_DIR is not set.`

[Dylan Aïssi]

Control: tag -1 wontfix

As explained in the linked upstream bug, this is expected
and marked as "won't fix".

Best,
Dylan

Bug#1061071: transition: libcamera 0.2.0

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:libcamera

Dear Release Team,

Please schedule a transition slot for libcamera 0.2.0.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 1.0.1-1) builds fine with
2 upstream patches [1], since they break the backward
compatibility, I plan to do an upload of pipewire once libcamera0.2
is in unstable.

Thanks,
Dylan

[1] https://salsa.debian.org/utopia-team/pipewire/-/commit/a48d3473

Bug#1060785: libspa-audioconvert: Crash sometimes due to misaligned load to YMM register.

[Dylan Aïssi]

Hi Ohta,

Le dim. 14 janv. 2024 à 10:24, Kyuma Ohta
 a écrit :
>
> Sometimes ...mostly be load growth a lot..., pipe-wire daemon or
> pipewire-pulse daemon crashes with below message [1].
>
> This happens misalign of loading to YMM register [2][3].
>
> This crash seems to happen at "vlddqu -0x20(%rcx),%ymm2" [2],
> this need align at 256bit (but, Older Ryzen may be need only align of
> 128bit).
> But, RCX register didn't align of 256bits [3].
> Value is 0x5650f98e99c4 .
>
> So, software related libspa-audioconvert crashes sometime and randomly.
> I think.

Thank you for this bug report. May I ask you to forward it upstream?
at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Thank you!
Best regards,
Dylan

Bug#1012454: wireplumber: multiple permission denied errors in logs after installing

[Dylan Aïssi]

Hi,

Do you still have this problem?

Best regards,
Dylan

Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

[Dylan Aïssi]

Hi,

Are there still problems here?

I'm tempted to close this bug since wireplumber doesn't conflict with
pulseaudio. If there is a conflict it is between pulseaudio and
pipewire-pulse and/or pipewire-alsa. But installing pipewire-audio
should get ride of pulseaudio to avoid any conflicts (**after** a reboot).

Best regards,
Dylan

Bug#1006365: wireplumber: Please split audio files out of the main package

[Dylan Aïssi]

Control: tag -1 wontfix

Le jeu. 24 févr. 2022 à 11:33, Laurent Bigonville  a écrit :
>
> Would it be possible to split the configuration and plugins files that
> enable the "audio" part of pipewire to an other package? That way
> pipewire-pulse could depend on that package instead?

I tag this bug as wontfix for now. Once wireplumber 0.5 is released,
we can re-evaluate it.

Best,
Dylan

Bug#998073: wireplumber: fails to automatically switch to headphones when connected

[Dylan Aïssi]

Control: fixed -1 0.4.13-1

Hi Vincent,

Le lun. 18 déc. 2023 à 23:57, Vincent Lefevre  a écrit :
>
> FYI, I have a new laptop, where I use wireplumber 0.4.13-1
> (Debian stable) with the same Bluetooth devices (speakers and
> headphones), and there are no such problems with it.

That is a good news!

> So either the bug has been fixed in wireplumber 0.4.13-1 or there
> has been something else on the old laptop that broke wireplumber.
>

I don't see any change in the changelog of 0.4.13 that could be related to
this bug. As we have no other clues, I tag this bug as fixed with 0.4.13-1
without closing it.

Best regards,
Dylan

Bug#1057767: pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown

[Dylan Aïssi]

Hi,

Le ven. 8 déc. 2023 à 10:48, arne anka  a écrit :
>
>* What led up to the situation?
>
> On Dec 6 I upgraded and since the my BT thingy does not connect to my PC 
> anymore.
> I am hearing impaired and need to use a BT thingy called RemoteMic+ (by 
> Starkey) to be able to listen to music or make calls/attend meetings via PC. 
> So, this is a major issue for me.
> Among others these packages were upgraded:
>
> firmware-iwlwifi
>
> libpipewire-0.3-0
> libpipewire-0.3-common
> libspa-0.2-bluetooth
> libspa-0.2-modules
>
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> First I downgraded firmware-iwlwifi to version 20230210-5 -- to no avail.

Did you try downgrading only firmware-iwlwifi to the last working version
without downgrading pipewire? Was the kernel updated at the same time?

If you can confirm that the problem comes from pipewire, it's worth filling
a bug report upstream at:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Best regards,
Dylan

Bug#1056701: ITP: roc-toolkit -- real-time audio streaming over the network

[Dylan Aïssi]

Package: wnpp
Severity: wishlist
Owner: Dylan Aïssi 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-multime...@lists.debian.org

* Package name: roc-toolkit
* URL: https://roc-streaming.org/
* License: MPL-2.0

Roc is a network transport, highly specialized for the real-time streaming use
case. The user writes the stream to the one end and reads it from another end,
and Roc deals with all the complexity of the task of delivering data in time
and with no loss. Encoding, decoding, adjusting rates, restoring losses - all
these are performed transparently under the hood.

This package is maintained by Debian Multimedia Team at:
  https://salsa.debian.org/multimedia-team/roc-toolkit

Bug#1055825: pipewire v0.3.84 breaks HDMI audio

[Dylan Aïssi]

Le dim. 12 nov. 2023 à 07:15, Ian Bruce  a écrit :
>
> pipewire v0.3.84 broke that. It forced the removal of pulseaudio (except some
> libraries),

There was no change in the packaging of pw 0.3.84 forcing the removal
of pulseaudio.

> and disabled HDMI audio completely. HDMI output can still be selected in
> "pavucontrol",
> and the amplitude indicator wiggles appropriately, but absolutely nothing 
> comes
> out of the
> TV speakers. Switching the stream back to the analog speakers works properly;
> switching
> to HDMI produces silence.

No issue here with pw 0.3.85 to switch between laptop speakers and
hdmi speakers.

> I have now downgraded pipewire to v0.3.65/stable, and everything works 
> properly
> again.
> A playing stream can be switched back and forth repeatedly between speakers 
> and
> TV,
> with no problems. pipewire v0.3.83 is no longer available in the archive for
> testing,
> but something between v0.3.65 and v0.3.84 broke HDMI audio completely, at 
> least
> with this
> hardware configuration, which doesn't seem particularly unusual.

If you want to test other versions, you can find all previous packages at
https://snapshot.debian.org/package/pipewire/

Best,
Dylan

Bug#1055254: transition: dav1d

[Dylan Aïssi]

Le dim. 5 nov. 2023 à 22:01, Sebastian Ramacher  a écrit :
>
> Please go ahead.
>

Thanks, uploaded!

Best regards,
Dylan

Bug#1055266: pipewire: Changing monitor settings makes HDMI output silent forever

[Dylan Aïssi]

Hi,

Le ven. 3 nov. 2023 à 10:57, Eduard Bloch  a écrit :
>
>* What was the outcome of this action?
>
> There is NO SOUND comming out of the speaker anymore!! I still see the
> devices there in pavucontrol, it seems to be in the same state as before
> and "...  HDMI output" is selected as before. I can still control it,
> but it remains SILENT.

Did it work before pw 0.3.84?

Can you forward this issue upstream at:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Thank you.

Best regards,
Dylan

Bug#1055254: transition: dav1d

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for dav1d.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-dav1d.html

All reverse deps (ffmpeg, libavif, libheif, vlc and xine-lib-1.2) build fine
with the new version in experimental.

Thanks,
Dylan

Bug#1055248: bookworm-pu: pipewire/0.3.65-3+deb12u1

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:pipewire

[ Reason ]
Fix memory leak in pipewire-pulse #1015915.

[ Impact ]
If not fixed, unnecessary memory consumption.

[ Tests ]
Tested in a VM without any sound issue.

[ Risks ]
Low, The change is small and already applied since several versions
in testing/unstable.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable (and trixie)


Best regards,
Dylan


pw_0.3.65-3+deb12u1.debdiff
Description: Binary data

Bug#1005047: pipewire daemon starting even in non-graphical sessions

[Dylan Aïssi]

Control: tag -1 wontfix

Le dim. 6 févr. 2022 à 00:15, Martin Mares  a écrit :
>
> Is it intentional that the systemd user services for pipewire and 
> pipewire-pulse
> (and the related socket services) are WantedBy default.target? This causes
> them to be started even for users logged in via SSH.
>

This is the expected behavior. There are many pipewire use cases running
without graphical session like with embedded devices. For example, I am
currently working on a pipewire project with an ARM board without any graphical
session.

Thus I mark this bug as "won't fix".

Best regards,
Dylan

Bug#1054274: Sound changes volume with cracking noise

[Dylan Aïssi]

Hi,

Le lun. 23 oct. 2023 à 01:03, david  a écrit :
>
> After using for two days last pipewire version, sound seems more stable now,
> with usual clicks when changing window focus, for example, but without 
> cracking
> in youtube videos or mpv films.
>

I mark the bug as fixed with 0.3.83-1 but will keep it open for a while.

For cracking issues, feel free to report your bug directly to upstream at
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
by providing logs as explained here
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting

Best regards,
Dylan

Bug#1054019: broken sample rate passthrough

[Dylan Aïssi]

Hi Nicholas,

Le mar. 17 oct. 2023 à 19:59, Nicholas D Steeves  a écrit :
>
> Oops!  Yes, thank you, I forgot to test a newer pipewire after tiring
> and running out of time during the initial investigation.
>
> 0.3.82-1~bpo12+1 solves the bug :)

Great! :-)

> Rather than close this bug as fixed right away, do you think it would be
> worthwhile to keep it open and/or add something to the bookworm release
> notes?  I could write a few words if you'd prefer.  There are always
> questions of "can I switch to $new_technology without regressions", and
> I think this would help answer them.

Sure, if you think it could be useful then it is worth adding something in the
bookworm release note (maybe also in the debian pipewire wiki page?).

> It's also the case that pipewire-jack makes taking one's first steps in
> Linux music production much easier, but sample rate mismatches are RC
> for this use case...so at a minimum release notes should be provided.

Yep, I would recommend using pw from bookworm-backports to use pipewire-jack
as there have been many improvements on this point in the latest versions.

Would you be willing to write it? :-)

Best regards,
Dylan

Bug#1054019: broken sample rate passthrough

[Dylan Aïssi]

Hi Nicholas,

Le dim. 15 oct. 2023 à 23:27, Nicholas D Steeves  a écrit :
>
> So yeah, it looks like Pipewire's default sample rate is always
> applied when using pipewire or JACK sinks, despite
> "default.clock.allowed-rates" being set, except with using pulseaudio.
> I'm not sure why this is the case, but it seems wrong that everything
> is buggy except Pipewire and Pulseaudio...and that's why I'm reporting
> this bug against pipewire.  Please feel free to reassign if this is a
> naive assessment.
>
> I hope this is enough to identify which package[s] is[are] affected as
> well as to forward the bug upstream.  Please let me know if any more
> info is required.

pipewire 0.3.65 is quite old now. May I ask you to test with pipewire
in bookworm-backports (i.e. 0.3.82-1~bpo12+1)? To check if this bug
is already fixed in the latest version.

Best regards,
Dylan

Bug#1015915: fixed in pipewire 0.3.81-1

[Dylan Aïssi]

Hi Vuk,

Le mar. 17 oct. 2023 à 16:15, Vuk Mirovic  a écrit :
>
> Can we get malloc_trim fix backported to stable?
> It can be applied to 0.3.65 easily and shouldn't mess anything.

Sure, but since it's not a security fix, we will have to follow the
"proposed-updates" mechanism [1]. That means it will land in
the debian archive with the next point release. We can anyway
already prepare the package, thus I just created a new branch
"debian/bookworm-updates" on salsa [2]. I don't have much time
this week, so feel free to propose a MR, or I will prepare when
time permits.

Best regards,
Dylan

[1] https://www.debian.org/releases/proposed-updates
[2] 
https://salsa.debian.org/utopia-team/pipewire/-/commits/debian/bookworm-updates

Bug#1052466: OOM killed

[Dylan Aïssi]

Le mar. 26 sept. 2023 à 19:54, Philipp Marek  a écrit :
>
> Well, actually I'm not complaining about the process being buggy  - what is 
> worrying me is that the process runs in the logged-on user's context, but 
> without the ulimits (as per /etc/security/limits.conf) or any other limits 
> set up!

I'm inclined to disagree, I prefer to treat the cause rather than the symptoms.
I don't see any benefit in adding a safeguard to avoid triggering another
safeguard.

> At the very least the systemd file should include some sane values for max 
> CPU (resp. cores) and memory usage.

And how would you choose these arbitrary limits? What you consider sane limits
will probably not be enough for other legitimate uses.

> The first one would be a systemd bug, but the latter one surely belongs to 
> this package?!

Pipewire's services are only user services, you can override them by customized
ones that match your needs.

Best regards,
Dylan

Bug#1052682: pipewire-pulse: Updated section in /etc/pipewire/pipewire-pulse.conf.d/ not loading module-switch-on-connect

[Dylan Aïssi]

Le mar. 26 sept. 2023 à 08:00, S.  a écrit :
>
> I am following these instructions to enable module-switch-on-connect for
> pipewire-pulse by adding just the section I want to modify in
> /etc/pipewire/pipewire-pulse.conf.d/my.conf
>
> https://docs.pipewire.org/page_module_protocol_pulse.html#autotoc_md380
>
> 
> pulse.cmd = [
> { cmd = "load-module" args = "module-always-sink" flags = [ ] }
> { cmd = "load-module" args = "module-switch-on-connect" }
> ]
> 

It works using only:

pulse.cmd = [
{ cmd = "load-module" args = "module-switch-on-connect" }
]

Not sure, why it doesn't work when it is preceded by module-always-sink,
could be an upstream bug.

Since pw 0.3.70 (that means you will have to use the version in
bookworm-backports),
you can use the tool called pw-config to debug your config files, like:

pw-config -n pipewire-pulse.conf list

Best regards,
Dylan

Bug#1052466: OOM killed

[Dylan Aïssi]

Le ven. 22 sept. 2023 à 17:09, Philipp Marek  a écrit :
>
> I just got my pipewire process OOM killed:
>
> [62615.563546] 
> oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service,task=pipewire,pid=2550,uid=1000
> [62615.563573] Out of memory: Killed process 2550 (pipewire) 
> total-vm:22028128kB, anon-rss:21793560kB, file-rss:3972kB, shmem-rss:1204kB, 
> UID:1000 pgtables:42860kB oom_score_adj:200
>

Would it be possible that firefox was running at this time? Firefox is known
to cause memory leaks in pipewire-pulse. That could explain why the OOM killer
was triggered. See:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840

Best regards,
Dylan

Bug#1052467: transition: svt-av1

[Dylan Aïssi]

Le ven. 22 sept. 2023 à 21:25, Sebastian Ramacher
 a écrit :
>
> Please go ahead.
>

Thanks, uploaded.

Best regards,
Dylan

Bug#1052467: transition: svt-av1

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for svt-av1.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-svt-av1.html

All reverse deps (ffmpeg, libavif and libheif) build fine with the new version
in experimental.

Thanks,
Dylan

Bug#934811: webrtc-audio-processing 1.0 available, pipewire will require >= 1.2

[Dylan Aïssi]

Hello all,

The next version of pipewire depends on webrtc-audio-processing-1 >= 1.2 for
its echo-canceller module. Although it is an optional dependencies, upstream
advised me not to disable it to avoid too many complaints. That means, I
won't be able to update pipewire in debian anymore until we have a newer version
of webrtc-audio-processing-1.
By checking the upstream pulseaudio repo, latest commits are adding support of
this new webrtc-audio-processing. So, it looks like we'll have to make the
transition soon.

Apart the Jonas's uploads last year, I don't see any recent work on this pkg,
is there any plan around this transition?

Best regards,
Dylan

Bug#1051128: pipewire FTBFS on alpha; failure in test suite due to sigfpe

[Dylan Aïssi]

Hello Michael,

Le dim. 3 sept. 2023 à 10:45, Michael Cree  a écrit :
>
> pipewire FTBFS on Alpha due to test suite failure. From the build
> log [1]:
>

Upstream has pushed two commits to fix the build on alpha:
- 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/805fbd0b34772fbc4d16bb94317706f2c17cdb59
- 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/632f532036d3c69ce0aba89a85dbc3a94af7ad0a

As I don't have access to an alpha machine, can you test to build pipewire
with these commits?

Best regards,
Dylan

Bug#1050916: pipewire death secondary to general protection fault in libspa-bluez5.so

[Dylan Aïssi]

Hello,

Thank you for this bug report.

Le jeu. 31 août 2023 à 13:42, John Smith  a écrit :
>
> Hello, I noticed this line in dmesg after a Bluetooth audio loss:
> [96307.727270] traps: wireplumber[2128] general protection fault 
> ip:7f7b0145d29f sp:7f7b03ffe950 error:0 in 
> libspa-bluez5.so[7f7b01449000+b1000]
>

Can you forward this bug report upstream at:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Thank you!

Best regards,
Dylan

Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages

[Dylan Aïssi]

Hi Boud,

Le mar. 29 août 2023 à 00:27, Boud Roukema  a écrit :
>
> PROPOSAL (1):
>
> Should the user be informed when doing the system upgrade? More specifically,
> would a one-line warning to the user be considered acceptable, as a 
> post-install
> script? E.g. something like:
>
> "Please recommend that users restart all scripts running pipewire (such as 
> pipewire, pipewire-pulse)"

This is a discouraged behavior. Pipewire is updated every ~ two weeks, if
it displays messages for each update that will annoy people and I will receive
a wave of complaints to disable it.

> PROPOSAL (2):
>
> Add the following file (under the default licence for pipewire - Expat - no
> need to complicate the licensing further):
>
> cat > debian/pipewire-pulse.README.Debian << EOF
> Relation to pipewire and upgrades
> =
>
> The pipewire-pulse systemd service runs independently of the pipewire
> service. Both run as user services and are not restarted when a
> system-level upgrade is performed by the root user. If you wish to
> check that you restart pipewire-pulse whenever the pipewire is
> upgraded using dpkg or apt, then consider using either
> "checkrestart" in the "debian-goodies" package [1] or "needrestart" [2].
> These need to be run as root user, but aim to check for both
> system and user services that need restarting.
>
> [1] https://tracker.debian.org/pkg/debian-goodies
> [2] https://tracker.debian.org/pkg/needrestart
> EOF

This would be possible but as you said pipewire-pulse is not the only
user service here that means we should do the same for all other
packages providing a user service. Looks like a waste of resources
as it is the expected behavior.

> PROPOSAL (3)
> Add the following file for the overall pipewire documentation:
>
> cat >> debian/pipewire.README.Debian << EOF
>
>
> After upgrading pipewire
> 
>
> A system-level upgrade of pipewire will not automatically restart all
> pipewire-related services. After an upgrade of pipewire, you may check
> the output of "pw-dump" to see if you forgot to restart some services,
> e.g.
>
>$ pw-dump |grep -nE "core\.(version|name)|process\.binary"
>
> or you may use "checkrestart" [1] or "needrestart" [2] with
> sudo or as root user.
>
> [1] https://tracker.debian.org/pkg/debian-goodies
> [2] https://tracker.debian.org/pkg/needrestart
> EOF

This proposal seems more appropriate :-) merge requests to improve this
file are more than welcome :-P here is the git repo:
https://salsa.debian.org/utopia-team/pipewire
I also want to mention our pipewire wiki page:
https://wiki.debian.org/PipeWire
if you consider it lacks some information then edits are also welcome :-).

> Independent of proposals (1) + (2) + (3), the 'pw-dump'
> output gives me the feeling that restarting pipewire
> should force the restart of all the related services - but
> I don't know how well they are expected to work together
> when according to pw-dump they are using inconsistent
> pipewire versions.

As the interactions between all these components is complex,
the safest way is to restart your device after an update of pipewire.
Or eventually you can try to only close your session and then
reopen a new one to restart user services.

The upstream wiki [1] provides the following command to restart pw/wp
services, but before filling a new bug, I would at least try to restart
my device anyway.

systemctl --user restart wireplumber pipewire pipewire-pulse

[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting

Best  regards,
Dylan

Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages

[Dylan Aïssi]

Hello Boud,

Le ven. 25 août 2023 à 13:09,  a écrit :
>
> * What outcome did you expect instead?
>
> What I expected was that the dpkg/apt system and/or the systemd system
> should have recognised that the old 'pipewire-pulse' process was invalid
> and should have forced it to restart with the 0.3.78-1 version.
>

I think the bug you are describing is a kind of duplicate of #1027136 [1]
filled against xdg-desktop-portal. So, I will quote the smcv's answer here [2]:

>> I think (the) xdg-desktop-portal user service(s) should be stopped before
>> removing the package. Is that possible?
>
> Not really: maintainer scripts happen in the context of the overall system
> (as root) and there is not really a good way to inject service-management
> commands into user sessions. Other per-user services like PulseAudio,
> Pipewire, gpg-agent and so on are not stopped when you remove them either.

Best regards,
Dylan

[1] https://bugs.debian.org/1027136
[2] https://bugs.debian.org/1027136#10

Bug#1050700: pipewire-media-session: complains about nonexistent device

[Dylan Aïssi]

Le lun. 28 août 2023 à 17:31, Francesco Potortì  a écrit :
>
>
> Wow.  Thanks for the info.
>
> Should I just install wireplumber and everything should work?
>

Yes that should work after a reboot to be sure pipewire-media-session
doesn't run anymore.

For safety, you can install the meta package called "pipewire-audio", it depends
on a recommended set of pipewire packages for a standard audio use.

Dylan

Bug#1050700: pipewire-media-session: complains about nonexistent device

[Dylan Aïssi]

Hello Francesco,

Le lun. 28 août 2023 à 14:09, Francesco Potortì  a écrit :
>
> Package: pipewire-media-session
>
> Two strange things in logs by pipewire-media-session.
>
> 1) format of log timestamp is not always the same
>
> 2) repeatedly complains about a missing default device
>

Thanks for your bug report, however pipewire-media-session is dead
upstream [1] and was removed from debian a week ago [2]. Now, it is
recommended to use wireplumber instead, which is a more sophisticated
session manager for pipewire.

Best regards,
Dylan

[1] https://bugs.debian.org/1030765
[2] https://bugs.debian.org/1043405

Bug#1043034: pipewire-pulse: Missing dependencie(s) or incomplete

[Dylan Aïssi]

Hi,

Le sam. 5 août 2023 à 11:42, B  a écrit :
>
> After removing almost all pulseaudio packages, except those linked to
> other programs, I rebooted and pipewire-pulse was gone (pipewire and
> wireplumber were launched as usual).

Not sure what happened, maybe a package that should have stayed
has been deleted.

> I rebooted just in case, but still no pipewire-pulse, so I scooped the
> web searching for a solution and find a guy saying that installing
> pavucontrol & paprefs made him troubleshoot his loss of audio also with
> pipewire-pulse too, so I tried, which installed some other packages, and
> rebooted - this time, pipewire-pulse was up and running after login.
>
> I'm not a specialist, but I think it was missing an
> org.freedesktop.xxx.xml file that came with one of these two packages or
> came from one of their dependencies.

I don't see any reference about a missing org.freedesktop.xxx.xml file in
the log you provided. I suppose you've confused it with the missing
"org.freedesktop.portal.Desktop"  which is a D-Bus interface used by
pipewire for screen-sharing, so not related to your sound issue. This
file is provided by the package xdg-desktop-portal (neither pavucontrol
nor paprefs).

However, I can see in your log you are facing these bugs #995357 [1]
and #1037447 [2]. Both of them are not blocking to get sound and
are already fixed in newer versions that should land in
*-backports repo soon I hope (waiting for a review in the backports queue)

> As I made a research for org.freedesktop.*.xml and checked before
> and after installing these 2 packages, I saw that the one in the log
> wasn't on my disk before, but was there after.
>
> So, I emitted the hypothesis that it could be an omission in the
> pipewire-pulse package, whether it is missing in it or a missing
> dependency toward another package.

To get rid of pulseaudio and to install pipewire, you can install the
metapackage pipewire-audio which depends on all required pipewire
packages and conflicts with pulseaudio and its bluetooth plugins
package. But really, pipewire does not depend or requires pavucontrol
or paprefs.

Best regards,
Dylan

[1] https://bugs.debian.org/995357
[2] https://bugs.debian.org/1037447

Bug#1043034: pipewire-pulse: Missing dependencie(s) or incomplete

[Dylan Aïssi]

Hi,

Le ven. 4 août 2023 à 23:21, Jiff  a écrit :
>
> Ze error :
> ==
> Uninstall *pulse* except those required by other packages.
>
> Ze cure :
> =
> apt install pavucontrol paprefs
>

I don't understand what is your issue, can you elaborate?
pavucontrol and paprefs are not dependencies of pipewire.

Best regards,
Dylan

Bug#1042713: wireplumber: High cpu usage

[Dylan Aïssi]

Le lun. 31 juil. 2023 à 00:21, Nick  a écrit :
>
> On rebooting, a process called wireplumber consumes most of the cpu.
> Sound does work.  If I kill the process, cpu usage falls, my fan stops
> spinning and I no longer have sound.  I have to kill wireplumber on
> each reboot (or let it try to fry my cpu).

Do you have pipewire-libcamera installed? If yes, can you remove it?

Can you provide log from pipewire and wireplumber as explained here [1]?

Best regards,
Dylan

[1] 
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#general

Bug#1042011: openrazer-driver-dkms: Driver module fails to build with 6.3 kernel

[Dylan Aïssi]

Hi,

Le mar. 25 juil. 2023 à 19:54, Dimitar Samarov
 a écrit :
>
>   CC [M]  /var/lib/dkms/openrazer-driver/3.6.1/build/driver/razerkbd.mod.o
> /var/lib/dkms/openrazer-driver/3.6.1/build/driver/razerkbd.mod.c:10:10: fatal
> error: asm/orc_header.h: No such file or directory
>10 | #include 
>   |  ^~
> compilation terminated.
>
>
> I have no clue what could've caused this. I made an attempt at reinstalling 
> the
> linux image, including the headers, but to no avail.
>

This seems to be a duplicate of #1040178 [1] which is a bug is the kernel
package. It should be fixed with the kernel pkgs in unstable, could you confirm?

Best regards,
Dylan

[1] https://bugs.debian.org/1040178

Bug#1041302: svt-av1: breaks ABI without SONAME bump

[Dylan Aïssi]

Hi Sebastian,

On Mon, 17 Jul 2023 08:51:00 +0200 Sebastian Ramacher
 wrote:
> Version 1.6.0 removed compressed_ten_bit_format from the middle of
> EbSvtAv1EncConfiguration, hence changing the memory layout of that
> struct. This means that the ABI changed requiring a SONAME bump.

I reported this issue upstream.

But , now the question is: what is the best way to deal with that on our side?
Should I artificially bump the soname? If so, what soname can I use?
How do we handle these cases in Debian usually?

Best regards,
Dylan

Bug#1041535: transition: libcamera 0.1.0

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for libcamera 0.1.0.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 0.3.74-1) builds fine with the
new libcamera in experimental.

Thanks,
Dylan

Bug#1040500: routine-update: Don't create d/salsa-ci.yml file

[Dylan Aïssi]

Hi Andreas,

Le ven. 7 juil. 2023 à 11:24, Andreas Tille  a écrit :
>
> Thanks for your opinion about this.  What I mean with de facto standard:  We
> have about 2000 repositories configured to check debian/salsa-ci.yml.  I have
> not yet found a way to set the according field via gitlab API to something
> else.  If this is scriptable I'd happily remove debian/salsa-ci.yml.  For the
> moment I state two votes against salsa-ci.yml. ;-)
>

We have a tool in Debian for that gitlab-rulez [1].
I haven't tried it on salsa yet, but it should work as we use it with our
gitlab instance.

Best regards,
Dylan

[1] https://tracker.debian.org/pkg/gitlab-rulez

Bug#1040330: Build without libffado on Ubuntu

[Dylan Aïssi]

Hi Sebastien,

Le mar. 4 juil. 2023 à 16:45, Sebastien Bacher  a écrit :
>
> The recent update added a depends on libffado, that component is
> currently in Ubuntu universe so it means we need to build without it
> there. Could you consider using the attached patch so we can keep the
> package in sync between the distributions?
>
> The .install change is a bit hackish but works, I can work on another
> variant with logic in the .rules instead of if you would prefer
>

Thanks for this patch. I applied the d/rules part, it would be wonderful
to have the logic in d/rules. I like to have the list of installed files
to make sure I don't miss anything.

Best regards,
Dylan

Bug#1040207: pipewire: Playing audio from JuK results in the beginning of all tracks messed up

[Dylan Aïssi]

Le lun. 3 juil. 2023 à 18:32, Russell King
 a écrit :
>
> On Monday, 3 July 2023 16:36:16 BST Dylan Aïssi wrote:
> > Are you using your Anker Soundcore 2 via bluetooth? It could be a
> > bluetooth issue. Could you try to connect your speaker via a jack
> > wire to discard any bluetooth issue if any.
>
> Yes I am, in both cases. It has been consistently fine under pulseaudio
> with Bullseye. Upgrading to Bookworm which switched over to pipewire
> exhibited the issue consistently. Switching Bookworm back to pulseaudio
> and the issue goes away.
>
> I don't have a cable to connect via a jack, sorry.

It could be a bluetooth regression, I would suggest to try the latest version
of pipewire since 0.3.65 is quite old now. As soon as the bookworm-backports
repositories are open, I will upload a newer version of pipewire + wireplumber.
Once you can reproduce this issue with a more recent version of pipewire,
it is worth opening a bug upstream at:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

> > Do you use wireplumber as session manager for pipewire?
>
> It seems the upgrade to Bookworm installed that for me, and logs show
> that it had been running. In terms of "use", until you mentioned it, I
> was unaware of it.
>

I asked because some users use the deprecated pipewire-media-session
session manager instead of wireplumber.

Bug#1038146: wireplumber[…]: Failed to call Lookup: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for camera

[Dylan Aïssi]

Le jeu. 15 juin 2023 à 23:57, AlMa  a écrit :
> Jun 15 04:42:15 AnonymizedMachineName wireplumber[1124]:
> GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner
> Jun 15 04:42:15 AnonymizedMachineName dbus-daemon[957]: [system]
> Successfully activated service 'org.freedesktop.UPower'
> Jun 15 04:42:15 AnonymizedMachineName systemd[1]: Started upower.service
> - Daemon for power management.
> Jun 15 04:42:15 AnonymizedMachineName gnome-shell[1312]: Running GNOME
> Shell (using mutter 43.4) as a X11 window and compositing manager
> Jun 15 04:42:15 AnonymizedMachineName pipewire[1122]: spa.v4l2:
> '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control)
> für das Gerät
> Jun 15 04:42:15 AnonymizedMachineName pipewire[1122]: spa.v4l2:
> '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control)
> für das Gerät

  ^^^
This is the issue we are talking at https://bugs.debian.org/1035901

> Jun 15 04:42:15 AnonymizedMachineName systemd[1083]: Started
> xdg-permission-store.service - sandboxed app permission store.
> Jun 15 04:42:15 AnonymizedMachineName wireplumber[1124]:
>  Failed to call Lookup:
> GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for camera
> Jun 15 04:42:15 AnonymizedMachineName wireplumber[1124]:
>  Failed to call Lookup:
> GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for camera
>

I suppose these lines are a consequence of the earlier bug.
Most likely, this bug is a duplicate of #1035901.

Bug#1035901: spa.v4l2: '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät

[Dylan Aïssi]

Le mar. 4 juil. 2023 à 00:35, AlMa  a écrit :
>
> I've never been able to make my TV tuner work in Debian.  Even scanning
> the channels has never worked properly.  This problem might,
> hypothetically, have its roots partially in the bug here or in the
> corresponding kernel driver.  Hence an elevated severity may be
> justified; please feel free to reconsider.

I assumed your TV tuner was working, but if you are not able to use it even
with other software then it's clearly not a pipewire bug.

Bug#1028490: pipewire-pulse: syslog being spammed with "source not ready" and "sink not ready"

[Dylan Aïssi]

Control: fixed -1 0.3.71-2

Hello Julian,

Le mar. 4 juil. 2023 à 08:34, Julian Groß  a écrit :
>
> it wasn't a one-time thing, but I cannot reproduce the issue any more on
> the current pipewire package version (0.3.71-2+b2) on Debian Trixie.
> So I would presume that his was fixed in a recent pipewire update.
>

So, I will keep this bug report open for now, but I mark it as fixed
with 0.3.71-2.
Don't hesitate to update this bug report if it happens again.

Best regards,
Dylan

Bug#1035901: spa.v4l2: '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät

[Dylan Aïssi]

Le sam. 1 juil. 2023 à 22:50, AlMa  a écrit :
>
> > I suspect a bug in the driver handling your /dev/video4 device.
> > Do you have more information about what device is your /dev/video4?
>
> Yes; it seems to be my TV-Tuner Hauppauge WinTV HVR 5525 HD:
>

Since it's not a vital part of pipewire, you can try to disable your device
in wireplumber for now. You can fill a bug upstream [1] they will fix potential
bug in pipewire or will redirect you to the right place.

I reduce the severity of this bug since using a Tuner TV card with pipewire
is a special case and this bug doesn't "have a major effect on the usability
of a package" [2].

Thank you
Dylan

[1] https://gitlab.freedesktop.org/pipewire/pipewire
[2] https://www.debian.org/Bugs/Developer#severities

Bug#1038874: pipewire-audio: no sound pipewire Audio HDMI Gemenilake J4125

[Dylan Aïssi]

Hi,

Le jeu. 22 juin 2023 à 14:16, Remi  a écrit :
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***

Only a title to describe a bug is probably not enough :-).
Can you be a bit more verbose? A description of your audio setup, which
audio parts work, which ones don't work. What have you tried?

All these information will be useful to help you :-)

Best,
Dylan

Bug#1040207: pipewire: Playing audio from JuK results in the beginning of all tracks messed up

[Dylan Aïssi]

Hi,

Le lun. 3 juil. 2023 à 15:39, Russell King
 a écrit :
>
> Using pipewire with JuK under Debian Stable (Bookworm) with an Anker
> Soundcore 2 results in the beginning of every track being messed up.
> I've also noticed similar oddities when playing audio from Firefox.

Are you using your Anker Soundcore 2 via bluetooth? It could be a bluetooth
issue. Could you try to connect your speaker via a jack wire to discard any
bluetooth issue if any.

Do you use wireplumber as session manager for pipewire?

Dylan

Bug#1028490: pipewire-pulse: syslog being spammed with "source not ready" and "sink not ready"

[Dylan Aïssi]

Hi,

Le mer. 11 janv. 2023 à 22:27, Julian Groß  a écrit :
>
> my Intel HD Audio device seems to be causing pipewire-pulse to spam syslog 
> with "source not ready" and "sink not ready" messages.
>

Is this a one-time bug? Are you able to reproduce it with bookworm? Or
even better with pipewire and wireplumber versions in sid?

Dylan

Bug#1034019: pipewire: Tascam Portacapture x8 Not Working as USB Mic in Interface Mode

[Dylan Aïssi]

Hi,

Le jeu. 6 avr. 2023 à 16:15, Zachary E. Braun  a écrit :
>
>First, appologies if this is the wrong package to report this to.
>I have a Tascam Portacapture X8 which is able to work as an audio 
> interface.  In theory, the built-in microphones should pass to the operating 
> system while the device itself should be able to monitor system audio.  The 
> latter, system aduio, works fine; however, I cannot get the microphones to 
> pass back to Debian.
>
>I was able to test this device on OSX; microphone input worked as expected.
>
>I have included the verbose output from lsusb for the device at the end of 
> the standard "System Information" section.

It looks like your device is currently not supported by Linux,
see the discussion at https://linuxmusicians.com/viewtopic.php?t=25192

This is not a pipewire bug, but probably a kernel bug (or missing feature).

Best,
Dylan

Bug#1033899: pipewire: Pipewire fails to sart, "Main process exited, code=killed, satus=31/SYS".

[Dylan Aïssi]

Le lun. 3 avr. 2023 à 18:54, Itai Shaked  a écrit :
>
> I am at a loss since there seems to be zero usable information in the logs,
> just that the service is killed for some (unspecified?) reason.
>

Can you manually start pipewire with an increased verbose level?
The following command should give us more details [1]:

PIPEWIRE_LOG_SYSTEMD=false PIPEWIRE_DEBUG=5 pipewire 2>log


Dylan

[1] 
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#pipewire-debugging-options

Bug#1035901: spa.v4l2: '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät

[Dylan Aïssi]

Le mer. 14 juin 2023 à 17:30, AlMa  a écrit :
> Jun 13 21:00:22 AnonymizedMachineName pipewire[1146]: spa.v4l2:
> '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control)
> für das Gerät
> Jun 13 21:00:22 AnonymizedMachineName pipewire[1146]: spa.v4l2:
> '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control)
> für das Gerät
>
> The last two error messages
>
> spa.v4l2: '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL
> (I/O-Control) für das Gerät

I suspect a bug in the driver handling your /dev/video4 device.
Do you have more information about what device is your /dev/video4?

Dylan

Bug#1038990: transition: liblc3 1.0.3

[Dylan Aïssi]

Le dim. 25 juin 2023 à 21:36, Sebastian Ramacher
 a écrit :
>
> > The unique reverse dep (pipewire) builds fine with the
> > new liblc3 in experimental.
>
> Please go ahead.

Thanks, uploaded!

Best regards,
Dylan

Bug#1038990: transition: liblc3 1.0.3

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for liblc3 1.0.3.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-liblc3.html

The unique reverse dep (pipewire) builds fine with the
new liblc3 in experimental.

Thanks,
Dylan

Bug#1037447: pipewire[…]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?

[Dylan Aïssi]

Le mar. 13 juin 2023 à 22:51, AlMa  a écrit :
>
> Here, wireplumber 0.4.13-1 and pipewire:amd64 0.3.65-3 are installed.  I
> have no idea whether the pipewire issue 3194 at gitlab.freedesktop.org
> resolves it or not.
>

As explained in the upstream bug, these warnings messages have been demote
to only log messages, nothing to worry about.

Bug#1037941: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?

[Dylan Aïssi]

Le mer. 14 juin 2023 à 17:03, AlMa  a écrit :
>
> What is SPA? The package pipewire-libcamera is NOT installed; it seems
> to be not recommended or even suggested by any other package. So besides
> a guess based on the name (and pipewire-libcamera may or may not be
> relevant), there's no way of knowing how to get rid of this error.  So
> who is the culprit and what to do?
>

What is the actual error you are facing?
"PipeWire's libcamera SPA missing or broken. libcamera not supported" is only
a log message (not even a warning) saying indeed the plugin provided by
pipewire-libcamera is not installed. SPA is for "Simple Plugin API" is the
pipewire's plugin API. If you don't know what is libcamera then you
probably don't need to install pipewire-libcamera. I can add it in suggested
package of wireplumber though, but again this is not an error only a log
message.

Bug#1037286: transition: libcamera 0.0.5

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for libcamera 0.0.5.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 0.3.71-1) builds fine with the
new libcamera in experimental.

Thanks,
Dylan

Bug#1035081: RFC: onnxruntime packaging

[Dylan Aïssi]

Hello,

I have finalized [1] the package of onnxruntime and have sent it to the
NEW queue [2]. I only enabled features I need. A review and/or improvements
are welcome :-).

Best,
Dylan

[1] https://salsa.debian.org/deeplearning-team/onnxruntime
[2] https://ftp-master.debian.org/new/onnxruntime_1.12.1+dfsg-1.html

Bug#981285: Please move fdk-aac to main

[Dylan Aïssi]

Hello ftpmasters,

First of all, thanks for your hard work!

May I ask about the status of the request to move the fdk-aac package into
main? A new version moving fdk-aac in main was uploaded in the NEW queue on
the 31 Jan 2022, but if I am not wrong, there has been no feedback yet
(at least not in #981285).

I am asking because regularity, pipewire users ask me why AAC support is
disabled in the pipewire package whereas it is enabled in others distributions.

I'm sure the decision is not obvious otherwise it would not be the oldest
package in the NEW queue :-) but it would be nice to have an update of your
point of view on that. A "yes", "no" or "maybe" one of them would be enough :-)

Thank you for your time!

Best regards,
Dylan

Bug#1036731: python3-debian: fails to parse some debian/control.in files

[Dylan Aïssi]

Package: python3-debian
Version: 0.1.49

Hello,

python3-debian is not able anymore to parse correctly some debian/control.in.
The first version with this issue is 0.1.44, so I suppose it is related to the
new RTS parser. The consequence of this bug is wrap-and-sort crashes when it
run on these files. Below is the error message:

Traceback (most recent call last):
  File "/usr/bin/wrap-and-sort", line 496, in 
main()
  File "/usr/bin/wrap-and-sort", line 481, in main
modified_files = wrap_and_sort(args)
 ^^^
  File "/usr/bin/wrap-and-sort", line 312, in wrap_and_sort
control = WrapAndSortControl(control_file, args)
  ^^
  File "/usr/bin/wrap-and-sort", line 99, in __init__
super().__init__(filename, use_rts_parser=args.rts_parser)
  File "/usr/lib/python3/dist-packages/devscripts/control.py", line
210, in __init__
self._deb822_file = parse_deb822_file(sequence)
^^^
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py",
line 3095, in parse_deb822_file
deb822_file = Deb822FileElement(LinkedList(tokens))
^^
  File "/usr/lib/python3/dist-packages/debian/_util.py", line 159, in __init__
self.extend(values)
  File "/usr/lib/python3/dist-packages/debian/_util.py", line 272, in extend
for v in values:
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 104, in _impl
for token in token_stream:
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 104, in _impl
for token in token_stream:
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py",
line 2991, in _build_field_with_value
value_element = next(buffered_stream, None)
^^^
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 143, in __next__
return next(self._stream)
   ^^
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 104, in _impl
for token in token_stream:
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py",
line 2939, in _build_value_line
tokens_in_value = list(buffered_stream.takewhile(_non_end_of_line_token))
  ^^^
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 149, in takewhile
while buffer or self._fill_buffer(5):

  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 198, in _fill_buffer
self._buffer.append(next(self._stream))
^^
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py",
line 104, in _impl
for token in token_stream:
  File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py",
line 3031, in _abort_on_error_tokens
raise SyntaxOrParseError(
debian._deb822_repro.types.SyntaxOrParseError: Syntax or Parse error
on the line: "%if USE_SYSTEM_ZLIB\n"

An easy way to reproduce the crash is to run wrap-and-sort on the
debian/ folder of
firefox-esr:
> wget 
> http://deb.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_102.11.0esr-1.debian.tar.xz
> tar -xvf firefox-esr
> wrap-and-sort

It crashes in a similar way on these packages: babel-minify and xapian-bindings.

Best regards,
Dylan

Bug#1034462: Pipewire: Inappropriate ioctl for device

[Dylan Aïssi]

Hello,

Le dim. 16 avr. 2023 à 01:42, Al Ma  a écrit :
>
> $ sudo aptitude show pipewire| grep Version
>
> Version: 0.3.56-1

This version is not available in Bullseye, can you upgrade to the latest version
available in bullseye-backports (i.e. 0.3.65-2~bpo11+1)?

> $ sudo aptitude show pipewire-media-session | grep Version
>
> Version: 0.4.1-3

pipewire-media-session is dead upstream, instead it would be better to switch to
wireplumber. 0.4.13-1~bpo11+1 is available in bullseye-backports.

Bug#1025453: Is there any update

[Dylan Aïssi]

Le sam. 18 mars 2023 à 14:51, graeme vetterlein
 a écrit :
>
> I, for one, have had no sound for the past 4 months. Not personally critical 
> as it's an unstable dev system, not main dev machine.
>

Do you have no sound at all or choppy sound like you said in [1].
Have you tried using speakers not connected via HDMI? I guess it is related
to HDMI connection, can you fill a bug on the upstream bug tracker [2]?

[1] https://bugs.debian.org/1025453#40
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Bug#1033118: unblock: libcamera/0.0.3-6

[Dylan Aïssi]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Dear Release Team,

Could you please unblock the key package libcamera/0.0.3-6?

[ Reason ]
Open source IPA (Image Processing Algorithms) modules are signed at build time
allowing them to be trusted. However, IPA binaries are modified by dh_strip
invalidating the signatures. Thus IPA modules provided in the package are not
trusted anymore and need to be re-signed after the dh_strip step. This fix is
applied in 0.0.3-5 and improved in 0.0.3-6.

[ Impact ]
Not resigning IPA modules will make them untrusted, they will be isolated
inside a Sandbox environment with restricted access to the system (like any
closed-source module). Provided IPA modules won't work as expected.

[ Tests ]
The test requires supported hardware but it was tested in a Apertis (a Debian
derivative distrib). Some superficial tests have been added at the same time in
0.0.3-5 to detect early crashes as seen in a previous version.

[ Risks ]
The risk is low since we only regenerate signatures after dh_strip, i.e.
/usr/lib/*/libcamera/ipa_.so.sign files.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock libcamera/0.0.3-6

Best,
Dylan
diff -Nru libcamera-0.0.3/debian/changelog libcamera-0.0.3/debian/changelog
--- libcamera-0.0.3/debian/changelog	2023-01-24 21:36:29.0 +0100
+++ libcamera-0.0.3/debian/changelog	2023-03-06 10:40:47.0 +0100
@@ -1,3 +1,20 @@
+libcamera (0.0.3-6) unstable; urgency=medium
+
+  * Use the DEB_HOST_GNU_TYPE for the build directory.
+
+ -- Andrej Shadura   Mon, 06 Mar 2023 10:40:47 +0100
+
+libcamera (0.0.3-5) unstable; urgency=medium
+
+  [ Dylan Aïssi ]
+  * Add superficial tests.
+  * Add allow-stderr for tests.
+
+  [ George Kiagiadakis ]
+  * Add rule to re-sign the IPA modules after dh_strip.
+
+ -- Andrej Shadura   Mon, 06 Mar 2023 09:45:00 +0100
+
 libcamera (0.0.3-4) unstable; urgency=medium
 
   * Add doxygen-latex in Build-Deps
diff -Nru libcamera-0.0.3/debian/.gitignore libcamera-0.0.3/debian/.gitignore
--- libcamera-0.0.3/debian/.gitignore	1970-01-01 01:00:00.0 +0100
+++ libcamera-0.0.3/debian/.gitignore	2023-03-06 10:40:47.0 +0100
@@ -0,0 +1,2 @@
+!patches/
+!*.patch
diff -Nru libcamera-0.0.3/debian/rules libcamera-0.0.3/debian/rules
--- libcamera-0.0.3/debian/rules	2023-01-24 21:36:29.0 +0100
+++ libcamera-0.0.3/debian/rules	2023-03-06 10:40:47.0 +0100
@@ -25,6 +25,12 @@
 	# For now, testsuite failures are ignored
 	-dh_auto_test
 
+override_dh_strip:
+	dh_strip -a
+	MESON_INSTALL_DESTDIR_PREFIX=. ./src/ipa/ipa-sign-install.sh \
+		./obj-${DEB_HOST_GNU_TYPE}/src/ipa-priv-key.pem \
+		debian/libcamera-ipa/usr/lib/${DEB_HOST_MULTIARCH}/libcamera/ipa_*.so
+
 .PHONY: licensecheck
 licensecheck:
 	licensecheck --deb-machine -r * \
diff -Nru libcamera-0.0.3/debian/tests/control libcamera-0.0.3/debian/tests/control
--- libcamera-0.0.3/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ libcamera-0.0.3/debian/tests/control	2023-03-06 10:40:47.0 +0100
@@ -0,0 +1,3 @@
+Tests: run-tools
+Depends: @
+Restrictions: superficial, allow-stderr
diff -Nru libcamera-0.0.3/debian/tests/run-tools libcamera-0.0.3/debian/tests/run-tools
--- libcamera-0.0.3/debian/tests/run-tools	1970-01-01 01:00:00.0 +0100
+++ libcamera-0.0.3/debian/tests/run-tools	2023-03-06 10:40:47.0 +0100
@@ -0,0 +1,7 @@
+#!/bin/sh -e
+# autopkgtest check: Run cam and lc-compliance both with the --list option.
+
+cam --list
+
+lc-compliance --list
+

Bug#1031700: Audio s/pdif selection in gnome quick settings (bookworm )

[Dylan Aïssi]

Hi,

Le mer. 22 févr. 2023 à 18:27,  a écrit :
>
> the issue, looks like this description
>
> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6207

If it is the same bug then it is not a pipewire bug but a gnome-shell
bug which was fixed in gnome-shell 43.3.
This version of gnome-shell has migrated into debian/testing three days ago.

Are you still able to reproduce it or is it solved?

Best,
Dylan

Bug#1031396: Unable to upgrade to *gnome* 1:43+1 with `apt full-upgrade`

[Dylan Aïssi]

Hi,

This seems to be solved by adding pulseaudio-module-bluetooth in Conflicts and
Replaces of pipewire-audio. pipewire-audio already conflicts and replaces
pulseaudio for some reasons, but looks like it is not enough.

Best regards,
Dylan

Bug#1031002: ITP: libavtp -- Audio Video Transport Protocol (AVTP)

[Dylan Aïssi]

Package: wnpp
Severity: wishlist
Owner: Dylan Aïssi 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-multime...@lists.debian.org

* Package name: libavtp
* URL: https://github.com/Avnu/libavtp
* License: BSD-3-clause

Audio Video Transport Protocol (AVTP) specified in IEEE 1722-2016 spec.

Remark: This package is maintained by Debian Multimedia Team at:
  https://salsa.debian.org/multimedia-team/libavtp

Bug#1029272: libasound2: Backport to stable for use with newer UCMs

[Dylan Aïssi]

Hello Jordi,

On Fri, 20 Jan 2023 15:02:50 + "Nicolas F. R. A. Prado"
 wrote:
>
> I'd like to request for this package to be backported to stable. Some
> machines, like Lenovo Chromebook N23 Yoga (mt8173-elm-hana), depend on
> UCM files to have working audio, and the UCM file for them is only
> available in more recent versions of alsa-ucm-conf. Since these newer
> UCM files also use more recent syntax versions (Syntax 4, and up to 6),
> a newer libasound2 is also needed. So by backporting both libasound2 and
> alsa-ucm-conf we can get audio working on these machines running stable.
>

Do you have an opinion on this request? If you don't have time, I can do it.

Best regards,
Dylan

Bug#1025427: pipewire: frequent crashes on x11 bell

[Dylan Aïssi]

Hi,

Le mer. 8 févr. 2023 à 13:00, Tomas Janousek  a écrit :
>
> Can we please cherry-pick 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/5552ff7fdd76116e10911ddedfeb7927db6d500e
>  and 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/fda829a1fa011c11808b151af135fa5c4dd9bf65
>  to make it possible to disable x11-bell? Even if it didn't crash, it's 
> certainly not desirable to have audible bell that cannot be disabled via 
> "xset b off" or some other sane means… And the reality on my machine is that 
> this audible bell happens to make a sound only a fraction of the time, most 
> of the time does nothing, and often just crashes pipewire.
>

I am not against backporting fixes, but to mitigate this issue I moved the
x11-bell module into its own package (since pipewire 0.3.63-3).
This new libpipewire-0.3-modules-x11 package is not pulled by dependencies, so
if you don't want to use this x11-bell module, it is possible to just uninstall
libpipewire-0.3-modules-x11.

Best,
Dylan

Bug#1030765: pipewire-media-session is dead upstream

[Dylan Aïssi]

Package: pipewire-media-session
Severity: important
Tags: trixie

pipewire-media-session is dead upstream and must not be shipped with Trixie.
Wireplumber must be used instead.

https://gitlab.freedesktop.org/pipewire/media-session/-/commit/80dae7e2

Bug#1030332: libcamera0.0.3:amd64: crashes wireplumber/pipewire sometimes when camera appears

[Dylan Aïssi]

Hello,

Le ven. 3 févr. 2023 à 01:27, Tomas Janousek  a écrit :
>
> When a USB camera appears (usbguard allow-device …, or just
> echo 1 >/sys/…/authorized), the pipewire and/or wireplumber processes 
> sometimes segfault in libcamera. Not always, but doing usbguard block-device 
> followed by usbguard allow-device a couple times makes them crash eventually. 
> I can reproduce this with the integrated camera on two different ThinkPads 
> made a couple years apart, the T25 and P14s Gen2i.
>

What versions of pipewire and wireplumber do you use?

Can you try to reproduce with libcamera 0.0.4 in experimental? But because of
a soname change, you would need to rebuild pipewire against the new libcamera.

Best,
Dylan

Bug#1029763: pipewire: does not seem to work unless xdg-desktop-portal is running

[Dylan Aïssi]

Hello,

Le sam. 28 janv. 2023 à 12:00, Wouter Verhelst  a écrit :
>
>
> I did not install pipewire manually; it was installed through dependencies.
>

It would be great to understand how pipewire pkgs have been pulled on your
system since I don't know which packages are installed by awesome. But that
could be non trivial as the dependency responsible for this may no longer
exist.

> In the mean time I removed pipewire as a workaround, but looking through
> dpkg.log told me how to reproduce it. If I have these installed, there
> is no audio:
>
> wouter@pc220518:~$ dpkg -l |grep pipewire
> ii  libpipewire-0.3-0:amd64   0.3.65-1
>  amd64libraries for the PipeWire multimedia server
> ii  libpipewire-0.3-modules:amd64 0.3.65-1
>  amd64libraries for the PipeWire multimedia server - 
> modules
> ii  pipewire:amd640.3.65-1
>  amd64audio and video processing engine multimedia 
> server
> ii  pipewire-bin  0.3.65-1
>  amd64PipeWire multimedia server - programs
> ii  pipewire-media-session0.4.2-1 
>  amd64example session manager for PipeWire
> ii  pipewire-pulse0.3.65-1
>  amd64PipeWire PulseAudio daemon
>
>
> I'm guessing the problem is that "pipewire-pulse" is installed (which
> redirects pulseaudio stuff to pipewire), but "pipewire-audio" isn't
> (meaning there's nowhere for the audio to go)
>
> This guess is supported by the fact that if I run "pavucontrol" and go
> to the "Configuration" tab, it says there are no devices available.
>

So, the real issue is when both pipewire-media-session and pipewire-pulse are
pulled by dependencies. This breaks sound and users have to create an empty file
to make the sound working. This empty file has been deleted because of some
conflicts with pulseaudio in the past https://bugs.debian.org/1006364.
But, I will create a new package for them and make pipewire-pulse
recommend wireplumber or this new package.

> I don't "want" to use pipewire, it was (partially) installed on my
> system and broke all audio ;-)

If you don't want to use pipewire, you can remove pipewire-pulse and
wireplumber/pipewire-media-session. If you want to use pipewire only for
screen-sharing (but I doubt based on your previous message), you can keep
pipewire-media-session but be sure to not have the file:
  /usr/share/pipewire/media-session.d/with-pulseaudio

Best regards,
Dylan

Bug#1029763: pipewire: does not seem to work unless xdg-desktop-portal is running

[Dylan Aïssi]

Hello Wouter,

Le ven. 27 janv. 2023 à 11:00, Wouter Verhelst  a écrit :
>
> The pipewire upstream troubleshooting guide suggests I look at
> journalctl output as a first step in troubleshooting things. That
> reveals:
>
> wouter@pc220518:~$ journalctl -xe | grep pipewire
> jan 27 11:04:01 pc220518 pipewire[2111]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:01 pc220518 pipewire[2111]: mod.rt: found session bus but no 
> portal
> jan 27 11:04:01 pc220518 pipewire-media-session[2113]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:01 pc220518 pipewire-media-session[2113]: mod.rt: found session 
> bus but no portal
> jan 27 11:04:01 pc220518 dbus-daemon[1042]: [system] Activating via systemd: 
> service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' 
> requested by ':1.33' (uid=127 pid=2113 comm="/usr/bin/pipewire-media-session")
> jan 27 11:04:01 pc220518 pipewire-pulse[2114]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:01 pc220518 pipewire-pulse[2114]: mod.rt: found session bus but 
> no portal
> jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: found session bus but no 
> portal
> jan 27 11:04:53 pc220518 pipewire-media-session[2730]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:53 pc220518 pipewire-media-session[2730]: mod.rt: found session 
> bus but no portal
> jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: found session bus but 
> no portal
> wouter@pc220518:~$ journalctl -xe | grep wireplumber
> wouter@pc220518:~$ journalctl --user-unit=pipewire --user-unit=wireplumber 
> --user-unit=pipewire-pulse -f
> jan 27 11:04:52 pc220518 systemd[2708]: Started PipeWire Multimedia Service.
> jan 27 11:04:53 pc220518 systemd[2708]: Started PipeWire PulseAudio.
> jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: found session bus but no 
> portal
> jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: Can't find 
> org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
> jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: found session bus but 
> no portal
>
> I use awesomewm, which probably doesn't require xdg-desktop-portal and
> therefore doesn't start it.

xdg-desktop-portal is only used by pipewire for screen-sharing. If you don't
have it, then pipewire will just not be able to do screen-sharing, but will work
correctly for the audio part. What do you mean by it doesn't start it? Do you
mean you don't have sound at all?

I don't see real issues in this log, or maybe yes you are using
pipewire-media-session instead of wireplumber. pipewire-media-session is dead
upstream see [1]. We keep it in Debian (for now) only for those who want to use
pipewire for screen-sharing only and not for the audio part because it is easier
to configure pms than wireplumber for this use. If you want to use pipewire for
sound you should use wireplumber instead. I recently added a metapackage
pipewire-audio to help users selecting pipewire packages. Please note this
package is in conflict with pulseaudio to avoid potential conflicts, but you can
take inspiration from dependencies of pipewire-audio if you want to keep
pulseaudio installed.

[1] 
https://gitlab.freedesktop.org/pipewire/media-session/-/commit/80dae7e24bec02b2befe09a72fbac6e2b38ccb5c

Best regards,
Dylan

Bug#1029648: gnome-core 1:43+1 not installable with Pulseaudio

[Dylan Aïssi]

Hello,

Le mer. 25 janv. 2023 à 22:13, Simon McVittie  a écrit :
>
> Pipewire maintainers: do you have an opinion on whether gnome-core should
> return to depending on the individual dependencies of pipewire-audio,
> rather than on the metapackage?

I intentionally marked pipewire-audio in conflict with pulseaudio even if there
is no technical reason for that (here I have both pulseaudio and pipewire-pulse
installed without any issue). The reason of this metapackage and its conflict
with pulseaudio is because for different reasons, users complained and filled
bugs about broken configs. The origins of these broken configs are differents
and not related to the pipewire packages. For example, it could be because they
didn't install the recommended packages (wireplumber without pipewire-pulse), or
because some packages where pinned leading to a non-functional combination of
packages. Some others followed outdated guides from random websites to switch
from pulseaudio to pipewire with as result weird conflicts with pulseaudio.
The aim of this package is to avoid common users mistakes leading to no audio.
I am annoyed for them since pipewire-pulse just works but because I have limited
time, I cannot figure what they did wrong for all of them.

I don't have a strong opinion whether gnome-core should depend on pipewire-audio
or on individual dependencies. If they follow the recommendation an upgrade from
Bullseye to Bookworm without having to conflict on pulseaudio will work
correctly. So, maybe would be better to have gnome-core not depending on
pipewire-audio to not hurt users who still want to use pulseausio leaving
optional pipewire-audio (and its conflict with pulseaudio). After all, users
complaining about a pkg conflicts between pipewire and pulseaudio had no real
reason (excepted [1]) to keep both installed just because I guess they were a
bit prudent about this transition.

[1] https://bugs.debian.org/1029377#20

> I'm not sure that I understand why pipewire-alsa and pipewire-audio need
> to conflict with pulseaudio. Would it be sufficient to rename
> /etc/alsa/conf.d/99-pipewire-default.conf to sort later than 99-pulse.conf,
> or ask the pulseaudio maintainers to rename /etc/alsa/conf.d/99-pulse.conf
> to sort slightly earlier? That would restore the older behaviour in which
> installing both pulseaudio and the equivalent of pipewire-audio is possible,
> and Pipewire "wins"?

Yes, that is correct. It's not implemented just because nobody asked for it.

> On Wed, 25 Jan 2023 at 15:10:52 -0500, Rann Bar-On wrote:
>
> I think this is a probem!
>
>> Please clarify why this is a problem?
>
> Given the above, my opinion has changed.

We are lacking pedagogy on that. Not sure how we can communicate more on the
pulseaudio to pipewire transition. At least, I will have to refresh the Debian
pipewire wiki page before the release of Bookworm.

> Maybe. I prefer cleaning up packages, so if something is inactive by
> necessity, I think it should be removed.

This is solved by the (optional?) pipewire-audio package which will ensure that
pulseaudio is removed.

Best regards,
Dylan

Bug#1029503: Last upload of spirv-cross breaks API

[Dylan Aïssi]

Hello Release Team,

My last upload of spirv-cross introduced an unexpected (small) API
break [1]. spirv-cross has only two reverse dependencies: filament and
mpv. Only filament is affected by this issue and the patch to fix it
is small and ready.

Now, the question is what should I do because of the freeze? Should I
somehow revert my upload with a new
`2021.01.15+1.3.236.0+real2021.01.15` version? Should I fix filament
or should I keep
the RC #1029503 open against the new version of spirv-cross?

Thanks for your advice,
Dylan

[1] https://bugs.debian.org/1029503
[2] https://salsa.debian.org/roehling/filament/-/merge_requests/2

Bug#996856: libcamera: Update package to a more recent version

[Dylan Aïssi]

Hello,

Since libcamera 0.0.2, I did several packaging changes. Are there any
other change required or can we close this bug?

Best regards,
Dylan

Bug#1029377: pipewire-pulse: Please remove Recommends: pipewire-alsa

[Dylan Aïssi]

Hello Erich,

Le dim. 22 janv. 2023 à 00:45, Erich Eickmeyer  a écrit :
>
> The introduction of the "Recommends: pipewire-alsa" line in the debian/control
> file has reintroduced the problem resolved by bug #1020903 in which pipewire-
> pulse is causing a conflict with pulseaudio, albiet indirectly this time.
>
> As pipewire-pulse is now soft-depending on pipewire-alsa, which does directly
> conflict with pulseaudio. This is causing a package conflict, especialy when
> seeded, when pulseaudio is installed and is causing the Ubuntu Studio seed to
> fail to build.
>
> Ubuntu Studio was intending to include, in their built-in-house Studio 
> Controls
> utility, a way to easily switch between the traditional Pulseaudio/JACK setup
> and the Pipewire setup. Unfortunately, this recommends line, however well-
> intentioned, completely broke that.
>
> My recommendation is to demote pulseaudio-alsa to a Suggests in this case.
>

I removed pipewire-alsa from depends field of pipewire-pulse. Instead, I created
a new metapackage pipewire-audio that depends on a set of pipewire packages
recommended for a standard audio use of pipewire. A large part of bug reports
against pipewire and wireplumber are mainly from users with broken
config because
they don't follow/install recommended packages. I guess this new package should
make that clearer.

I agree that pulseaudio and pipewire-pulse can be installed together
at same time,
but for whatever reasons several users have reported conflicts between them. And
it seems easier (at least for standard users of pipewire for audio) to
add a conflict
between them, but I guess users of Ubuntu Studio don't have a standard use of
pipewire. This brings me to the question, why do you want both pulseaudio and
pipewire-pulse to be co-installable?

Best regards,
Dylan

Bug#1029447: unmuting audio breaks video playing in browsers

[Dylan Aïssi]

Control: severity -1 normal

Le dim. 22 janv. 2023 à 18:15, Marco d'Itri  a écrit :
>
> If I replace pipewire-media-session with wireplumber then playing video
> in browsers (e.g. Youtube and other similar sites, or even just embedded
>  tags) stutters and stops. Just pressing the mute button in the
> video player makes video work as usual, 100% reproducibile.
> I have reproduced this both with Firefox and Chrome.
>
> Installing again pipewire-media-session and rebooting fixed this.
>

Not reproducible here.

With wireplumber installed and after a reboot what is the output of
"pactl info"?
And what audio backend uses firefox (in "about:support" then in the
"Audio section" )?
Do you have both  wireplumber.service and pipewire-pulse.service running?

Thanks,
Dylan

Bug#1028034: Fwd: Re: pipewire | Multi-profile bluetooth headphones show only a2dp profile (#2936)

[Dylan Aïssi]

Hello,

Le ven. 6 janv. 2023 à 21:48, Dylan Aïssi  a écrit :
>
> Le ven. 6 janv. 2023 à 19:57, Bob Hauck  a écrit :
> >
> > There was apparently a bug already filed and closed about this. Subsequent 
> > to my report I received the following note that there is a commit to master 
> > that fixes the issue.
> >> Distro maintainers including the Debian one were notified on December 27th 
> >> that they should consider applying the commit c7b3ef0d but it was during 
> >> the holiday season and only a maybe, so I'm not sure if that fix was 
> >> deployed to Debian or not.
> >
>
> I just uploaded a new package version with this upstream fix.
> 0.3.63-2 should be available soon in debian/unstable.
>

Debian/testing provides pipewire 0.3.63-4 that contains the upstream fix.
Can you confirm that your issue is fixed?

Thanks,
Dylan

Bug#1026768: vulkan-loader: please consider packaging version 1.3.238

[Dylan Aïssi]

Hi,

On Tue, 3 Jan 2023 14:55:47 +0200 Timo Aaltonen  wrote:
> Andrea Pappacoda kirjoitti 20.12.2022 klo 22.01:
> > By looking at  it seems
> > that version 1.3.238 has been tagged with a "v" prefix, and not with an 
> > "sdk-"
> > one; this means that this version is still in development, right?
>
> Correct, only sdk-releases have consistent tags across the stack
> (including glslang, spirv-tools etc).

In the meantime, can we have the sdk-1.3.236.0 tag packaged? I would
need it to update gfxreconstruct to 0.9.16.1 in order to fix its FTBFS
issue. I can help if needed.

Thanks,
Dylan

Bug#1028034: Fwd: Re: pipewire | Multi-profile bluetooth headphones show only a2dp profile (#2936)

[Dylan Aïssi]

Thanks!

Le ven. 6 janv. 2023 à 19:57, Bob Hauck  a écrit :
>
> There was apparently a bug already filed and closed about this. Subsequent to 
> my report I received the following note that there is a commit to master that 
> fixes the issue.
>> Distro maintainers including the Debian one were notified on December 27th 
>> that they should consider applying the commit c7b3ef0d but it was during the 
>> holiday season and only a maybe, so I'm not sure if that fix was deployed to 
>> Debian or not.
>

I just uploaded a new package version with this upstream fix.
0.3.63-2 should be available soon in debian/unstable.

Best,
Dylan

Bug#1028034: pipewire: Multi-profile bluetooth headphones show only a2dp profile.

[Dylan Aïssi]

Hi Bob,

Le ven. 6 janv. 2023 à 05:21, Bob Hauck  a écrit :
>
>* What was the outcome of this action?
> My adapters support both hfp and a2dp profiles but only a2dp shows up
> in pavucontrol and in KDE audio configuration. The a2dp profile does
> work with LDAC and AptX codecs so it is not totally broken.
>
>* What outcome did you expect instead?
> Both hfp and ad2p profiles should appear in pavucontrol configuration
> tab. This was the case in previous versions.

Could you please report this issue to the upstream bug tracker?
 https://gitlab.freedesktop.org/pipewire/pipewire

Thanks!

Best,
Dylan

Bug#1027762: Regression Pipewire 0.63 breaks underruns breaking emacspeak accessibility

[Dylan Aïssi]

Control: found -1 0.3.61-1

Works with 0.3.60-3 but fails with 0.3.61-1. Now, we have the version
introducing this regression.

Bug#1027289: transition: libcamera

[Dylan Aïssi]

Hi Sebastian,

Le sam. 31 déc. 2022 à 13:19, Sebastian Ramacher  a
écrit :
>
> On 2022-12-29 23:01:28 +0100, Dylan Aïssi wrote:
> > Dear Release Team,
> >
> > Please schedule a transition slot for libcamera.
> >
>
> Please go ahead

Thanks. Uploaded!

Best,
Dylan

Bug#1027289: transition: libcamera

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition slot for libcamera.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 0.3.63-1) builds fine with the
new libcamera in experimental.

Thanks,
Dylan