Re: Binary conflict between Midnight Commander and MinIO Client

[Marvin Renich]

* Simon McVittie  [240422 05:02]:
> On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
> > Philip Hands  writes:
> > > Might I suggest that the link goes the other way, so that the symlink
> > > lives in /usr/bin?  That way the existence of the lib directory is
> > > somewhat self-documenting.
> 
> Having the real executable in /usr/lib(exec) and the symlink in /usr/bin
> also makes it possible to be somewhat consistent with packages that don't
> normally add themselves to the PATH at all, but could be added to the PATH
> by a system integrator, sysadmin or user on specialized systems.

I don't think either way is best for all situations, but I think that
having the mc symlink in a directory other than /usr/bin (or /usr/sbin)
is the only way that is compatible with Debian's policies.

If a package puts the symlink in /usr/bin (e.g. having an additional
package minio-client-compat), that package must declare a Conflicts: mc,
and while this is still technically against policy (IIUC), there is
already precedent for this method (or at least there has been in the
past).

If the sysadmin puts the symlink there, it goes against FHS and then the
sysadmin is responsible for ensuring that mc is never installed.

On the other hand, if a symlink named mc is placed in
/usr/lib/minio-client, with the binary named minio-client in /usr/bin,
there is no policy violation, the choice of which binary is invoked by
mc at the command line is entirely up to individual users (either
through modifying $PATH or placing a symlink in ~/bin or ~/.local/bin/),
and both packages are co-installable.  If the sysadmin desires, a
symlink can be placed in /usr/local/bin.

In fact, I think /usr/lib/minio-client/mc -> /usr/bin/minio-client is
completely unnecessary.  Whatever is done must be documented (at least
in /usr/share/doc/minio-client/README.Debian, and possibly also in the
man page).  It is just as easy to document placing a symlink in ~/bin or
~/.local/bin as it is to document modifying $PATH in ~/.profile.

I think this should become the standard way to deal with this situation:
the package should not create any compatibility symlink, and the
documentation should describe that individual users can place a symlink
in ~/bin or ~/.local/bin or that the sysadmin can place a symlink in
/usr/local/bin, giving a non-standard default for all users.

A script in /usr/share/doc/minio-client/examples/ can help the user get
this correct, checking for the existence of ~/bin and ~/.local/bin and
setting up the symlink.


I believe upstream's reluctance to change the executable name is grossly
self-centered.  The current use of mc has a long history and is still
very popular.  I think the FLOSS community should do everything they can
to discourage this type of behavior, and any upstream behaving this way
should be called out loudly as being anti-social.  A lot of time gets
wasted every time this situation comes up.


...Marvin

Re: Bug#1068479 cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)

[Marvin Renich]

* José Luis González  [240407 15:00]:
> reopen 1068479
> thanks
> 
> Hi all,
> 
> Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a
> look at my recent bug reports to libreoffice-writer and his replies.
> 
> In this one:
> 
> > Am 06.04.24 um 11:03 schrieb Rene Engelhard:
> > > Am 06.04.24 um 00:34 schrieb José Luis González:
> > >> The setting for spacing between paragraphs is missing in the spacing
> > >> and indentation tab of the paragraph dialog.
> > >
> > > ?
> > >
> > >  It's definitely there. Format -> Paragraph has spacing "after/before".
> 
> I meant spacing between paragraphs, not spacing after and before
> paragraphs. The report was crystal clear.
> 
> The difference, for those who didn't realize is space after paragraph
> happens always, and between only between them, being the regular
> separation between paragraphs (the other is formatting, and isn't
> useful as a substitute because it adds something undesirable at the end
> of the document or between paragraphs and other kinds of block
> elements).
> 

First, please carefully consider the reply from Pierre-Elliott Bécue.
The tone of your email is way out of line.  If this is the way you
regularly communicate, I would not be surprised that Rene closes your
bug reports.

It is clear to me from your quote of Rene's response that Rene honestly
believed he was answering your question and the bug should be closed.
Politely expressing the difference between the current behavior and what
you were asking for, and at the same time reopening the bug (at a proper
severity), would have been appropriate.  It should have been done in the
bug tracker and _not_ on this list.  I've set Reply-To to the bug report
only.

I don't use libreoffice daily, but I do use it.  If this is a case that
lowriter already has a way to obtain "between" spacing, but it is just
not in the proper dialog box, then this is a "normal" bug at most,
possibly "minor".  However, I don't believe lowriter ever had such a
feature.  If this is the case, the severity is "wishlist", and not
higher.  (If it does have this feature, I would personally be interested
in how to do it!)

In no way would I consider this an "important" bug, and absolutely not
"serious" or RC.

All missing or not-yet-implemented features might be considered to have
a "major effect on usability" by someone, but in almost all cases, such
a feature request is still only a "wishlist" bug.  Please don't confuse
the difference between how you would like the software to behave and how
it is currently designed to behave as being anything more than a feature
request, regardless of how important you believe the feature is.

...Marvin

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Marvin Renich]

* Jonathan Kamens  [231230 14:39]:
> I think even "ssh-h3" is a confusing and frankly impudent name. The
> creator of this new package appears to be intentionally trying to use
> the ubiquity of the ssh "brand" to their benefit. This brand confusion
> can only harm end users and I do not think Debian should facilitate
> it.
> 
> Even something as simple as naming it h3sh would have avoided the
> brand confusion while communicating the purpose of the package. This
> does not appear to be a case of "unknowing infringement." It appears
> to be intentional.
> 
> Regardless of whether or not that's so, it is harmful and should be fixed.

No argument from me there.  The point was that if upstream does not
rename the project or executable, the package name does not need to
match the executable or even the upstream project name.

...Marvin

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Marvin Renich]

* Simon Josefsson  [231230 11:54]:
> One alternative that was suggested was to call the package something
> else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
> as long as the 'ssh3' name is in there.

There is no reason the package (source and binary) can't be named ssh-h3
even if the binary is not renamed.  I would not keep the "ssh3" part in
the package name.

...Marvin

Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go

[Marvin Renich]

* Nilesh Patra  [231026 06:43]:
> On Thu, Oct 26, 2023 at 08:35:51AM +0200, Salvo Tomaselli wrote:
> > > Go has the extremely nice feature that cross-compiling for other
> > > architectures and OSs is very easy.  I have, on a number of occasions
> > > used Debian to cross-compile Go programs for Windows.
> > > 
> > > I have no particular interest in this package, but yes, it is
> > > appropriate to package a Windows-only Go package in Debian.
> > 
> > Why would it be in debian though?
> > 
> > Go provides a repository for libraries. I thought we were packaging 
> > libraries 
> > in debian if they were a requirement for things used in debian, that can't 
> > just download libraries when building (which is the normal way in go)
> 
> This is true. It makes sense to package go libraries in debian only when
> some target package actually depends on it. In this case, for me it
> makes no sense to have a windows specific go library in debian.

>From the original ITP:
  This golang package is dependency to my program I am packaging for Debian.

As I said, I do not know about or care about this particular package.
My statement was meant to correct what looked like a blanket statement
that windows-only Go packages should not be in Debian.

If you were saying that _the package in question_ should not be
packaged, that was not clear; you did not give any reason that I could
see other than it is windows-only.  That fact should not have any
bearing on the reasons for packaging or not packaging.

[BTW, I am subscribed to d-devel; no need to (B)CC me.]

...Marvin

Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go

[Marvin Renich]

* Nilesh Patra  [231025 16:13]:
> Hello,
> 
> On Wed, Oct 25, 2023 at 05:13:10PM +0300, Ramūnas Keliuotis wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ramunas Keliuotis 
> > 
> > * Package name: golang-github-microsoft-go-winio
> >   Version : 0.6.1-1
> >   Upstream Author : Microsoft
> > * URL : https://github.com/Microsoft/go-winio
> > * License : Expat
> >   Programming Lang: Go
> >   Description : Win32 IO-related utilities for Go
> 
> This seems to be a windows specific library - if I'm not mistaken, there
> is no use of this library for debian/any linux distro, yes?

Go has the extremely nice feature that cross-compiling for other
architectures and OSs is very easy.  I have, on a number of occasions
used Debian to cross-compile Go programs for Windows.

I have no particular interest in this package, but yes, it is
appropriate to package a Windows-only Go package in Debian.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Andrey Rakhmatullin  [230925 15:13]:
> On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote:
> > The documentation you inked to does not specify a tag that can be used
> > specifically to mark something as not actually a bug.
> Yes, we just close those. The Debian BTS is not as rich as e.g. a typical
> bugzilla installation in this regard. Though I guess not having a fixed
> version and not having the wontfix tag usually suggests the report was
> invalid.

How hard is it to add a 'notabug' tag?

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Jonathan Kamens  [230925 12:56]:
> Closed bugs are available for direct search for 30 days after they're
> closed.
> 
> After that you can still search them by selecting either "Archived" or
> "Archived and Unarchived" under "Misc Options" on the search page.

Except that in the general case, this is not very useful for avoiding
the duplicated filing of a bug that has already been discussed and
rejected.

> All that aside, in this particular case I closed the bug because it wasn't
> actually a bug, but rather a PEBKAC issue (user complaining that a program
> wasn't respecting his locale when he had LC_ALL set to "C" so he was
> essentially telling the program to ignore his locale).

That is a very good reason to close the bug.  Your original message did
not refer to the bug or even the package, so I had no knowledge of the
details.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Russ Allbery  [230925 12:43]:
> Marvin Renich  writes:
> 
> > I've seen differing opinions about closing "wontfix" bugs, but as a
> 
> I think it's a trade-off.

Which is why I said there are differing opinions.  This has come up on
this list before.

> There are some bugs that seem unlikely to ever
> come up again or that aren't helpfully worded, and I'm more willing to
> close those.

Agreed.

> Also, in the abstract, I don't like using the BTS as a documentation
> system, which is sort of what collecting wontfix amounts to.  If it's

Except that if it looks like a bug to me, I am going to fire up
reportbug without looking at README.Debian, and I think many users do
the same.  But, I do go through existing bugs to try to avoid
duplication.  I know not everyone does, but they should.

I feel that even though this was not the original intent of the BTS, it
is the most useful and pragmatic place to document this sort of thing.
Documenting it in a bug script may be more in line with its intended
use, but is probably a poorer use of Debian resources, as it uses Debian
and mirror archive space and download resources (both Debian and user)
for something that is only going to come up every 10,000 package
downloads.

> something that I think is going to come up a lot, it feels better to put
> it into the actual documentation (README.Debian, a bug script if it's
> reported really often, etc.).  You're also expecting everyone filing a bug
> to read through all the existing wontfix bugs (at least their titles),
> which in some cases is fine but in some cases can become overwhelming.

I wasn't trying to start a lengthy discussion or get Debian to make an
official policy, just stating a preference.  I expect that most
maintainers use good judgement, and adding the reasoning for my
preference might help them decide which wontfix bugs to close and which
to leave open.

...Marvin

Re: Control header sent with done email didn't do what I expected, should it have?

[Marvin Renich]

* Jonathan Kamens  [230925 07:17]:
> Hi all,
> 
> I recently tried to close a bug, explain why, and set a "wontfix" tag all at
> once by sending my explanation to ###-d...@bugs.debian.org with "Control:
> tags ### wontfix" as the first line of my message body. The bug was closed
> but the tags command wasn't processed.

I've seen differing opinions about closing "wontfix" bugs, but as a
user, I appreciate when they are left open.  Whether it is a simple
wishlist feature request or a crash when the user abuses the software,
if I go to file the same or similar bug at a later time, if the bug is
closed I will not see it and file a duplicate.  If it is left open, I
can see the maintainer has already thought about it and intentionally
decided not to fix it, so I can save the trouble of refiling.  Also, I
might gain some insight about the circumstances.

...Marvin

Re: Questionable Package Present in Debian: fortune-mod

[Marvin Renich]

* Dominik George  [230818 17:52]:
> Debian is not ..., it is an operating system.

This is simply and blatantly incorrect.  Debian is a distribution.

It includes an operating system and many, many application packages that
different people find useful or interesting.  The vast majority of
packages are not part of the OS.  The vast majority of users will only
be interested in a small portion of the applications.

I would go as far as saying that the applications are the most important
part of the distribution, and that the OS is included as a necessity so
that the applications can be run.  I will certainly agree that the OS
can, itself, be considered an application, useful for doing things
independently of other packaged applications.

As others have said, the CoC is specifically intended to be applied to
communications and interactions within the Debian community, not the
content of the distribution.

The only document that I can think of that describes what is appropriate
content for the distribution is the DFSG.  Other than paragraph 2, which
states that the program must include its source code, the DFSG talks
entirely about the license.

However, if we extrapolate paragraphs 5 and 6 of the DFSG, which talk about
discrimination against persons, groups, and fields of endeavor, along with
the Diversity Statement, to how we decide what packages are allowed, I
think it is clear that we should be very accepting of packages with
content that we don't agree with, as long as someone finds it useful or
interesting enough to go to the effort of packaging it.

Not doing so is equivalent to saying, "We accept you but not your
contribution."

The whole point of the Diversity Statement is that we accept people into
the Debian community who have ideas and values that are different than,
and even contradictory to, our own.  How can we not accept the packages
that they would like to include?

The point is to make them available to those who want to use them; we
are not forcing anyone who does not want to use them to do so.

...Marvin

Re: Bug#1050005: ITP: pdftopng -- Convert PDF to PNG

[Marvin Renich]

* Elena Grandi  [230818 05:27]:
> Package: wnpp
> Severity: wishlist
> Owner: Elena Grandi 
> 
> * Package name: pdftopng
>   Description : Convert PDF to PNG
> 
> A command line tool and python library to convert PDFs to PNGs, based on
> pdftoppm from poppler.
> 
> This is a dependency of camelot-py (#1049944) and I intend to maintain
> it in the Python Team.

Does pdftocairo from the poppler-utils package do what you need?  If
not, would it make sense to submit patches to add pdftopng to the
poppler-utils package instead of creating a separate package for it?

Just a suggestion.

...Marvin

Re: Fwd: Wayland and NVidia driver conflict

[Marvin Renich]

debian-user and debian-desktop are both good lists for this question.
It is off-topic for debian-devel.

Anyone who answers, please remove debian-devel from the replies.

(Sorry, I don't have an answer for you.)

Thanks...Marvin

Re: DEP 17: Improve support for directory aliasing in dpkg

[Marvin Renich]

* Helmut Grohne  [230428 09:50]:
> I think we have a misunderstanding here. As far as I understand it, the
> core idea of Luca's approach is that we move all files to their
> canonical locations and then - when nothing is left in directories such
> as /bin or /lib - there is no aliasing anymore, which is why we do not
> have to teach dpkg about aliasing and never patch it.

My understanding from following this thread (and others) is that dpkg
has a bug that can easily be triggered by a sysadmin replacing a
directory with a symlink (and some other necessary conditions that don't
happen very often), which is explicitly allowed by policy.  This bug is
the one that is causing the problem with the approach that was chosen by
the people implementing usrmerge, even though they were aware of this
problem and a different approach that would have taken two release
cycles and would not have triggered this bug was considered and
rejected.

If this is correct, then Luca's approach may fix the problem for
usrmerge, but does not fix the general dpkg bug.  (And, IIUC, is going
to take two _more_ release cycles to fix the problems with usrmerge as
implemented!  Hmm...)

The --add-alias solution that has been suggested in this thread seems
like it would fix the general problem iff policy was changed to require
sysadmins to use it if they replaced a directory with a symlink.

I do not understand why the dpkg maintainer has rejected this solution;
it would still be a fix for the general bug after the usrmerge
transition has completed.  And it would be at least one order of
magnitude more performant than scanning the filesystem for directory
symlinks.

...Marvin

Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Marvin Renich]

* Marvin Renich  [221115 12:57]:
> TEMPDIR, on the other hand, is for _specific_ cases, and can have
  ^ et al

Of course, that should be TMPDIR, not TEMPDIR.  Apologies.

...Marvin

Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Marvin Renich]

* Robie Basak  [221113 14:15]:
> On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote:
> > On Nov 13, Robie Basak  wrote:
> > 
> > > This seems inconsistent to me. Where is the expectation that TMPDIR must
> > > be unset if dropping privileges coming from? Obviously for users of
> > Where is the expectation that $TMPDIR is writable by any user but the 
> > current one?
> > I do not believe that it is expected that if a user creates a directory 
> > and points $TMPDIR to it then they also have to make it sticky, so this 
> > has nothing to do with libpam-tmpdir.
> 
> I understand the traditional semantics of TMPDIR to be exactly the same
> as /tmp. So that includes the sticky bit, or at least behaviour that is
> equivalent under all circumstances. Or, alternatively, that someone who
> sets TMPDIR without setting the sticky bit is certain that it will be
> used in a way that does not rely on that.

This is an incorrect assumption and may be what is driving your
resistance to others' guidance on how to resolve these bugs.  /tmp has
world-writable, sticky-bit semantics specifically because it was
necessary in order for the system to give a single _common_ place where
all users could write temporary files, not because a temporary directory
for a given process needs those semantics.

TEMPDIR, on the other hand, is for _specific_ cases, and can have
whatever semantics are appropriate for the environment in which it is
set.  TEMPDIR is specifically for use when /tmp has properties that are
not appropriate for a process for any reason.  The inappropriate
property may be available disk space, inappropriate permissions
(privacy), or anything else.  When TEMPDIR is set, you specifically
cannot assume that it is world-writable or has a specific amount of disk
space.  Also, you cannot count on automatic cleaning of the TEMPDIR
directory, while you can with /tmp (at some indeterminate point in the
future).

