Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Hi Dylan,
Something in pipewire caused my laptop to lose all audio. Since I work
remotely and need to attend meetings over various video conferencing
tools, that was not an option for me, so I reverted back to pulseaudio
by removing everything from src:pipewire from my laptop and rebooting,
which seems to have "fixed" the issue.
Obviously however, this can't be the right long-term solution, but I
don't know exactly what went wrong.
When I opened an ALSA mixer tool, the mixer was set to 0, and moving it
up would work but then restarting the mixer tool would show it was at 0
again.
Opening pavucontrol would show a single device, called "dummy audio
device" (paraphrasing), with no way to select another device.
I'm not familiar enough yet with pipewire to know which tools to use to
debug what went wrong. Can you point me to the relevant docs? Once I
have a better idea of what went wrong, expect a bug report coming your
way ;-)
Thanks,
On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> Hi,
>
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.
>
> As you know, PipeWire is already installed by default with Bullseye (at least
> with Wayland environments) for screen-sharing. PipeWire was not mature enough
> to use it as default sound server for Bullseye, but since it gained in
> stability, features and popularity. Several other major distributions
> (Fedora, Ubuntu is doing the switch with 22.10) have switched to PipeWire
> for audio [1-3].
>
> We cannot talk about PipeWire without mentioning its session manager.
> Thus, this change should go along the switch of the default session manager,
> i.e. from the deprecated pipewire-media-session to WirePlumber.
> We still use pipewire-media-session as default session manager because it
> enables PipeWire *only* for screen-sharing and not for managing audio.
> Whereas WirePlumber always configures PipeWire for audio excepted by modifying
> conf files in a non-compatible packaging way. This issues was also hit on
> the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
> major release 0.5 planned later this year.
>
> BTW, I just uploaded latest PipeWire and WirePlumber in bullseyes-backports
> (still in the NEW queue) to allow more users to test them.
>
> Best,
> Dylan
>
> [1] https://fedoraproject.org/wiki/Changes/DefaultPipeWire
> [2] https://fedoraproject.org/wiki/Changes/WirePlumber
> [3] https://wiki.ubuntu.com/ImpishIndri/ReleaseNotes
> [4]
> https://archlinux.org/news/undone-replacement-of-pipewire-media-session-with-wireplumber/
>
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1021300: ITP: ocaml-uucp -- access properties of Unicode characters
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uucp Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uucp * License : ISC Programming Lang: OCaml Description : access properties of Unicode characters This low-deps library gives access to properties of Unicode characters of the Unicode character database. It is a dep of a new dep for ocaml-cohttp. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Hi Wouter, Le mer. 5 oct. 2022 à 09:21, Wouter Verhelst a écrit : > > I'm not familiar enough yet with pipewire to know which tools to use to > debug what went wrong. Can you point me to the relevant docs? Once I > have a better idea of what went wrong, expect a bug report coming your > way ;-) > You can find the upstream troubleshooting guide here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting I should add a paragraph about that on our wiki. In any case, feel free to open a "it doesn't work" bug against the pipewire package :-) Best, Dylan
Bug#1021313: ITP: golang-github-aymanbagabas-go-osc52 -- Golang terminal ANSI OSC52 wrapper
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-devel@lists.debian.org, vil...@debian.org * Package name: golang-github-aymanbagabas-go-osc52 Version : 1.0.3-1 Upstream Author : Ayman Bagabas * URL : https://github.com/aymanbagabas/go-osc52 * License : Expat Programming Lang: Go Description : Golang terminal ANSI OSC52 wrapper A terminal Go library to copy text to clipboard from anywhere. It does so using ANSI OSC52. The Copy() function defaults to copying text from terminals running locally. This package is a new B-D for golang-github-muesli-termenv.
Re: debos should depend on systemd-resolved
Hi, > > So far, the package fakemachine Depends on systemd, and that was enough. > > Now with the split, and since we need systemd-resolved, we should make > > fakemachine Depend on systemd-resolved as well. However, and if I > > understand properly, installing systemd-resolved also *enables* it. A > > user installing the package is saying: I want name resolution to be done > > by systemd-resolved. Therefore it's not really suitable to put it in a > > Depend or a Recommend. fakemachine only needs the code from > > systemd-resolved (lib and binary, I suppose), but it definitely doesn't > > want to enable it: this decision belongs to the user. > > > > Does that make sense so far? Many times I have got the same feeling/need about packages like apache2, tomcat, etc. I would like to install and maintain them up-to-date using their Debian package distribution, but having a facility to not activate their (default) root/system- land and provide a facility for a user-land activation. In general it is possible in fact, I have achieved such for at least the two apache2 and tomcat ones. I mean for such packages providing a way to activate them-self in the root/system-land as well as a (general?) facility for a user- land service. I know that having a general approach to solve this is somehow infeasible. But despite this could it be really interesting (at least for my pov) to think about it and therefore a good candidate for a grow-your-idea-for- Debian-Project ticket? Best, Patrice
Moving netboot debian-installer binaries out of main?
> "Steve" == Steve McIntyre writes: Steve> Hi all! [ I've also blogged about this - see Steve> https://blog.einval.com/2022/10/02#firmware-vote-result ] Steve> I'm assuming that there will be no surprises and Kurt will Steve> shortly confirm the result that devotee reported already Steve> [1]. :-) Steve> We have quite a few things to do now, ideally before the Steve> freeze for Debian 12 (bookworm), due January 2023 [2]. This Steve> list of work items is almost definitely not complete, and Steve> Cyril and I are aiming to get together this week and do more Steve> detailed planning for the d-i pieces. Off the top of my head Steve> I can think of the following: Steve> If you think I've missed anything here, please let me and Steve> Cyril know - the best place would be the mailing list Steve> (debian-b...@lists.debian.org). If you'd like to help Steve> implement any of these changes, that would be lovely too! So, for each architecture there are packages in main like debian-installer-12-netboot-archname I'm assuming the plan is to include firmeware into the initrds for these images. As an example, you'd probably want GPU firmware in the gtk images and probably want sound firmware:-) Also, presumably any network firmware. We revised the social contract by adding: >The Debian official media may include firmware that is otherwise not >part of the Debian system to enable use of Debian with hardware that >requires such firmware. So, the official installer images can include the firmware. But as far as I can tell we did not either 1) revise the DFSG or 2) revise the definition of the main section of the archive. So at least in my reading, these binary packages will no longer qualify for the main section of the archive. I think that technically this is probably not a big deal, unless we get into a situation where for example we decide we want a source package in main building binaries in wherever we decide to move these netboot images. Also, I guess there's a question of whether we move the images to non-free or non-free-firmware. Presumably non-free-firmware would make them more available. --Sam signature.asc Description: PGP signature
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: > On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: > >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >> > What's the plan for upgraded systems with an existing > >> > /etc/apt/sources.list. > >> > Will the new n-f-f section added on upgrades automatically(if non-free > >> > was > >> > enabled before)? > >> > >> So this is the one bit that I don't think we currently have a good > >> answer for. We've never had a specific script to run on upgrades (like > >> Ubuntu do), so this kind of potentially breaking change doesn't really > >> have an obvious place to be fixed. > > > >Is there a reason to not continue to make the packages available in non-free? > >I don't see a reason to force any change on existing systems. > > Two things: > > 1. I'm worried what bugs we might expose by having packages be in two > components at once. > 2. I really don't like the idea of leaving two different > configurations in the wild; it'll confuse people and is more > likely to cause issues in the future IMHO. > > Plus, as Shengjing Zhu points out: we already expect people to manage > the sources.list anyway on upgrades. > I think in the absence of a release upgrade script (which I very much doubt will happen, and be tested, and we can rely will be used, for bookworm), Michael's suggestion seems like a reasonable way forward. I imagine we'll need to patch dak to allow that, but it seems like it should be tractable? Cheers, Julien
