Bug#1069934: 4.9.2. The dak ls utility should mention rmadison

[Bill Allombert]

Package: developers-reference
Version: 13.6
Severity: normal

Hello Holger,

4.9.2. The dak ls utility

could mention rmadison from devscripts
that does not require to log to ftp-master.debian.org.

There is also a be interface:

% curl 'https://api.ftp-master.debian.org/madison?package=evince'
evince | 3.30.2-3+deb10u1 | oldoldstable   | source, amd64, arm64, 
armhf, i386
evince | 3.30.2-3+deb10u1 | oldoldstable-debug | source
evince | 3.38.2-1 | oldstable  | source, amd64, arm64, 
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince | 43.1-2   | stable | source
evince | 43.1-2+b1| stable | amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x
evince | 45.0-1   | testing| source
evince | 45.0-1+b1| testing| amd64, arm64, armel, 
armhf, i386, mips64el, ppc64el, s390x
evince | 46.0-1   | unstable   | source
evince | 46.0-1   | unstable-debug | source
evince | 46.0-1+b1| unstable   | amd64, arm64, armel, 
armhf, i386, mips64el, ppc64el, riscv64, s390x

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: single-page html of debian-policy to be revived?

[Bill Allombert]

On Sat, Apr 27, 2024 at 10:15:19AM +0100, Sean Whitton wrote:
> Hello,
> 
> On Mon 15 Apr 2024 at 09:59am GMT, Holger Levsen wrote:
> 
> > On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote:
> >> ... but if dev-ref is already shipping both, maybe singlepage is indeed
> >> usable these days ...
> >
> > I think it is.
> >
> >> > Could the Policy Editors team check, if everything is fine now, and if
> >> > this should be published again?
> >> > At least there is still an issue with the footnotes, there are 16 
> >> > occurrences
> >> > of #id1 for example... (search for "[1]" in policy-1.html).
> >> Hrm.  That seems like a pretty serious problem :\
> >
> > I wouldnt call it serious. annoying yes, maybe.
> >
> >> Holger L., did you know about this issue?
> >> Did you decide it was worth publishing anyway?
> >
> > yes.
> >
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages
> > or (single page)
> > https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#how-could-installing-a-package-into-testing-possibly-break-other-packages
> > both show four footnotes, right where they belong, it's just that
> > each foot note is numbered and that [1] or [2] or whatever is
> > a link, pointing to a wrong place.
> >
> > I agree it's a bug, but I do think it's a pretty harmless one.
> 
> Thanks.  I'd be grateful for some feedback from other regular Policy
> contributors.

My view is that any issue with single-page is much more likely to be fixed if
we use it than if we do not.

I note that the links from the text to the footnotes are correct, it is only 
the backlink from the
footnotes to the text which are wrong. I consider this minor.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks

[Bill Allombert]

On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote:
> On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote:
> > Package: base-files
> > Version: 12.4+deb12u1
> > Followup-For: Bug #1039979
> > Control: tags -1 patch
> > 
> > I attach a patch to change absolute symlinks to relative symlinks,
> which would fix this bugreport if you choose to do so.
> 
> At least the /var/run directory is also created as a symlink to ../run
> by tmpfiles.d:
> 
> /usr/lib/tmpfiles.d/var.conf from the systemd package contains:
> L /var/run - - - - ../run

Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ?
/usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Bill Allombert]

On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote:
> I'm not sure what I think about that.  We have a general escape hatch
> already for non-free packages in Policy 2.2.3 that says they may not fully
> comply with Policy, which may be sufficient. 

But precisely, we _do_ want non-free packages that are built on the autobuilders
to comply with this requirement. So we do not want 2.2.3 to apply in that
specific case. It seems cleaner to say that the requirement only apply if
Autobuild: yes is declared.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Bill Allombert]

On Thu, Apr 04, 2024 at 09:25:36PM +0200, Philipp Kern wrote:
> Hi,
> 
> On 04.04.24 20:51, Bill Allombert wrote:
> > I still think we should allow Autobuild: no as an escape hatch.
> > If we want to require non-free package to be autobuildable, we should
> > be more explicit about it (and probably require more feedback from
> > debian-devel).
> 
> There is no requirement for non-free to be autobuildable today. This change
> also does not introduce this, except for everything that is to be built on
> official builders to not require network access.

Sorry, could you point me where the diff is limiting its scope to "everything
that is to be built on official builders"  ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Bill Allombert]

On Thu, Apr 04, 2024 at 11:42:34AM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> > On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:
> 
> >> Thanks Philipp. Following that result, please find a patch proposal: 
> >> 
> >> --- a/policy/ch-source.rst
> >> +++ b/policy/ch-source.rst
> >> @@ -338,9 +338,9 @@
> >>  For example, the build target should pass ``--disable-silent-rules``
> >>  to any configure scripts.  See also :ref:`s-binaries`.
> >>  
> >> -For packages in the main archive, required targets must not attempt
> >> -network access, except, via the loopback interface, to services on the
> >> -build host that have been started by the build.
> >> +Required targets must not attempt network access, except, via the
> >> +loopback interface, to services on the build host that have been started
> >> +by the build.
> >>  
> >>  Required targets must not attempt to write outside of the unpacked
> >>  source package tree.  There are two exceptions.  Firstly, the binary
> 
> > LGTM, Seconded.
> 
> Also looks good to me.  Seconded.

I still think we should allow Autobuild: no as an escape hatch.
If we want to require non-free package to be autobuildable, we should
be more explicit about it (and probably require more feedback from
debian-devel).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

[Bill Allombert]

On Tue, Apr 02, 2024 at 09:21:02AM +0800, Sean Whitton wrote:
> Hello,
> 
> On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote:
> 
> > Package: debian-policy
> > Version: 4.6.2.1
> > Severity: normal
> > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> > Control: affects -1 buildd.debian.org
> >
> > Hi,
> >
> > The debian policy, section 4.9, forbids network access for packages in
> > the main archive, which implicitly means they are authorized for
> > packages in contrib and non-free (and non-free-firmware once #1029211 is
> > fixed).
> >
> > This gives constraints on the build daemons infrastructure and also
> > brings some security concerns. Would it be possible to extend this
> > restriction to all archives?
> 
> We need to know if this is going to break existing packages and allow
> some input from their maintainers.  Are you able to prepare a list of
> the affected packages?

What I suggested was that "Autobuild: yes" imply no network access.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free

[Bill Allombert]

On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote:
> On 2024-04-01 17:52, Bill Allombert wrote:
> > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> > > Package: debian-policy
> > > Version: 4.6.2.1
> > > Severity: normal
> > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> > > Control: affects -1 buildd.debian.org
> > > 
> > > Hi,
> > > 
> > > The debian policy, section 4.9, forbids network access for packages in
> > > the main archive, which implicitly means they are authorized for
> > > packages in contrib and non-free (and non-free-firmware once #1029211 is
> > > fixed).
> > > 
> > > This gives constraints on the build daemons infrastructure and also
> > > brings some security concerns. Would it be possible to extend this
> > > restriction to all archives?
> > 
> > Does the build daemons actually build non-free ? 
> 
> Yes, they do, though only part of non-free, only the packages that have
> Autobuild: yes and that have been put on an allow list after review.

Is your concern is that the package start to do network acces during build
after it has been added to the allow list ?

Do you need "Autobuild: yes" to preclude network access ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

[Bill Allombert]

On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> Package: debian-policy
> Version: 4.6.2.1
> Severity: normal
> X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> Control: affects -1 buildd.debian.org
> 
> Hi,
> 
> The debian policy, section 4.9, forbids network access for packages in
> the main archive, which implicitly means they are authorized for
> packages in contrib and non-free (and non-free-firmware once #1029211 is
> fixed).
> 
> This gives constraints on the build daemons infrastructure and also
> brings some security concerns. Would it be possible to extend this
> restriction to all archives?

Does the build daemons actually build non-free ? 

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1063605: debian-policy: mandate use of `dpkg-buildflags` for all software compilation on Debian

[Bill Allombert]

On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: important
> 
> Hi,
> 
> with the upcoming time_t & friends 64-bit transition, dpkg-buildflags
> will be used to configure the ABI in use.

This decision comes from the wrong premise that the use of dpkg-buildflags
is universal, which is not the case. Hence it needs to be reconsidered.
There is not magic that will make all packages use dpkg-buildflags consistently
in the timeframe of this migration.

>  Thus all compiler
> invocations *must* use the flags specified by dpkg-buildflags to avoid
> ABI inconsistencies like this one:
> 
>   struct T { time_t a; time_t b; };
> 
> If this struct is accessed from both `libfoo1t64` (built respecting
> dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a user
> invoking gcc themselves), the result is probably not what one wants.
> 
> Thus `dpkg-buildflags` *must* be used by all packages *and* all users,
> including users building their own software.  There is one exception
> when libraries provide both 32-bit and 64-bit time_t ABIs like glibc
> itself (but I doubt there are many of those).

No, it is required that packages use correctly the right compiler flags.
Since packages need to be reuploaded anyway this is not a real issue.
dpkg-buildflags is not required for that, and does not necessarily achieve it
either, since upstream build system might not honor the environment variables
CFLAGS  etc. consistently.

> Any compiler invocation missing these *should* be a serious bug.
> (This should probably be mentioned in user documentation as well.)

This a different issue than mandating dpkg-buildflags.
dpkg-buildflags leads to build flags which are significantly different from
upstream, that have not been tested by users building from source, and they
can change without notice. It is very reasonable not to trust them.
In general we discourage diverging from upstream for similar reasons.

I offered #724621 as an option which would let packages maintainers control
which buildflags are used while still providing the benefit of buildflags.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1062983: Developers Reference in A4 instead of US Letter

[Bill Allombert]

On Mon, Feb 05, 2024 at 10:23:39AM +, Holger Levsen wrote:
> On Mon, Feb 05, 2024 at 11:00:42AM +0800, Paul Wise wrote:
> > > I think for English at least I'd prefer to offer both A4 and letter, for 
> > > eg
> > > the German translation I think it's enough to only provide A4.
> > Looks like that info can be gotten from the locales on glibc systems:
> [...]
> 
> nice, thanks.
> 
> > For languages with one translation instead of one per dialect,
> > you could produce documents in each of the unique sizes.
> 
> I don't understand, what do you mean with "one per dialect" here?

I assume dialect means pt_PT vs pt_BR. Each locale can have a different
page size even if the translation is the same.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness

[Bill Allombert]

On Wed, Dec 13, 2023 at 10:27:20PM +0100, Daniel Gröber wrote:
> On Wed, Dec 13, 2023 at 07:24:49PM +, Holger Levsen wrote:
> > On Wed, Dec 13, 2023 at 07:04:01PM +0100, Daniel Gröber wrote:
> > > That's fine, but in that case this fact should be documented instead no?
> > > Right now there's confusion across the docs what criticality levels are
> > > available. Britney.conf and d-policy mention critical/emergency but 
> > > nothing
> > > else even acknowledges they exist which is just confusing.
> > 
> > I believe Debian policy should be changed then and not mention a severity
> > which is not used in practice.
> 
> Easier said than done. I see debian-policy@d.o is already CCed on this bug
> so, opinions?
> 
> Doesn't policy document the reality that these urgency values are in fact
> usable? Do you not agree that britney does in fact support these? If I go
> ahead and upload a package with urgency=critical will this be REJECTed by
> ftp-master?

Theses urgency values are historical. Their current behaviour is not defined.
A long time ago in a distro not far away, packages for non-i386 were built
manually by porters that used the urgency to decide which packages to build
first.  
I do not think this is still the case, except that the security queue is build
first by the autobuilders.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1057238: debian-policy: Take dpkg-build-api into account for Rules-Requires-Root

[Bill Allombert]