I think Simon's analysis is the most thorough, well-thought-out, and
technically correct that I have seen in this thread.  His reasoning
should be used to determine how these bugs are resolved.

...Marvin

Re: Firmware GR result - what happens next?

[Marvin Renich]

* Paul Wise  [221014 01:35]:
> On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
> 
> > I'd prefer if we could make things work vs making things fail,
> > however loudly.
> 
> There seem to be a few ways to deal with this transition:
> 
> 2. Add some code somewhere to automatically modify the apt sources,
> somehow ensure that code is run by all Debian users and hope that other
> automated processes (like ansible/puppet) don't overwrite those changes
> and hope that users aren't storing apt sources config in packages,
> which would mean conffile prompts after the modification happens.

Actually, I think this would work really well.  Do not modify any
existing sources.list; drop a new file in sources.list.d.  This file can
have a default name that includes "firmware-nonfree" so is highly
unlikely to exist, but if it does, add "-NNN" suffix with the smallest
numeric NNN that does not exist.

Of course, the file would only be added if the current sources do not
include that component, which would _really_ decrease the probability of
a file name conflict to be about the same as the probability of the
earth being destroyed by an asteroid.

...Marvin

Re: Automatic trimming of changelogs in binary packages

[Marvin Renich]

* Hakan Bayındır  [220914 03:41]:
> 
> 
> > On 14 Sep 2022, at 10:37, Wouter Verhelst  wrote:
> > 
> > On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote:
> >> Yes, you’re right. However, my reservation is whether dpkg is more prone to
> >> breaking in disaster recovery scenarios. Reading a gzipped file is always
> >> simpler than querying a DB via more abstraction.
> > 
> > Honestly though, the way to track down a regression is to read
> > /var/log/dpkg.log, not changelogs.
> 
> Does /var/log/dpkg.log contain why my VPNs suddenly don’t connect or
> my daemon behaves differently after the last update? I thought they’re
> delivered through news and changelogs.
> 
> Actually, OpenVPN’s changing defaults are nicely delivered through
> NEWS and changelogs, so I know why things broke at the first place.

And the trimmed changelogs are unlikely to alter that at all.  The
probability that the change that caused your VPN to break will have been
trimmed are close to zero.  If it has been trimmed, it means you haven't
upgraded in more than two releases, and yes, you will have to get the
untrimmed changelog using apt changelog.

...Marvin

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Marvin Renich]

* Dylan Aïssi  [220914 05:57]:
> Le mer. 14 sept. 2022 à 03:08, Felipe Sateler  a écrit :
> >
> > Dylan, have you thought about how a transition plan would look like?
> 
> Now, regarding the transition plan, I propose to switch right now to pipewire.
> 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]. Thus, we will have
> 4 months for Debian and 2 months for Ubuntu to fix the worst bugs. Then, we

In my opinion, this is a major switch that should be started at the
beginning of a release cycle, not at the end (I completely agree with
Felipe).  Four months is not long enough to get appropriate testing.

You say there are four packages that depend on PA rather than PA | PW,
and the next version of PW will conflict with PA.  That means that
unless all four of those packages are fixed before the freeze, some
users will have trouble upgrading.  Four months is quite frequently an
inadequate amount of time to coordinate a change with upstream and get
that change back into Debian, and that doesn't even include testing by
users once that change gets into Debian.

Also, keep in mind that part of the transition will be users who need to
learn a new set of tools to get their audio working.  Those with more
complicated use cases, especially mission-critical ones, are going to
need to more time to make the switch, and it may not be convenient for
them to do so in the next four months.  It's not just about getting the
software in the release.

A library transition that affects many rev-deps but is otherwise
transparent to the end user is completely different from changing the
audio stack where the end user will be required to learn a new set of
tools and configuration files/syntax.

Please continue to coordinate the changes necessary to make the
transition, but hold off on the change until after the release.

...Marvin

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Marvin Renich]

* Ansgar  [220910 09:37]:
> the transition to usrmerge as described in [1] is planned to start
> around 2022-09-15 (next Thursday).
[snip]
> We will send an announcement to debian-devel-announce@ once the upload
> to unstable happens.

What is the point in waiting until after the upload to send to
debian-devel-announce?  I would think that most users running
testing/unstable would want prior notice, and you shouldn't assume that
all users will read their mail before performing a routine
update/upgrade cycle on the morning after the upload.  I don't think
everyone running testing/unstable reads debian-devel, so I think it
would be appropriate to send to -announce at least one (two?) day(s)
before the upload.

...Marvin

Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Marvin Renich]

* Jeremy Bicha  [220714 10:06]:
> On Thu, Jul 14, 2022 at 2:41 PM Roberto C. Sánchez  wrote:
> >
> > On Thu, Jul 14, 2022 at 11:14:43AM +0100, Steve McIntyre wrote:
> > > edw...@4angle.com wrote:
> > >
> > > >Package: wnpp
> > > >Severity: wishlist
> > > >Owner: Edward Betts 
> > > >X-Debbugs-Cc: debian-devel@lists.debian.org, 
> > > >debian-pyt...@lists.debian.org
> > > >
> > > >* Package name: gender-guesser
> > > >  Version : 0.4.0
> > > >  Upstream Author : Israel Saeta Pérez 
> > > >* URL : https://github.com/lead-ratings/gender-guesser
> > > >* License : GPL-3 & GFDL-1.2+
> > > >  Programming Lang: Python
> > > >  Description : Guess the gender from first name
> > >
> > > Oh, not *another* package that tries to guess things from names.
> > >
> > > Do you have a real use for this package?
> >
> > Why in the world is that even a relevant question?  There are plenty of
> > packages in the archive which are useful to essentially nobody apart
> > from the maintainer and there are even packages which are maintained
> > without being useful to the maintainer at all (but rather useful to
> > others).
> >
> > > There are a *lot* of issues
> > > in this area, and mis-gendering people is not something to risk
> > > lightly...
> > >
> >
> > "There are a *lot* of issues in this area" seems rather nebulous.  In
> > which area?  Given the fact that we have clear and rather unambiguous
> > guidelines for what constitutes software which is appropriate for
> > inclusion in the archive, and given that on its face this software does
> > not seem to be in conflict with any of those guidelines, what then is
> > the problem?  BTW, I'm not interested in any sort of "well I don't like
> > ..." or "such and such could offend so and so ..." sort of arguments.
> 
> Debian has a Diversity Statement [1] which says that Debian welcomes
> people regardless of how they identify themselves. Trans people and
> non-binary people face a lot of discrimination, harrassment and
> bullying around the world. That bad treatment of these people is
> against Debian's core values. Therefore, the Debian Project wouldn't
> want to distribute software that appears to facilitate that kind of
> harassment, regardless of the software license it is released under.
> We might not want to distribute such software even if it also has
> non-harmful uses. We don't have to distribute *everything* ourselves.

People within the Debian community have a right to expect that others in
the community will not bully, harass, or denigrate them.  They do _not_
have any right to expect that others will not offend them by discussing
or making contributions that espouse values that are different and
incompatible with their own.  Such an expectation assumes that one set
of values is correct and the other is wrong.  In order for such an
expectation to be met, only one of the two sets of values could exist
within Debian.

Saying that gender-guesser should not be packaged within Debian (using
the excuse given early in this thread) is excluding a contribution based
on the values to which that package adheres and possibly the contributor
and the users who would like to use it.  This is contrary to being
inclusive.

Being offended by someone else's civil expression of their values
(including the packaging of a particular piece of software) is not the
same as being bullied or denigrated.  Please stop trying to use the
excuse "it might offend someone" to block participation or inclusion of
software.  Instead, be inclusive and acknowledge that others' values may
be different from and incompatible with yours, and accept that Debian is
a collection of software from diverse sources and some of it may not
adhere to your values.

This is the difference between true inclusiveness and the false
"political correctness" that seems to be permeating our society today.

When we can all say, "I disagree with your values, but I accept you as a
Debian contributor," then we will be truly inclusive.

...Marvin

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

[Marvin Renich]

