Bug#1071577: transition: libcamera 0.3.0
Hi, Le mer. 22 mai 2024 à 08:51, Emilio Pozuelo Monfort a écrit : > > > Please schedule a transition slot for libcamera 0.3.0. > > > Go ahead. > Thanks, done! Best regards, Dylan
Bug#1071577: transition: libcamera 0.3.0
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.3.0. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-libcamera.html The unique reverse dep (pipewire 1.0.6-1) builds fine with libcamera 0.3.0 in experimental. Thanks. Best regards, Dylan
Bug#1070041: waybar: wireplumber support disabled in 0.10.2-1
Hello, On Mon, 29 Apr 2024 11:01:52 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= wrote: > > Currently, wireplumber 0.5 is only available in experimental waiting for his > transition slot. wireplumber 0.5 was uploaded to unstable today. Best regards, Dylan
Bug#1070043: transition: wireplumber 0.5
Le dim. 5 mai 2024 à 18:41, Sebastian Ramacher a écrit : > > > Please schedule a transition slot for wireplumber 0.5. > > Please go ahead. > Thanks, uploaded to unstable. Best regards, Dylan
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Hello Andreas, Le mar. 30 avr. 2024 à 17:26, Andreas Henriksson a écrit : > > We now have asahi-audio 2.x in experimental. Please poke us again when > we should upload to unstable (or feel free to NMU asahi-audio to > unstable when you upload wireplumber 0.5.x to unstable). > The release team agreed to go ahead with this transition, so I am going to upload wireplumber in unstable and I will do a nmu for asahi-audio at the same time. Best regards, Dylan
Bug#1070348: pipewire: pipewire-pulse: warningin syslog every second for snap_get_audio_permissions
Hello Sergio and Jeremy, Le sam. 4 mai 2024 à 05:48, Michael Welsh Duggan a écrit : After updating my linux kernel to 6.7.12-1, I keep getting the following message in my syslog, once a second: pipewire-pulse[]: default: snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap audio permissions won't be honored. It seems that snap support in pipewire requires a kernel feature (fine grained unix mediation) that is not yet enabled in Debian. I'm thinking of disabling for now the snap support in Debian since there is no point in keeping it enabled if it's unusable. But, I will keep it enabled for Ubuntu. What do you think? Best regards, Dylan
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
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.
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
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
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
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
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
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#1067886: chromium: Repeated crashes
Package: chromium Version: 123.0.6312.58-1 Severity: important X-Debbugs-Cc: d...@bostoncoop.net, d...@bostoncoop.net After upgrading from 122.0.6261.128-1 to 123.0.6312.58-1, I'm experiencing repeated crashes/thread hangs on many web pages. It seems to happen more often on pages with more complicated scripting. For instance browsing Discord will trigger the crash pretty quickly. Another place I experience frequent crashes is on my university's Canvas page. I downgraded to verify that it wasn't just my memory. I've attach a gdb log from a Discord session. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 123.0.6312.58-1 ii libasound2t641.2.11-1+b1 ii libatk-bridge2.0-0t642.51.90-4 ii libatk1.0-0t64 2.51.90-4 ii libatomic1 14-20240315-1 ii libatspi2.0-0t64 2.51.90-4 ii libc62.37-15.1 ii libcairo21.18.0-3 ii libcups2t64 2.4.7-1.2+b1 ii libdbus-1-3 1.14.10-4+b1 ii libdouble-conversion33.3.0-1+b1 ii libdrm2 2.4.120-2 ii libevent-2.1-7t642.1.12-stable-8.1+b1 ii libexpat12.6.2-1 ii libflac12t64 1.4.3+ds-2.1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.0+dfsg-1 ii libgbm1 24.0.3-1+b1 ii libgcc-s114-20240315-1 ii libglib2.0-0t64 2.78.4-6 ii libgtk-3-0t64 [libgtk-3-0] 3.24.41-4 ii libjpeg62-turbo 1:2.1.5-2+b2 ii libjsoncpp25 1.9.5-6+b2 ii liblcms2-2 2.14-2+b1 ii libminizip1t64 1:1.3.dfsg-3.1 ii libnspr4 2:4.35-1.1+b1 ii libnss3 2:3.99-1 ii libopenh264-72.4.1+dfsg-1 ii libopenjp2-7 2.5.0-2+b3 ii libopus0 1.4-1+b1 ii libpango-1.0-0 1.52.1+ds-1 ii libpng16-16t64 1.6.43-3 ii libpulse016.1+dfsg1-3+b1 ii libsnappy1v5 1.1.10-1+b1 ii libstdc++6 14-20240315-1 ii libwebp7 1.3.2-0.4+b1 ii libwebpdemux21.3.2-0.4+b1 ii libwebpmux3 1.3.2-0.4+b1 ii libwoff1 1.0.2-2+b1 ii libx11-6 2:1.8.7-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon01.6.0-1 ii libxml2 2.9.14+dfsg-1.3+b2 ii libxnvctrl0 535.171.04-1 ii libxrandr2 2:1.5.4-1 ii libxslt1.1 1.1.35-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.15.1-1+b1 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages chromium recommends: ii chromium-sandbox 123.0.6312.58-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.37-15.1 ii libjsoncpp25 1.9.5-6+b2 ii
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
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
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
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
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
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
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
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
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
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
~~ ../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:344:37 - error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. 344 type RequestDuplex = import("undici-types").RequestDuplex; ~~ ../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:360:21 - error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. 360 : typeof import("undici-types").Request; ~~ ../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:367:21 - error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. 367 : typeof import("undici-types").Response; ~~ ../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:374:21 - error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. 374 : typeof import("undici-types").FormData; ~~ ../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:381:21 - error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. 381 : typeof import("undici-types").Headers; ~~ Found 18 errors in the same file, starting at: ../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:325 dh_auto_build: error: cd ./llparse-builder && sh -ex ../debian/nodejs/llparse-builder/build returned exit code 2 Best regards, Dylan
Bug#1061071: transition: libcamera 0.2.0
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.`
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
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.
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
Hi, Do you still have this problem? Best regards, Dylan
Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Le ven. 22 sept. 2023 à 21:25, Sebastian Ramacher a écrit : > > Please go ahead. > Thanks, uploaded. Best regards, Dylan
Bug#1052467: transition: svt-av1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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"
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
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".
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
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
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
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#1038001: librem-ec-acpi-dkms: Patch available upstream
Package: librem-ec-acpi-dkms Version: 0.9.1-4 Followup-For: Bug #1038001 X-Debbugs-Cc: d...@bostoncoop.net There's a patch for this upstream: https://source.puri.sm/nicole.faerber/librem-ec-acpi-dkms/-/commit/cec8c0e8bf1532c9c605f60bb02a2ef0f98e5d77 --Dylan Thurston -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librem-ec-acpi-dkms depends on: ii dkms 3.0.11-2 librem-ec-acpi-dkms recommends no packages. librem-ec-acpi-dkms suggests no packages. -- no debconf information
Bug#1037447: pipewire[…]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
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?
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
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#1037138: linux-image-6.0.0-4-amd64: Linux kernel appears to not be respecting sysctl config value "net.ipv6.conf.all.disable_ipv6=1"
Package: src:linux Version: 6.0.8-1 Severity: normal Tags: ipv6 X-Debbugs-Cc: dizzy@domad.science Dear Maintainer, I am attempting to disable ipv6 entirely on this machine as it being enabled is causing multiple issues with long connection timeouts etc, and I do not have ipv6 support from my ISP nor do I use it locally. However, the generally given advice to set net.ipv6.conf.all.disable_ipv6 to 1 is having no effect, neither setting it in /etc/sysctl.conf nor using command line sysctl. Setting net.conf.ipv6..disable_ipv6 works, and is what I am currently doing for my primary network interface, but I would like ipv6 disabled globally. This appears to be a kernel issue afaict, I'm not 100% up on how the sysctl mechanism works, but yeah. -- Package-specific info: ** Version: Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11) ** Command line: root=UUID=9195fe01-470b-4e23-8bec-110cf1aa12cc ro quiet splash initrd=boot\initrd.img-6.0.0-4-amd64 ** Tainted: OE (12288) * externally-built ("out-of-tree") module was loaded * unsigned module was loaded ** Kernel log: [652201.887641] I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887644] Buffer I/O error on dev sr0, logical block 0, async page read [652201.887653] sr 2:0:0:0: [sr0] tag#7 unaligned transfer [652201.887654] I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887656] Buffer I/O error on dev sr0, logical block 1, async page read [652201.887661] sr 2:0:0:0: [sr0] tag#8 unaligned transfer [652201.887661] I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887662] Buffer I/O error on dev sr0, logical block 2, async page read [652201.887666] sr 2:0:0:0: [sr0] tag#9 unaligned transfer [652201.887667] I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887668] Buffer I/O error on dev sr0, logical block 3, async page read [652201.887672] sr 2:0:0:0: [sr0] tag#10 unaligned transfer [652201.887673] I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887674] Buffer I/O error on dev sr0, logical block 4, async page read [652201.887678] sr 2:0:0:0: [sr0] tag#11 unaligned transfer [652201.887678] I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887679] Buffer I/O error on dev sr0, logical block 5, async page read [652201.887683] sr 2:0:0:0: [sr0] tag#12 unaligned transfer [652201.887684] I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887685] Buffer I/O error on dev sr0, logical block 6, async page read [652201.887689] sr 2:0:0:0: [sr0] tag#13 unaligned transfer [652201.887690] I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [652201.887691] Buffer I/O error on dev sr0, logical block 7, async page read [660275.943849] input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input68 [661843.954123] usb 1-3: USB disconnect, device number 24 [661844.358016] usb 1-3: new full-speed USB device number 25 using xhci_hcd [661844.757670] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea, bcdDevice= 5.0f [661844.757676] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [661844.757677] usb 1-3: Product: Controller [661844.757679] usb 1-3: Manufacturer: Microsoft [661844.757680] usb 1-3: SerialNumber: 303336303030383234323338 [661844.769591] input: Microsoft X-Box One S pad as /devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input69 [663457.496690] usb 1-3: USB disconnect, device number 25 [663457.905293] usb 1-3: new full-speed USB device number 26 using xhci_hcd [663458.237568] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea, bcdDevice= 5.0f [663458.237574] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [663458.237576] usb 1-3: Product: Controller [663458.237577] usb 1-3: Manufacturer: Microsoft [663458.237578] usb 1-3: SerialNumber: 303336303030383234323338 [663458.247343] input: Microsoft X-Box One S pad as /devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input70 [672383.489343] usb 1-3: USB disconnect, device number 26 [672384.599744] usb 1-3: new full-speed USB device number 27 using xhci_hcd [672384.930355] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea, bcdDevice= 5.0f [672384.930361] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [672384.930363] usb 1-3: Product: Controller [672384.930364] usb 1-3: Manufacturer: Microsoft [672384.930366] usb 1-3: SerialNumber: 303336303030383234323338 [672384.940759] input: Microsoft X-Box One S pad as /devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input71 [672631.293810] usb 1-3: USB disconnect, device number 27 [672631.933067] usb 1-3:
Bug#1035081: RFC: onnxruntime packaging
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
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
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
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#1034383: biber: Documentation file biber.pdf not TeXed correctly
Package: biber Version: 2.18-1 Severity: minor X-Debbugs-Cc: d...@bostoncoop.net The file /usr/share/doc/biber.pdf has evidently not been run through LaTeX enough times: all cross-references show up as '??'. -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages biber depends on: ii libautovivification-perl 0.18-2+b1 ii libbusiness-isbn-perl 3.006-1 ii libbusiness-ismn-perl 1.202-1 ii libbusiness-issn-perl 1.005-2 ii libclass-accessor-perl0.51-2 ii libdata-compare-perl 1.27-3 ii libdata-dump-perl 1.25-1 ii libdata-uniqid-perl 0.12-3 ii libdate-simple-perl 3.0300-3+b3 ii libdatetime-calendar-julian-perl 0.107-1 ii libdatetime-format-builder-perl 0.8300-1 ii libdatetime-perl 2:1.59-1 ii libencode-eucjpascii-perl 0.03-1+b2 ii libencode-eucjpms-perl0.07-3+b11 ii libencode-hanextra-perl 0.23-6+b1 ii libencode-jis2k-perl 0.03-2+b1 ii libfile-slurper-perl 0.014-1 ii libipc-run3-perl 0.048-3 ii liblingua-translit-perl 0.29-2 ii liblist-allutils-perl 0.19-1 ii liblist-moreutils-perl0.430-2 ii liblog-log4perl-perl 1.57-1 ii liblwp-protocol-https-perl6.10-1 ii libparse-recdescent-perl 1.967015+dfsg-4 ii libreadonly-perl 2.050-3 ii libregexp-common-perl 2017060201-3 ii libsort-key-perl 1.33-3+b1 ii libtext-bibtex-perl 0.89-1 ii libtext-csv-perl 2.02-2 ii libtext-csv-xs-perl 1.50-1 ii libtext-roman-perl3.5-4 ii libunicode-linebreak-perl 0.0.20190101-1+b5 ii liburi-perl 5.17-1 ii libwww-perl 6.68-1 ii libxml-libxml-simple-perl 1.01-3 ii libxml-libxslt-perl 2.002001-1 ii libxml-writer-perl0.900-2 ii perl [libunicode-collate-perl]5.36.0-7 ii tex-common6.18 Versions of packages biber recommends: ii texlive-bibtex-extra 2022.20230122-3 biber suggests no packages. -- no debconf information
Bug#1025453: Is there any update
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
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 )
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`
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)
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
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
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
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
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
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
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
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
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