On Sat, Dec 02, 2023 at 01:22:04AM +0100, Guillem Jover wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: wishlist
> 
> Hi!
> 
> Starting with dpkg 1.22.0, it implements a dpkg-build-api mechanism
> similar in concept to the debhelper-compat levels.
> 
> You can check its documentation in the dpkg-build-api(7) and
> dpkg-buildapi(1) manual pages.
> 
> I think at least the part that involves the Rules-Requires-Root field
> which in level 1 defaults to value «no» instead of «binary-targets»
> should be documented in the Debian policy.

Note that I proposed that in bug #229357 in 2004, this was even fully 
implemented,
commited to the VCS and finally reverted without explanation.
I am still not sure why I suffered so much hostility over such a simple design.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Bill Allombert]

Hello Russ,

In my view the main purpose of policy is to allow interoperability by defining
interfaces between packages.
 
We used to have a separate Packaging Manual, but it has been merged with
Policy a long time ago. The intent was to reduce duplication which lead to
outdated information.
However, this directly lead to the structural problem we have now.

While it would be OK for a Packaging Manual to say "just use debhelper"
that does not help the debhelper developers that need to know what it
is expected of debhelper.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Bill Allombert]

On Sun, Sep 17, 2023 at 08:28:56AM -0700, Russ Allbery wrote:
> Bill Allombert  writes:
> > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> >> On Sep 17, Russ Allbery  wrote:
> 
> >>> (I am a little confused by this wording, but I think what you're
> >>> saying is that /usr is encrypted and read-only, and /var is recreated
> >>> on each boot.  That at least is my understanding of the pattern that
> >>> you're trying to enable.)
> 
> >> The general idea is to be able to create /var on the first boot.
> 
> > Does not that would break users expectation that the system image
> > contains /var before the first boot ?
> 
> > A lot of things in /var are caches that are mostly instance-independent
> > and can be prefilled, but for that, users expect a minimal directory
> > hierarchy to be present before first boot.
> 
> Not that I think we're particularly close to achieving this design
> currently (and to be clear we haven't decided we're working towards this
> yet), but while I understand why a user would have that expectation today,
> I'm not sure why it would practically matter.  If all of that directory
> structure appears on first boot, and no static data is stored in /var,
> what use case requires the directory structure already exist in /var
> before the first boot?

As I said, filling the caches in /var/cache. For that they need to
exist with correct ownership and permissions.

Most of the cache in /var/cache/ (some are in /var/lib actually) 
do not depend on the host configuration, and can be regenerated/redownloaded as
needed, but not for free.

For example you might want to populate
/var/cache/apt/archives/ with the debs you need install later on (for example
for a pbuilder-like system), populate /var/lib/texmf/fonts/ with your fonts, or
even populate /var/www with your website, etc.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Bill Allombert]

On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> On Sep 17, Russ Allbery  wrote:
> 
> > (I am a little confused by this wording, but I think what you're saying is
> > that /usr is encrypted and read-only, and /var is recreated on each boot.
> > That at least is my understanding of the pattern that you're trying to
> > enable.)
> The general idea is to be able to create /var on the first boot.

Does not that would break users expectation that the system image contains /var
before the first boot ?

A lot of things in /var are caches that are mostly instance-independent and can
be prefilled, but for that, users expect a minimal directory hierarchy to be
present before first boot.

It seems your scheme favors some usecase over some others.

Cheers
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051371: Post-/usr-merge paths for script interpreters

[Bill Allombert]

On Sun, Sep 17, 2023 at 08:52:17AM +0200, Ansgar wrote:
> > Control: unblock 1051371 by 1050001
> > 
> > Ansgar  writes:
> > 
> > > However, there is a proposal by Jackson for an alternative filesystem
> > > layout based on symlink farms in consideration by the technical
> > > committee.  This advocates removing compat symlinks in /bin, /sbin over
> > > time[1], thus requiring (c).
> > 
> > This is not a correct summary of Ian's proposal.  In the message that you
> > linked, Ian says:
> > 
> >     /bin and /lib etc. remain directories (so there is no aliasing).  All
> >     actual files are shipped in /usr.  / contains compatibility symlinks
> >     pointing into /usr, for those files/APIs/programs where this is needed
> >     (which is far from all of them).  Eventualloy, over time, the set of
> >     compatibility links is reduced to a mere handful.
> > 
> > I am absolutely certain that Ian would consider /bin/sh to be one of the
> > programs for which a compatibility symlink is needed, and one of the
> > remaining handful of links that would exist indefinitely into the future.
> > Indeed, he mentions /bin/sh explicitly later in that message.
> 
> But the subject of this issue talks about "script interpreters", not
> just `/bin/sh` (which I guess is safe to assume would be one of the
> "handful").
> 
> It is unclear what files the Jackson symlink farm proposal would leave
> in /bin.  Would /bin/python3 stay?  Or would it stay first, but dropped
> at some later point?  What about /bin/perl, /bin/zsh, /bin/env, ...?

/bin/perl, /bin/env, /bin/python3 did not exist in the old scheme, so there is
no point in creating them now.

/bin/zsh and /bin/sed existed, though.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

[Bill Allombert]

On Sun, Sep 17, 2023 at 12:12:18AM +0200, Daniel Gröber wrote:
> Sam, Russ, Bill,
> 
> Thanks for your input. To be quite frank I still don't see how the
> interpretation of allowing configuration files outside of /etc can be
> supported based on the policy text.
> 
> Ultimately I'm just concerned about the UX aspects of admins suddenly
> having to go hunting for config files all over their system when packages
> start implementing this config-in-/usr business en mass.

It seems your issue is more with the documentation and transition to these
new schemes, which is a valid concern I mentionned in my answer.

There are two common schemes:
1/ the default file is read and then the config file is read to 
override/supplement it.
In that case the package should ship with dummy config files that document 
where is the file
they override

2/ the default file is only read when the config file does not exist.
This is more annoying since this precludes shipping with dummy config files.
In that case I recommend including a README file listing the path to the
default files that can be overrided.
Especially if this is a new scheme that users cannot yet be aware of.

Cheers,
Bill.

Bug#1051371: Post-/usr-merge paths for script interpreters

[Bill Allombert]

On Wed, Sep 13, 2023 at 10:47:48AM +0200, Bill Allombert wrote:
> On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery wrote:
> > Control: retitle -1 Post-/usr-merge paths for script interpreters
> > 
> > Simon pointed out that this bug is not yet ready to act on, which was very
> > helpful.  Thank you.  However, presumably the buildds will be /usr-merged
> > at some point in the not-too-distant future, and we do need to decide what
> > to do after that point.
> > 
> > I think the root problem behind this bug is that it is revealing we have
> > not made a decision about /bin and /usr/bin path references in Debian
> > after /usr-merge.  Various people, myself included, made assumptions about
> > what the policy would be, but we never actually decided anything that I am
> > aware of and people's assumptions are not matching.  I think we need to
> > talk about this directly, after which what to do with this bug will
> > probably become obvious.
> 
> Russ, there is a quite related point I do not think the TC addressed 
> directly, 
> but I can easily be mistaken: the default PATH.
> It is currently defined in /etc/login.defs (unless my copy of this file is 
> out of date):
> as
> ENV_SUPATH  
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> 
> so in pratice, tools like 'which' will always favor /usr/bin over /bin
> 
> $ which sh
> /usr/bin/sh
> 
> One of the issue in the past is that reproducible build was broken because 
> different
> build environment lead to different paths. We at least need to address that.

To be specific, I needed to add 
SHELL=/bin/sh GREP=/bin/grep SED=/bin/sed DD=/bin/dd
to configure to get reproducible build. (This was in December 2018).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

[Bill Allombert]

On Thu, Sep 14, 2023 at 04:01:05PM +0200, Daniel Gröber wrote:
> Hello debian-policy,
> 
> iproute2 has moved it's config files that were traditionally at
> /etc/iproute2 to /usr/lib/iproute2 due to an upstream change. I've tried to
> convince the maintainer(s) that this is a bad idea in Bug#1051577, when
> this was shot down I filed Bug#1051847 as severity:serious on the basis of
> Debian policy section 10.7.2 section 10.7.2. "Configuration files /
> Location" which states as follows:
> 
> > Any configuration files created or used by your package must reside
> > in /etc.
> 
> Pretty clear cut in my reading, however this was promptly shot down by
> Bastian  with the justification:
> 
> > No, it does not.  The files in /usr are defaults.  Those should be copied
> > to /etc for modification, which is config.
> 
> Am I going nuts? Somehow long established unix convention and usability
> doesn't matter anymore and policy doesn't mean what it says?

The idea is that files in /usr/ are default files that can be 
overrided or supplemented by a configuration file in /etc/ with the same name.
When properly documented, this is a very good scheme since that make update of
configuration file easier.
The kpathsea system of TeX is an extreme version of that scheme that allow
several level of override simultaneously.

For a simple example, popularity-contest ships
/usr/share/popularity-contest/default.conf as default file
which is overrided by the configuration file
/etc/popularity-contest.conf

/usr/share/popularity-contest/default.conf says PARTICIPATE="no"
and users that want to participate set PARTICIPATE="yes" in
/etc/popularity-contest.conf (through debconf) to override it.

It is recommended that /etc/ carry dummy configuration files that provide
information on the default file they override.

Of course changing the configuration files scheme is a different issue and need
to be done carefully so that users understand what is expected of them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051801: document DEB_BUILD_OPTIONS value nopgo

[Bill Allombert]

On Mon, Sep 11, 2023 at 09:25:11AM +0200, Helmut Grohne wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: wishlist
> X-Debbugs-Cc: 
> debian-cr...@lists.debian.org,rb-gene...@lists.reproducible-builds.org
> 
> Hi,
> 
> more and more packages implement a technique called profile guided
> optimization. The general idea is that it performs a build that is
> instrumented for profiling first. It then runs a reasonable workload to
> collect profiling data, which in turn is used to guide the optimizer of
> a second build which is not thus instrumented. The idea is that this
> second build probably is faster than a regular build.

Hi!

Is it possible to save the profile data to reperform the second build later ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051371: Post-/usr-merge paths for script interpreters

[Bill Allombert]

On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery wrote:
> Control: retitle -1 Post-/usr-merge paths for script interpreters
> 
> Simon pointed out that this bug is not yet ready to act on, which was very
> helpful.  Thank you.  However, presumably the buildds will be /usr-merged
> at some point in the not-too-distant future, and we do need to decide what
> to do after that point.
> 
> I think the root problem behind this bug is that it is revealing we have
> not made a decision about /bin and /usr/bin path references in Debian
> after /usr-merge.  Various people, myself included, made assumptions about
> what the policy would be, but we never actually decided anything that I am
> aware of and people's assumptions are not matching.  I think we need to
> talk about this directly, after which what to do with this bug will
> probably become obvious.

Russ, there is a quite related point I do not think the TC addressed directly, 
but I can easily be mistaken: the default PATH.
It is currently defined in /etc/login.defs (unless my copy of this file is out 
of date):
as
ENV_SUPATH  
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

so in pratice, tools like 'which' will always favor /usr/bin over /bin

$ which sh
/usr/bin/sh

One of the issue in the past is that reproducible build was broken because 
different
build environment lead to different paths. We at least need to address that.

Personnally, I favor keeping /bin/sh for consistency, but that is aside.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Bill Allombert]

On Tue, Sep 12, 2023 at 10:49:02AM -0700, Russ Allbery wrote:
> To take an example that I've been trying to get rid of for over a decade,
> many of the /usr/share/common-licenses/BSD references currently in the
> archive are incorrect.  There are a few cases where the code is literally
> copyrighted only by the Regents of the University of California and uses
> exactly that license text, but this is not the case for a lot of them.  It
> looks like a few people have even tried to say "use common-licenses but
> change the name in the license" rather than reproducing the license text,
> which I don't believe meets the terms of the license (although it's of
> course very unlikely that anyone would sue over it).

Note that my proposal makes detecting the discrepancy more visible rather
than less, since you can compare the generated copyright file with
the actual license statement without chasing files.

Also, overengineering aside, the copyright generator could support 
parameter substitution to accomodate small discrepancies in license.
For example an option to replace in /usr/share/common-licenses/BSD the
line 
"Copyright (c) The Regents of the University of California."
by whatever is required when generating DEBIAN/copyright.