* Dylan Aïssi  [220530 08:31]:
> Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard  a écrit :
> >
> >  a) pipewire package enables pipewire service by default
> 
> Indeed, but pipewire service doesn't take control of audio over
> pulseaudio. Only pipewire-pulse does that.
> So, if you don't want to use pipewire for audio, then don't install
> pipewire-pulse and that's it.
> What is the real issue with pipewire service?
> 
> libpipewire recommends pipewire for a reason [1], do you mean this is
> not a good reason?
> 
> [1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1

Jonas is exactly correct.  Because it is a very common case for a user
to need to have libpipewire installed but want to _not_ have pipewire
installed, libpipewire MUST NOT Recommed pipewire.

"Recommends"
   This declares a strong, but not absolute, dependency.

   The "Recommends" field should list packages that would be found
   together with this one in all but unusual installations.

pipewire clearly _does not_ satisfy this definition.  It is up to the
application that links with libpipewire to determine if pipewire should
be a Depends, Recommends, Suggests, or none of these.

As an alternative, you could separate libpipewire into libpipewire
(non-audio-server API) and libpipewire-pulse (audio server API).  Have
libpipewire-pulse Suggest, but not Recommend, pipewire-pulse.
Applications that want to use whatever sound server the user has
installed will link with libpipewire-pulse instead of libpipewire, and
will not automatically pull in pipewire or pipewire-pulse.  However, I'm
not sure if this would or would not leave the non-audio libpipewire in
the same position that the current libpipewire is in.

To answer your question above, I presume that one of libpipewire's
functions is to determine whether specific pipewire services are
available, perhaps by calling an init function and checking the result.
This clearly obviates the reason stated in the above link, and adding
the Recommends violates the policy definition and creates undesired
setups for users in many situations.  So, no, that is not a good reason.

...Marvin

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

[Marvin Renich]

* Marvin Renich  [220517 08:55]:
> I do not fully understand the relationships between the different sound
> servers, for example I think pulseaudio can use ALSA as one of its
> backends, but do I think that they all need to be co-installable without
 I do
> interfering with the operation of each other, because some applications

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

[Marvin Renich]

* Vincent Lefevre  [220517 06:36]:
> On 2022-05-16 16:14:02 +, Bill Allombert wrote:
> > On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> > > And for the record: you get pipewire installed because libpipewire-0.3-0
> > > recommends it.
> > 
> > For a similar situation, I advocated to add a apt option so that apt
> > only install Recommends of the packages on the command line, but not
> > Recommends of dependencies (and not Recommends of Recommends).
> > This would make recommends more usable but less deterministic.
> 
> So, if I understand correctly, this implies that if a package A needs
> package B and package B recommends package C, and if it happens that
> A needs C, then package A should also depend on or recommend C.
> 
> And what about upgrades? Should Recommends be checked only for
> manually installed packages?

I disagree with making Recommends non-transitive.  The problem is
incorrect use of Depends and Recommends.  This used to be a much bigger
problem; at least one large packaging group in the past had
intentionally abused Depends in metapackages because they felt too many
users had turned off automatic Recommends, and they were getting too
many bug reports about features not being available.  Turning off
automatic Recommends was (and still is, I think) common because too many
packages inflate the dependencies.  Inflating dependencies creates a
positive feedback loop, which will only end with the entire archive
using _Depends_ for everything.

The situation seems to be much better now, but it is still not as good
as it could be.

Let's analyze the Recommends in libpipewire-0.3.0.  First, the
definition of Recommends:

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

Because pipewire, pulseaudio, and ALSA each provide sound middleware,
and the user may have a preference for one of them, a number of
applications (e.g. mpd, obs-studio, and webcamoid-plugins) link the
libraries for all three sound servers.  Somehow they each choose which
library to use at runtime.

It is clear from this that libpipewire is commonly installed in
situations where pipewire is not only not used, but actually not
_wanted_.  Using Recommends is clearly wrong in this case, both from a
practical point of view and by any reasonable interpretation of Policy.

This same analysis, when applied to other situations, is why making
Recommends non-transitive is the wrong solution to the problem; fixing
the level of dependency is the right solution.

There is, unfortunately, a catch here.  In order for any of the
applications that require a sound server to work, one of them must be
installed.  For example, mpd links with libasound, libpipewire, and
libpulse.  If each of these libs simply provides the glue to another
package that provides the middleware and drivers, and for the reasons
stated above they each only Suggest their middleware package, then it is
possible for _none_ of the sound servers to be installed.

I do not fully understand the relationships between the different sound
servers, for example I think pulseaudio can use ALSA as one of its
backends, but do I think that they all need to be co-installable without
interfering with the operation of each other, because some applications
appear to only use pulseaudio and others only pipewire.  Clearly from
the original message in this thread, installing pipewire breaks at least
some setups when using VLC and ogg123.  This is definitely a bug, either
of severity "serious" (violates Debian Policy definition of
"Recommends") or "critical" (breaks other software).  But I think to
sort this out will require the sound server maintainers to come up with
a way for the user specify which sound server to use, and then have a
metapackage that forces at least one of them to be installed.

I think you (Vincent) are fully justified in filing a bug against
libpipewire of severity at least "serious", however it may take more
than just downgrading the Recommends to Suggests in order to straighten
this out correctly.

...Marvin

Re: blocking UDP with UFW (bug?)

[Marvin Renich]

* Michael Lazin  [220506 04:39]:
> The UFW firewall package uses iptables at the backend, but it is lacking
> syntax to block UDP ports and I think this would be useful.
> 
> I ran the command "UFW default deny incoming UDP" and it wrote to the chain
> successfully, but I ran nslookup afterwards and it succeeded, meaning that
> it did not block UDP all ports because DNS uses UDP.  This may be a bug.

Hi, Michael.

First, I have added an appropriate Subject.  Doing so initially will
help.

Second, debian-devel@l.d.o is not an appropriate place to report bugs in
specific packages.  Use the reportbug command once you have gathered
appropriate information for the bug.  If you need help determining what
information to gather, a user forum, such as
debian-us...@lists.debian.org, is a good place to start.  If you can't
or don't want to do that, go ahead and file a bug with reportbug asking
what info is needed.  Note that this places more burden on the
maintainer, whereas starting at debian-users allows a larger audience to
help you.

Next, your email does not really give the information needed to show
that a bug really exists.  You say ufw lacks syntax to block UDP ports,
but then you give an example that does so and say it wrote to the chain.

You don't say where you ran nslookup, on the host where you set the
firewall rules, or on an external host specifying the host with the
firewall as the DNS server.  Note that a rule to block incoming UDP may
be superseded by a previous rule to allow "RELATED,ESTABLISHED"
connections.  So using nslookup on the host creates a
RELATED,ESTABLISHED connection using an outgoing UDP packet, which
(depending on your rules) may allow the incoming UDP packets to pass,
because the rule to block UDP is later in the chain.

You should look at the output from iptables-save to see if UFW actually
added the rule you wanted, and use a tool such as tcpdump to see what
packets are going which direction when you try the nslookup command.
With that info in hand, you can use reportbug to send a bug report to
the bug tracking system, which will ensure that the ufw maintainer gets
it.

Please take this discussion to debian-users or another user forum, and
then use reportbug when you have enough info for the maintainer to act
on the bug.

...Marvin

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

[Marvin Renich]

* Eric Brown  [220427 20:24]:
> Thank you for the explanation, and thanks for the history and pointer
> towards tftp. Looks like you remembered correctly
> (https://lists.debian.org/debian-devel/2020/02/msg00197.html). I installed
> tftpd-ahp. Interestingly, after all that discussion, it still does create a
> directory /srv/tftp which is its default served directory, like the upstream
> shiny-server behaviour.
> Best,
> Eric

If tftpd-hpa does, it is violating Debian Policy.  However, there is a
significant difference between an FTP server and a web server:  the FTP
server's data directory is dynamic, and can be modified by clients on
other hosts.  /var/lib/package is not a good choice for this directory.

I agree with the others in this thread that you _must not_ step on the
sysadmin's toes by creating directories or files in /srv without
explicit permission.

I see two possible approaches.  The first is to use /srv/shiny-server as
the configuration default, and not place anything there (not even
creating the directory).  You can use README.Debian or (although
possibly a mild abuse) NEWS.Debian to guide the sysadmin on how to fix
things.

The other, which I strongly prefer and follows what other web servers in
Debian have done, is to use /var/lib/shiny-server as the default, and
modify the default web page to give instructions, explaining that for
the package to use /srv/shiny-server as the default without the user's
explicit permission is a violation of both the FHS and Debian Policy.
You can provide a script in /usr/share/doc/shiny-server/examples/ that
will "correct" the default if the user wishes.

The fact is that for shiny-server to be useful, the user must customize
the website anyway.  One extra step that is explained in the default web
page to get it to match the upstream defaults is not onerous.

What would be policy compliant, would be to have a debconf question (as
others have suggested), whose default behavior is to use
/var/lib/shiny-server, but if the user explicitly changes it to
/srv/shiny-server, then it is fine to go ahead and create and populate
the directory.  Asking a debconf question, but defaulting to
/srv/shiny-server would be the same as not asking the question, and is
thus a policy violation.

Also, note that /var/shiny-server is not FHS or Debian Policy compliant,
but /var/lib/shiny-server is (I vaguely remember someone mentioning
/var/shiny-server earlier in this thread, so I thought I would point
this out).

...Marvin

Re: The future of src:ntp

[Marvin Renich]

* Richard Laager  [220119 14:34]:
> On 1/19/22 9:49 AM, Bernhard Schmidt wrote:
> > AFAICT other than systemd-timesyncd being installed by default we don't
> > have a "default" NTP daemon in Debian.
> 
> I'm not sure how much more "default" it can be than installed by default. So
> I'd say we do have a default: systemd-timesyncd.
> 
> > So we should most probably decide on a "default" and have all of them
> > changed to $newdefault | time-daemon
> 
> +1, except that my position is we already have that answer:
> systemd-timesyncd | time-daemon

This is only appropriate if the package doesn't care which time daemon
is installed.  If the package depends on ntp because it uses one of the
provided binaries in a script, replacing the dependency as you suggest
would be inappropriate.  A number of the packages mentioned by Bernhard
depend specifically on ntp, so the reason for that must be determined
for each individual package.

...Marvin

Re: Not running tests because tests miss source code is not useful

[Marvin Renich]

* Pirate Praveen  [211007 05:41]:
> On 7 October 2021 3:02:55 am IST, Thomas Goirand  wrote:
> >On 10/6/21 6:53 PM, Pirate Praveen wrote:
> >> On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard > 
> >>  wrote:
> >>> Quoting Yadd (2021-10-06 11:43:40)
>   On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>   > Source: src:node-lodash
>   > Version: 4.17.21+dfsg+~cs8.31.173-1
>   > Severity: serious
>   > Justification: do not compile from source
>   >
>   > Dear Maintainer,
>   >
>   > The vendor directory should be emptied
>   >
>   > The debug version is compiled without source (lintian warn)
>   > and moreover the rest of file are already packaged
>   >
>   > grep -R vendor * gives only a few hit that could be cured by
>   > symlinking
>   >
>   > Bastien
>   Hi,
> 
>   this files are used for test only, maybe severity could be decreased.
> >>>
> >>> I find the severity accurate: Relying on non-source code is a severe
> >>> violation of Debian Policy, not matter the purpose of relying on it.
> >> 
> >> I think we should change the policy here. Running tests helps improve
> >> the quality of the software we ship. Many times the vendored code is
> >> used to ensure the code does not break in a specific situation. I don't
> >> think reducing test coverage in such situations is really helpful.
> >
> >Right, running tests helps improve the quality of software we ship.
> >Which is why you probably need to test using what's shipped in Debian
> >rather than using a vendored source-less code.
> 
> We are not shipping the source less code. This is used only during
> tests. I don't think we are not gaining anything by removing tests
> here. Just making it harder for the package maintainer to run tests.

If the original report is correct (I haven't looked at the package),
then Debian is, indeed, shipping the source-less code.  Debian ships
both source packages and binary packages.  The source-less code is in
the source package, and is thus shipped by Debian.  The DFSG applies to
both source and binary packages.

> >If we rely on non-free code for tests, that's really bad too, and that
> >must be avoided just like we're avoiding source-less code everywhere
> >else in Debian. The policy shall not change, please.

+1

> The code is not non-free here, just a specific version of a Free
> Software code built outside Debian.

I think you are confusing "Free Software" with "DFSG Free Software".
Debian has more strict standards than some other parts of the Free
Software community.

> I think tools required for tests should be considered separately from
> tools required to compile. I think it should be treated similar to
> test data.

Actually, I agree with this, but not exactly in the way you intended.  I
think there should be a way for a source package to specifically
identify a Build-Dep as a test (probably with a separate field, maybe
Test-Depends), and to identify tests that must run for the build to be
considered successful, and tests that are optional (perhaps
Test-Suggests).  This would allow Non-Free tests (and test data) to be
packaged separately and included in non-free where they belong, with the
requirement that a source package can Test-Suggests a non-free package,
but it cannot Test-Depends such a package.  This would also allow tests
that require external networking resources, or tests that consumed an
inordinate amount of CPU, or..., to be Test-Suggested, without
interfering with a normal binary build.

The buildds could be enhanced to build the binary packages without any
of the test dependencies present, then install the desired set of test
dependencies and run them.  This would ensure that the binary packages
were built without the test packages even present (a huge benefit, in my
opinion), but that tests were still performed.

I'm not sure how many existing tests require the built programs to still
have the build environment present (i.e. vestiges of the build process
are used by the test), but it would be nice if the binary package could
be sent to another machine where the binary package (without the source
package) was installed with the desired test packages, so the tests
could be run on the properly installed binary package.

This would, of course, require a moderate amount of implementation in
the buildds and core tools such as dpkg, and I am not in a position to
help with this, so the people who can do so would have to like my idea
enough to spend their own time to implement it.

> I think blindly applying a rule without thinking of any consequences is bad 
> too.

I don't think anyone is blindly applying the DFSG to the source package
here.  It is important to separate "DFSG Free" (main) from "Free but not
DFSG Free" (non-free) in all aspects of the source package, including
tests.  The problem is that there is currently no mechanism available to
have the build process identify and select either 

Re: Bug#993488: maybe reason for wontfix?

[Marvin Renich]

* Tomas Pospisek  [210903 08:27]:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a
> "wontfix + close" but no rationale. Which leaves the original reporter with
> a large "?" I guess.
> 
> I am guessing that the reason for the "wontfix" is "that's just how Unix
> works unfortunately" aka "that's a Unix design bug"? Is my guess correct?
> 
> One other question - any idea on a way forward here? I would guess that
> behaviour (changing group membership won't change group membership of
> running processes) is rooted somewhere quite low in the stack, maybe in the
> kernel itself (or in posix :-#)? So if the original reporter would want to
> go ahead and look to that problem beeing fixed would he need to go talk to
> the kernel mailing list or do you have idea where he could go to?
> *t

Attempting to "fix" this can never fully work.  One of the fundamental
designs of *nix permissions is that a process can open handles with
current permissions, than drop privileges below what would be necessary
to open those handles, but continue to use those handles.

So, even if the Linux kernel watched for group membership changes, it
could only affect attempts to open new handles, not existing open
handles (otherwise, much existing code intended to increase security
would cease to function without any obvious way to fix it).

I don't think this was a design bug, but rather a conscious design
choice.  Just like a process can drop permissions, the process gets is
initial set of permissions from the state of the user db _at process
start_, not dynamically each time a permission-checking system call is
made.

Suppose a root process calls setgroups to add specific supplementary
groups, then sets the uid.  One of the groups the process intentionally
set is coincidentally one of the user's additional groups.  Now the user
(in the user db) is dropped from that group, but the program was written
intentionally to grant that group regardless of the user's group
membership.

In other words, the kernel has no way of knowing whether a process was
granted group access because the user was a member of that group or
because the program running in that process explicitly added that group.

The OP's issue is really only an issue for shells, where one might
expect that a new "command" uses the current user db rather than
inheriting from the shell, which got its permissions from the initial,
rather than current, state of the user db.

Changing the shell behavior to track the user db is fraught with
security issues.  Adding new groups would require the shell to maintain
CAP_SETGID permissions, and properly retain or drop those permissions
for each created process.  This would require the shell to be setuid
root to be able to work correctly in all situations.  This is just not
going to happen.  It doesn't make much sense to me for the shell to drop
removed groups but not add new groups when the user db changes.

So, I think your real answer is "that's just how Unix works
(fortunately)".  I really think this should be tagged not-a-bug.  :-)

...Marvin

Re: merged-/usr vs. partially-symlink-farmed-root

[Marvin Renich]

* Ansgar  [210823 11:16]:
> Hi Marvin,
> 
> On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote:
> > Yet they cannot be counted on to work on Debian now, nor will they on
> > non- or partially-merged systems.  You are saying "the end result is
> > thus, so the partially merged system must have this property."
> 
> No. I am comparing end results from two different proposals. I am not
> talking about any intermediate state.
> 
> There is no replacing /bin with a /bin -> /usr/bin symlink ever in the
> partially-symlink-farmed-root proposal. So you only get the symlinks
> provided explicitly in /bin by packages and, e.g., dash would ship
> forever a /bin/sh -> /usr/bin/sh symlink and this would be present on
> all systems.
> 
> Only non-required symlinks like for, say, run-parts could be dropped.
> 
> See [1] about "finishing the transition".
> 
>   [1]: https://lists.debian.org/debian-devel/2019/02/msg00321.html

I did, indeed, miss this.  I stand corrected; please accept my
apologies.

While I understand Guillem's rational, I believe that the effort to
clean up once there are only symlinks in /{,s}bin could be easily
automated and would technically be worth the effort (including code in
dpkg to recognize symlinks such as /bin/dash → /usr/bin/dash and mark
them in its database as "intentionally not placed on the filesystem").

However, at this point, I don't believe it is socially feasible to
continue down the symlink-farm path.

Again, I apologize for the misinformed argument.

...Marvin

Re: merged-/usr vs. partially-symlink-farmed-root

[Marvin Renich]

* Ansgar  [210822 17:29]:
> Hi,
> 
> On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote:
> > * Ansgar  [210822 05:08]:
> > > To get a filesystem layout equivalent to merged-/usr via symlinks
> > > farming *every* package shipping files in at least /usr/bin,
> > > /usr/sbin and possibly some of /usr/lib would need to include
> > > symlinks in /bin, /sbin, /lib.  This would affect far more
> > > packages than updating the packages currently shipping files in
> > > /bin, /sbin and /lib* to ship these under /usr instead.
> > 
> > It is true that for a symlink-farm-usr-merge system to be strictly
> > equivalent to a symlink-dir-usr-merge system, many packages that
> > never had /bin/foo but had /usr/bin/foo would have to add a symlink
> > /bin/foo, however this is clearly unnecessary.
> 
> No, it is required if we want users to be able to run scripts that use
> `#!/bin/python3` (or similar for other interpreters).  Such scripts
> exist in the wild, they were not initially written on Debian.
> 
> These would need Debian-specific patches to work on Debian.  It is just
> the opposite of now having to patch software packaged in Debian to use
> /bin/rm instead of /usr/bin/rm (that also happens in the wild for
> software not developed on Debian).  We also happen to miss such
> instances and needlessly make software buggy on Debian.
> 
> Not having to worry about yet another small incompatibility between
> distributions is a nice feature.

Yet they cannot be counted on to work on Debian now, nor will they on
non- or partially-merged systems.  You are saying "the end result is
thus, so the partially merged system must have this property."  That
does not follow.  It is part of the impatience for a finished product
that usually ends up with something less ideal than would be possible
with a more patient approach.  (And the symlink-dir approach appears to
me to be driven primarily by impatience.)

Anyone who has a '#!/bin/python3' script now, must ensure the link is
there themselves, and that would not change in the middle of a
symlink-farm transition, nor would it hinder such transition.

I was initially in favor of the symlink-farm approach, because it is the
correct technical solution.  I have become convinced that the
symlink-dir approach is the correct social solution (which is often, and
I believe in this case it is, worse than the correct technical
solution).  I also believe that fixing dpkg to handle the general
"symlink dir on file system where .deb has a real dir" case is useful
for other cases.

However, do not use bogus arguments such as the one above to try to make
your point.  It clutters the discussion with needless debunking.

...Marvin

Re: merged-/usr vs. partially-symlink-farmed-root

[Marvin Renich]

* Ansgar  [210822 05:08]:
> Hi Guillem,
> 
> On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote:
> > There was talk about the huge amount of symlinks required in a
> > symlink farm setting, but that might have been true for a scenario
> > where those symlinks would have been handled automatically and
> > transparently.
> 
> To get a filesystem layout equivalent to merged-/usr via symlinks
> farming *every* package shipping files in at least /usr/bin, /usr/sbin
> and possibly some of /usr/lib would need to include symlinks in /bin,
> /sbin, /lib.  This would affect far more packages than updating the
> packages currently shipping files in /bin, /sbin and /lib* to ship
> these under /usr instead.

It is true that for a symlink-farm-usr-merge system to be strictly
equivalent to a symlink-dir-usr-merge system, many packages that never
had /bin/foo but had /usr/bin/foo would have to add a symlink /bin/foo,
however this is clearly unnecessary.  The problem that the symlink farm
is solving is that scripts (distributed or user-written) that depend on
/bin/foo need to continue to work on a partially merged system.  A
previous message (already deleted, so I'm not sure from whom) clearly
identified 240 packages (number pulled from memory, so might be off)
that would have to put symlinks in /bin and /sbin for the
symlink-farm-usr-merge strategy to work.

The amount of work is orders of magnitude less than you are
representing.  There is no need for the symlink-farm to exactly match
the symlink-dir solution.  The union of systems during the symlink-farm
merge and systems after the merge is complete can _only_ count on
/bin/foo existing if it existed before the merge was started.  There is
no need for anything else (wrt /bin/foo existing).

...Marvin

Re: Planning for libidn shared library version transition

[Marvin Renich]

* Marvin Renich  [210527 13:41]:
> packages use the same wording in the description, and searching for the
> specific word "transitional" has a non-negligible chance of a false
^
or  "dummy"

...Marvin

Re: Planning for libidn shared library version transition

[Marvin Renich]

* Andrey Rahmatullin  [210527 10:38]:
> On Thu, May 27, 2021 at 10:10:15AM -0400, Marvin Renich wrote:
> > If transitional packages either had a debtag or a control file field
> > that identified them, then tools like deborphan could easily be made to
> > find and remove them
> Oh they already do (both the oldlibs section and the "dummy" description
> substring are supported by deborphan), but deborphan needs to be run
> manually.

oldlibs has a different purpose:  to identify libraries that are
outdated, but that the user might want for various reasons (e.g.
non-Debian software that requires an older library version).

Using text in the description seems, uh, kludgey at best.  Something
more specific and canonical would be an immense improvement.  Just
looking through oldlibs makes it obvious that not all transitional
packages use the same wording in the description, and searching for the
specific word "transitional" has a non-negligible chance of a false
positive.

...Marvin

Re: Planning for libidn shared library version transition

[Marvin Renich]

* Simon McVittie  [210527 06:19]:
> The one non-cosmetic reason I can think of why transitional packages
> are potentially bad is that they aren't removed automatically, so systems
> that have been upgraded many times can end up with a lot of transitional
> packages;

If transitional packages either had a debtag or a control file field
that identified them, then tools like deborphan could easily be made to
find and remove them, perhaps ensuring that the replacement package was
appropriately marked as manual or automatic.

Once that is common, apt and friends could be made smarter as that
particular itch bothered the responsible maintainers.

...Marvin

Re: Proposal: plocate as standard for bookworm

[Marvin Renich]

* Steinar H. Gunderson  [210209 14:27]:
> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
> > And there are now also many non-technical Linux users who have never
> > used a shell.
> 
> Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
> traceroute? host? All of these are irrelevant for a non-technical
> non-shell user, yet a fairly common part of a Linux installation.

These have come to be expected to be on a typical Linux system by almost
every technically-knowledgeable Linux user.  Locate does not satisfy
that criterion, and I think the dissension in this thread is evidence of
that.  Most of the ones you mention above might be necessary when trying
to fix a broken system.  Locate might save a little time, but find,
which is standard, will suffice for that purpose.

I just tried plocate, and it certainly looks faster to update than
mlocate.  Thanks for packaging this!  I've just removed mlocate.

However, I agree with others here that anyone who wants a locate
implementation will know how to find all the packages with "locate" in
their names and plocate looks to me, from the descriptions, to be the
best choice.  I don't think it deserves "Priority: standard".

...Marvin

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.

[Marvin Renich]

* Jeremy Bicha  [201013 18:09]:
> On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich  wrote:
> > Describing a clear benefit to having both open and see would help
> > immensely.  Alternatively, convincing the mime-support authors that open
> > should replace see would also work.
> 
> This thread is full of people who strongly prefer "open" over "see"
> ("see" is also little known). Add me to that list. In this case, I
> don't care whether other operating systems do it or not.
> 
> I think "see" was used because "open" was not available. I don't know
> why you are so interested in having "see" go away. It could be removed
> but it's not clear at all to me that it needs to be removed at the
> same time "open" is added. (I don't see anything else that would want
> to use "see".)

Sorry if I gave the impression that I thought see should be removed.
That was not at all what I was saying, and I don't believe it should.

I was trying to identify how the new proposed implementation of "open"
was better or different than "see".  My impression from this thread is
that the only issue is that a lot of people like the name "open" better,
and the current "see" is technically better (or at least as good) other
than a name preference.  If that is the case, then there is probably a
much better solution than adding a new package to the archive that will
likely be installed in most of the same system configurations that
mime-support is.

The mime-support package seems to me to be the "right" place for "open"
and/or "see".  If enough people have a strong opinion that Debian needs
an "open" that does what "see" currently does, I think a wishlist bug on
mime-support is the correct course of action.  That would allow several
choices of implementation, the most likely (in my opinion) is adding
another symlink from open to run-mailcap and _possibly_ deprecating, but
leaving in the package, the "see" symlink.

If mime-support used "see" because "open" was unavailable at the time, I
would expect the mime-support maintainers to be very favorably inclined
to such a wishlist bug.

Adding even a very small package to the archive has a significantly
higher cost for the archive, the maintainers (including ftpmasters,
security, QA, etc.), and the end users than does adding one symlink in
an existing package.

Again, if the new "open" has features that "see" does not, let's
identify them so we can decide whether they belong in the mime-support
package or in a new package.  If the only advantage is the name, I
cannot understand why anyone would object to at least approaching the
mime-support maintainers before plowing ahead with a new package.

...Marvin

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.

[Marvin Renich]

* Noah Meyerhans  [201013 00:54]:
> "open" is a verb commonly used to describe the action of accessing a
> file in Linux.  You used it yourself above, and it's one of the most
> prominent functions in the file API.  It seems sensible to provide a
> tool that matches the verb most commonly used to describe this action.
> 
> The availability of
> /usr/bin/open wouldn't preclude your use of whatever program you want to
> use.  What it would do is provide a convenient utility to support people
> who don't (yet) have a preference for what application they want to use
> to open a file.  Maybe they have only basic needs, or are unfamiliar
> with the file type and its associated commands.  There are surely many
> other reasons.

Earlier in this thread, the program "see", part of mime-support, was
mentioned as already providing this functionality.  What does the
proposed "open" do that "see" doesn't, or what does it do in a
significantly different way that having both of them would be a benefit?

So far, the only answer I have seen is that MacOS users are familiar
with open.  To me, this is not significant enough.  A symlink or cover
script that does simple massaging of the arguments, which invokes an
existing utility like run-mailcap, would be better served by a
macos-helpers package that can become a collection of utilities that
help users coming from MacOS feel more comfortable in Linux.  These
wouldn't clutter the $PATH space for users who did not want them.

The other difference that I remember being mentioned is that the
proposed open only handled files, not URLs, but the author was willing
to add that functionality to open if it was deemed popular.

Describing a clear benefit to having both open and see would help
immensely.  Alternatively, convincing the mime-support authors that open
should replace see would also work.

If open does not provide any real benefit over see, I would not want it
to be in the transitive Depends or Recommends of a standard Debian
desktop installation, which would then obviate its usefulness in the
archive (except as a macos-helper as above).

...Marvin

Re: Preferred form of modification for binary data used in unit testing?

[Marvin Renich]

* s...@debian.org  [200717 17:51]:
> On Fri, 17 Jul 2020 at 10:44:24 -0400, Marvin Renich wrote:
> > The intended purpose is to ensure that the recipient has every
> > reasonable opportunity to modify the software in any reasonable way the
> > recipient desires.  The sole purpose of the requirement for source is to
> > protect this freedom, and the requirement should not be applied
> > independently from this purpose.
> 
> I mostly agree, and I do agree with the resulting conclusion, but I
> don't think this is *quite* the whole story. What you said here maps
> to the FSF's "Freedom 3" and half of "Freedom 1", and also matches the
> justification given for the source code requirement in the annotated
> Open Source Definition.
> 
> In addition to freedom to modify, I think we also want to make sure a
> sufficiently knowledgeable recipient can inspect the unmodified software;
> that's the other half of the FSF's "Freedom 1" (freedom to study).
> However, I don't think considering freedom-to-study actually changes
> the conclusion in this case.

Thanks, Simon.  This is very instructive, and I agree.

...Marvin

Re: Preferred form of modification for binary data used in unit testing?

[Marvin Renich]

[This was just a convenient point in the thread to which to reply; it's
not really a reply to Sean's specific message.]

I think, instead of pedantically applying the wording of the DFSG, we
should be pedantically applying the intended purpose of the DFSG.  The
legal profession has proven, time and time again, that no written
language can perfectly express any sufficiently complex idea (nor can it
express perfectly many very simple ideas).

The intended purpose is to ensure that the recipient has every
reasonable opportunity to modify the software in any reasonable way the
recipient desires.  The sole purpose of the requirement for source is to
protect this freedom, and the requirement should not be applied
independently from this purpose.

So the question becomes how does the inclusion or exclusion of the
binary blob, without inclusion of the full source and build process of
the broken version of the software used to produce the binary blob,
enhance or detract from the recipient's ability to produce a modified
version of the current, good, distributed software.

First, recognize that in this case, the software may be built with or
without the binary blob present, and the resulting software will be the
same.  The blob is only used to allow the person modifying the software
to check for mistakes made during modification.  My opinion would very
likely be different if this were not the case.

In what way does the absence of the blob's source limit the recipient's
ability to modify the current version of the software?  What real,
reasonable (as opposed to hypothetical and unreasonable) kind of
brokenness of the _current_ version of the software would you want to
produce a test for, that not having the old broken version of the source
code would hinder?  The real answer is that the programmer is much more
likely to base such tests on slight modifications of the _current_ code
rather than the _old_ code that had one specific bug that was the
impetus for producing the blob as a test case.

So the reduction of freedom by including the blob without its original
source is infinitesimally small (if not zero).  It is made even smaller
in this specific case by the fact that the source is available from an
older Debian distribution, though this is really beside the point, as
the current application of the DFSG treats one version of Debian as a
stand-alone entity that cannot depend on software in other versions of
Debian.

On the other hand, by including the blob, the test suite used to prevent
regressions due to modifications is significantly more robust, which is
a huge increase in the recipient's ability to modify the software
without unintended consequences.

So, in my opinion, the inclusion of the blob provides a significant
increase in the freedoms that the DFSG is intended to protect, without
any real decrease.

...Marvin

Re: Is an init required to obey policy-rc.d during boot ?

[Marvin Renich]

Reply-To debian-devel@lists.debian.org:
In-Reply-To: 

* Michael Biebl  [200422 19:43]:
> Am 23.04.20 um 00:43 schrieb Thomas Goirand:
> > On 4/22/20 4:11 PM, Sam Hartman wrote:
> 
> >> And a native interface for a sysadmin overriding that (masking).
> > 
> > Unless I'm mistaking, that's not useful if you want to disable starting
> > the daemon before installing it (ie: before the .service exists in the
> > system).
> 
> Your assumption is wrong. You can mask a service before installing a package
> - systemctl mask foo.service (will issue a warning that foo.service
> doesn't exist but will proceed)
> - apt install foo (shipping a foo.service)
> → foo.service will not be started

With the limitation that you need to know, before installing the
package, the names of all the services it contains.

...Marvin

Re: documenting on how not starting a daemon upon installation

[Marvin Renich]

Thanks, Russ, Ansgar, and Marco for the explanations.

So in summary:

* For systems running systemd

  - systemctl mask works well to disable individual daemons until
explicitly re-enabled, regardless of which mechanism the package
uses (systemd service or init script) to start the daemon.

  - systemctl mask requires you to know, prior to installing a package,
the names of all services the package installs.
  - it has not been mentioned whether systemd provides any facility to
block starting _all_ services for a period of time (esp when working
in a chroot), including services that have not been installed at the
time the hypothetical "block all services" command is invoked.

* For systems running either systemd or sysvinit (maybe also runit?)

  - policy-rc.d can block individual systemd services and init scripts.
  - policy-rc.d can block all services and init scripts.

  - policy-rc.d is not well documented.
  - policy-rc.d requires manually writing a shell script (a trivial
one-liner for the "block all" case).

It is also worth noting that systemctl mask works on any systemd
distribution, not just Debian GNU/Linux, but not other Debian ports with
non-Linux kernels.

And, policy-rc.d presumably works on any Debian distribution, not just
Debian GNU/Linux, but not on non-Debian distributions.

It looks to me like policy-rc.d is the best fit for performing package
installations in a chroot (the OP's original question, IIUC), while
systemctl mask is the right choice for manually dealing with maintenance
of individual, already installed packages.

...Marvin

Re: documenting on how not starting a daemon upon installation

[Marvin Renich]

* Marco d'Itri  [200310 11:23]:
> The modern and simple solution is "systemctl mask", as long as you do 
> not need to care about the 0.6% of systems which do not use systemd.
> If you are doing this for your own systems then you obviously know if 
> you can rely on systemd or not.

I don't believe this is correct, though I could be wrong.  I believe
policy-rc.d is sufficient for both systemd and sysvinit systems, and
that it is necessary for _packages_ that only ship an init script and
not a service file, regardless of the init system in use.

Can you tell me,

A)  Does systemctl mask work for packages that do not have a systemd
service file when systemd is the init system?

B)  Can systemctl mask be run on a subdirectory that you are about to
chroot into, but have not yet done so?

If both these questions are yes, and the system in the chroot is using
(will be using) systemd, than systemctl mask should be sufficient.
Otherwise I think policy-rc.d is necessary.

...Marvin

Re: documenting on how not starting a daemon upon installation

[Marvin Renich]

* Simon Richter  [200309 12:33]:
> On Mon, Mar 09, 2020 at 04:02:52PM +0100, Tomas Pospisek wrote:
> > In my logic, finding out how "not to start services on install" should
> > be documented in `man dpkg` or referenced from that man page. As far as
> > I could see there is absolutely no trace of any hint on how to do that
> > in that man page.
> 
> I'd expect to find this information in Policy, since it's a matter of
> system integration and package-to-package interaction. Dpkg has no control
> over whether a postinst starts a daemon or not.
> 
> For init.d based init systems, policy 9.3.3.1 indeed documents exactly what
> you need to do to install a daemon that is disabled by default. This
> section should be extended to document the interface for systemd.

I think the OP's question was not about creating a package with a daemon
that is disabled by default, but about preventing an existing package,
that would otherwise start its daemon, from starting it.

My understanding (and I might very well be wrong) was that, due to the
historical evolution of systemd in Debian, even packages that only
include systemd service files and not init scripts still use
invoke-rc.d, and systemd provides its own implementation that obeys
policy-rc.d (if it exists) and then either invokes systemctl start or
the init script, as appropriate.

I was under the impression that the init-system-agnostic method to
prevent dpkg from automatically starting daemons was to create an
appropriate policy-rc.d file.

This is definitely not clear from the current policy document, and
policy should define an init-system-agnostic way to do this.

As for the other poster who seems to be advocating an approach which
combines policy-rc.d and diverting or replacing files in /bin and
/usr/bin, I believe that is neither necessary nor appropriate in the
general case.  For the specific cases of debootstrap and live-build,
there might very well be other reasons for diverting system binaries (or
it could be left over from before the implementation of policy-rc.d),
but let's not cargo-cult this into inappropriate situations.

...Marvin

Re: not starting a daemon upon installation

[Marvin Renich]

* jnq...@gmail.com  [200308 10:58]:
> On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote:
> > The problem is that installing the package will automatically start
> > the
> > daemon cluster in a "default" configuration.
> > 
> > [1]
> > https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#
> 
> i can't comment on what might be considered an "official" solution.
> 
> how live-build achieves this is essentially the same as happens to be
> discussed in the linked page for Debian's debootstrap package (the tool
> for building the base filesystem).
> 
> that is to use dpkg-divert to temporarily replace the /sbin/start-stop-
> daemon binary with something that essentially just exits with success
> (i.e. 0). This could be an empty shell script (or one that prints a
> warning about the diversion being in place as in the linked discussion)
> or a symlink to /bin/true.
> 
> enabling diversion:
> ```
> dpkg-divert --add --rename /sbin/start-stop-daemon
> ln -fs /bin/true /sbin/start-stop-daemon
> ```
> 
> removing diversion:
> ```
> rm -f /sbin/start-stop-daemon
> dpkg-divert --remove --rename /sbin/start-stop-daemon
> ```

I'm surprised that live-build does this and that debootstrap does as
well.  Note that the link above, farther down the page, gives what I
thought was the "correct" answer, which is to create a script,
/usr/sbin/policy-rc.d, which simply invokes exit 101.  This is also the
method described in the Debian wiki page for chroot [2].

live-build and debootstrap may have been doing this since before the
policy-rc.d API was defined, and they may also have more strict needs
than is defined by policy-rc.d (e.g. handling misbehaving packages).

However, for the OP's original purpose described in this thread, I
believe the policy-rc.d approach is the correct solution, and
dpkg-divert should be avoided.

[2] https://wiki.debian.org/chroot

...Marvin

Re: Heads up: persistent journal has been enabled in systemd

[Marvin Renich]

* Matt Zagrabelny  [200204 21:27]:
> The contents of /var/log/journal will be binary files that journalctl
> will read. IIRC.

This is my objection to the systemd journal.  Binary log files are
absolutely _horrible_ for the general user, but they are terrific for
large data centers.

In a large data center, the logs from many machines are being sent via
network to a machine whose job it is to collect them, where sysadmins
can monitor all the hosts.  The binary format is much more efficient.

However, on an individual user's machine, you are now forced to use a
specialized program to parse the logs.  If a journal file is damaged in
the middle, the remainder of the file is useless without expertise in
the binary format of the file and significantly more (usually
prohibitive) forensic effort.  If a machine crashes and the user needs
to examine the logs offline (e.g. booting from a live image, or copying
the logs to a different machine), now he/she needs to learn how to use
journalctl on external files; perhaps this is easy, but it is one more
thing to learn.  Anyone administering their own personal machine knows
how to look at text files, and there are a wide variety of tools
available to manipulate them.  Text log files can be copied to a Windows
machine, a BSD system, or even to a smart phone, and are just as usable
there; binary journal files are not.

When your machine has crashed or your hard disk is having intermittent
failures are times when you most need to be able to read log files, and
are times when dealing with a binary format may be the hardest.

When choosing defaults for the Debian distribution, if one default is
more appropriate for the general user and another is better for the
experienced sysadmin, the maintainer should almost always opt in favor
of the general user.

...Marvin

Re: Adding security features (was: Kernel parameters protecting fifos and regular files)

[Marvin Renich]

* Richard Laager  [200129 19:05]:
> On 1/29/20 8:28 AM, Marvin Renich wrote:
> There are plenty of shades of
> grey in this, and what counts as "minimal", "medium", or "massive" is
> going to be at least somewhat subjective.

Completely agree.

> I'd say that "massive breakage" (breaking lots of things) is not the
> same as "maximal disruption" (the most disruption). Maximum disruption
> would be, for example, breaking things that were "fully correct" (not
> doing something "dodgy") before the change. This would be a "flag day"
> change. That level of disruption needs to be avoided if at all possible,
> and carefully managed if completely unavoidable and worth the pain.

My intended meaning of disruption, in my previous message, was not the
inevitable churn associated with ironing out the bugs.  It was the
resulting decrease in ease of use (and increase of other costs) after
the bugs settled.  Sorry if that wasn't clear.

There is always a trade-off between security and usability.  My point is
to not force more security on everybody _as the default_ when only some
users need that security, and most of the time the users who need the
security are the ones who are able figure out the knob to tweak to get
it (and many times they are using something like puppet to ensure that
all the machines they support get the configuration they want).

Because of this, distributions, when choosing defaults, should give more
weight to the needs of those less likely to be able to do the
configuration themselves than to those with more advanced needs.  I do
agree that sometimes having a slightly higher level of security is the
best default; just give appropriate thought to the associated costs.

> > Time and time again I see security expert "wannabes" pushing for the
> > most security possible.  Even real experts sometimes lose sight of the
> > balance between usability and security.  Unfortunately, there are a lot
> > more "wannabes" than real experts, and the "wannabes" are typically much
> > more vocal.
> 
> While I understand your point, I think it would be better to focus on
> the arguments rather than the people making them.

Okay, that paragraph was too pejorative.  Let me rephrase it.  (Note,
however, that I did not identify anyone in particular, nor did I have
any specific person or persons in mind.)

Some people actively and regularly encourage others (distributions,
large ISPs, etc.) to use a higher level of security as a default than
most people need without regard to how it affects usability and other
real costs (such as bandwidth and CPU usage, which affects how much
people have to spend).  Not only is setting the default level of
security too high a bad thing, but the act of promoting this is a bad
thing.  (This last sentence was really the point I was trying to make
with the paragraph in my previous message.)

If I offended anyone who considers themselves to be one of the people
described in the previous paragraph by calling them security expert
"wannabes" in my original message, I do apologize.  But please, stop
pushing for higher-than-necessary defaults for security.

As a specific example of unnecessary default security, take the "https
everywhere" campaign.  Having https available on most servers is
definitely good.  However, if you explicitly go to
http://www.google.com/ you are redirected to the https version.  Of all
the (hundreds of?) billions of google searches done every day, how many
of them would really cause any harm at all if the communications were
unencrypted?  Yet the entire computer-using segment of society pays the
price for higher bandwidth and CPU usage.

Note that my whole argument is not about what should or shouldn't be
available.  It is about what the defaults should be.

...Marvin

Adding security features (was: Kernel parameters protecting fifos and regular files)

[Marvin Renich]

I have no opinion about this specific feature; at first glance it looks
like it might be a reasonable thing to do.  On the other hand, I
strongly disagree with this statement as a general rule:

> Unless massive breakage is expected, the default should
> be the most secure option.

This is the wrong way around.  In a general distribution, the default
should be to use the maximum amount of security that can reasonably be
expected to cause _minimal_ disruption to usability.  The above
statement implies that the default should be the maximum security that
does _not_ cause _maximum_ disruption.  (Even medium disruption is the
wrong balance for a general distribution's default.)

Time and time again I see security expert "wannabes" pushing for the
most security possible.  Even real experts sometimes lose sight of the
balance between usability and security.  Unfortunately, there are a lot
more "wannabes" than real experts, and the "wannabes" are typically much
more vocal.

If you change "Unless massive breakage is expected" to "If breakage is
expected to be minimal", than I would agree.

On the other hand, I do agree with using unstable and testing to
determine the level of disruption, on the condition that there is a
_commitment_ to removing the feature before stable release if the impact
on usability is more than minor.

I would like to give big kudos to the AppArmor team for providing Debian
developers and users with an exemplary experience while adding a
security feature as a distribution default.  I think the rollout went so
smoothly that the AppArmor team did not get enough attention for the
terrific job they did.  That transition should be held up as a model for
implementing any big feature change in Debian.

...Marvin

Re: [RFC] Proposal for new source format

[Marvin Renich]

I think this discussion has conflated two separate needs that should be
kept distinct.  The current source package provides a record of how the
binary packages were built from source.  This includes signatures and
verifiability of source, and, more recently, reproducibility.  It
provides the ability to build the binary packages on a user's own
machine, and can be a starting point for building them in an environment
not supported by Debian (in simple cases this might be exactly the same
as building on a current Debian architecture).

The source package has historically (prior to the widespread use of VCS)
also provided the basis for future development.  Since most development
these days is done using VCS, it's natural to try to adapt the source
package to contain the VCS.  I believe this is a mistake.  I think the
source package should remain a succinct encapsulation of the source
required to build a specific version of the binary packages.  It should
also identify the canonical VCS location where new development occurs
(and from which this snapshot was taken), but it does not need, and
should not have, the complete VCS history.

I do believe that Debian should strongly encourage use of a publicly
accessible VCS for packaging, and should define some VCS-agnostic
standards that the repositories SHOULD (RFC implications) follow, e.g.
basic branch structures, tag naming conventions, etc.

Separating the source package from the VCS repository, but having both,
allows both Russ' and Russell's goals to be met easily.

One important aspect of this separation is that the VCS can include the
original, unmodified upstream source, as long as it is redistributable
in that fashion.  It has always bothered me that the modifications
needed to convert the upstream source to a DFSG-compatible source are
lost in the Debian source package.  Keeping the VCS separate allows it
to contain the original, non-DFSG source and show what was done to make
it DFSG and why.  It will also help to facilitate using a single
repository to build both a source package for main and a corresponding
source package for non-free, when that is appropriate.

[Perhaps the following should be moved to the Git Packaging thread, but
I think much of this sub-thread could also be said to belong there.]

I think the VCS-agnostic aspect of this has not been brought up in the
related "Git Packaging" thread, but I think this is important.  While
git is overwhelmingly the most popular VCS, it is not the only one (it's
also not my preferred VCS for usability reasons).  I think it is
short-sighted for Debian policy to mandate or even to strongly encourage
a specific VCS.  This effectively shuts down the use of any other VCS,
and extremely hinders attempts to get a new or better VCS to be used for
Debian development.

Debian should separate everyday development with the VCS from
interaction between the VCS and the Debian archive.  The tools provided
for the former can be very VCS-specific, and can make full use of that
VCS' features.

The tools for interacting with the archive, e.g. making it trivial to
upload a signed commit to be built on official Debian hardware, should
define a very small set of standard features necessary to accomplish
that, such as clone, commit, checkout, push, pull, and tag (with
signature).  This API should have a minimum of options, and it should be
easy for someone to implement a shim from that API to a specific VCS.

This separation would allow much greater freedom of choice, but still
allow the developer to take full advantage of the chosen VCS.

...Marvin

Re: When acting as a service admin, it's official, no really.

[Marvin Renich]

* Alexander Wirt  [191009 08:45]:
> If we want to announce something, we announce it. Until we do something like
> this: of course there can be a (temporary) veto. You can't expect us to allow
> things that will break the service for everybody without stepping in. That
> doesn't mean that such things are final decisions or the we don't work with
> people to improve/fix things. 
> 
> Bastians communication is sometimes a bit shorter or more direct than it
> should be. If you are unsure about things - talk to the team and not
> something hidden in some threads (salsa-admin@ or IRC).

While that may be fine in general, when a team member speaks officially
(and that was explicitly stated by Bastian in this case:

> > >> > Bastian> For this I need to use my veto as Salsa admin.

) on a public Debian list (or privately), it is up to the team to make
each other aware; it is not up to others to use alternate channels to
say "Hey, one of your team said X on devel.d.o".

If Bastian's veto was not a permanent decision, that was not
communicated at all, and it should have been.  I'm glad it has been
clarified now.

...Marvin

Re: ML-Policy and tesseract-ocr

[Marvin Renich]

[Debian list policy is to reply to list without CC to individuals,
except where the individual has asked for a CC.]

For the rest of your reply, I agree with Sam's response (i.e. no
Suggests is necessary).

...Marvin

* Mo Zhou  [190812 20:29]:
> > The source package would need to Build-Depend on the training
> > program and its inputs, but in general there would not need to be a
> > normal Depends.
> 
> I see. The idea is that an ELF binary (ML model) doesn't have to
> Depend on it's compiler (training program) and source (input data).

Correct.  You don't see a binary package built with gcc Depending on
gcc.  Its source package, however, does Build-Depend on gcc.

...Marvin

Re: ML-Policy and tesseract-ocr

[Marvin Renich]

* Mo Zhou  [190812 10:31]:
> To this end, I wrote the policy #5 [3]:
> 
>A package that includes a machine learning model, must also include
>the corresponding training program, or depend on the package that
> provides
>the corresponding training program.
> 
> Does that make sense? If it looks good, then the solution
> for this bug is already obvious enough.

Perhaps I am not interpreting what you are saying correctly, but I would
say it is wrong.  The corresponding training program must be packaged in
Debian, but it seems unlikely that there would be a binary package
dependency from the model (result of running the training program with
specific input data, if I understand correctly?) to the training
program.  The source package would need to Build-Depend on the training
program and its inputs, but in general there would not need to be a
normal Depends.

Perhaps you were just being sloppy about Build-Depends vs Depends, but
when writing policy it is important to be very specific about that.

...Marvin

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

[Marvin Renich]

* Simon McVittie  [190808 18:37]:
> On Thu, 08 Aug 2019 at 15:20:28 -0400, Marvin Renich wrote:
> > The man page for machine-id says:
> > 
> >   This ID uniquely identifies the host. It should be considered
> >   "confidential", and must not be exposed in untrusted environments, in
> >   particular on the network.
> > 
> > Why is the file mode 0666?
> 
> I very much hope it's 0644 (rw-r--r-- or 0444 (r--r--r--). Mine is 0444.

Sorry, that was an incorrect translation from reading r--r--r-- to
typing 0666 when I should have typed 0444.  My next sentence expressed
my concern, which had nothing to do with the 0222 bits.

> > Does it need to be non-root readable?
> 
> Yes. Some of the applications that want an opaque unique identifier for
> the machine, like dbus-launch(1) (which uses it to disambiguate between
> machines sharing an X11 display), are unprivileged. If /etc/machine-id

Okay.  So, some unprivileged programs have a need to know (or at least
are currently implemented in a way that breaks if they cannot read it).

> > If
> > so, how can it be prevented from being exposed on the network if there
> > is any user access from the network?  Is this really a security concern?
> 
> If applications routinely broadcast the machine ID on local LANs or
> to an Internet server, then the operator of those LANs or servers
> can tell whether connections are coming from the same or different
> machines. Some people would consider this to be a privacy violation
> ("fingerprinting"). I suspect that the intention of that text is to
> encourage authors of networked software that uses the machine ID to
> think about this.
> 
> Analogous: don't tell those same LANs or servers your gethostname(2),
> or your MAC address (without randomization), or your IPv6 address
> (without "privacy extensions"), if you don't want them to be able to
> tell which machine you are using.

I don't get this at all.  Has there ever been a routine, best-practice
of having a machine that frequently changed its IP address to prevent
operators of other machines on the net from "fingerprinting"?  (I'm not
talking about intentional use of an onion router.)

My point is that Debian as a distribution is used in a wide variety of
use cases, from locked-down server to single-user desktop to multi-user
application server (what used to be called time sharing).

Specifically in this last scenario, and to a lesser degree in others,
any world-readable file MUST be considered both LAN readable and
Internet readable.  It is ludicrous to base any security on a
world-readable file (in the file permissions sense) being kept secret
from the real world.

My query was because the man page said "must not be exposed in untrusted
environments" and yet the file is world readable.  These two are
absolutely and unequivocally incompatible.

There are both privacy and spoofing concerns any time a machine
transmits any information on the network.  If that sentence in the man
page is aimed at application writers, then it should be reworded some.
One possibility is to remove that sentence and expand a little farther
down after the target audience is established:

This ID uniquely identifies the host. If a stable unique identifier
that is tied to the machine is needed for some application, using
the machine ID or any part of it directly could pose a privacy
concern. Instead the machine ID should be hashed with a

(I didn't smooth out the sentence transitions, but it's a start.)  This
avoids making a global, unqualified claim that cannot possibly be
maintained with the current implementation (i.e. mode 0444).

Alternatively, the file could be made mode 0400 and require all existing
applications that currently use it directly to be changed to use an API
such as sd_id128_get_machine_app_specific(3).  I suspect that this is
neither necessary nor practical, based on my new understanding from your
explanation.

BTW, thanks for your explanation; it did clear up the intent.  I now
believe this is just over-zealous documentation, which is much easier to
correct!

...Marvin

[OT] /etc/machine-id "must not be exposed in untrusted environments"

[Marvin Renich]

This is related to the thread Generating new IDs for cloning, but is
probably OT for this list.  I guess this is really a question for
systemd maintainers?  Should I file a bug?

The man page for machine-id says:

  This ID uniquely identifies the host. It should be considered
  "confidential", and must not be exposed in untrusted environments, in
  particular on the network.

Why is the file mode 0666?  Does it need to be non-root readable?  If
so, how can it be prevented from being exposed on the network if there
is any user access from the network?  Is this really a security concern?

...Marvin

Re: Generating new IDs for cloning

[Marvin Renich]

* Michael Stone  [190808 12:34]:
> I guess I need you to say what's confusing. It's an ID that doesn't change.
> You can look up gethostid to get a little more background. If you need an ID

First, let me say that I am not trying to be intentionally obtuse.  I am
really interested to know what programs, more specifically, what
services in a "typical" installation, actually use machine-id (for one
or more definitions of "typical", e.g. desktop or server).

What prompted my question was that someone earlier in this thread stated
that when he removed this file the system became unbootable (I think it
was a banana pi).  What part of the boot process fails?  What other
things that are commonly installed on some large class of machines are
going to fail if this is either missing or identical to ten other
machines on the same network that I cloned from the same image?

Marc's comment that systemd-networkd fails is a good partial answer.
The fact that the man page belongs to the systemd package is another
good clue, but not an answer.  Was this file added as part of systemd
because it was believed that gethostid(3) was insufficient?  If so, what
parts of systemd use it?

...Marvin

Re: Generating new IDs for cloning

[Marvin Renich]

* Michael Stone  [190808 08:42]:
> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> > Does anyone know what applications use this file for what purpose?  Is
> > this a systemd-ism?
> 
> man machine-id

The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists.  What
applications expect it to be there?

...Marvin

Re: Generating new IDs for cloning

[Marvin Renich]

* Bernhard Schmidt  [190808 07:48]:
> Am 08.08.19 um 13:39 schrieb Marc Haber:
> > How do I generate a new one?
> 
> I followed
> https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
> last time which means

Hmm.  The advice in that link doesn't match what man machine-id says,
which is to replace /etc/machine-id with an empty file rather than
remove it, and then reboot.

I have no idea which is the "correct" solution, but if the man page is
correct, that seems to be the simpler solution.

Does anyone know what applications use this file for what purpose?  Is
this a systemd-ism?

...Marvin

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Marvin Renich]

* The Wanderer  [190807 09:28]:
> Cloning isn't the only example of a case where some machine-specific
> configuration detail may need to be updated, without that being obvious
> in advance.
> 
> I've begun to wonder whether it might be worth the overhead to set up
> some type of mechanism to let packages which define such
> machine-specific IDs A: declare the fact, in a central location which
> the sysadmin of a machine where that package is installed can easily
> check, and B: define an automated way of performing the appropriate
> update / regenerate step in a way which covers all known places where
> the ID needs to be updated.

I think this is a good idea, but will require work and coordination to
accomplish.  A wiki.debian.org page with your ideas and (perhaps on a
separate page) a place to list things that need updating after the
physical copying is complete would be wonderful, if you feel motivated
to get it started.  :-)  Hostname, machine-id (new to me too!), and ssh
host keys can start the list.

...Marvin

Re: Propositon: Multiarchitecture Support in Next Debian 64-bit, Mozilla Firefox Release,...

[Marvin Renich]

* patrick.dre...@gmx.net  [190714 14:24]:
> Propositon: Multiarchitecture Support in Next Debian 64-bit (64-bit and
> 32-bit), Mozilla Firefox Release, in LXDE Startup Menu a Search field
> 32-bit i386 for Adobe Reader ftp.adobe.com

All of your recent posts to this list (debian-devel@lists.debian.org)
are more appropriate for the debian-user mailing list
(debian-u...@lists.debian.org).  In the future, please ask for help
there first.

Debian already has multi-architecture support, and running 64-bit
(amd64) and 32-bit (i386) programs simultaneously on a system whose
hardware supports amd64 instructions has been possible for a number of
years now.  A Google search for debian multiarch or debian
multiarchitecture will both give you the Debian Multiarch HOWTO wiki
page as the first result.

Please try to help yourself before asking others to spoon feed you
answers.

When you have suggestions, please try to determine the current status of
those features in Debian (e.g. Multiarch or Firefox vs Firefox ESR).
Asking on debian-user is a good resource for this; debian-devel is not
the right place to ask these questions.  If you determine that the
feature does not exist, familiarize yourself with the Debian Bug
Tracking System  and determine the
appropriate package (e.g. lxde or debian-installer) and file a bug on
that package with severity wishlist.  If you are having trouble
determining which package is appropriate, ask on the debian-user mailing
list.  The command reportbug, which is installed on a default Debian
installation, can help you through the process of filing a bug and
setting the appropriate severity.  All feature requests should have
severity wishlist.

Debian already has a number of PDF readers; ask on debian-user if you
cannot find one you like by searching with Google (or using synaptic or
one of the other package managers on your Debian system).

To reiterate, try to use search engines like Google or DuckDuckGo first.
If that doesn't work, ask on debian-user or some other user support
channel.  There is also a debian-user-french mailing list if that would
be easier for you.

...Marvin

Re: Bug: Opera 12.16 disappears

[Marvin Renich]

* patrick.dre...@gmx.net  [190623 17:27]:
> Bug: Opera 12.16 disappears.
> He can't see in Desktop of Debian in Search.
> How i can resolve this?

Opera has not been in Debian for quite some time.  A quick look at
www.opera.com seems to indicate that it is no longer open source
software, and thus cannot be included in Debian.

...Marvin

Re: Bug: can't install Mozilla Firefox

[Marvin Renich]

* patrick.dre...@gmx.net  [190623 17:24]:
> Fear Woman and Man!
> 
> In the system is the ESR version. I will have the Release version.
> Bug: can't install Mozilla Firefox.
> apt remove firefox*
> apt purge firefox*
> apt install firefox
> How can resolve this?
> 
> With kind Greetings!
> 

I think the package you want is firefox-esr, although firefox is in
unstable but not stable or testing.  This is a user question; please ask
for help on .

...Marvin

Re: Proposition: Simlify the Installation

[Marvin Renich]

* patrick.dre...@gmx.net  [190623 17:27]:
> Proposition: Simlify the Installation. Dosn't have 2 Installation options.
> ..., Graphical Installation.

You may file a bug with severity "wishlist" against the package
"debian-installer".  However, I think many people like having the choice
of text vs graphical installer, so you may find that the Debian
installer team will choose not to accept this particular suggestion.

...Marvin

Re: Debian Bugs: LXDE Desktop is missing

[Marvin Renich]

* patrick.dre...@gmx.net  [190623 17:24]:
> Dear Woman and Man!
> 
> Debian Bugs: LXDE Desktop is missing.
> Terminal Comands not functions.
> apt-get install lxde-core
> apt-get install lxde
> apt-get install task-lxde-desktop
> How can resolve this?
> 
> With kind Greetings!

These packages are still in stable, testing, and unstable.  This is a
user question; please ask for help on .

...Marvin

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Marvin Renich]

* Vincent Bernat  [190409 01:26]:
>  ❦  9 avril 2019 08:41 +10, Ben Finney :
> 
> >> >> yes, it can be done, but it is a lot more work for individual
> >> >> packagers.
> >> >
> >> > Sure. And, on the other hand, providing an APT repository for arbitrary
> >> > packages of unknown copyright status is also a lot of work to expect
> >> > disinterested volunteers to do without motivation.
> >>
> >> Disinterested volunteers are never forced to work for Debian.
> >
> > Yes, that's why I said “expect” and not “force”.
> 
> Being forced is the definition of expect.
> 
> "to consider bound in duty or obligated they expect you to pay your
> bills" 

No, "expect" means that one person has a belief that another person has
some obligation (note the word "consider" in the definition you quoted).
An expectation does not need to, and very often does not, have any
coercion ("force") associated with it.  Expectations are often not met,
and are sometimes not even reasonable.

> >> What is the point of being so negative?
> >
> > Not sure who you're addressing here, and I'm sorry if the discussion
> > appears negative to you.
> 
> I am addressing you. You try to dissuade people on the basis this is
> work you are not interested to do. If someone was implementing PPA/DPA,
> what would be the downside for people not interested in them? None. You
> can just ignore the feature.

I don't believe he was being negative.  Combining the paragraph you
quoted with his next paragraph, I interpreted it as "Your idea may not
align with the principles of the Debian project as a whole, but you seem
to have enough capable developers who are interested in your idea to
implement it outside of Debian."

That sounded constructive and encouraging, while redirecting away from a
solution that he did not believe would (or should?) work for reasons
related to the ideals of the project.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Holger Levsen  [181026 10:45]:
> On Fri, Oct 26, 2018 at 09:24:17AM -0400, Marvin Renich wrote:
> > Using Depends instead of Recommends actually _prevents_ the admin from
> > being able to choose. 
> 
> you know about the equivs package, do you?

Sure.  But that requires the admin to build a package and deal with
version number issues related to that package.  E.g. A Depends: B, then
later, A Depends: B and A Breaks: B < someversion.  The admin simply
wants to not install B and not have to worry about it.

equivs used in this way is simply a much less convenient workaround to
an incorrect dependency.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* The Wanderer  [181026 08:38]:
> On 2018-10-26 at 00:51, Russ Allbery wrote:
> > You choose the strongest relationship that is applicable.
> 
> I'm not sure that's clear from the given definitions, nor that it should
> necessarily hold. Is there any statement which would make that explicit?
> I haven't noticed one in a quick look through Policy 7.2, but it's
> entirely possible that I've just missed it.
> 
> Two mutually-exclusive "should"s cannot be simultaneously true.
> 
> I suppose, on consideration, that this boils down to me being a grumpy
> pedant about language - which isn't necessarily helpful in a discussion
> that's more related to technical merits... so on that basis, unless
> someone chimes in to agree with me that this is worth pursuing, I expect
> to drop the subject. (At least for purposes of this thread.)

My argument for using Recommends over Depends is not based on language
pedantry, but partially on what I believe is the "best" interpretation
of the current definitions, and much more on what I believe is best for
both Debian users and the Debian distribution.  I do believe that the
current wording of Recommends should explicitly be interpreted as giving
an exception to the definition of Depends.

I have not been trying to use the wording of policy as a stick with
which to beat maintainers into submission (I would not want to, nor
would such an effort be successful), but as evidence that the early core
Debian team had a very good understanding that not every dependency
relationship was cut and dried, and that it was important to give as
much latitude to the administrator as possible, while still providing a
working system in the default case.

> That's especially true since, now that I'm awake enough to think of it,
> the simplest (albeit not the most elegant) way to address the problem I
> see would be to revise the Recommends definition to something like
> "packages for which Depends does not apply, but which would be found
> together with this one in all but unusual installations" - and that's a
> moderately clunky construction, which smacks enough of pro-forma
> boilerplate to seem inappropriate for this sort of context.

I think that is going backwards.  Recommends should say that if there
are reasonable situations, even if they are unusual, to install one
package without the other, Recommends should be preferred over Depends.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Russ Allbery  [181026 00:52]:
> I don't know why you would expect otherwise?  That seems entirely natural
> and expected given that Depends is a stronger relationship than
> Recommends, and therefore is naturally a subset of the things that would
> qualify as Recommends.

[As The Wanderer said, I was careful not to imply that the definition of
Depends could not be said to apply in this case.]

> You choose the strongest relationship that is applicable.

Actually, I contend that this last statement is incorrect.  If the
different dependencies are meant to provide a consistent and working
system, while allowing system administrators as much flexibility as
possible, you should choose the weaker relationship.

The use of the specific word "unusual" in the definition of Recommends
clearly indicates an exception that should be applied even if the
definition of Depends would otherwise apply.  If there are situations
where an admin would specifically want package A installed, but not
package B, even though A apparently does not provide significant
functionality without B, this seems to me to be exactly the reason for
the wording of the definition of Recommends, and it should take
precedence.

Using Depends instead of Recommends actually _prevents_ the admin from
being able to choose.  Using Recommends means that in default
situations, the system works as intended; the admin must actively do
something to prevent the Recommends from being installed.  This might be
intentional or accidental; it might be because the admin configured Apt
some time in the past and wasn't paying attention when installing the
package declaring a Recommends, but it was an active choice on the
admin's part.

Saying "both definitions apply, lets choose the dependency that does not
give the admin any choice" is backwards.

If you think about why there seems to be a prevalence (at least
according to some) of configuring Apt to not install Recommends by
default, the first thing that comes to my mind is that there must be a
prevalence of inflating Suggests to Recommends and users don't like
that.  So now maintainers are inflating Recommends to Depends because
less experienced and/or less careful users are filing bugs resulting
from their own misconfiguration or lack of understanding.

This tendency leads in the wrong direction and is an abuse of the
dependency system.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Wouter Verhelst  [181025 08:26]:
> On Tue, Oct 23, 2018 at 05:04:11PM +0200, Vincent Lefevre wrote:
> > But a Depends or Recommends on gnupg
> > will annoy 99.9% of the users;
> 
> Err, no.
> 
> That number makes the assumption that all users who have something
> installed that they don't end up using will be "annoyed".
> 
> That's just not correct.
> [snip]
> Of those that do worry, a number may be annoyed, yes. But I suspect that
> the number who will be annoyed will be closer to the .1% number you
> quote above than the number who will not.

I certainly agree with you that 99.9% is clearly a wrong number for
this.  However I disagree that even 0.1% justifies using a different
definition for Recommends than policy gives.

The definition of Recommends specifically uses the word "unusual".  Its
purpose is to provide flexibility to the clueful admin who has a
specific need or use case to avoid installing the recommended package,
even when that use case is unusual or uncommon.  It allows the admin to
continue to use official Debian binary packages to get all the benefits
thereof.

The purpose of the various dependencies is specifically _not_ to prevent
clueless users from submitting bug reports that you believe are useless
and a waste of time.

Abusing the dependency system as a bug triaging tool at the expense of a
small number of admins for this package and another small number for
that package, and still more for those other packages with inflated
dependencies is simply _wrong_.

With that logic, we might as well give up Recommends completely and
always use Depends.

Recommends is for when Depends would be right, but there are some useful
edge cases where the admin might not want the dependent package
installed.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

[I'm subscribed; please do not CC me.]

* Matthias Klumpp  [181022 14:18]:
> Because having a real dependency eliminates another source of bugs.
> The library will throw weird (for unexperienced end-users) errors and
> they have to hunt down a solution for why something isn't working as
> they expect.

Why would a library give a weird error to a user?  It is the
application's responsibility to check the return code from the library
and provide an appropriate message to the user (e.g. "Unable to
initialize gpg library."), which should be sufficient for the end user
to track down the problem, even if the message is a bit cryptic to them
at first.  The point here is that it is still a bug in the software if
error messages are insufficient to correct the issue.  So if someone
reports "my application broke and I can't figure out what to do",
retitle the bug to "Error message given to user when libgpgme returns
failure is too cryptic."  It is still a bug, just a different one than
the user reported.

> The "Recommends" relation should work here in theory, in practice
> though people manage to remove stuff that was recommended by accident,

I think this is the key point.  Your experiences are obviously different
from mine, because I do not see accidental removal of recommended
packages very often.  However, I am willing to accept that it does
happen, and its likelihood probably depends on the organization (which
might be a personal one-user computer or a cluster of corporate servers)
and its admins.

> or even configure APT to never install recommends, and then end up
> with things not working (granted, in the latter case it's their own
> fault).

Right.

However, in both cases, abusing the dependency system to force the
installation of a package that the admin should be able to choose not to
install in specific situations is the wrong answer.

In a well-run organization, the admins either will install recommends as
the default, or they will be rather selective about choosing appropriate
dependencies to install or not install.  Further, their users will come
to them, not Debian, with problems.

Debian can't do anything about poorly-run larger organizations, and
should not abuse dependencies to try to fix them. :-P

That mostly leaves the single-user computer with a less experienced
user-admin.  I suspect that this is the source of the large majority of
this class of bug reports.  If you think about why they would configure
APT to not install recommends, it is likely because they have heard that
Debian has a reputation for inflating dependencies, and they don't
really need all the Recommended packages.  I think in some cases this
reputation either is or was justified.

So, what is the solution?  Keep inflating dependencies until everything
is Depends?  This is exactly the wrong solution.

There are at least two better responses to these "false" bug reports.
The first is to retitle and forward upstream as in my reply above.  The
second is to enhance reportbug to list recommended packages that are not
installed and encourage the user to try to reproduce the problem with
all recommended packages installed.  Also, reportbug can check the APT
configuration and nudge the user if appropriate as well as including it
in the bug report for the maintainer's information.

The problem with inflating Suggests to Recommends is that then people
routinely avoid installing Recommends.  However, inflating Recommends to
Depends is _much_ worse, because you have removed the admin's ability to
make informed choices.

Ignoring the policy definition of Recommends to avoid getting bug
reports from inexperienced users (or more experience users who are about
to have a palm-to-forehead moment) is simply and unequivocally wrong.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Russ Allbery  [181022 16:23]:
> Minimal installation size is *not* the only goal here.  Ease of use and
> lack of surprise is important to.

Then don't disable Recommends in apt preferences.

> Personally, I think people in this thread are too worried about trying to
> remove as many packages from their system as possible and not worried
> enough about a straightforward user experience.

I agree with Adam here.  The problem is that it is not just a small
number of packages that inflate dependencies.  It only takes a few
inflated dependencies here and a few there to result in significant
bloat.

And to be clear, this thread is not about the difference between
Suggests and Recommends.  Both of those cases allow the admin to choose
not to install the dependent package.  It is about the difference
between Recommends and Depends.  Once this line is crossed, you have
taken away the sysadmin's ability to choose.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Matthias Klumpp  [181021 14:04]:
> libgpgme is communicating with gnupg in the background - having
> libgpgme without gnupg itself will render the library completely
> unusable and break existing users of the library.

This keeps getting repeated in this thread in spite of the fact that
multiple people have stated that having libgpgme installed without gnupg
is useful in a very reasonable scenario.

> Also, gnupg/libgpgme are tiny, so you won't waste much disk space
> here.

See Steve Langasek's reply.

Why are some maintainers so adamant about using Depends when Recommends
is the correct dependency?

I'm going to use the neomutt → libgpgme → gnupg as an example, but this
applies as well to any other case where someone has a legitimate use for
installing one package without a dependency that would normally be found
with that package.

If libgpgme Depends: gnupg, then anyone who wishes to install libgpgme
(or, in cases like this, a package that has a Depends: libgpgme) without
gnupg must either use equivs to build a fake gnupg package or build a
modified libgpgme package that does not depend on gnupg.

However, if libgpgme Recommends: gnupg, then gnupg will be installed
whenever libgpgme is installed, _unless_ the admin specifically prevents
its installation.

With Recommends, everybody can get what they want:  gnupg installed
unless specifically prevented.  With Depends, preventing installation of
gnupg requires someone skilled and knowledgeable enough to build a
Debian package, as opposed to skilled enough to use aptitude's curses
mode.

N.B. the policy definition of Recommends:

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

That definition fits the relationship between libgpgme and gnupg
perfectly.

...Marvin

Re: Bug#911539: tinysshd: Use Recommends: systemd rather than Depends

[Marvin Renich]

* Jan Mojzis  [181021 13:45]:
> fixed here: 
> https://salsa.debian.org/debian/tinyssh/commit/64ab1d6729ecf5e0a7115bffa634beb8dbb5b3e6
>  
> 

Wow!  Thanks very much for the extremely rapid fix.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Andrey Rahmatullin  [181021 13:20]:
> On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote:
> > Semantically, Depends: declares that the package has to be
> > installed to proceed.  It doesn’t specify whether the package
> > has to actually be used.  Which kind of invalidates the point.
> 
> "Every package must specify the dependency information about other
> packages that are required for the first to work correctly." Policy 3.5.
> 
> "The Depends field should be used if the depended-on package is required
> for the depending package to provide a significant amount of
> functionality." Policy 7.2.

Allowing optional behavior without requiring the installation of a much
larger body of packages is, in my mind, an _extremely_ significant
amount of functionality.  Thus having libgpgme installed without gnupg
is significant functionality.

The dependency relationships in Policy were very well thought out;
package maintainers should not inflate dependencies.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Andrey Rahmatullin  [181021 13:16]:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > The proper fix is to convince upstream to dynamically link at runtime
> > and disable some features if libgpgme is not available.
> dlopening a dependency is bad: for example, it doesn't allow distro
> builders to track the deps properly and with the symbol granularity.

Perhaps.  But that is simply a matter of tooling.  The appropriate
Recommends can be used to help track this, or the fact that dlopen is
used and with what libraries could be added to the source package.  And
this is specifically a distro issue, not a behavioral correctness issue.
And this is an argument that I don't feel is worth continuing because
even if Debian put the effort into changing packaging practices to
handle this better, we will never get a significant following of
upstreams willing to use dlopen when appropriate.

On the other hand, your comment emphasizes even more my point that
library packages should not Depend on packages they use.

...Marvin

tinysshd: Use Recommends: systemd rather than Depends

[Marvin Renich]

Package: tinysshd
Version: 20180201-1

[Jan Mojžíš: this is a reply to a thread on debian-devel; some of the
statements below are directed toward that thread, not to you
personally.]

* Vincent Bernat  [181021 11:29]:
>  ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
> 
> >  >>> tinysshd only ships a systemd unit file; neomutt links against
> >  >>> libgpgme11 which again Depends on gnupg.  It’s the kind of
> >  >>> dependencies that individually make sense,
> >
> > I beg to differ; I suppose (though haven’t actually tried) I
> > can start tinysshd straight from rc.local just as well, or even
> > write my own init.d script, right?  Having the dependency in
> > place just makes it harder to me to contribute an init.d script
> > for the package.
> 
> tinysshd requires some kind of socket server to run. It could run from
> inetd, so if you were an actual user, I would propose you file a bug
> report against the package to let the maintainer knows the dependency is
> too strong for your use (and maybe propose a patch to integrate with
> inetd).
> 
> As you are not, please, do not. Our resources are scarce and we already
> cater for the need of many non-existent users.

Recommends, rather than Depends is correct, based on your description,
even without a patch to enable use with inetd.  Anyone who is not using
systemd, either out of dislike of systemd or because they have real
requirements for no or a stripped-down init system, is able to add a
single line to inetd (or one of its successors).

However, adding Depends just because the package ships with a systemd
unit file, and no other init integration, is simply wrong.

Don't let the fact that systemd antagonists keep annoying you prevent
you from doing the right thing.  openssh-server has an uncompressed size
of 922k with a long list of Depends.  tinysshd has an uncompressed
size of 606k with only two Depends, libc6 and systemd.  Changing systemd
to a Recommends would make tinysshd significantly more useful in some
of the use cases where its stated description "minimalistic SSH server"
already makes it the preferred ssh server.

As a general rule, please use Recommends over Depends whenever it will
not truly break the package.  This is exactly what Recommends is for.

...Marvin

Re: no{thing} build profiles

[Marvin Renich]

* Sune Vuorela  [181021 06:05]:
> On 2018-10-21, Jonas Smedegaard  wrote:
> > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all: 
> > As a library it cannot possibly declare how tight a relationship to 
> > declare - instead, all _consumers_ of the library must declare whether 
> > they depend/recommend/suggest gnupg.
> 
> libgpgme is completely useless without gnupg. I think it is perfectly
> fine for these kind of relations, unless we really are in corner-case
> territory. See for example fam.

I strongly agree with Jonas.  Upstream links to libgpgme as a .so to
provide optional behavior.  This requires libgpgme to be installed in
order to even run neomutt, whether the user wants the feature or not.
It is perfectly reasonable to want to install neomutt but want to _not_
install gnupg.

The proper fix is to convince upstream to dynamically link at runtime
and disable some features if libgpgme is not available.  However, this
(IMO wrong) upstream behavior is pervasive, and trying to get all
upstreams to use runtime linking for optional behavior is a very steep
uphill battle that we cannot win.

However, correcting Debian package dependencies is something that Debian
can do without involving upstream.  The Debian library package should
Recommend, rather than Depend, the package.

The -dev package should clearly document what packages need to be
installed for the linked .so file to be useful, and the packages linking
to the library should choose Depends or Recommends for the leaf package
(e.g. gnupg) based on whether the top package (e.g. neomutt) will be
broken or just have less functionality if the library returns "function
not available".

If the library crashes, rather than returning an error, if the
depended-on package (gnupg in this case) is not installed, that is a
real (serious, IMO) bug that upstream should fix.  Usually, however, the
library will do the right thing.  The same applies to the package
calling the library.

Having a library that may reasonably be used solely to provide optional
behavior bring in a significant amount of potentially unwanted software
is simply bad behavior, as well as being contrary to Policy definition
of Depends and Recommends.  While the library is usually used with the
leaf package installed, it is perfectly useful for shared linking for
optional behavior even when the leaf package is not installed.  This is
exactly the definition of Recommends.

...Marvin

Re: wpa_supplicant cannot authenticate against freeradius 3.0.16+dfsg-4.1+b1

[Marvin Renich]

* Kamil Jońca  [181017 01:27]:
> 
> Recently I tried to upgrade my freeradius package to 3.0.16+dfsg-4.1+b1
> And after that my laptop with wpa_supplicant stops authenticate:
> 
> with version 3.0.16+dfsg-3+b1 everything works ok.
> Any hints what to check in logs?

Please ask user questions on debian-user, not debian-devel.  You might
also try to find a freeradius  support channel; they are likely to have
both a mailing list and an IRC channel (I don't use freeradius, so I
don't know).

>From your description, this could certainly be a bug in either
freeradius or wpa_supplicant, but doing the triage on a user support
mailing list is usually very helpful to the maintainer.  Afterwards, you
can use reportbug to file a bug for the correct package.  debian-devel
is not the correct mailing list for this.

...Marvin

Re: Should the weboob package stay in Debian?

[Marvin Renich]

* Stephan Seitz  [180724 09:49]:
> On Di, Jul 24, 2018 at 01:19:35 +0100, Matthew Vernon wrote:
> > Stephan Seitz  writes:
> > > He certainly should NOT rename any parts of the package without
> > > upstream consent.
> > Why not? I can see an argument about not confusing users (though
> > transitional packages / a weboob-offensive could be made for the old
> > names / etc), but I don't think that's where you're going here.
> 
> Well, upstream has chosen these names. Besides from the fact that the
> project and its applications are known by these names (how would you tag the
> package, so that someone who knows the project would find the right package
> with apt or apt-file?) it has something to do with politeness (in my
> opinion). If you wish to package the work of others you should use the right
> names (we don’t have any name clash).

While I agree that renaming the files in an arbitrary Debian package
should not be done without good reason, I do not agree that it should
not be done.  I believe the names in this package provide more than
sufficient justification to carry a local Debian fork (as was done for
Firefox/Iceweasel for many years for a different reason).

However, the maintainer of weboob has clearly expressed that he is not
willing and/or does not have the resources to maintain a local Debian
fork, so I did not suggest this.

...Marvin

Re: Should the weboob package stay in Debian?

[Marvin Renich]

* Stephan Seitz  [180724 07:25]:
> He certainly should NOT rename any parts of the package without upstream
> consent. If upstream doesn’t approve (and it seems that these names are part
> of upstream’s working culture), then the other choices are removing to
> package or keeping it as it is.

Or, if the software is useful enough (and there have been several
mentions on this thread that it is useful), fork the project and rename
everything in the fork.  This is, after all, open source, and this is an
excellent example of a reason to avail ourselves of the privileges
afforded by open source software.  Maybe enough people will appreciate
the de-objectification of the fork that the original project will simply
fade into obscurity.

In the open source community, we rightfully have a healthy respect for
the original author's wishes and an aversion to forking a project to
wrest control from the author, but it is, on rare occasions, warranted,
and by giving the software an open source license, the author has
granted permission to do so.

Of course, this requires someone who cares enough about the software and
who disagrees enough with the current names used to be willing to spend
the time and effort to fork it.  I don't use the software, so I have no
desire to create such a fork myself.  I do believe that renaming the
current package to include -offensive is clearly warranted.

...Marvin

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Marvin Renich]

* Emilio Pozuelo Monfort <po...@debian.org> [180420 11:00]:
> On 20/04/18 16:46, Marvin Renich wrote:
> > I would also like /etc/debian_version to contain both number and name,
> > but I suspect there is some resistance to this on the grounds that
> > scripts may be using $(cat /etc/debian_version) for comparisons.
> > Perhaps /etc/debian_codename?  Since debian_version contains
> > codename/sid for testing and unstable, debian_codename could just
> > contain the codename.
> 
> You already have that information in /etc/os-release and the lsb_release 
> command.

Thanks much!  I completely missed that.

Closing the bug now.  Sorry for the noise.

...Marvin

Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Marvin Renich]

Package: base-files
Version: 10.1
Severity: wishlist

* Stephan Seitz  [180420 07:38]:
> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:
> > But being human I prefer names over numbers, even if it's just for
> > aesthetic reason - "buster" is just more comfortable than "debian10".
> 
> No, it’s not. I know that my systems are running Debian 8 or 9, but I always
> have to think if stretch is 9 or was it jessie.
> 
> I have to look up the name not the number.

I have often wanted to have on my system a text file containing the
correspondence between code name and release number.  I know this is one
more thing for the base-files maintainer to do during an already busy
period just before release, but if he is willing, it would be nice to
have a file, suggested to be /usr/share/doc/base-files/debian_releases,
that contains each code name with its Debian release number, as well as
the code name for the current testing release.

I know this info is in the Debian wiki, but having it in a local text
file is more convenient.  I would also be okay if this were a text file
in debian-history, but I find that solution less satisfactory than being
in base-files which is essential/required.

I would also like /etc/debian_version to contain both number and name,
but I suspect there is some resistance to this on the grounds that
scripts may be using $(cat /etc/debian_version) for comparisons.
Perhaps /etc/debian_codename?  Since debian_version contains
codename/sid for testing and unstable, debian_codename could just
contain the codename.

Santiago, if you are willing to do either or both of these, I would
appreciate it, but I certainly understand if it is just one too many
things to remember during release prep.  If you don't want
debian_releases in base-files, I'll reassign this bug to debian-history.

...Marvin

Re: interpretation of wontfix

[Marvin Renich]

* Andreas Tille  [180328 07:51]:
> On Wed, Mar 28, 2018 at 12:01:19PM +0100, Simon McVittie wrote:
> > On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote:
> > > I think "wontfix" is exactly the feature of the BTS that was invented to
> > > solve the problem I described.  The bug is not closed and remains listed
> > > - so everybody is free to ignore that tag and close the bug.
> > 
> > Is this how most people interpret wontfix?
> 
> Honestly, I don't know.
> 
> > I'd usually interpreted it as
> > an indication of policy rather than priority: "I acknowledge that this
> > is a bug, but it isn't going to change, even if you provide a patch".
> 
> I see your point.

I also interpret wontfix as "patches will not be accepted; the current
behavior will stand."

> When I use the help tag I usually do this together with asking for help
> say on debian-mentors, upstream or elsewhere.  I do not hope that some
> help just comes from simply setting the tag.  I also look into bug
> reports that I've tagged help from time to time whether some help might
> have arrived which I could have missed for some reason.

I would also interpret the help tag as "yes, this should be fixed, but I
would appreciate some assistance with it."

It might be helpful to have a new tag (perhaps "ignored"?) that means
that the maintainer believes that the effort to fix this bug would not
provide enough benefit to the overall user base of the package to
warrant spending the time to fix, but if someone who did care provided a
clean, easy-to-review-and-apply patch, it would be applied as time
allows.

...Marvin

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Marvin Renich]

[added d-dev back]

* intrigeri <intrig...@debian.org> [180319 07:40]:
> Marvin Renich:
> > Actually, a short beginner's guide as a text file in
> > /usr/share/doc/apparmor, which has more than just "how to disable a
> > profile" would be extremely helpful.  I don't have the apparmor
> > knowledge to write it, though.
> 
> FYI the most useful bits were added to
> https://wiki.debian.org/AppArmor/HowToUse
> which is linked from /usr/share/doc/apparmor/README.Debian :)
> 
> It's only a start and there's lots of room for improvement,
> but it's a start.

Thanks for this pointer!  

Adding these two links [1], [2] on that page might be helpful.  I found
them by following links to [3].

As a side note, my laptop runs testing, and I allowed apparmor to be
enabled when that change hit testing.  The only issue I have noticed so
far is that smbd would not have access to some (intentionally public,
not in /home) shares if it were in enforce mode, rather than complain
mode.  If I were not aware of apparmor, and if smbd were in enforce
mode, I would have had a difficult time tracking this down.

Is there a way that an app (e.g. smbd) whose file access requirements
change dynamically through admin and user configuration can at least
inspect its own apparmor profile and give the user a clue that the admin
must update the profile?  For Samba, perhaps at least a comment in
/etc/samba/smb.conf at "Share Definitions" giving a reminder that if any
LSM is enabled, the LSM config may need to be updated to reflect changes
to shares.

(Samba maintainers added to CC; please remove them for replies not
pertaining to samba.)

...Marvin

[1] Creating and modifying AppArmor policy with the tools
https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools
[2] Creating and modifying AppArmor policy by hand
https://gitlab.com/apparmor/apparmor/wikis/Profiling_by_hand
[3] https://gitlab.com/apparmor/apparmor/wikis/Documentation

Re: FHS: Where to store user specific plugins / code

[Marvin Renich]

* Ian Jackson  [180228 17:45]:
> Georg Faerber writes ("FHS: Where to store user specific plugins / code"):
> > I'm maintaining schleuder in Debian [1], a "gpg-enabled mailing list
> > manager with resending-capabilities".
> > 
> > Currently, we allow users to run / execute their own plugins, stored in
> > /etc/schleuder/plugins. Obviously, that's not the right place, as /etc
> > is for config files, not executable code. We would like to fix this, but
> > are unsure which location to offer. The (empty) directory would be
> > provided by the package, but the (possible) content would be provided by
> > the user.
> > 
> > Therefore, I'm wondering what's the correct place: Would
> > /usr/local/lib/schleuder/plugins be sensible? If not, any other place
> > which is more suitable?
> 
> Do plugins do something which people might not want if present, and
> not configured ?  If so then perhaps you want a thing a bit like the
> apache mods-enabled scheme: a link farm.
> 
> If not, then if it's easy to do I would load all plugins in
> /usr/local/lib/schleuder/plugins
> /usr/lib/schleuder/plugins
> (former masking the latter with for with the same name)

If a user get to install his/her own plugins, they should go in the
user's home directory, e.g. /home/user/.config/scheduler/plugins/.
Non-root users should not generally be given write permission to
/usr/local, and definitely not to /usr/lib.

If the app takes care of installing the plugins on the user's behalf,
that is slightly different.  However, if the plugin can be selected by
the user from a non-trusted source, I would still go with the user's
directory.  Allowing a non-root user to put his own plugin where others
can execute it without being able (even required) to verify its
integrity is a huge security hole.

Ian's comments are good for admin-installed plugins that the users can
use.  In fact there is good precedent for an app checking
/usr/lib/pkg/... for plugins installed from Debian packages,
/usr/local/lib/pkg/... for plugins installed by the admin from
non-Debian locations, and then finally the user's .config/pkg/...
directory.

...Marvin

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Marvin Renich]

