Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Wed, Sep 14, 2022 at 11:36 PM Felipe Sateler wrote: > What does "switch right now" mean? Just switching gnome-core? What about > the other users? They would all have to switch their order from > `pulseaudio | pipewire-pulse` to `pipewire-pulse | pulseaudio`. Otherwise > you would have a different audio server depending on which order packages > are installed. Moreover, what about upgrades? Would they be forcefully > upgraded (ie, drop the pulseaudio alternative)? Or would they be allowed > to continue using pulseaudio (which wouldn't migrate them because the > dependency would be satisfied)? This is what I mean with Yes, I noticed the upgrade problem. apt recognizes that the alternate dependency is already satisfied and doesn't install the preferred (first) dependency. So my draft was for gnome-core to unconditionally switch to pipewire: https://salsa.debian.org/gnome-team/meta-gnome3/-/merge_requests/7/diffs For context, gnome-core in Debian 11 "Bookworm" unconditionally depends on pulseaudio. > > This give us 4 months until the "transition and toolchain freeze" on > > 2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is > > also doing the switch) planned to be released on 2022-10-20 [7]. > > Do you know what the transition plan for ubuntu is? Are they patching all > rdeps to switch to `pipewire-pulse`? For Ubuntu Desktop, the ubuntu-desktop-minimal metapackage depends on pipewire-pulse & wireplumber & recommends libspa-0.2-bluetooth. Ubuntu's metapackages are generated using germinate and alternate dependencies aren't supported at all. https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal (Recommends are the lines with parentheses). In general, almost everything in Debian's GNOME metapackages are a hard Depends instead of a Recommends. In our experience, we get a lot of bugs and complaints about things not working correctly because there are a lot of people who believe it's a good idea to disable installing Recommends system-wide and have trouble understanding why their system doesn't run well. Interestingly, in Ubuntu, a lot of the ubuntu-desktop metapackage dependencies are just Recommends. But even there, the sound server is a hard dependency. pipewire and wireplumber are systemd user services. Maybe we just need to write up instructions for disabling PipeWire and switching to PulseAudio. Or maybe we could create a Debian package that handles this. That way we could keep the hard dependency in gnome-core so that upgrades do the expected thing, but there is an easy escape. However, I've not seen a single complaint from Ubuntu about switching to PipeWire. So maybe we still ought to switch gnome-core now to get real feedback. Thank you, Jeremy Bicha
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote: Am 13.09.22 um 18:17 schrieb Antoine Beaupré: I also have the feeling that pipewire has already gone beyond what pulseaudio is capable of in terms of Bluetooth support, but I might be mistaken on that. Interesting. What do you have in mind here? Supported codecs? AptX? I had more success with PA in the past here, but that experience is anecdotal. PA also hasn't stood still, and PA+bluetooth is now working much better than it did even a few months ago.
Re: Bug#1019721: libopenmpi-dev: Cannot uninstall rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such file or directory
On 2022-09-14 Paul Wise wrote: > On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote: >> Is there a way to find all packages built against broken dh-fortran- >> mod so all affected packages can be rebuilt? > I am not sure of the correct regex, but the binary package control > search should work, if it doesn't then you need a local mirror: > https://binarycontrol.debian.net/?q=%2Fusr%2Flib%2F%5C%24multiarch%2Ffortran%2Fgfortran&path= Thank you, I have justed filed a binNMU request #1019876 for the remaining 4 source packages. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 15, 2022 at 08:22:52AM -0400, Michael Stone wrote: > On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote: > > Am 13.09.22 um 18:17 schrieb Antoine Beaupré: > > > I also have the feeling that pipewire has already gone beyond what > > > pulseaudio is capable of in terms of Bluetooth support, but I might be > > > mistaken on that. > > > > Interesting. What do you have in mind here? Supported codecs? AptX? > > I had more success with PA in the past here, but that experience is > > anecdotal. > > PA also hasn't stood still, As far as I can see, the latest "new upstream" upload to unstable was in "2021-08-25" which is more than an year from now, post which there have been few bug fix uploads. More notable upload has been the one that enables gstreamer support I'm not sure if this is what you are pointing towards with "hasn't stood still" https://tracker.debian.org/news/1306307/accepted-pulseaudio-150dfsg1-4-source-into-unstable/ Ofcourse the maintainers of this package are doing an excellent job but from upstream release pov, it is still kind of standing still. (There's however a new release in experimental ATM) > and PA+bluetooth is now working much better than > it did even a few months ago. This sounds a little vague. What does "much better" mean? What exactly changed (for you)? -- Best, Nilesh signature.asc Description: PGP signature
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 15, 2022 at 06:13:35PM +0530, Nilesh Patra wrote: As far as I can see, the latest "new upstream" upload to unstable was in "2021-08-25" which is more than an year from now, post which there have been few bug fix uploads. More notable upload has been the one that enables gstreamer support I'm not sure if this is what you are pointing towards with "hasn't stood still" https://tracker.debian.org/news/1306307/accepted-pulseaudio-150dfsg1-4-source-into-unstable/ Ofcourse the maintainers of this package are doing an excellent job but from upstream release pov, it is still kind of standing still. So from the user perspective it's gained new functionality and also not broken what works. I can think of worse problems.
Re: Proposed MBF: wxwidgets3.2 transition
On 2022-09-13 Scott Talbert wrote: > Hi, > wxWidgets 3.2 (a new API/ABI stable release) has been released a few months > ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped > supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx > package users to wxwidgets3.2 for bullseye, with the plan to remove > wxwidgets3.0 before release. > For most packages, the transition should be as simple as changing > Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages > may require small patches; I'm happy to help with those (and I have some > already from working on this transition in Fedora already). [...] A successful build is no guarantee for a working packaging though. e.g. hugin errs out immediately when built with the newer wxWidgets. cu Andreas
Re: Proposed MBF: wxwidgets3.2 transition
On Thu, 15 Sep 2022, Andreas Metzler wrote: On 2022-09-13 Scott Talbert wrote: Hi, wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). [...] A successful build is no guarantee for a working packaging though. e.g. hugin errs out immediately when built with the newer wxWidgets. That is certainly true - and probably another good reason we don't use the single-dev-package approach. Do you want help with those errors? Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Wed, 14 Sep 2022 16:00:32 -0400, Scott Talbert wrote: > > libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental. > > > > Next step: check what libwx-perl [0] says and do a binNMU or sourceful > > upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to > > wxperl-gtk-3-2-0-uni-gcc-3-4). > > > > Reviews of the packaging changes welcome. > > Thanks! Looks fine, other than a Build-Depends on wx-common isn't necessary > - libwxgtk3.2-dev will pull that in. Thanks for the review and the email! I noticed that wx-common gets pulled in, I just thought that it's "cleaner" to have an explicit build dependency on wx-common as we are using wx-config. But if this is an internal implementation detail of the wx* packages and we can be sure that we always get wx-config when we install libwxgtk*-dev I'm happy to remove the build dependency. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Le jeu. 15 sept. 2022 à 03:21, Ben Hutchings a écrit : > > I understand that applications with very low latency requirements may > need this sort of performance tweaking. But this is not the normal > case, and PulseAudio hasn't required this. If PipeWire does, I think > that's a serious limitation in PipeWire, and it is not ready for us to > make it the default. Le jeu. 15 sept. 2022 à 05:35, Felipe Sateler a écrit : > > This seems a step backwards to me. Even though pulseaudio also does the > same, the code in question is from an era before rtkit existed. Nowadays, > most users get their RT thread from rtkit. Why isn't rtkit enough for PW? By default, pipewire uses rtkit (without removing its safeguards) and it works perfectly without having choppy sound. In certain circumstances, we need to do some performance tweaking. Now, we have to find the right balance in the pipewire configuration to avoid playing with rtkit safeguards. I am not saying we should bypass rtkit (or remove its safeguards) by default, or even recommend our users to do it. But, if they have a particular use of pipewire requiring the upstream recommendations, we can probably help them and explain them what are the risks. Just a random example [1] where rtkit has limitation for some pipewire uses. rtkit was enough for pulseaudio, but because pipewire goes beyond pulseaudio support for real-time and low latency maybe that is no longer sufficient? But again, we are not talking about a normal use of pipewire. Dylan [1] https://github.com/heftig/rtkit/issues/25
Bug#1019894: ITP: golang-sourcehut-rockorager-tcell-term -- TODO
Package: wnpp Severity: wishlist Owner: Robin Jarry * Package name: golang-sourcehut-rockorager-tcell-term Version : 0.1.0-1 Upstream Author : Tim Culverhouse * URL : https://git.sr.ht/~rockorager/tcell-term * License : expat Programming Lang: Go Description : A virtual terminal widget for tcell tcell-term implements the native tcell Widget interface. This is a new dependency for aerc.
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote: > Hi, > > the transition to usrmerge as described in [1] is planned to start > around 2022-09-15 (next Thursday). > > init-system-helpers 1.65~exp1 in experimental adds the new dependency > on > "usrmerge | usr-is-merged" and will be uploaded to unstable to start > the > transition. Feel free to test and report any issues. > > Recent versions of debootstrap[2] will setup the usr-is-merged > package to > avoid installing additional dependencies required by usrmerge. The > usr-is-merged package can also be manually installed in existing > systems > for the same reason. > > Debian's buildds will continue to use the legacy filesystem layout > for > Debian 12 (bookworm). > > We will send an announcement to debian-devel-announce@ once the > upload > to unstable happens. > > Ansgar > > [1]: https://lists.debian.org/debian-ctte/2022/09/msg5.html > [2]: debootstrap 1.0.114+deb10u1, 1.0.123+deb11u1, 1.0.127 Quick update: three minor issues where found, two with i-s-h itself (one solved in experimental just now about test deps uninstallability on some ports and one piuparts seemingly false positive about /etc/shells that I'll fix tomorrow), and one in usrmerge+nspawn+arm64 [0]. I have just come back home from LPC so did not have much time today, will have a look at the latter two tomorrow and then upload to unstable once the situation is clearer. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019575 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Thu, Sep 15, 2022 at 10:57:52PM +0100, Luca Boccassi wrote: > On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote: > > the transition to usrmerge as described in [1] is planned to start > > around 2022-09-15 (next Thursday). > I have just come back home from LPC so did not have much time > today, will have a look at the latter two tomorrow and then upload to > unstable once the situation is clearer. ... unstable of what distribution? I seriously hope you're not talking about Debian. Have you fixed the issues listed, as discussed on IRC? Implemented at least the configurable list of aliases compromise, as agreed? If not, the only transition that can work is one to a scheme supported by dpkg, which usrmerge is not. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Work-needing packages report for Sep 16, 2022
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1257 (new: 2) Total number of packages offered up for adoption: 175 (new: 0) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: tcsh (#1019858), orphaned today Description: TENEX C Shell, an enhanced version of Berkeley csh Reverse Depends: bedops doris ferret-vis gridengine-common gridengine-exec libcam-pdf-perl libncarg-bin libncarg0 ncl-ncarg qflow (3 more omitted) Installations reported by Popcon: 5452 Bug Report URL: https://bugs.debian.org/1019858 watchman (#1019497), orphaned 5 days ago Description: file watching service Reverse Depends: python3-pywatchman Installations reported by Popcon: 114 Bug Report URL: https://bugs.debian.org/1019497 1255 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 175 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1433 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (131 more omitted) Installations reported by Popcon: 96784 Bug Report URL: https://bugs.debian.org/910917 apparmor (#1006872), requested 192 days ago Description: user-space parser utility for AppArmor Reverse Depends: apparmor-notify apparmor-profiles apparmor-profiles-extra apparmor-utils content-hub-testability dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages dovecot-core (18 more omitted) Installations reported by Popcon: 187562 Bug Report URL: https://bugs.debian.org/1006872 aufs (#963191), requested 817 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 7600 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 2115 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1200 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 4008 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 605 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1983 days ago Description: Rust package manager Reverse Depends: dh-cargo python3-setuptools-rust rust-all Installations reported by Popcon: 2893 Bug Report URL: https://bugs.debian.org/860116 chromium (#1016047), requested 51 days ago Description: web browser Reverse Depends: chromium chromium-driver chromium-l10n chromium-shell icingaweb2-module-pdfexport node-puppeteer qunit-selenium x2gothinclient-minidesktop Installations reported by Popcon: 25705 Bug Report URL: https://bugs.debian.org/1016047 courier (#978755), requested 623 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 831 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 557 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common bcron btrfsmaintenance buildd checksecurity clamtk cricket cron (24 more omitted) Installations reported by Popcon: 206553 Bug Report URL: https://bugs.debian.org/984736 crun (#1016183), requested 49 days ago Description: lightweight OCI runtime for running containers Reverse Depends: podman Installations reported by Popcon: 1478 Bug Report URL: https://bugs.debian.org/1016183 cyrus-imapd (#921717), requested 1315 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 400 Bug Report URL: https://bugs.debian
Debian Med video conference on Monday 2022-08-19 18:00 UTC
Hi, this is the call for the next video conference of the Debian Med team that are an established means to organise the tasks inside our team. Please note that we do not meet at 17th as usually but on 19th. Usually it takes us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220919T18 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 These video meetings were started in the Debian Med Biohackathon. The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: Preparation of next release by - Pushing latest versions of our software - RC bugs Newcomers are always welcome. Lets keep on the great work and see you tomorrow Andreas. -- http://fam-tille.de