Cheers,
Bill

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Bill Allombert]

On Mon, Sep 11, 2023 at 09:21:56AM -0600, Sam Hartman wrote:
> > "Santiago" == Santiago Vila  writes:
> 
> Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió:
> >> I therefore would like to propose a first: I think Policy should
> >> simply say that any package that provides a system service should
> >> use debhelper and rely on dh_installsystemd to put the
> >> appropriate commands in its maintainer scripts.  (We can then
> >> discuss whether we should do the same for init scripts and
> >> dh_installinit, although its stanzas are simpler.)
> 
> Santiago> Hello. I don't like this approach, and I believe we are
> Santiago> mixing two different things here. One of them is our
> Santiago> ability (or lack thereof) of policy to catch up with real
> Santiago> development done elsewhere. Another one is the fact that
> Santiago> policy does not mandate any given implementation.
> 
> The question in my mind is whether it is valuable to support multiple
> implementations, and I think the answer is no.

But we do: we support debhelper 13.11.4 and debhelper 13.11.6.
Even if we support a single implementation, we still need to know what is
expected of it.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#567033: Decide if we should continue recommending /usr/games

[Bill Allombert]

On Mon, Sep 11, 2023 at 02:38:14PM -0400, Antoine Beaupré wrote:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
> > Antoine Beaupré  writes:
> >
> >> I get the argument against bad binaries not being in PATH but we have
> >> some tooling for that, don't we? /usr/libexec, no?
> >
> > /usr/libexec isn't a replacement because it's not on any user's PATH.
> > /usr/games is intended to be added to a regular user's path but not
> > root's, which is a distinct use case.
> 
> That's an odd argument to make: /usr/games isn't on any user's PATH
> either, is it?

% grep games /etc/profile /etc/login.defs
/etc/profile:  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
/etc/login.defs:ENV_PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#567033: Decide if we should continue recommending /usr/games

[Bill Allombert]

On Mon, Sep 11, 2023 at 12:51:33PM -0400, Antoine Beaupré wrote:
> On 2018-06-14 11:42:22, Simon McVittie wrote:
> > Debian can choose to put games in the /.../games directories, or in the
> > standard directories /usr/bin, /usr/share etc., or any mixture of our
> > choice, orthogonal to whether/when we move to FHS 3.0.
> 
> It's been a while since this was discussed, but I have just learned of
> this issue, so sorry for bumping an old thread but...
> 
> I have recently learned that FreeBSD moved their games out of /usr/games
> and into /usr/bin. Things like rot13(6), fortune(6), primes(6) are all
> in the main PATH now, amazing no? :)
> 
> That happened in 2015:
> 
> https://cgit.freebsd.org/src/commit/ObsoleteFiles.inc?id=11d9aa670723f508821f2bf6980a555360783a80
> 
> I wonder if we should just do the same. I'm not sure I see the point of
> having all that stuff in a separate directory, personnally, but at least
> in this case we shouldn't needlessly diverge from upstream... although
> in terms of upstream for bsd-games, things are kind of hazy, at best,
> from what I understand.

I do not see any advantage over /usr/games.

On the other hand, /usr/games allows:
- priviledged accounts to omit /usr/games in their path (root does not have it 
e.g)
- quickly find which games are installed on a system (ls /usr/games).
- have a separate partitions for game data (which are amongst the largest 
Debian package)
- have a specific policy for /var/games

Cheers,
Bill

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Bill Allombert]

On Mon, Sep 11, 2023 at 12:47:15PM +0200, Santiago Vila wrote:
> El 10/9/23 a las 4:09, Russ Allbery escribió:
> > I therefore would like to propose a first: I think Policy should simply
> > say that any package that provides a system service should use debhelper
> > and rely on dh_installsystemd to put the appropriate commands in its
> > maintainer scripts.  (We can then discuss whether we should do the same
> > for init scripts and dh_installinit, although its stanzas are simpler.)
> 
> Hello. I don't like this approach, and I believe we are mixing two different 
> things
> here. One of them is our ability (or lack thereof) of policy to catch up with
> real development done elsewhere. Another one is the fact that policy does
> not mandate any given implementation.

I agree. The issue is that we need to document what dh_installsystemd should do,
otherwise we will not be able to distinguish between bug in dh_installsystemd 
and
intended behaviour, and we will end up freezing dh_installsystemd to avoid 
introducing
problem by breaking incidental interfaces.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Bill Allombert]

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > Quoting Hideki Yamane (2023-09-10 11:00:07)
> 
> >>  Hmm, how about providing license-common package and that depends on
> >>  "license-common-list", and ISO image provides both, then? It would be
> >>  no regressions.
> 
> I do wonder why we've never done this.  Does anyone know?  common-licenses
> is in an essential package so it doesn't require a dependency and is
> always present, and we've leaned on that in the past in justifying not
> including those licenses in the binary packages themselves, but I'm not
> sure why a package dependency wouldn't be legally equivalent.  We allow
> symlinking the /usr/share/doc directory in some cases where there is a
> dependency, so we don't strictly require every binary package have a
> copyright file.

Or we could generate DEBIAN/copyright from debian/copyright using data in
license-common-list at build time. So maintainers would not need to manage the 
copying
themselves.

Cheers,
Bill

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Bill Allombert]

On Wed, Sep 06, 2023 at 04:51:10PM -0600, Sam Hartman wrote:
> > "Luca" == Luca Boccassi  writes:
> Luca> /bin/sh is not universally compatible with non-Linux OSes.
> 
> I claim it is more compatible.
> 
> 
> Luca> Also I thought that policy should not be used to beat other
> Luca> developers (it is because of this) and it should reflect the
> Luca> common practices adopted in Debian (it does not because of
> Luca> this). Is that no longer the case?
> 
> I'd consider it a non-RC bug if someone were manually writing
> #!/usr/bin/sh
> 
> We can debate about normal vs minor.
> 
> I do not think it should be a bug if some automated build process found
> /usr/bin/sh and stuck that into a script.
> I'd support a policy change to make that clear.

I would. Having two paths for the same thing is a technical debt going forward.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1050322: Partial versus complete replacement of a package by another

[Bill Allombert]

On Wed, Aug 23, 2023 at 09:22:41AM +0200, julien.pu...@gmail.com wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: normal
> 
> Hi,
> 
> over at bug #1050027 there is a discussion of applicable policy when
> splitting a package. I'll first explain what the bug is about and then
> why that's a problem with the Policy.
> 
> The src:mathcomp-analysis package provided a single binary package
> libcoq-mathcomp-analysis until 0.6.3-2 ; with 0.6.4-1, it's now
> providing two binary packages libcoq-mathcomp-analysis and libcoq-
> mathcomp-classical. The binary package libcoq-mathcomp-analysis Depends
> on libcoq-mathcomp-classical (= ${binary:Version}). And with 0.6.4-1,
> that Depends was the only information, so of course file conflicts
> weren't handled correctly, and that is what #1050027 is about.
> 
> In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
> classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
> bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
> according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
> mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
> analysis (<< 0.6.4) -- it only provides a small part of it!
> 
> 
> So what does the Policy actually say?

The main purpose of Replaces: is that dpkg normally does not allow two 
different packages
to provide the same files. When the second package is installed dpkg will issue 
an
overwrite error, unless the second package has the same name as the first or 
when
the second package Replaces: the first.

Mostly there are two cases:
1/ you decide to move the file /usr/share/foo/data from foo to foo-data:
foo-data needs to Replaces: foo for at least one release.

2/ you decide to rename the package foo to foo1:
foo1 need to Replaces: foo for at least one release.

Cheers,
Bill

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Bill Allombert]

On Sun, Jul 30, 2023 at 08:22:54PM +0100, Luca Boccassi wrote:
> On Fri, 30 Jun 2023 00:04:29 +0100 Luca Boccassi 
> wrote:
> > This happened a few days ago and nobody complained (if we ignore
> > grumblings because of the fact that I used lintian.debian.org queries
> > which are hopelessly and silently out of date, sigh), and bugs are
> > filed, there have been a couple of uploads too already.
> > 
> > Can we go ahead, or do you want to wait a specified amount of time?
> > If
> > so, how long (just so that I know when to come back)?
> 
> Hi, monthly ping. Anything I can do to move this forward?

I consider this proposal to be premature. Policy should document current
practice, and I do not think this proposal does that.
It would it more useful to help maintainers adapt their script to conform
to this first, and change policy later.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: 6.1.3. Multiple binary packages question

[Bill Allombert]

On Sat, Jun 17, 2023 at 09:21:00PM +, Holger Levsen wrote:
> On Mon, Apr 03, 2023 at 09:29:04AM -0600, Sam Hartman wrote:
> > > "Kristian" == Kristian Penno  writes:
> > Kristian> source package is referenced.  The lyx source package uses
> > Kristian> some shell commands to move files around in the rules
> > Kristian> file.  Is this preferred to using debhelper
> > Kristian> .install files?
> > No.
> > If .install files work for you, that's better.

The drawback of dh_install is that it requires more diskspace to build than
dh_movefiles but is less error prone.
So unless your package is very large, it is safer to use dh_install.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Bill Allombert]

On Tue, Jun 13, 2023 at 05:43:17PM +0200, Thorsten Glaser wrote:
> On Mon, 5 Jun 2023, Simon McVittie wrote:
> 
> >No init system at all, (C.), can only happen when starting with a
> >minbase debootstrap or equivalent (because a default debootstrap
> >includes the init metapackage due to its Priority: required). In
> >this scenario it *usually* doesn't really matter whether we
> >install systemd or systemd-tmpfiles-standalone. systemd is somewhat
> 
> This is not quite true; there is one really important use case:
> chroots. I have multiple chroots (sid, stretch, buster) on one
> of my bullseye systems which I use with schroot, but that could
> just as well be any other chroot, to run individual software in
> it. They are, as is proper, configured to not run any services
> (via policy-rc.d).

I agree, chroots are important to consider, and the system should not make
assumptions how and why there are used.

Conversely, sometimes I need to use chroots to test init scripts.
start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows
it.

Cheers,
Bill.

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 11:34:17PM +0100, Luca Boccassi wrote:
> On Wed, 7 Jun 2023 00:01:42 +0200 Bill Allombert 
> > This is beside the point. Your problematic statement was
> > "The whole project is moving toward git and Salsa ".
> > This is not conducive of productive interaction.
> 
> It was not problematic at all, unless you are deliberately trying to
> see problems where there are none. It was an hyperbole: a huge number
> of packages and teams are using effectively Salsa workflows for
> collaboration today. Are you denying this?

This is not important. What matters is that this statement could be read as
excluding from the project or belittling developers that are not moving toward
Salsa.  This is inappropriate. Even assuming it was not your intent, such
statements creates friction in the project by making people uncomfortable
without any benefit, and so should be avoided.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Wed, Jun 07, 2023 at 08:19:08AM -0700, Russ Allbery wrote:
> > In general, policy proscription are only useful when the description of
> > a better mechanism is provided.  But there is no place for that in this
> > section.
> 
> I'm not sure I understand this statement, since describing a better
> mechanism is exactly the point of that language about systemd.  We link
> directly to those better mechanisms (masking, drop-ins, and, for
> alternatives, aliases).

What I meant was that this section in not the right place for systemd or other
software configuration detail, because nobody will look for systemd
configuration detail in the dpkg-divert section.

> I definitely agree that Policy should have a whole section devoted to
> systemd and its configuration files, but I don't want to try to boil the
> ocean in one bug.  But yes, we should be working towards that, IMO.

Yes that what I wanted to say.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> 
> > I think what's a bit peculiar here is using "must" for a case where
> > there might be package-specific exceptions.  In other cases, Policy uses
> > "should" for these cases.  Typically "must" rules are simple and
> > completely determinate.
> 
> I prefer that too, but in this case, it feels like must is appropriate for
> at least systemd configuration files.  And also, just intuitively, I feel
> like must is correct when people are using diversions rather than a native
> mechanism.  Diversions add weird edge cases and we really shouldn't be
> using them lightly.
> 
> The wording I proposed and that Luca has now adopted therefore uses must
> with a caveat.  Does that sound okay to you?