* Scott Kitterman <deb...@kitterman.com> [180201 09:04]:
> On February 1, 2018 1:47:17 PM UTC, Marvin Renich <m...@renich.org> wrote:
> >I agree that the FTP team should not second guess the maintainer's
> >removal request.  However, with or without a new ITR process, I think
> >it would be justified (and good practice) for the FTP team to start
> >requiring the maintainer to record in the bug the reasoning behind
> >the removal.
> 
> While I agree that would be best, I don't think it's the primary
> purpose of an rm bug.  It doesn't take an FTP team member to ping the
> maintainer to ask why, cc the bug.

I think the RM bug should include both what is being requested (removal)
and why.  I think the two are closely related enough that they should
share the title of "primary purpose".

However, I know that you and the rest of the FTP team do a tremendous
amount of work (thank you very much!), so I will concede that this is
one item that should be the responsibility of the bug filer and doesn't
need to be on your plate.

> If this concerns people, they can ask for more information.

True, but that happens after the fact, and sometimes time has a way of
helping information to get lost.

...Marvin

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Marvin Renich]

* Mattia Rizzolo  [180201 03:26]:
> I seriously doubt ITRs or somesuch would help, you wouldn't notice them
> anyway.
> If you can parse a list of ITRs you can equally easy parse a list of
> packages with open RC bugs with next to the same effect.

