Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470

[Andreas Tille]

Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
> Would it be possible to manually remove this item from the list that generates
> autoremovals?

... or generate a blacklist of packages that should not trigger those removals.

The autoremoval warnings are pretty helpful in general but if I'm forced to mass
remove this subject from my mailbox I might loose other sensible autoremoval
warnings.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470

[Julien Puydt]

Hi

Le ven. 27 mai 2022 à 09:27, Andreas Tille  a écrit :

> Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
> > Would it be possible to manually remove this item from the list that
> generates
> > autoremovals?
>
> ... or generate a blacklist of packages that should not trigger those
> removals.
>
> The autoremoval warnings are pretty helpful in general but if I'm forced
> to mass
> remove this subject from my mailbox I might loose other sensible
> autoremoval
> warnings.
>

Or the removal watcher could have a cap on the number of warnings it sends
per sensible period of time. If it exceeds this number, it sends a special
warning that something is amiss to debian-devel, so we still get to know
something is going wrong.

One message to say "I was supposed to send 31415 warnings today" is
definitely better than 31415 false-positive warnings...

Cheers,

J.Puydt

>

Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470

[Paul Gevers]

Hi all,

On 27-05-2022 09:42, Julien Puydt wrote:

... or generate a blacklist of packages that should not trigger
those removals.


That exists: key packages.

Or the removal watcher could have a cap on the number of warnings it 
sends per sensible period of time. If it exceeds this number, it sends a 
special warning that something is amiss to debian-devel, so we still get 
to know something is going wrong.


Patches welcome. Code is here: 
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: use of Recommends by vlc to force users to use pipewire

[Simon McVittie]

On Fri, 27 May 2022 at 01:35:51 +0200, Vincent Lefevre wrote:
> with the installation of
> vlc-plugin-pipewire, VLC was automatically using pipewire

If vlc-plugin-pipewire is prioritized higher than other audio backends,
then I can see how that could happen. It's probably premature for
vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in
Debian.

The dependency graph around this stuff is complicated, particularly in
a distribution like Debian where the answer to "do we try to support A
or B?" is always "yes". Some early-adopter distributions have switched
to Pipewire as their preferred audio service, replacing PulseAudio,
and in *those* distributions, it would make sense to prioritize
vlc-plugin-pipewire ahead of other audio backends - but Pipewire was not
sufficiently mature to replace PulseAudio in bullseye, and it remains
to be seen whether it will be sufficiently mature to replace PulseAudio
in bookworm.

If Pipewire was only an audio service, then the right thing to do would be
to make sure it was completely optional and not pulled in by depenencies,
but it's a video service too, and during a global pandemic with a lot of
people working and socializing remotely, not having working screen-sharing
or screencasting in GNOME/KDE (together with not having working webcams
in sandboxed Flatpak/Snap apps) seemed like a sufficiently major issue
to make Pipewire worth the headaches it can cause.

> and apparently ditto with ogg123 (via ALSA, which I had as the default)

I don't know why that would be. The Pipewire module for libasound is in
pipewire-audio-client-libraries, which nothing depends on.