I do not think appropriate for the policy to list systemd or any
other packages specifically in this section.

If a package set up a diversion that breaks another, then it is buggy,
whatever policy say. If the diversion does not cause any breakage, there is
no purpose for policy to declare it a RC bug.

In general, policy proscription are only useful when the description of a
better mechanism is provided.  But there is no place for that in this section.

It would more suitable to have a separate section or document defining the
interface between systemd and other packages, that would explain how to avoid
diversion by providing better solutions rather than direct proscriptions, with
more details than just "use native systemd configuration files".

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 07:52:35PM -0700, Russ Allbery wrote:
> Bill Allombert  writes:
> > On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
> 
> >> If you prefer, I can reword the general rule to be stricter, ie:
> >> "packages must not use diversions where native mechanisms are
> >> available" or so. Would this be better?
> 
> > "native mechanisms" seems to vague.
> 
> I suggested "must not be used when a suitable override mechanism that
> accomplishes the same goal is already available."  Does that sound okay?
> It's a bit weaker and opens the door to arguments about whether the native
> override mechanism accomplishes the same goal, but I think that's a
> feature here rather than a bug.

It is fine with me. It is in line with the notion that diversion are a last
resort, but not precluded entirely.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 03:16:02PM +0100, Luca Boccassi wrote:
> On Tue, 6 Jun 2023 15:23:35 +0200 Bill Allombert ,
> Luca Boccassi  wrote:
> > On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > > > The diversion system is made precisely to work around other
> packages
> > > behavior,
> > > > this is a feature not a bug. That it should only be used as last
> > > resort, I
> > > > think everyone agree. But when it is, it should not be a RC bug.
> > > 
> > > This is a technical matter, I'm not sure what 'consensus' means in
> this
> > > context? Things _will not work_ as expected by shoe-horning dpkg's
> > > overrides onto systemd mechanisms, they _will_ break in weird and
> > > unexpected ways, and we as maintainers _will not support it_ -
> whether
> > > somebody else agrees or disagrees with this won't change any of it.
> > 
> > Consensus is the way the Debian Policy update process works.
> > But you do not need changes in Policy to report bugs about package
> that breaks
> > others, there is the "grave" severity already.
> 
> That does not help, given currently policy allows it, without changes
> they could just say "policy allows me, so go fix it yourself". What
> then?

That simply not how Policy works.
Policy is for promoting interoperability and documenting current practices.
"Policy is not a stick to beat people with" as Manoj used to say.

If you are suggesting a policy change so that you can report RC bugs on other
packages, you are on the wrong track.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 09:36:31PM +0100, Luca Boccassi wrote:
> On Tue, 6 Jun 2023 20:51:46 +0200 Dominik George
>  wrote:
> > > Ok, how about: "the whole project, minus
> naturesha...@debian.org who
> > > appears to be unfamiliar with the concept of hyperboles, is moving
> > > toward git and Salsa". Better?
> > 
> > No.
> > 
> > Your "hyperbole" very much read as "Come on, minority who cares about
> > the mail workflow, you're weird anachronists, get onto the Salsa
> train already!"
> > 
> > So that's what I am criticizing.
> 
> Sure, and you just coincidentally happened to leave out the part that
> says the exact opposite:

This is beside the point. Your problematic statement was
"The whole project is moving toward git and Salsa ".
This is not conducive of productive interaction.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > The diversion system is made precisely to work around other packages
> behavior,
> > this is a feature not a bug. That it should only be used as last
> resort, I
> > think everyone agree. But when it is, it should not be a RC bug.
> 
> This is a technical matter, I'm not sure what 'consensus' means in this
> context? Things _will not work_ as expected by shoe-horning dpkg's
> overrides onto systemd mechanisms, they _will_ break in weird and
> unexpected ways, and we as maintainers _will not support it_ - whether
> somebody else agrees or disagrees with this won't change any of it.

Consensus is the way the Debian Policy update process works.
But you do not need changes in Policy to report bugs about package that breaks
others, there is the "grave" severity already.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 12:16:39PM +0100, Luca Boccassi wrote:
> > > local administrators and local packages to override the behaviour of
> > > Debian. Its use between Debian packages should be rare, should involve
> > > coordination between the packages and their maintainers, and must only
> > > be used to solve problems that cannot be handled through other
> > > facilities or native mechanisms.  In other words, packages in Debian
> > > must not divert a file from another package unless this is arranged
> > > cooperatively between the packages to solve some specific and unusual
> > > problem.
> >
> > How about:
> >
> > Diversions and alternatives are primarily tools for local
> > administrators and local packages to override Debian's default
> > behaviour.  Maintainers should prefer to use other, package-specific
> > facilities for overriding configuration, such as systemd's unit file
> > overrides, wherever possible.
> >
> > If diversions and alternatives are to be used, maintainers should
> > co-ordinate with the maintainers of all the packages involved.  For
> > example, configuration files used by systemd components should not
> > be diverted with dpkg-divert or the alternatives system without
> > agreement between not only the maintainers of the packages that ship
> > the files, but also the maintainers of the relevant systemd
> > components.
> 
> As above, as long as this wording makes any offending package
> rc-buggy, it's fine by me, but my understanding is that using 'should'
> doesn't guarantee that. Please correct me if I'm wrong here.

I do not think there is consensus that this should be a RC bug outside of
a case by case basis. It is already awkward to mention systemd explicitly
in this paragraph.

The diversion system is made precisely to work around other packages behavior,
this is a feature not a bug. That it should only be used as last resort, I
think everyone agree. But when it is, it should not be a RC bug.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Tue, Jun 06, 2023 at 12:33:52PM +0100, Luca Boccassi wrote:
> On Tue, 6 Jun 2023 at 12:25, Dominik George  wrote:
> >
> > > The whole project is moving toward git and Salsa
> >
> > Sorry for the noise, but as you are clearly misattributing this to me (I am 
> > part of the project, so "the whole project" includes me):
> >
> > I am not, and do not want to, move bugs and patches to Git and Salsa. I 
> > consider it a huge advantage of Debian that I can contribute limitless with 
> > something as barrierfree as an e-mail.
> >
> > If you voice your opinion, please do not impose it on me. Thanks!
> 
> Ok, how about: "the whole project, minus naturesha...@debian.org who
> appears to be unfamiliar with the concept of hyperboles, is moving
> toward git and Salsa". Better?

This is out of line.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
> If you prefer, I can reword the general rule to be stricter, ie:
> "packages must not use diversions where native mechanisms are
> available" or so. Would this be better?

"native mechanisms" seems to vague.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Bill Allombert]

On Wed, Apr 26, 2023 at 10:49:32AM +, Robert Ernst wrote:
> Hello Bill,
> 
> thank you for the swift reply!
> 
> Excuse me if I do err, but even after consulting others, this bug seems to
> be open.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013195
> 
> And from an uninitiated perspective it seems like the policy team never
> looked at this bug.
> So the best solution for this specific bug would be to leave a comment with
> a hint to the history and then close it?

This bug is duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884223

Cheers,
Bill.

Re: Bug #1013195: base-files: Please add AGPL-3 license

[Bill Allombert]

On Wed, Apr 26, 2023 at 09:03:14AM +, Robert Ernst wrote:
> Hello,
> 
> I found this bug because I was asking myself why we don't include more
> licenses in the /usr/share/common-licenses/ folder.
> While I am open to have the big topic (of why we don't just put all licenses
> know to man in every language put into the common-licences folder and then
> refer from the debian/copyright file to that folder/files instead of putting
> the whole license text into every package itself) I prefer to keep it at a
> specific example in case of this bug.
> 
> This bug was assigned at Mon, 03 Oct 2022 22:03:07 GMT to debian-policy. It
> seems it was not getting attention from the debian-policy team since 6
> months.

The rule we follow is that the license need to be used by a non negligible
percentage of packages. It is not the first time a bug report ask to add the
AGPL. Last time the statistic was computed, the AGPL did not cut it, so the bug
was closed.

Cheers,
Bill

Re: Reducing allowed Vcs for packaging?

[Bill Allombert]

On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> Hi!
> 
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of 
> them for
> one package. No package makes use of several Vcs references and frankly I do 
> not
> see why this was supported in the first place.
> 
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
> 
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.

People that use e.g. subversion could just remove the Vcs-svn field and pretend
that they do not use any VCS. What does that gain us ?

I have sympathy for maintainers that use the same VCS as usptream. I have 
sympathy for 
upstream of a VCS to use that VCS instead of GIT.

... Unfortunately some projects I work with did not convert their whole history 
to GIT 
and I find useful that Debian still provide subversion and mercurial to access 
older
commits (and dead projects history).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Bill Allombert]

On Mon, Feb 20, 2023 at 01:59:21PM +, Jelmer Vernooij wrote:
> On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote:
> > Hello,
> > 
> > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote:
> > 
> > > Package: debian-policy
> > > Severity: wishlist
> > >
> > > Policy currently describes Vcs-* headers as something optional, but stops 
> > > to
> > > endorse a particular Vcs.
> > >
> > > At this point, it seems uncontroversial to encourage use of Vcs-Git
> > > specifically here. Apart from technical arguments, it's the vcs that the
> > > majority of packages in the archive uses - and thus will have the better
> > > tooling, less of a learning curve for other contributors, etc.
> > >
> > > There are very few holdouts of other vcses in the archive. I count 62
> > > (ignoring those with an alioth URL):
> > >
> > >  * 26 on Svn
> > >  * 3 on Cvs
> > >  * 4 on Hg (2 are hg/hg-buildpackage)
> > >  * 39 on bzr (half of these are actually bzr and related packages, which 
> > > I maintain)
> > 
> > This strikes me as a matter for devref not Policy?
> 
> I've created a PR for devref - 
> https://salsa.debian.org/debian/developers-reference/-/merge_requests/41
> 
> Are you saying that it doesn't belong in policy because it'd be a
> recommendation rather than a must/should (at this point?), or because it's 
> more about the
> workflow inside of Debian than package contents?

Yes this is about the workflow and not the package, and so far we have let 
developpers pick
whatever workflows suit them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#934536: info version not shipped, close this bug?

[Bill Allombert]

On Thu, Feb 09, 2023 at 02:35:42PM +, Holger Levsen wrote:
> control: tags -1 +moreinfo
> thanks
> 
> hi,
> 
> (originally sent to the wrong (but archived) bug number...)
> 
> we're not shipping the manual in .info format, so I'm wondering whether this
> bug should simply be closed, or why not?

$ dpkg -L developers-reference | grep info
/usr/share/info
/usr/share/info/developers-reference.info.gz

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#299927: debtags future unclear

[Bill Allombert]

On Wed, Feb 08, 2023 at 01:24:52PM +, Holger Levsen wrote:
> control: tags -1 +moreinfo
> control: affects -1 debtags
> thanks
> 
> hi,
> 
> https://lists.debian.org/msgid-search/20221019132043.d4c4liyt6s6qe...@enricozini.org
> and
> https://lists.debian.org/msgid-search/bb7064071ebd838a9e045a1916bba49a9b960d80.ca...@debian.org
> indicate that debtags.debian.org might be shutdown after the release
> of bookworm, thus tagging this bug moreinfo for now, as there's not
> much point documenting something which is going away.

It seems this concerns only the debtags.debian.org website, not the whole
debgtags system, right ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#801065: Documenting how to not fail postinst on service fails to starto

[Bill Allombert]