I disagree.  As a user, if I see RC bugs on a package, I have no idea
what work is or isn't being done by the maintainer or others to address
those bugs.  However, if the maintainer (or someone close to the
package) files an ITR, I now know that this is my last chance to speak
up.  With something similar to apt-listchanges that notifies me when I
do aptitude update that a package I have installed will be removed soon,
I have an opportunity to react.  Something similar for RC bugs would not
serve the same purpose (though it might be very useful for someone
looking for ways to contribute to Debian:  "There are RC bugs on these
packages that you use; would you like to help out?").

> RoQA packages without RC bugs is very rare (and I don't like them
> myself), and ROM shouldn't be second guessed anyway (as an ftpteam
> member stated).

I agree that the FTP team should not second guess the maintainer's
removal request.  However, with or without a new ITR process, I think it
would be justified (and good practice) for the FTP team to start
requiring the maintainer to record in the bug the reasoning behind the
removal.  This appears to be common, but not universal, practice when
filing ROMs, but making it mandatory and enforced by the FTP team does
not seem out of line.  This has nothing to do with second guessing; it
is about openness to the rest of the Debian community (esp users who are
wondering why their favorite niche package didn't make it into the next
release).  And as stated elsewhere in this thread, it will help a
prospective new maintainer know whether reintroducing the package will
be worth the effort.