Could it be the case that the chain of Recommends pulled in wireplumber
(which Recommends pipewire-pulse) instead of the preferred alternative
pipewire-media-session (which was not always listed first, see #999363),
resulting in pipewire-pulse taking over audio routing from PulseAudio?

> However, for the support of bluetooth devices, libspa-0.2-bluetooth
> is needed, but it isn't even pulled when pipewire is installed!

That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
which (as a distribution) we are not yet aiming to do. It isn't needed
(or useful) if you are only using Pipewire as a video multiplexer.

pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
if people consider Bluetooth audio to be sufficiently important to
justify that (of course, every critical feature for one user is considered
"bloat" by someone else, so we can't win). pipewire probably shouldn't,
until such time as we are ready to recommend Pipewire as a replacement
for PulseAudio.

> But xdg-desktop-portal just depends
> on the libpipewire-0.3-0 library package. If it needs more than
> the library, then I suppose that it should also recommend pipewire
> directly and not expect that the library will do it.

Perhaps. If I add that Recommends, how many angry bug reports are we
going to get accusing me of forcing people to use Pipewire against
their will? Conversely, if installing xdg-desktop-portal doesn't
pull in pipewire-bin by any chain of Recommends, how many angry bug
reports are we going to get because screen sharing doesn't work in a
apparently-unrelated Flatpak app or web browser, which in fact needs
pipewire for behind-the-scenes reasons that are not visible to a typical
user?

smcv

Re: use of Recommends by vlc to force users to use pipewire

[Alberto Garcia]

On Fri, May 27, 2022 at 02:18:10AM +0200, Vincent Lefevre wrote:
> > In this case you need the portal in order to have access to the
> > font settings:
> IMHO, such explanations could be useful to users, who may wonder why
> xdg-desktop-portal-gtk is recommended or why some features are not
> available (in case the Recommends got broken, but this is unnoticed
> by the user). That could be some file under the
> /usr/share/doc/libwebkit2gtk-4.0-37 directory.

I understand that there's always room for a more detailed explanation,
but the changelog.Debian.gz file shipped with the package already
explains why the dependency was added and references the original bug
report with all the details.

Berto

Bug#1011956: ITP: fonts-nunito -- Well balanced Sans Serif with rounded terminals

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 
X-Debbugs-Cc: debian-devel@lists.debian.org
X-Debbugs-Cc: debian-fo...@lists.debian.org

* Package name: fonts-nunito
  Version : 0.0~20220527
  Upstream Author : Vernon Adams 
Manvel Shmavonyan 
Jacques Le Bailly

* URL : https://fonts.google.com/specimen/Nunito
* License : SIL Open Font License, Version 1.1
  Programming Lang: None
  Description : Well balanced Sans Serif with rounded
terminals

Nunito is a well balanced sans serif typeface superfamily, with 2 
versions: The project began with Nunito, created by Vernon Adams as a 
rounded terminal sans serif for display typography. Jacques Le Bailly 
extended it to a full set of weights, and an accompanying regular 
non-rounded terminal version, Nunito Sans.



I'll maintain this font within the Debian Fonts Task Force.

Regards,
Tobias


OpenPGP_signature
Description: OpenPGP digital signature

When uploading a package we get two mails. Could it be one ?

[Jérémy Lal]

Hi,

Is it some misconfiguration on my side ?
When a package is uploaded, we get two emails:

node-d3-color_1.2.8-3_source.changes ACCEPTED into unstable
Accepted node-d3-color 1.2.8-3 (source) into unstable

Couldn't this be just one email ?

Jérémy

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
> If vlc-plugin-pipewire is prioritized higher than other audio backends,
> then I can see how that could happen. It's probably premature for
> vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in
> Debian.
> 
> The dependency graph around this stuff is complicated, particularly in
> a distribution like Debian where the answer to "do we try to support A
> or B?" is always "yes". Some early-adopter distributions have switched
> to Pipewire as their preferred audio service, replacing PulseAudio,
> and in *those* distributions, it would make sense to prioritize
> vlc-plugin-pipewire ahead of other audio backends - but Pipewire was not
> sufficiently mature to replace PulseAudio in bullseye, and it remains
> to be seen whether it will be sufficiently mature to replace PulseAudio
> in bookworm.
> 
> If Pipewire was only an audio service, then the right thing to do would be
> to make sure it was completely optional and not pulled in by depenencies,
> but it's a video service too, and during a global pandemic with a lot of
> people working and socializing remotely, not having working screen-sharing
> or screencasting in GNOME/KDE (together with not having working webcams
> in sandboxed Flatpak/Snap apps) seemed like a sufficiently major issue
> to make Pipewire worth the headaches it can cause.

So I suppose that the solution should be that PulseAudio have the
priority over Pipewire.

> > and apparently ditto with ogg123 (via ALSA, which I had as the default)
> 
> I don't know why that would be. The Pipewire module for libasound is in
> pipewire-audio-client-libraries, which nothing depends on.

It has never been installed.

> Could it be the case that the chain of Recommends pulled in wireplumber
> (which Recommends pipewire-pulse) instead of the preferred alternative
> pipewire-media-session (which was not always listed first, see #999363),
> resulting in pipewire-pulse taking over audio routing from PulseAudio?

The wireplumber package was installed from 2021-10-26 to 2021-10-29
only. So, perhaps ogg123 was using something else. But the ogg123
audio stream was not appearing in pavucontrol, and the sound was
sent to the speaker of my laptop instead of the bluetooth speakers.

> > However, for the support of bluetooth devices, libspa-0.2-bluetooth
> > is needed, but it isn't even pulled when pipewire is installed!
> 
> That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
> which (as a distribution) we are not yet aiming to do. It isn't needed
> (or useful) if you are only using Pipewire as a video multiplexer.

The issue appeared automatically with the upgrade of the vlc package.

> pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
> if people consider Bluetooth audio to be sufficiently important to
> justify that (of course, every critical feature for one user is considered
> "bloat" by someone else, so we can't win). pipewire probably shouldn't,
> until such time as we are ready to recommend Pipewire as a replacement
> for PulseAudio.

So why did Sebastian Ramacher reassign bug 1011035 to pipewire?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22

> > But xdg-desktop-portal just depends
> > on the libpipewire-0.3-0 library package. If it needs more than
> > the library, then I suppose that it should also recommend pipewire
> > directly and not expect that the library will do it.
> 
> Perhaps. If I add that Recommends, how many angry bug reports are we
> going to get accusing me of forcing people to use Pipewire against
> their will?

Fewer: This is already an issue because xdg-desktop-portal depends
on libpipewire-0.3-0, which recommends pipewire. The advantage would
be that packages just depending on libpipewire-0.3-0 would not pull
pipewire. So, this would solve the pipewire issue in some cases.

Said otherwise, this would not change anything for xdg-desktop-portal,
but could improve things for other packages (if xdg-desktop-portal and
other packages pulling pipewire are not installed).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: When uploading a package we get two mails. Could it be one ?

[Paul Gevers]

Hi Jérémy,

On 27-05-2022 23:08, Jérémy Lal wrote:

Is it some misconfiguration on my side ?


I think so.


When a package is uploaded, we get two emails:

node-d3-color_1.2.8-3_source.changes ACCEPTED into unstable


As the (team) uploader, I only got ^ that one. I believe it is sent to 
the maintainer of the package 
(pkg-javascript-de...@lists.alioth.debian.org).



Accepted node-d3-color 1.2.8-3 (source) into unstable


I think ^ one comes from tracker.d.o.

You may want to check the headers of the e-mail.

Paul


OpenPGP_signature
Description: OpenPGP digital signature