O#n Wed, Feb 08, 2023 at 04:47:37PM +, Holger Levsen wrote:
> retitle -1 turn #904558 into advice - how postinst should deal with failures
> thanks
> 
> On Wed, Feb 08, 2023 at 09:26:58AM -0700, Sam Hartman wrote:
> > The TC bug is 904558.
> 
> thank you very much for this pointer, that's a pretty good discussion,
> which resulted in
> 
> -
> 
> So, the TC declines to rule on what should maintscripts do when failing 
> to
> (re)start a service (or otherwise encountering a similarly serious
> problem).
> 
> -
> (read the full result at 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904558#137 )

Note that the TC declining to rule on an issue does not override the policy 
group right to make
a determination on that issue. So we are back to the situation before the 
referral to the TC.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#801065: consent unclear

[Bill Allombert]

On Wed, Feb 08, 2023 at 03:54:22PM +, Holger Levsen wrote:
> hi,
> 
> btw, as pointed out on irc: I ment consensus, not consent. :)
> 
> On Wed, Feb 08, 2023 at 10:36:02AM -0500, Marvin Renich wrote:
> > > I don't think there has been consent on the issue, thus I'm tagging it
> > > moreinfo.
> > > 
> > > I'm also wondering whether to mark this bug as wontfix (until there is
> > > consent) or to reassign to debian-policy or simply to close it.
> > 
> > I disagree.  Re-reading the messages to the bug report, We have
> > "strongly support" from Sam Hartman, and "also in favor" from Russ
> > Allbery and Bill Allombert.
> > 
> > The only objection was from Henrique de Moraes Holschuh based on lack of
> > risk assessment from the mistaken impression
> 
> not only based on that, but way more importantly that this would change
> *years* of existing practice.

Could you clarify which 'existing practices' ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Bill Allombert]

On Fri, Feb 03, 2023 at 05:57:21PM +, Jelmer Vernooij wrote:
> On Fri, Feb 03, 2023 at 06:48:13PM +0100, Bill Allombert wrote:
> > On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote:
> > > Package: debian-policy
> > > Severity: wishlist
> > > 
> > > Policy currently describes Vcs-* headers as something optional, but stops 
> > > to
> > > endorse a particular Vcs.
> > > 
> > > At this point, it seems uncontroversial to encourage use of Vcs-Git
> > > specifically here. Apart from technical arguments, it's the vcs that the
> > > majority of packages in the archive uses - and thus will have the better
> > > tooling, less of a learning curve for other contributors, etc.
> > > 
> > > There are very few holdouts of other vcses in the archive. I count 62
> > > (ignoring those with an alioth URL):
> > > 
> > >  * 26 on Svn
> > >  * 3 on Cvs
> > >  * 4 on Hg (2 are hg/hg-buildpackage)
> > >  * 39 on bzr (half of these are actually bzr and related packages, which 
> > > I maintain)
> > 
> > I do not quite understand. Surely the package need to use the VCS-* header
> > corresponding to the VCS used by the repository, whathever it is ? This is 
> > not
> > a matter of preference.
> 
> Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather 
> than just
> of the Vcs-Git header.

Then maybe it would be a better fit for the developer reference than to policy ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Bill Allombert]

On Fri, Feb 03, 2023 at 05:24:36PM +, Jelmer Vernooij wrote:
> Package: debian-policy
> Severity: wishlist
> 
> Policy currently describes Vcs-* headers as something optional, but stops to
> endorse a particular Vcs.
> 
> At this point, it seems uncontroversial to encourage use of Vcs-Git
> specifically here. Apart from technical arguments, it's the vcs that the
> majority of packages in the archive uses - and thus will have the better
> tooling, less of a learning curve for other contributors, etc.
> 
> There are very few holdouts of other vcses in the archive. I count 62
> (ignoring those with an alioth URL):
> 
>  * 26 on Svn
>  * 3 on Cvs
>  * 4 on Hg (2 are hg/hg-buildpackage)
>  * 39 on bzr (half of these are actually bzr and related packages, which I 
> maintain)

I do not quite understand. Surely the package need to use the VCS-* header
corresponding to the VCS used by the repository, whathever it is ? This is not
a matter of preference.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Bill Allombert]

On Sat, Jan 21, 2023 at 12:58:19PM -0800, Russ Allbery wrote:
> Wouter Verhelst  writes:
> > On Fri, Jan 20, 2023 at 05:16:43PM +, Simon McVittie wrote:
> 
> >> Sure, but neither of those actually require us to support GBK or GB
> >> 18030 as a system locale, only as something that iconv() (or whatever
> >> browsers actually use, which is probably their own thing) can convert
> >> into their preferred internal representation (which is almost certainly
> >> UTF-8, UTF-16 or UCS-4).
> 
> > Those files need to be edited *somewhere*. If that somewhere is a Debian
> > desktop, then you also need editors that know how to write such files,
> > etc.
> 
> Both Emacs and vim will edit files in whatever (supported) encoding you
> want, regardless of the locale encoding.  I would assume this is not that
> uncommon of a feature for other editors as well.  This is therefore a bit
> like Simon's web browser example (although may be somewhat less
> transparent, admittedly).

This is true but this is missing an important point: it is usually not possible
to detect the characther encoding of a plain text file.
That is where a default encoding is required.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Bill Allombert]

On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> On Wed, 18 Jan 2023 at 16:30:46 -0700, Anthony Fok wrote:
> > In their mind, GB 18030 encompasses a lot more than just
> > a character encoding mapping table.  It is the full support package
> > (including fonts, display, printing, input methods, etc.) for Han
> > Chinese and all other minority languages used in China.
> 
> Preferring to use Unicode does seem to be the direction that all of
> computing is going in, as a simplifying assumption - for example W3C
> advice for HTML is "You should always use the UTF-8 character encoding"[1]
> - and as we know, things that aren't tested usually don't work. So I
> think the level of functionality for non-UTF-8 locales and encodings in
> the software we package is going to decline over time, whether Debian
> wants it to or not.

It is true for everything. Users know how to pick the software that works for 
their
environment. It is not relevant that software they do not use do not support 
their
environment.

Telling users to switch to UTF-8 because such and such software they never used
and were never going to use do not support GB18030 does not make sense.

It is like saying the Linux console is deprecated because there are Debian
packages that requires X or Wayland.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Bill Allombert]

On Wed, Jan 04, 2023 at 07:13:04PM +0100, Santiago Vila wrote:
> El 4/1/23 a las 18:23, Sam Hartman escribió:
> > I think that the
> > cost of going and adding all the build-depends on
> > required-but-not-build-essential is not worth what I estimate we'd gain
> > from having this extra information.
> 
> I think you can't really estimate such thing. You seem to imply that we have
> been allowing packages with missing build-dependencies for a long time, but 
> that's
> not accurate. The *buildds* have been allowing packages with missing 
> build-dependencies
> for a long time, but I have been reporting those bugs for a long time as well.
> 
> So it's not as if I were proposing that we start doing something that we have 
> never done.
> My only aim is that we detect such bugs earlier in the chain, in the buildds, 
> where it should be.
> 
> BTW: Today I reported that kodi did not build without tzdata. But in the end
> this was not a missing build-dependency of kodi, but a missing *binary* 
> dependency
> of one of the build-dependencies of kodi.

So is there a service that detect such missing *binary* dependency ?
This seems the missing piece. 

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Bill Allombert]

On Wed, Jan 04, 2023 at 08:46:39AM +0100, Santiago Vila wrote:
> El 4/1/23 a las 2:32, Sam Hartman escribió:
> > > > > > > "Santiago" == Santiago Vila  writes:
> > 
> >  Santiago> As an example, packages tzdata, mount or e2fsprogs are not
> >  Santiago> build-essential and afaik have not been for a long time,
> >  Santiago> but there are still people who believe that they are
> >  Santiago> build-essential for the mere fact that they are
> >  Santiago> priority:required.
> > 
> > Why not just make all required packages build-essential?
> > I agree we should fix the class of bugs you are talking about, but it
> > seems like in some cases it might be easier to fix them by declaring
> > them not buggy.
> 
> Because required to build != required in a _running_ system

At minimum, it should not be allowed to Build-Conflicts with a required package.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Bill Allombert]