...Marvin

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Marvin Renich]

* John Johansen  [171118 16:02]:
> You can disable individual profiles without editing them and messing up the 
> packaging by using aa-disable
[some really good beginner stuff snipped]

John, many thanks for these tidbits.  Can they be put in a text file in
/usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so
that when the package is pulled in, the user has some idea where to
start?  Since Thunderbird seems to be one of the problem packages,
having it in a text file on the local system seems like a good idea.

Actually, a short beginner's guide as a text file in
/usr/share/doc/apparmor, which has more than just "how to disable a
profile" would be extremely helpful.  I don't have the apparmor
knowledge to write it, though.

Thanks...Marvin

Re: Gedit window is not moved into foreground when Nautilus opens a text file

[Marvin Renich]

* gocha...@unseen.is  [171012 00:57]:
> Can anyone help solve this issue?
> 
> When I use Nautilus to open a text file, the text file gets opened in
> the background. That is, the Nautilus window stays in the foreground
> and the text file is opened in the background inside a new tab in the
> Gedit window.
> 
> How do I make the Gedit window move into the foreground whenever a new
> file is opened?
> 
> I am using latest Debian Stretch. I never had this issue when using
> Debian Jessie.

The debian-devel list is for the developers who are helping to build the
Debian distribution (and others interested in it) to discuss the
development of the distribution.  A more appropriate place for user
support questions like yours is the debian-user list
.  Please redirect your question there.
There is probably also a GNOME IRC channel where you could get help, but
I don't know what it is.

If you find what you believe is a bug (I would discuss the above
question on debian-user first; this might just be a configuration
issue), you can use the reportbug package to file a bug report directly
for the appropriate package (likely nautilus in this case).

Thanks...Marvin

Re: Proposal: A new approach to differential debs

[Marvin Renich]

* Christian Seiler <christ...@iwakd.de> [170813 18:59]:
> (Setting reply-to to debian-devel@ only as I don't think this
> should continue on debian-dpkg@ and deity@)
> 
> On 08/14/2017 12:29 AM, Marvin Renich wrote:
> > * Christian Seiler <christ...@iwakd.de> [170813 13:19]:
> >> On 08/13/2017 07:11 PM, Peter Silva wrote:
> >>>> apt by default automatically deletes packages files after a successful 
> >>>> install,
> >>>
> >>> I don't think it does that.
> >>
> >> The "apt" command line tool doesn't, but traditional "apt-get" does, as
> >> does "aptitude". This was documented in the release notes of Jessie and
> >> the changelog of the APT package when the "apt" wrapper was introduced.
> > 
> > This differs from my experience.  My laptop's /var/cache/apt/archives/
> > directory has 3459 .deb files.  I use aptitude almost exclusively, and I
> > update several times a week.
> 
> Erm, rereading my text, I misspoke a bit, I meant the opposite of
> what I said:
> 
>  - apt-get / aptitude leave /var/cache/apt/archives lying around
>  - apt doesn't

Thanks.  My system isn't completely backwards, then!

> > Is there an apt.conf parameter that controls this?
[snipped good answers]

Thanks.  I won't need the apt.conf entry, since it applies to apt, not
apt-get and aptitude, but I appreciate your pointing it out.

...Marvin

Re: Proposal: A new approach to differential debs

[Marvin Renich]

* Christian Seiler  [170813 13:19]:
> On 08/13/2017 07:11 PM, Peter Silva wrote:
> >> apt by default automatically deletes packages files after a successful 
> >> install,
> > 
> > I don't think it does that.
> 
> The "apt" command line tool doesn't, but traditional "apt-get" does, as
> does "aptitude". This was documented in the release notes of Jessie and
> the changelog of the APT package when the "apt" wrapper was introduced.

This differs from my experience.  My laptop's /var/cache/apt/archives/
directory has 3459 .deb files.  I use aptitude almost exclusively, and I
update several times a week.

Is there an apt.conf parameter that controls this?  I don't remember
seeing any news or changelog about this, but if I did, I might have
disabled it.  Or maybe there is an apt.conf entry, whose default is to
not do apt-get clean after each install, but newly installed systems
have a snippet in /etc/apt.conf.d/ that turns it on?

Can you give the version number in /usr/share/doc/apt/changelog.gz where
this was mentioned?  A cursory glance through the Jessie release notes
(HTML) TOC doesn't give any obvious pointer to where this was mentioned;
can you give a ref for this as well?  (This is an honest question, I'm
not trying to be accusatory.)

Thanks...Marvin

Re: Naming of network devices

[Marvin Renich]

* Vincent Bernat <ber...@debian.org> [170710 16:25]:
>  ❦ 10 juillet 2017 15:53 -0400, Marvin Renich <m...@renich.org> :
> 
> >> > With the new scheme, if I want to rename the interface to something more
> >> > meaningful, ..., and type all of
> >> > that information by hand, hoping I type everything correctly.
> >> 
> >> Have a look at systemd.link(5) which enables you to do that without
> >> debugging udev.
> >
> > Okay, I had a look...
> 
> Not really.
> 
> In /etc/systemd/network/whatever.link, put:
> 
> #v+
> [Match]
> MACAddress=00:11:22:33:44:55
> 
> [Link]
> Name=em0
> #v-
> 
> Note the manual page has a similar example. I don't see exactly how this
> is more complex than the udev rules we had:
> 
> #v+
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="eth*",
> NAME="em0"
> #v-

How does that help with ensuring that I type the MAC address correctly,
which was my point above?  With the state file, udev puts the correct
information in the file for me; I only have to change the interface
name.

Your answer did not address my concern.