On Wed, Dec 21, 2022 at 03:23:09PM +0100, Adam Borowski wrote:
> On Mon, Dec 19, 2022 at 10:44:12PM +0100, Bill Allombert wrote:
> > Which raise the question: does the corresponding user group moved to UTF-8 ?
> > Judging from <https://en.wikipedia.org/wiki/Chinese_character_encoding>,
> > neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
> > so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.
> 
> We actually do have data about locale usage in Debian.
> I've copied .report files from bugs-mirror, and
> grep -arm1 ^Locale: */*/*.report
> shows that:
> * most recent use of BIG5 is #925894 from March 2019
> * there's no use of any GB locale (other than en_GB :p) past #609517 (2011)
> * for EUC there's #1001207 (2021) #953616 #939588 #939494 #893625

I do not think bug submitters expect the Locale field to be used for locale
usage statistics, so it does not seem fair to use it for that purpose.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Bill Allombert]

On Mon, Dec 19, 2022 at 07:08:09PM +, Simon McVittie wrote:
> On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote:
> > As of Bookworm, legacy locales are no longer officially supported.
> 
> For clarity, I think when you say "legacy locales" you mean locales
> whose character encoding is either explicitly or implicitly something
> other than UTF-8 ("legacy national encodings"), like en_US (implicitly
> ISO-8859-1 according to /usr/share/i18n/SUPPORTED) and en_GB.ISO-8859-15
> (explicitly ISO-8859-15 in its name). True?
> 
> Many of the non-UTF-8 encodings are single-byte encodings in the
> ISO-8859 family, but if I understand correctly, your reasoning applies
> equally to multi-byte east Asian encodings like BIG5, GB18030 and EUC-JP.
> Also true?
> 
> Meanwhile, locales with a UTF-8 character encoding, like en_AG
> (implicitly UTF-8 according to /usr/share/i18n/SUPPORTED) or en_US.UTF-8
> (explicitly UTF-8), are the ones you are considering to be non-legacy.
> Also true?

Which raise the question: does the corresponding user group moved to UTF-8 ?
Judging from ,
neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Bill Allombert]

On Fri, Dec 16, 2022 at 07:21:37PM +0100, Adam Borowski wrote:
> Package: debian-policy
> Version: 4.6.1.1
> Severity: wishlist
> 
> Hi!
> As of Bookworm, legacy locales are no longer officially supported.  In order
> to not break testsuites, they're mostly working if you install locales-all,
> and you may manually request their generation by editing /etc/locale.gen --
> but functionality is expected to bit rot and/or be removed in the future.

Hi Adam,

How do you define a legacy locale ?
What do you mean by "officially supported" ?  By whom ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[Bill Allombert]

On Fri, Nov 18, 2022 at 02:14:32PM +0100, Enrico Zini wrote:
> Package: debian-policy
> Version: 4.6.1.1
> Severity: normal
> 
> Hello, and thank you for maintaining the Policy!
> 
> Policy paragraph 4.9.1 has an example debian/rules which contains these
> lines:
> 
>INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
> 
>ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
>INSTALL_PROGRAM += -s
>endif
> 
> However, paragraph 10.1 recommends against it:
> 
>It is not recommended to strip binaries by passing the "-s" flag to
>"install", because this fails to remove .comment and .note sections,
>and also prevents the automatic creation of dbgsym binary packages by
>tools like "dh_strip".
> 
> I would personally prefer if the example built on debhelper. If the
> intention is to show what are the expectations at a lower level then
> I wish the example had a comment saying "This snippet serves to explain
> what are the expectations as a lower level. You usually want to use
> debhelper instead"

I know it is not what you are after, but maybe it is time to fix install -s ?

dh_strip only work if the upstream 'make install' did not already
strip the binaries by using install -s itself. So packagers need to work
around it each time.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Bill Allombert]

On Tue, Aug 16, 2022 at 07:22:21AM -0600, Sam Hartman wrote:
> > "Bastien" == Bastien Roucariès  writes:
> Bastien> I will like to stress that this kind of stuff is bad:
> Bastien> 
> https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec-
> Bastien> support.preinst.in#L10
> 
> How would you do better in that instance?
> I think everyone knows it's bad, but I'm guessing that the maintainer
> didn't have a better approach for detecting whether the referenced
> instructions worked on the installed system.
> 
> I'm assuming that if feature tests in /proc/cpuinfo were sufficient they
> would have been used.

What if the user change their CPU afterward ?
This should probably be tested at boot time instead.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#940234: debian-policy: add a section about source reproducibility

[Bill Allombert]

On Mon, Jun 20, 2022 at 07:43:45PM +0700, Teukumif tahulziran wrote:
> On Sat, 14 Sep 2019 13:34:49 +0200 Aurelien Jarno 
> wrote:
> > Package: debian-policy
> > Version: 4.4.0.1
> > Severity: wishlist
> >
> > There is already a section about reproducibility in the debian-policy,
> > but it only mentions the binary packages. It might be a good idea to
> > add a new requirement that repeatedly building the source package in
> > the same environment produces identical .dsc file modulo the GPG
> > signature.
> >
> > I haven't checked how many packages do not fulfill this condition, but
> > there are for sure packages where the Build-Depends: entry in the dsc
> > file does not match the debian/control file, as they have been added
> > manually after the package build. TTBOMK there is nothing preventing
> > that in the debian policy.

What about the fact that .dsc include the hash of the .debian.tar.xz
file that contains the debian/control, so changing debian/control
invalidate the hash ?

Cheers,
Bill

Bug#986320: Stronger advice on when to use native packages

[Bill Allombert]

On Tue, May 10, 2022 at 08:32:32AM -0600, Sam Hartman wrote:
> > "Holger" == Holger Levsen  writes:
> I'd much rather upload  a 50M package regularly than deal with the vcs
> complexity of separate maintainer and upstream releases in a lot of
> cases.
> 10 years ago sure, that would have been annoying for me, but these days
> with modern networks 50M is not a big deal.
> 
> Granted not everyone has a fast network.
> 
> If there is a consensus that the upstream source split is important for
> large packages, it is fairly rough.
> I'd definitely like to call that consensus into question and suggest
> that it's unclear whether it exists.
> It may; my opinion on this issue is definitiely on one side, and that
> would make me a poor choice to judge the consensus here.
> However, I don't want us to move forward assuming that consensus exists
> without actually exploring it.

There cannot be any consensus because "native pakages" cover widely
different packages and situation, and anyone has in mind their own
situation, and there are no general rules.

I expect most developers do not maintain any "native pakages",
and for a minority, this is the opposite, almost all their
packages are native. 

For me it is a mixed bag, with packages that "obviously" should be
native, other that should not and some other it could go both way.

tl;dr: natives packages are too diverse to be covered by a single rule.
Sometime we should trust maintainer good judgement since they are the
one that are the most impacted.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1004522: debian-policy: Proposing new virtual packages: wayland-session, x-session

[Bill Allombert]

On Sun, Jan 30, 2022 at 02:18:51PM +, Simon McVittie wrote:
> On Sat, 29 Jan 2022 at 20:12:21 +, Simon McVittie wrote:
> > I propose this entry for virtual-package-names-list.yaml:
> > 
> > - name: wayland-session
> >   description: a Wayland desktop session 
> > (/usr/share/wayland-sessions/*.desktop)
> 
> Having looked more closely at display managers, I think we should also
> consider adding:
> 
> So I think x-display-manager implementations in category 2 should be
> depending on [their preferred session] | wayland-session | x-session
> (omitting wayland-session if they are X11-only), perhaps with
> x-session-manager as an additional alternative for backwards compatibility.

For X at least, the X session might be running on a different host so
requiring a x-session package to be installed locally is not helpful.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

[Bill Allombert]

On Mon, Jan 31, 2022 at 10:13:19AM +0100, Stephan Lachnit wrote:
> On Sun, Jan 30, 2022 at 3:55 PM Andrei POPESCU  
> wrote:
> >
> > On Du, 30 ian 22, 13:21:40, Stephan Lachnit wrote:
> > >
> > > I like the idea. Just another idea for the naming, about
> > > wayland-desktop-session?
> >
> > It's longer and Phosh is not exactly a "desktop" ;)
> 
> Right, but then the description "a Wayland desktop session" and the
> file location (/usr/share/wayland-sessions/*.desktop) is also a bit
> off, right? I guess this depends on how one defines "desktop" ;)
> 
> Actually, just out of curiosity: the folder is called
> "wayland-sessions", but the files are all called "*.desktop". Are
> there other possibilities than "*.desktop", and if so what is the
> difference?

.desktop is just a standard file format used to register applications
with desktop environment, see


I prefer wayland-session over wayland-desktop-session.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[Bill Allombert]

On Fri, Jan 28, 2022 at 12:41:39PM +0100, Andreas Tille wrote:
)
> > > I personally would rather think that excluding files from the upstream
> > > source is a pretty good reason to make DEP5 mandatory *for these cases*.
> > > Besides a sensible way of documentation it saves maintainer time to
> > > simply use uscan to obtain a proper tarball.
> > 
> > The issue is that mk-origtargz does not actually need any field from
> > DEP5, it only needs the extra fields it specifies.
> 
> I can't parse this.  Do you mean `man mk-origtargz` is reading fields
> that are not mentioned in DEP5.  I'd say DEP5 is just older than
> Files-Excluded and the good thing about DEP5 is that it *enabled* other
> tools to parse those fields.

mk-origtargz ignore all the fields that are currently
mentionned in DEP5. The only fields that are used are the ones it
introduces. So in that sense it is not an application of DEP5.

> What I'm actually imagine is that the time I need to write this kind of
> mails I could perfectly use to convert 2-3 d/copyright files from old
> format to DEP5.  And now I'm wondering why I'm not doing so ...

Do not slow down on my account!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[Bill Allombert]

On Fri, Jan 28, 2022 at 09:08:17AM +0100, Andreas Tille wrote:
> Hi,
> 
> > It should be possible to use it with the plain old copyright format too,
> > otherwise we are kind of renegating on our promise that the machine
> > readable copyright format be optionnal.
> 
> Did we ever promised this? 

Yes we did.

> I personally would rather think that excluding files from the upstream
> source is a pretty good reason to make DEP5 mandatory *for these cases*.
> Besides a sensible way of documentation it saves maintainer time to
> simply use uscan to obtain a proper tarball.

The issue is that mk-origtargz does not actually need any field from
DEP5, it only needs the extra fields it specifies. It would be more
sensible for mk-origtargz to get this information from debian/watch
or debian/mk-origtargz.

While the new copyright format is part of the policy package, it is
a separate specification and is not intented for package to put
configuration information there.

>From the point of view of binary package, the information is quite often
meaningless since there is not explanation why a file was removed,
files that are removed are often regenerated at built time and shipped
and the file not removed from the source might still not be shipped in
any binary package generated from it. Important feature removal should
rather be documented in README.Debian.

So it is quite sufficient for this data to be in the source package
only.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

[Bill Allombert]

On Thu, Jan 27, 2022 at 02:52:18PM -0700, Sean Whitton wrote:
> Hello Joe,
> > +  
> > +These types of files, or any others that Debian does not want to
> > +include in our archive, must be stripped from the upstream tarball
> > +prior to uploading. The Files-Excluded field 
> > serves

This feature is orthogonal to the machine readable copyright format.

It should be possible to use it with the plain old copyright format too,
otherwise we are kind of renegating on our promise that the machine
readable copyright format be optionnal.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1002626: debian-policy: building packages should not require to be root

[Bill Allombert]

On Sat, Dec 25, 2021 at 10:38:47PM +0100, Vincent Lefevre wrote:
> Package: debian-policy
> Version: 4.6.0.1
> Severity: important
> 
> Building packages should not require to be root.

Hello Vincent!

Currently, packages are allowed to require root to build.
See Rules-Requires-Root for more detail.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Question on the use of "/nonexistent"

[Bill Allombert]

On Sat, Dec 18, 2021 at 12:51:56PM -0500, Jason Franklin wrote:
> Greetings:
> 
> I am a developer who is new to making contributions to Debian.  Most of
> my work so far has been focused on making improvements to the "adduser"
> package.  Of course, bug triage is one of the first things on which I am
> trying to show progress.
> 
> On the relevant BTS page, I came across this bug:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152195
> 
> A summary of this bug is below...
> 
>   # adduser --system --no-create-home foo
>   # getent passwd foo
>   foo:x:130:65534::/home/foo:/usr/sbin/nologin
> 
> As you can see, "/home/foo" is named as the new user's home directory,
> but that directory is not created due to the "--no-create-home" option.
> 
> This was reported many years ago and was given the "wontfix" tag.  I
> believe this should be reversed since Debian policy now has this to
> say...
> 
>   
> https://www.debian.org/doc/debian-policy/ch-opersys.html#non-existent-home-directories
> 
> I hope to see that, whenever possible, the "adduser" tools conform to
> Debian Policy when managing the addition and removal of users and
> groups.

This seems to be a misunderstanding of the purpose of --no-create-home.
This option does not say that the user does not have a home directory,
but that it should not be created by adduser, and instead will be create
later by some other procedure, for example by setting pam_mkhomedir
to create it on first login, or by mounting a NFS filesystem on /home,
etc.

In this bug report, users used --no-create-home but failed to create the
home directory themselves.
It seems that what they wanted to do was '--home /nonexistent'

I would suggest you add an option --no-homedir that do '--home /nonexistent'
or whatever is appropriate and close this bug.
Or you can close this bug without adding a new option. It mostly have
hostorical value now.

Cheers,
Bill.

Bug#999826: debian-policy: fix Build-Depends footnote

[Bill Allombert]

On Sat, Nov 20, 2021 at 01:24:28PM +, Holger Levsen wrote:
> On Wed, Nov 17, 2021 at 03:11:55PM +0100, Johannes Schauer Marin Rodrigues 
> wrote:
> > > This footnote might not be the best place to document the precise 
> > > behaviour
> > > of autobuilders (which currently is outside the scope of policy). On the
> > > other hand, having a fully specified build process could reduce build
> > > variability and make builds more reproducible.
> > Do you have suggestions for a better place to document this?
> 
> src:developers-reference maybe? with a pointer to it in -policy?

We need the input of the people on charge of writing the autobuilders
code.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#999826: debian-policy: fix Build-Depends footnoteo

[Bill Allombert]

On Wed, Nov 17, 2021 at 01:31:33PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Bill Allombert (2021-11-17 13:06:09)
> > > 1. "they are not normally used by the Debian autobuilders" should instead
> > >be "they are never used by the Debian autobuilders" or it should state
> > >when they are used and when they are not
> > 
> > If the base system on top of which the build-dependencies are to be
> > installed already include one of the alternative then it is used in
> > preference to the others.
> 
> But this is not what happens on the buildds. Sbuild munges all alternatives in
> B-D, B-D-I and B-D-A irrespective of the packages that are already installed
> and only passes the resulting meta-package to apt which cannot know anymore of
> the original alternatives.

... but it does not remove the already installed alternatives,
so the Alternative is not used even though the alternative package is
installed ?

This footnote might not be the best place to document the precise
behaviour of autobuilders (which currently is outside the scope of
policy). On the other hand, having a fully specified build process
could reduce build variability and make builds more reproducible.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#999826: debian-policy: fix Build-Depends footnoteo

[Bill Allombert]

On Wed, Nov 17, 2021 at 11:10:54AM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Source: debian-policy
> Version: 4.6.0.1
> Severity: normal
> X-Debbugs-Cc: jo...@debian.org
> 
> Hi,
> 
> currently, footnote [1] of §7 states:
> 
> > While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit
> > the use of alternative dependencies, these are not normally used by the
> > Debian autobuilders. To avoid inconsistency between repeated builds of a
> > package, the autobuilders will default to selecting the first
> > alternative, after reducing any architecture-specific restrictions for
> > the build architecture in question. While this may limit the usefulness
> > of alternatives in a single release, they can still be used to provide
> > flexibility in building the same package across multiple distributions
> > or releases, where a particular dependency is met by differently named
> > packages.
> 
> There are multiple problems with this footnote:
> 
> 1. "they are not normally used by the Debian autobuilders" should
>instead be "they are never used by the Debian autobuilders" or it
>should state when they are used and when they are not

If the base system on top of which the build-dependencies are to be
installed already include one of the alternative then it is used in
preference to the others.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Bill Allombert]

On Sun, Oct 31, 2021 at 11:18:35AM +0100, Mattia Rizzolo wrote:
> Package: debian-policy
> Version 4.6.0.0
> 
> Hi!
> 
> dpkg 1.19.0 introduced, following the request in #555743, a bunch of new
> substvars.  Notably, it now handles ${source:Synopsis} and
> ${source:Extended-Description} that are described as follow:
> 
>source:Synopsis
>The source package synopsis, extracted from the source stanza
>Description field, if it exists
> 
>source:Extended-Description
>The source package extended description, extracted from the
>source stanza Description field, if it exists
> 
> 
> Currently Policy §5.2 lists the allowed known fields, and Description is
> accepted only in the "binary package paragraphs", not in the one for the
> source package.
> 
> 
> As documented in the bug report mentioned above, these are the main
> benefits of having a Description in the source paragraph:
>  * helps de-duplicate the description in the binary paragraphs (mostly
>relevant for libraries and other packages that build many binaries
>and share a common description).  Note that this would only
>de-duplicate d/control, the binary DEBIAN/control of each binary
>package would still keep the generated long description.
>  * ship a generic source-level descrption of the package, which just
>make sense if one thinks about it
>  * as a consequence of the above, a bunch of tools (DDPO, PTS, etc)
>would be able to drop the weird and unnatural logic that they use to
>pick a description for the source package
> The main "bad" consequence would be that Description would be exported
> in the .dsc and as such end up in the Sources index.  This is probably
> what we want anyway, but with all the people complaining about how big
> the index is getting it's something to consider.  However it's also true
> that realistically very few packages are going to make use of this
> facility in the near future so it shouldn't really matter IMHO.

Could you clarify what source packages that produce several binary
packages should do ? Maybe give an example ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Bill Allombert]

On Fri, Aug 13, 2021 at 08:10:57AM -0700, Felix Lechner wrote:
> Hi,
> 
> On Fri, Aug 13, 2021 at 12:57 AM Bill Allombert  wrote:
> >
> > Is there some new external factor that make any unaddressed lintian
> > warnings problematic ?
> 
> That may go beyond the scope of the present discussion, but yes:
> First, Lintian packaging hints are always viewed as imperfections;
> contributors strive to make their packages "Lintian-clean". Second, we
> now offer performance measures that will eventually help to improve or
> drop tags people find "noisy," i.e. those with a high rate of false
> positives. Here is an example for a tag that, being 95% accurate,
> works well. [1] The tag 'outdated-standards-version' operates
> completely outside of that paradigm. It always is, and forever will
> be, noisy.

Then I would suggest that a new lintian category is designed to catter
for such usage, so that tools might chose not to display such warnings
as they do with 'P: pedantic' currently.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Bill Allombert]

On Thu, Aug 12, 2021 at 06:17:18PM -0700, Felix Lechner wrote:
> Finally, please allow me to add some powerful statistics to the
> record. The tag 'out-of-date-standards-version' currently occurs in
> 10,813 source packages in the archive (out of about 33,000). [7] It is
> an incident ratio of 33%.

For what is worth, I do not see that as a problem.
Standards-Version indicates to what standards debian/rules was coded to.
Given the way Debian is updated, it is expected that most packages will
have out of date Standards-Version.

Is there some new external factor that make any unaddressed lintian
warnings problematic ? They need to be brought in the discussion.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#990822: debian-policy: Please document version scheme for derivatives

[Bill Allombert]

On Thu, Jul 08, 2021 at 05:11:45PM +0200, Benjamin Drung wrote:
> Package: debian-policy
> Version: 4.5.1.0
> Severity: wishlist
> 
> Hi,
> 
> Paragraph 5.6.12. Version describes the version parts epoch,
> upstream_version, and debian_revision. But it does not describe how to
> use the Debian revision in Debian itself and in derivatives like Ubuntu.
> 
> To make packages in derivatives work seamlessly with Debian, I propose
> following scheme (which is used in Ubuntu, in-house, and by me
> personally):
> 
> The derivative selects a name for using in the debian_revision (e.g.
> Ubuntu uses "ubuntu", we use "ionos" in-house, and I use "bd" for
> personal builds). Then following rules apply:
> 
>  * no change in the package version when using the source package
>unmodified (e.g. 1.2-3)

This one is slightly annoying because it leads to two different binary
packages with identical filenames.

...

> Is the Debian policy the correct place to document that?

This is the issue. Of course policy can document what it wants, but it
does not have authority over non-Debian projects.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#989581: autopkgtest: ADTTMP is now obsolete

[Bill Allombert]

On Mon, Jun 28, 2021 at 03:20:04PM -0700, Sean Whitton wrote:
> control: tag -1 + pending
> 
> Hello Fabrice,
> 
> On Mon 07 Jun 2021 at 11:53PM +02, Fabrice BAUZAC wrote:
> 
> > autopkgtest.md only mentions the ADTTMP environment variable, while
> > lintian marks ADTTMP usage as deprecated in favour of AUTOPKGTEST_TMP.
> >
> > See https://lintian.debian.org/tags/uses-deprecated-adttmp
> >
> > I think autopkgtest.md should at least mention the new variable...
> 
> Thank you for this.  I've committed a fix -- I just changed the variable
> name rather than using your patch, if you don't mind, because it seemed
> unnecessary to me to mention the old name at all.

Maybe add it to the upgrading-checklist.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#983657: debian-policy: weaken manual page requirement

[Bill Allombert]

On Sun, Feb 28, 2021 at 08:58:44PM +0100, Helmut Grohne wrote:
> On Sun, Feb 28, 2021 at 10:53:20AM -0700, Sean Whitton wrote:
> > Can you post a patch just doing the moving manpages to dependencies part
> > and indicate that you are seeking seconds?  Then we can get that
> > applied.
> 
> I call for seconds on:
> 
> --- a/policy/ch-docs.rst
> +++ b/policy/ch-docs.rst
> @@ -12,9 +12,9 @@
>  "cat page".
>  
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> -configuration files also have a manual page included as well. Manual
> -pages for protocols and other auxiliary things are optional.
> +page included in the same package or a dependency. It is suggested that
> +all configuration files also have a manual page included as well.
> +Manual pages for protocols and other auxiliary things are optional.
>  
>  If no manual page is available, this is considered as a bug and should
>  be reported to the Debian Bug Tracking System (the maintainer of the

What matter, I think, is that if a program is installed, then its manual
is available. There are various ways to achieve that, even though I do
not think Recommends cut it.

Cheers,
Bill

Bug#983657: debian-policy: weaken manual page requirement

[Bill Allombert]

On Sun, Feb 28, 2021 at 08:29:21AM +0100, Helmut Grohne wrote:
> So this is actually asking for two distinct things:
>  * Allow moving manual pages to dependencies
>  * Allow demoting such dependencies to recommends
> 
> A possible wording in ch-docs.rst could be:
>  Each program, utility, and function should have an associated manual
> -page included in the same package. It is suggested that all
> +page included in the same package or one of its dependencies or
> +recommended packages. It is suggested that all
>  configuration files also have a manual page included as well. Manual
>  pages for protocols and other auxiliary things are optional.
> 
> What do you think?

The goal is to avoid program to be installed but not their manpages,
so generally I do not find Recommends to be enough.
I would object to manual page being moved to a -doc package even if they
are Recommended, because -doc packages tend to be large while manpages
are usually short and do not require pdf/html readers.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#980069: Better documentation of x-terminal-emulator

[Bill Allombert]

On Wed, Jan 13, 2021 at 10:49:27PM +, Bastien Roucariès wrote:
> Package: debian-policy
> Version: 4.5.0.0
> Severity: important
> affects: sensible-utils
> control: block -1 by 874019
> 
> Hi,
> 
> x-terminal-emulator documentation is incomplete.
> For instance the behavior of the -e option is different between xterm and 
> gnome-terminal:
> try:
> gnome-terminal -e sleep 60
> xterm -e sleep 60

Note that what policy documents is the minimal requirement for a package
to provide the x-terminal-emulator alternative.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Thu, Dec 31, 2020 at 04:42:46PM -0500, David Steele wrote:
> > Second seconds request.

> I'm not aware of any other inputs expected of me.

What Sean meant is that, at this stage, this proposal needs to be
seconded by people impacted by this virtual package before being
accepted.

If you know any, you can ask them, this would speed up the process.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Bill Allombert]

On Wed, Dec 09, 2020 at 06:30:12PM +0100, Bill Allombert wrote:
> > I disagree. The two packages provide the same functionality - the ability
> > to add, remove, modify and display todo lists. Alternatives routinely offer
> > different option sets and commands.
> 
> /usr/bin/todo is not registered as an alternative by devtodo,
> so you cannot register it as an alternative in another package.
> The conflict between devtodo and topydo is not justified.
> 
> > I would have preferred a discussion on #976402 in advance of an RC bug
> > report.
> 
> Sorry, policy does not work that way. A policy proposal never delays a RC bug.

I realise my answer might have been a bit brutal, sorry about that.

Your proposal made us uncomfortable because you seemed to conflate the
introduction of a new policy-sanctioned virtual package and the
introduction of a new alternative.

They are related but different. In particular policy is supposed to
document usage, that is virtual packages that are effectively in use.

Introducing an alternative requires at least the agreement of all the
maintainers of packages that are supposed to provide the alternative
and to provide backward compatibility.

In this instance, it can be argued that /usr/bin/todo is a bit too
generic a name to be used by a single package binary.

However this can only be changed after devtodo has provided a migration
path to another name.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Bug#976902: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Bill Allombert]

On Wed, Dec 09, 2020 at 12:00:23PM -0500, Dave Steele wrote:
> On Wed, Dec 9, 2020 at 3:54 AM Ansgar  wrote:
> 
> > Package: topydo
> > Version: 0.13-5
> > Severity: serious
> >
> > Example use of `todo` from devtodo:
> >
> > +---
> > | Add a task, like so:
> > |
> > | $ todo -a I should really update my homepage
> > |
> > | List all open tasks:
> > |
> > | $ todo
> > |
> > | Mark a task as complete:
> > |
> > | $ todo -d 1.2
> > +---[ https://swapoff.org/devtodo1.html ]
> >
> > Example use of `topydo`:
> >
> > +---
> > | topydo add "Water the flowers @Home rec:1w"
> > | topydo ls
> > | topydo do 2
> > +---[ https://github.com/topydo/topydo ]
> >
> > But postinst registers topydo as an alternative for /usr/bin/todo.
> >
> > Debian Policy[1] requires binaries with the same name to provide the
> > same functionality; given the command-line interfaces are
> > incompatible, this doesn't seem to be the case here.
> >
> > I've reported this bug against topydo as it seems to just have taken
> > over the name, but already has topydo and wouldn't need to take over
> > the todo binary.
> >
> > Ansgar
> >
> >   [1]: https://www.debian.org/doc/debian-policy/ch-files.html#binaries
> 
> I disagree. The two packages provide the same functionality - the ability
> to add, remove, modify and display todo lists. Alternatives routinely offer
> different option sets and commands.

/usr/bin/todo is not registered as an alternative by devtodo,
so you cannot register it as an alternative in another package.
The conflict between devtodo and topydo is not justified.

> I would have preferred a discussion on #976402 in advance of an RC bug
> report.

Sorry, policy does not work that way. A policy proposal never delays a RC bug.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 06:23:44PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 6:21 PM David Steele  wrote:
> 
> >
> > On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert  wrote:
> >
> >>
> >> Are people using /usr/bin/todo in script or Makefile ?
> >> Are they likely to still work with the alternatives ?
> >>
> >
> > I'd say no. It is an interactive end-user command.
> >
> > This gives flexibility in what they are interacting with.
> >
> 
> This is no more of a stretch than "vi" implementing "editor".

Note that even in this case there is a minimal common interface required
so that programms can call '/usr/bin/editor file' to let the user edit
'file'.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 05:12:13PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 4:42 PM Bill Allombert  wrote:
> 
> > On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote:
> > > On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert 
> > wrote:
> > >
> > > > Do you envision to have packages depending on todo and then use the
> > > > todo binary ?
> > > >
> > >
> > > No. This is a means to allow topydo and todotxt-cli to use "todo" without
> > > crowding devtodo. I believe this meets the definition of a virtual
> > package
> > > in the Policy.
> >
> > I am not use I understand. Do you plan for /usr/bin/todo to be managed by
> > update-alternatives ? That would require all alternatives to share a common
> > interface.
> >
> 
> The guidance in the Policy is that alternatives "offer more-or-less the same
> functionality". I believe this standard is met.

Are people using /usr/bin/todo in script or Makefile ?
Are they likely to still work with the alternatives ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert  wrote:
> 
> > What about devtodo ?
> >
> > Reading your summary, it seems that the todo.txt virtual package
> > is well specified, but the todo one is not.
> >
> > Do you envision to have packages depending on todo and then use the
> > todo binary ?
> >
> 
> No. This is a means to allow topydo and todotxt-cli to use "todo" without
> crowding devtodo. I believe this meets the definition of a virtual package
> in the Policy.

I am not use I understand. Do you plan for /usr/bin/todo to be managed by
update-alternatives ? That would require all alternatives to share a common
interface.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 12:40:01PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 12:30 PM Bill Allombert  wrote:
> 
> >
> > Does all theses tools provide an compatible interface ?
> > In other word, are there interoperable ?
> 
> Yes, topydo and todotxt-cli support common commands, which make them
> interoperable for most uses. However, the command sets are not identical.

Then the virtual package definition should specify that common commands
be supported.

What about devtodo ?

...

Reading your summary, it seems that the todo.txt virtual package
is well specified, but the todo one is not.

Do you envision to have packages depending on todo and then use the 
todo binary ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 12:15:06PM -0500, David Steele wrote:
> Package: debian-policy
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org, charlesmel...@outlook.com,
>   on...@debian.org
> thanks
> 
> 
> I'd like to propose adding the virtual packages "todo" and "todo.txt" to
> the authoritative list of virtual package names. I'm submitting this per
> Policy section 3.6 and the preamble to the [authoritative list].
> 
> [Todo.txt] describes an ecosystem of task management tools that revolve
> around a standard for a freeform-text tasking file.
> 
> The reference cli has been packaged for some time, as "todotxt-cli". It
> provides the executable "todo-txt".
> 
> An alternative cli provider, "topydo", has been recently added, adding
> an executable by the same name.
> 
> I propose uniting this packages using the name "todo" - the common name
> for the utility. Since not all todo list packages that may want to share
> that name conform to the todo.txt standards, I also propose "todo.txt",
> a strict subset of "todo", for packages which conform.
> 
> Note that topydo already implements these virtual packages, and that
> there now exists a todo.txt-base packages that extends cli todo.txt
> capabilities. There is also a todo.txt-cli package in Sid. This is
> redundant, and has a pending RM request.
> 
> I did a screen scrape of p.d.o to find any possible collisions for these
> names. There is a single package, devtodo (popcon 74, recently ITA'd),
> that installs a "todo" executable. Currently, topydo Conflicts with this
> package. I'd propose adding it to the "todo" virtual package.
> 
> This is a request for comment per the procedure in the list.

Does all theses tools provide an compatible interface ?
In other word, are there interoperable ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#975250: clarify gathering together of copyright information

[Bill Allombert]

On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote: > > "Russ" == 
Russ Allbery  writes:
> 
> Russ> That said, I tend to be hyper-conservative and nit-picky about
> Russ> things like this, accurately representing copyright years
> Russ> isn't in my top thousand things I want people to work on in
> Russ> Debian, and I'm highly dubious that it will ever matter or
> Russ> anyone will ever care.  So I'm very open to being told I'm
> Russ> being much too cautious.
> 
> On the compromise front, how would people feel about leaving the gap
> years question ambiguous in policy?

Let us be honest with ourselves: what matter for most purpose
is the position of the ftp-master team that processes the NEW queue.
What policy says is secondary.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted

[Bill Allombert]

On Mon, Nov 30, 2020 at 02:37:08PM +0100, Oxan van Leeuwen wrote:
> Source: debian-policy
> Version: 4.5.1.0
> Severity: normal
> 
> Currently Policy requires that init.d scripts, and only init.d scripts, don't 
> fail if the corresponding /etc/default is removed (section 9.3.2, 
> second-to-last 
> paragraph).
> 
> Personally I interpret "not fail" as "succeed to function", i.e. it has to 
> actually start the daemon. I don't think that's a particularly sensible 
> requirement.

'not fail' here means that the script terminates with return code 0.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Bill Allombert]

On Tue, Nov 24, 2020 at 01:37:53PM +0100, Ansgar wrote:
> Package: debian-policy
> Version: 4.5.1.0
> Severity: normal
> 
> After a discussion in #-devel today I reviewed packages using other
> choices of "Rules-Requires-Root" than "no" and "binary-targets".  The
> query [1] found two uses:
> 
> - wfrench 1.2.6-1.  This could just use "no"; a bug was filed[2].
> 
> - libcap2 1:2.44-1.  Uses it for running tests as root, but doesn't support
>   fakeroot anyway.  Rules-Requires-Root can't however communicate this so
>   additional knowledge is needed.
> 
> The complexity to support arbitrary additional keywords as choices of
> R³ seems overkill given there is just one real user (libcap2) and the
> current R³ specification doesn't handle that usecase fully either.
> 
> Therefore I suggest to deprecate using R³ values other than "no" and
> "binary-targets" within Debian.

What about 'Rules-Requires-Root: yes' ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#954794: New packages must not declare themselves Essential

[Bill Allombert]

On Thu, Oct 15, 2020 at 11:56:19AM -0700, Jonathan Nieder wrote:
> Javier Serrano Polo wrote:
> > On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder 
> > wrote:
> 
> >> Even so, some *rough* consensus on the plan is very useful for
> >> helping people evaluate that first step.
> >
> > Here is a rough plan:
> >
> >1. Policy: Packages should declare all their dependencies, even
> >   essential ones.
> 
> I agree: this is the right first step.
> 
> More specifically, it's the right first three steps.
> 
> https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies
> currently says
> 
>   Packages are not required to declare any dependencies they
>   have on other packages which are marked Essential (see below),
>   and should not do so unless they depend on a particular
>   version of that package.[4]
> 
>   [4] [...] If packages add unnecessary dependencies on packages
>   in this set, the chances that there will be an unresolvable
>   dependency loop caused by forcing these Essential packages to
>   be configured first before they need to be is greatly
>   increased.
> 
> I'd propose that as a first step we change that to
> 
>   Packages are not required to declare any dependencies they
>   have on other packages which are marked Essential (see below),
>   but are permitted to do so even if they do not depend on a
>   particular version of that package.[4]

This is very dangerous with respect to upgrade between stable releases.
The issue is at the time a package is made for a stable release, the
state of Debian and Essential: yes packages is not known. It is
unrealistic to expect Debian to plan so far in advance.
Requiring changes to Essential packages to take into account spurious
dependencies is too fragile.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#970234: consider dropping "No hard links in source packages"

[Bill Allombert]

On Tue, Oct 13, 2020 at 09:44:42AM -0400, Sam Hartman wrote:
> > "Giacomo" == Giacomo Catenazzi  writes:
> 
> Giacomo> The rationale was probably similar so symlinks: they may
> Giacomo> fail across different filesystems, and we supported to have
> Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
> Giacomo> /home /tmp /boot etc on different file systems. Now we are
> Giacomo> more strict on where we can split filesystems (and disk are
> Giacomo> larger, and LVM simplified much of filesystem handling).
> 
> But I think even in 1996, we anticipated a single source package
> (*source package*) being unpacked on a single filesystem.
> Perhaps we were worried about filesystems like umsdos?

It is good to see I am not the only one left who remember about umsdos!

I am pretty sure we were concerned about source packages being
unpackable on non Debian systems, though.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

[Bill Allombert]

On Tue, Aug 04, 2020 at 02:15:59PM +0200, Ansgar wrote:
> Package: debian-policy
> 
> Hi,
> 
> 10.9 Permissions and owners currently says
> 
> | Files should be owned by root:root, and made writable only by the
> | owner and universally readable (and executable, if appropriate),
> | that is mode 644 or 755."
> 
> However most files shouldn't be modified as modifications will just be
> lost (e.g. everything installed by the package manager that isn't
> handled as a conffile).  It also gives more permissions than the
> minimum needed.

What about dpkg-divert ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Bill Allombert]

On Fri, Jun 12, 2020 at 09:09:22AM +, Holger Levsen wrote:
> hi,
> 
> I'm not fully sure if people really intend to change the 1.0 format, but if 
> so,
> I'm against it. If you do it, please call it 1.1 or whatever, but please don't
> change 1.0, too many tools rely on it's decade old behavior.
  
For what it is worth, Debian revisions with 1.0 native package were
allowed for a long time. so this is not a change to the 1.0 format.

> Besides that it's also my opinion that we should get rid off native packages
> completly, though that's yet another discussion. Native packages made sense
> when Debian had little or no downstreams, but...

I believe there are exceptions.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532

[Bill Allombert]

On Fri, Jun 05, 2020 at 04:35:54PM +0200, Adam Borowski wrote:
> On Fri, Jun 05, 2020 at 03:35:23PM +0200, Bill Allombert wrote:
> > On Fri, Jun 05, 2020 at 03:23:11PM +0200, Ansgar wrote:
> > > There is an updated version (RFC 5322) that should be used instead. 
> > > Notably RFC 5322 is more restrictive on the local part (whitespace and
> > > escape sequences are no longer allowed except as obsolete syntax).
> > > 
> > > Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in
> > > local parts (and other places).  That should probably be allowed as
> > > well.
> > > 
> > > So, Policy should probably:
> > >  - Refer to RFC 5322.
> > >  - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax").
> 
> > Are there packages actually using the obsolete syntax ? Can this be
> > checked by Lintian ?
> 
> Running Lintian on the whole archive is costly.

Sure. But a lintian test for this is probably required if we are going
to add it to policy.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532

[Bill Allombert]

On Fri, Jun 05, 2020 at 03:23:11PM +0200, Ansgar wrote:
> Package: debian-policy
> 
> 5.6.2 Maintainer currently states:
> 
> +---
> | The package maintainer’s name and email address. The name must come
> | first, then the email address inside angle brackets <> (in RFC822
> | format).
> |
> | If the maintainer’s name contains a full stop then the whole field
> | will not work directly as an email address due to a misfeature in the
> | syntax specified in RFC822
> +---
> 
> There is an updated version (RFC 5322) that should be used instead. 
> Notably RFC 5322 is more restrictive on the local part (whitespace and
> escape sequences are no longer allowed except as obsolete syntax).
> 
> Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in
> local parts (and other places).  That should probably be allowed as
> well.
> 
> So, Policy should probably:
>  - Refer to RFC 5322.
>  - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax").

Hello Ansgar,

Are there packages actually using the obsolete syntax ? Can this be
checked by Lintian ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#956818: developers-reference: contradictory information about removing packages from Incoming

[Bill Allombert]

On Wed, Apr 15, 2020 at 06:22:07PM +0200, Vincent Prat wrote:
> Package: developers-reference
> Version: 11.0.10
> 
> In section 5.6.1, it is mentioned that the dcut command can be used to
> remove packages from the upload queue.
> However, section 5.9.2.1 states that it is no longer possible to remove
> packages from incoming.
> This seems contradictory.

It is not. The upload queue and incoming are separate entities.
Package are uploaded to the upload queue, then the signature are checked
and they are moved to incoming.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.