> > BTW, there seems to be a typo in the man page:  it refers to a
> > /run/systemd/network directory; should that be /run/systemd/netif/links?
> > I'll leave you to file a bug if appropriate.
> 
> No, it seems correct. All systemd-related stuff look at /lib/systemd/X
> (shipped with a package), /run/systemd/X (added by a third-party
> program) and /etc/systemd/X (added by the user).

Okay, the system I looked at (which was installed about six weeks prior
to stretch release) does not have a directory named
/run/systemd/network, but it does have an empty directory named
/run/systemd/netif/links.  Is this directory for something different,
or did the directory name change between my install and the release?

> > I don't get this at all.  The previous behavior was neither unreliable
> > nor unpredictable (unless you are talking about much older systems
> > before persistent-net.rules).
> 
> It was unreliable. Google for "eth0_rename", you'll get ton of examples
> of people with hosts that don't boot reliably because of the inherent
> race conditions. Udev people didn't invent all this just to get people
> pissed. They have fixed a real problem.

Okay, but in a previous message in this thread you said that using a
prefix other than the one automatically assigned by the kernel would be
a trivial fix for this bug.  This is a bug in the implementation, not in
the design.

> > You have completely sidestepped the question, which is about the
> > relative importance of the two goals, simple names _all the time_ vs
> > avoiding a state file.  The previous behavior sacrifices the second,
> > much less important goal in favor of the first.  The new behavior
> > sacrifices the first in favor of the second.  Until you address this
> > issue, all your explanations look like attempts to ameliorate bad
> > behavior.
> 
> Predictable names are more important to me. Simple name should also work
> for most people (using the eno*) scheme. Maybe it's not available as
> widely as it should be.

You are again answering the wrong question by conflating predictable
names with the new scheme.  If the bug in the state file mechanism were
fixed, it would give names that are just as predictable as the new
scheme, but they would always be a short prefix followed by a single
decimal number.  I have not said in this thread that the prefix must be
"eth", just that it must be simple.  I would be happy with names like
en1, en2, wl1, and wl2.  I don't care if the numbering starts at 0 or 1.

If we can _always_ have simple names and at the same time ensure that on
reboot, the same interface always gets the same name, that is much,
much, much more important than avoiding a state file.  The new scheme is
guaranteed to give awkward-to-use names in at least one common
situation.  The old way has one known bug in which the rename fails.
There is a known fix for that bug.  With the bug fixed, the old way also
gives predictable names, but the names are always simple, rather than
occasionally being simple, sometimes being not so simple but not so
complex, and sometimes being very awkward.

The presence or absence of a state file makes very little difference.
If it can be avoided without sacrificing simple names, that's great.
But if avoiding a state file means that sometimes the names must be more
complex, it is not worth the cost.

Again, your answer does not address my concern about a common case where
the new scheme gives awkward names.  This concern is clearly shared by
others, as seen in this thread and past threads.  This concern has never
been adequately addressed in any thread of which I am aware.

...Marvin

Naming of network devices (was: Re: Debian 9 in a VM with Proxmox 5 system)

[Marvin Renich]

* Vincent Bernat <ber...@debian.org> [170710 14:56]:
>  ❦ 10 juillet 2017 14:36 -0400, Marvin Renich <m...@renich.org> :
> 
> > The only benefit I have seen between the new scheme and the previous
> > one is that there is no state file.  While getting rid of the state
> > file is a nice goal, it is extremely minor compared to having short,
> > simple names in common use cases like inserting a wifi usb dongle.
> 
> Knowing the device name of a wifi dongle seems a pretty niche case. Most
> users will just use network manager to select the appropriate SSID and
> forget about it.

I am specifically addressing the middle-tier users:  those who have some
knowledge, are manually configuring the machine for some reason, but are
not professional sysadmins.  Neither the naive user nor the professional
sysadmin will be bothered by either choice, but I believe that there is
a significant population of Debian users (and Linux users in general)
that fall into the tech-hobbyist category, for whom this is an important
issue.

> > With the new scheme, if I want to rename the interface to something more
> > meaningful, I have to go find an older machine that already has a
> > persistent-net.rules file or read through a lot of documentation to
> > figure out the correct syntax.  I then have to determine the correct
> > ATTR elements to identify the interface in question, and type all of
> > that information by hand, hoping I type everything correctly.
> 
> Have a look at systemd.link(5) which enables you to do that without
> debugging udev.

Okay, I had a look on a six-weeks-before-release stretch VM, and I don't
see anything there that makes this easier than with the udev .rules
file.  There is still no skeleton .link file that already has the
appropriate attributes already filled in.  It looks like I still have to
create a .link file and manually type the appropriate attributes.  Am I
missing something?

BTW, there seems to be a typo in the man page:  it refers to a
/run/systemd/network directory; should that be /run/systemd/netif/links?
I'll leave you to file a bug if appropriate.

> > There is an easy fix to revert the default behavior while still allowing
> > knowledgeable sysadmins to get the new behavior.  On the other hand,
> > those who need to administer systems but are not sysadmins by trade (and
> > thus will have to do significantly more research to even know that the
> > older behavior is possible) are the ones who need the older behavior as
> > the default.
> 
> Having a default behavior that's unreliable doesn't seem great
> either. The change is surprising (and not expected on non-new systems),
> but there is nothing difficult in identifying the right interface with
> the new naming scheme. Other major distributions are using this new
> scheme (notably Ubuntu which has no reason to have users smarter than
> ours) and I don't see a lot of drama on their side. It seems that for
> some reason, we are the only ones making a fuss about any change.

I don't get this at all.  The previous behavior was neither unreliable
nor unpredictable (unless you are talking about much older systems
before persistent-net.rules).  What change is surprising?  The change
between jessie and stretch?  Absolutely.

You have completely sidestepped the question, which is about the
relative importance of the two goals, simple names _all the time_ vs
avoiding a state file.  The previous behavior sacrifices the second,
much less important goal in favor of the first.  The new behavior
sacrifices the first in favor of the second.  Until you address this
issue, all your explanations look like attempts to ameliorate bad
behavior.

...Marvin

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marvin Renich]

* Marco d'Itri  [170710 13:12]:
> On Jul 10, Adam Borowski  wrote:
> 
> > Predictability is important, thus let's actually have _predictable_
> > interface names.  The kernel default, eth0 and wlan0, is good enough for
> > most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.
> Please stop beating this long time dead horse.

This has been discussed on debian-devel in the past, but this is the
first time that many of our users have seen this.  This horse is very
much alive, just locked in the barn without food.

Neither you, nor any other proponent of the new scheme has addressed the
fact that short, easily remembered names in _all_ cases is significantly
more important than not having a state file.

The only benefit I have seen between the new scheme and the previous one
is that there is no state file.  While getting rid of the state file is
a nice goal, it is extremely minor compared to having short, simple
names in common use cases like inserting a wifi usb dongle.

And no, enp2s0f1 is neither short nor simple.  It requires remembering
three numbers and three letters that identify internal parts of the
hardware hierarchy that are irrelevant to the sysadmin.

With the previous scheme, an interface would be assigned a short, simple
name the first time it was seen.  The sysadmin could easily edit the
state file to give it a more meaningful name, if desired.  The state
file already had all the other information needed to identify the
interface; a simple one-word change in the file was sufficient.
Whatever name was in the state file was used for that piece of hardware
from then on.  The names were at least as predictable as they are with
the new scheme.

With the new scheme, if I want to rename the interface to something more
meaningful, I have to go find an older machine that already has a
persistent-net.rules file or read through a lot of documentation to
figure out the correct syntax.  I then have to determine the correct
ATTR elements to identify the interface in question, and type all of
that information by hand, hoping I type everything correctly.

There is an easy fix to revert the default behavior while still allowing
knowledgeable sysadmins to get the new behavior.  On the other hand,
those who need to administer systems but are not sysadmins by trade (and
thus will have to do significantly more research to even know that the
older behavior is possible) are the ones who need the older behavior as
the default.

...Marvin

New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Marvin Renich]

First, the original thread belongs on debian-user, not debian-devel.
Please move the "how do I use the new (more than a decade old)
networking tools" user question there.

* Rene Engelhard  [170710 08:03]:
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names
> 
> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

I do want to respond to this, though.  (I see Adam already has, as
well.)

The new interface naming scheme seemed to have two primary goals:  to
have reproducible interface names, and to avoid using a state file.
There also appeared to be a very minor goal of having short, simple
names when easily done.

I am very disappointed at the outcome, because I believe having short,
simple names in _all_ cases is more important than not using a state
file, by _at least_ an order of magnitude.

The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
extremely small, even in the very worst case where a user continually
plugs in many, many different usb network dongles, which is a very
unrealistic case to begin with.

On the other hand, the cost of having to deal with wlxf81a671bcfae just
because you are using a usb dongle is considerable, and this is a very
realistic and much more common case.

This is a case of misplaced design priorities that has turned out very
badly.  I would like to see /lib/udev/rules.d/80-net-setup-link.rules
moved somewhere that is not used by default (e.g.
/usr/share/udev/optional-rules/) and only used if the sysadmin
explicitly links to it in /etc/udev/rules.d/.

Thanks, Adam, for the clue about how to disable this!

...Marvin

Re: /root directory

[Marvin Renich]

* jvieir...@sapo.pt  [170605 11:33]:
> Hi,
> 
> In the Debian tutorials, somewhere in the Debian file system[1] page it
> states: “When you refer to root directory it means you talk about the root
> of the file system: ‘/’. This is different from the home directory for the
> root user: ‘/root’.”
> 
> The use of the same term with different meanings (“root”, in the case) in
> general makes things getting confused for those non familiar with the
> matter.
> 
> Would it be feasible to change the name of the /root directory to sort out
> the confusion? It could be renamed as /adm, for instance.
> 
> I’m not an IT educated person, so I recognize that I may be suggesting a
> nonsense.

You are not suggesting nonsense.  However, both uses of the term root
have been around since the very beginning of Unix, about 1969 or 1970, I
think.  Both uses are so deeply entrenched in the *nix culture that
neither will ever be changed.  New users just have to learn to
disambiguate this term from context.  The explanation in the Debian file
system page is, I presume, an attempt to help educate newcomers about
this ambiguity.

Sorry...Marvin

Re: Depends/Recommends from libraries

[Marvin Renich]

* Simon McVittie <s...@debian.org> [170310 05:17]:
> On Thu, 09 Mar 2017 at 17:52:05 -0500, Marvin Renich wrote:
> > If more upstreams were careful to use dynamic loading in these
> > situations, it would be less of a problem.  In a perfect world, the
> > solution would be for foo's maintainer to convince upstream to switch to
> > dynamic loading.
> 
> (For context, I maintain several game engines that default to dlopen()ing
> their dependencies, some of which I have patched to stop doing that.)
> 
> I do not agree that dlopen()ing dependencies (what you have called "dynamic
> loading") is something we should encourage over normal linking with -lfoo
> (resulting in a DT_NEEDED entry, what you have called "static loading").

I'm sorry if I wasn't clear.  By "in these situations" I meant when the
library is only being used for a feature that is not likely to be used
by most users of the package, and only when the library has additional
dependencies that the user may want to avoid if he does not want the
feature provided by the library.

> Having done that, either the plugin can either be split out into its own
> package that is recommended or suggested by the main package (as was done
> for gnome-software support for Flatpak), or the plugin's dependencies can
> be downgraded to Recommends or Suggests with something like
> "dh_shlibdeps -- -e/usr/lib/myplugins/myplugin.so -dRecommends" and it
> will fail to dlopen if they are missing (as is done in at least iproute2 and
> thunar, see https://codesearch.debian.net/search?q=-dRecommends).

I believe I was suggesting something along those lines...

> If a library dependency is sufficiently "heavy" that it needs to become
> optional, please consider that approach.

...and only in this specific case.

...Marvin

Re: Depends/Recommends from libraries

[Marvin Renich]

* Russ Allbery  [170309 13:19]:
> I think this would be a great way of introducing spurious bugs in our
> distribution from people who don't happen to read the README file and miss
> dependencies they actually need...

I think you are missing Ian's meaning.  Currently foo Depends libbar,
and libbar Depends bar-daemon.  If libbar were dynamically loaded, the
maintainer of foo would have used either a Recommends or Suggests for
libbar, but must instead use Depends because it is statically loaded.
If libbar-dev documents that it requires bar-daemon (and under what
circumstances, if appropriate), but libbar does not declare the Depends,
then it becomes the Debian maintainer of foo who decides to add an
appropriate Depends, Recommends, or Suggests for bar-daemon, in addition
to the Depends (that should be, but can't be, a Recommends or Suggests)
on libbar.  This is not pushed to the user at all, except in the normal
way that a user currently chooses to install Recommends or Suggests in
other circumstances.

Every Debian maintainer whose package links libbar would then be
required to read the documentation of libbar-dev, and act on that to add
a dependency that libbar would have used.  I would certainly expect a
Debian maintainer to read said documentation (irregardless of Ian's
proposal).  This has nothing to do with an end user reading a README
file to get the dependencies right (at least not any differently than
the current situation for other non-lib Recommends or Suggests).

I have not decided which side of the fence I am on, but I am certainly
empathetic to Ian's, Adam's, and others' desire to improve the
situation, as I have been bitten by this myself on more than one
occasion.  This is a situation where the maintainer of foo has no choice
but to use Depends, even if the library "can perhaps enhance [foo's]
usefulness, but installing [foo] without [libbar] is perfectly
reasonable."  You end up with a daemon that you don't want because
libbar Depends bar-daemon is appropriate, even if you, the end user, are
never going to use foo in a way that uses the libbar functionality.

If more upstreams were careful to use dynamic loading in these
situations, it would be less of a problem.  In a perfect world, the
solution would be for foo's maintainer to convince upstream to switch to
dynamic loading.  I'm not convinced that Ian's proposal is the right
approach, but I definitely agree that it is an attempt to solve a real
problem, and I believe it has more merit than you give it.

...Marvin

Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED

[Marvin Renich]

* Vincent Bernat  [170209 16:54]:
> Browserify takes code from npm (targetted at Node) and makes it run
> in the browser. Node comes with an API of its own that is not available
> in browsers. Browserify provides this code. There is nothing to patch
> since browserify is not a direct user of this code. It exposes it to
> modules that are unaware they are running in a browser.

If, as you describe, these small, do-nothing packages are not what node
uses when _not_ being run with browserify, but are just stubs
specifically for browserify, than a much better solution would be to
provide one package, browserify-dummy-stubs, have browserify depend on
that, and place all the stubs there.  Since, as Pirate Praveen says,

* Pirate Praveen  [170209 11:49]:
> We are not expecting anyone to install this module directly.

there is no reason to have a separate Debian package for each of these.
The excuse that the multitude of node packages have different update
cycles, so they should be in separate packages, is a complete
non-sequitur for a bunch of one- or two-line stubs that aren't going to
get any maintenance anyway.

...Marvin

Re: More 5 november in the release schedule

[Marvin Renich]

* Emilio Pozuelo Monfort  [161108 16:01]:
> It is true for other removals from testing, which can happen in two different 
> ways:
> 
> - The package was removed from unstable
> - The package was hinted for testing removal by the release team
> 
> Since britney doesn't enforce (atm) that build-dependencies are satisfiable in
> testing, those two cases can cause this problem. However in the former case,
> rdeps should get a FTBFS bug so you will know about the problem, and the 
> latter
> is not very frequent.

But wouldn't the FTBFS bug be filed after the removal of the build-dep,
so that it is too late for the maintainer to assist in keeping the
build-dep in the archive?  I thought this part of the thread was about
getting notification of pending, not already happened, removals so that
help could be directed in time to keep the package in the archive.  Do I
misunderstand?

...Marvin

Re: Bug#837606: general: system freeze

[Marvin Renich]

[Please do not CC me, I am subscribed.  You seem to have a habit of
CC'ing the individuals to whose messages you are responding.  This is
contrary to this list's documented policy.]

* Abou Al Montacir  [160914 05:31]:
> The duty of the project is to
> help him investigating the right way so that the bug get solved. Not saying 
> ask
> the community.

No, the project has no such duty.  This is a volunteer project, and the
software is both free and without any warranty.  Your whole tirade on
this thread appears to take the attitude that not only are you paying
the project for the software, but you are also paying for support.

You have no _right_ to expect any response at all to a bug report.
Fortunately, the members of the Debian project _want_ to make it better,
so they do pay attention to reported bugs.  Note that the first response
to the bug submitter was a very detailed description of things he could
do to begin narrowing down the problem (this has been pointed out to you
before).

However, if a bug report does not give any information that allows a
maintainer to determine the cause of the bug, or even what piece of
software has the bug, it absolutely is appropriate for the maintainer to
ask the bug reporter to "ask the community" for help in narrowing down
the cause of the bug, even to the point of closing the original bug and
asking the reporter to submit a new, more specific, bug after further
investigation.

In this case, nothing in the bug report gives any indication whether the
problem is due to software or hardware.  A low-RAM/high-swap situation
can also give symptoms similar to these, and in that case the OS is
behaving as expected.

The Debian Bug Tracking System is not a user support forum.  On the page
describing how to report bugs[1], it says

  If you are unable to determine which package your bug report should be
  filed against, please send e-mail to the Debian user mailing list
  asking for advice.

If you want a bug fixed, treat the maintainers as if they are doing you
a personal favor, because they are!  They are under no obligation to you
whatsoever.

...Marvin

[1] https://www.debian.org/Bugs/Reporting