Re: Reducing allowed Vcs for packaging?

[Adrian Bunk]

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.

Policy §5.6.26 says it is not permitted.

> 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.

One barrier is that our work is based around tarballs and quilt,
instead of using upstream git trees and commits.

> I would like to suggest removing the possibility to specify several systems 
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and 
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in 
> debian/control
> should be adapted to do the specified thing.

Policy §5.6.26 would be the primary definition you want to change.

Not using any Vcs for maintaining packages in Debian stays permitted, 
and I do not get your point what we would gain if the cvsd maintainer 
drops the Vcs-Cvs reference while continuing to maintain the package
in cvs.

In practice e.g. tracker.d.o seems to support Vcs-Bzr but not Vcs-Cvs,
and there is no requirement for tools to drop working support for
something that is no longer specified.

Vcs-Browser is Vcs agnostic and would stay permitted for any kind of Vcs,
including ones never listed in Policy.

> Thanks for any comments,
> Bastian

cu
Adrian

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Adrian Bunk]

On Thu, Sep 02, 2021 at 11:38:35PM +0100, Phil Morrell wrote:
>...
> 4. When 2 or 3 are too onerous to maintain, the package MAY use the
>convenience copy but MUST document why in README.source and SHOULD be
>included in the [security-tracker].
>...

  The package MUST be listed as being without security support in
  the debian-security-support package and the Release Notes,
  and it MUST NOT be installed as part of a default installation,
  unless the security team has explicitly agreed to support it.

If we are shipping software where Debian cannot provide security support,
then we shouldn't hide the problem from our users.

cu
Adrian

Re: severity of "fails to purge" issues

[Adrian Bunk]

On Sat, Jan 05, 2019 at 03:34:23PM +, Holger Levsen wrote:
>...
> There's also at least #918312 filed by Adrian Bunk.
> 
> The reasoning that these bugs will block migrations anyway sounds sound
> - except for new packages though!
>...

Are you sure about the latter?

For testing migration purposes salt (#918312) is new since it
was removed from testing in May.

(I only filed the bug after seeing #917116 and checking why salt
 did not migrate.)

> cheers,
>   Holger

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#915310: developer-reference: broken link to anonscm.debian.org

[Adrian Bunk]

reassign 915310 developers-reference 3.4.18
thanks

On Sun, Dec 02, 2018 at 06:28:40PM +0100, ydir...@free.fr wrote:
> Package: developer-reference
> Version: 3.4.18
> 
> We have a broken link in current master branch.  It also impacts stretch 
> (hence my selection of version).
> 
> developers-reference (master=)$ git grep anonscm.debian.org
> common.ent: "https://anonscm.debian.org/cgit/mirror/packages-arch-specific.git/tree/Packages-arch-specific;>

Re: Bug#900511: libcurl4 Conflicts: libcurl3

[Adrian Bunk]

On Sun, Jun 03, 2018 at 10:12:22AM -0400, Marvin Renich wrote:
> * Russ Allbery  [180602 22:41]:
>...
> > or we'd need to call our version libcurl5 or something,
> > which would break compatibility with everyone else.
> 
> That's almost what I meant.  Upstream should recognize that in spite of
> their strong statements about not _ever_ breaking ABI, their exposure of
> openssl 1.1 structure has, indeed, broken ABI and they should be
> responsible and admit it and bump SONAME.  (This is all based on my
> much-less-than-expert understanding of the discussion; my opinion might
> be way off here.)  If I'm right, though, this would make everyone happy;
> all distributions would have libcurl5, our libcurl3/4 mix could stay as
> is, and no Conflicts would be necessary.

This would have been a valid point 2 years ago when OpenSSL 1.1 support 
was added to libcurl.

Today with everyone else (including the current Ubuntu LTS)
already using libcurl4 with OpenSSL 1.1 this is moot.

> ...Marvin

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#900511: libcurl4 Conflicts: libcurl3

[Adrian Bunk]

On Thu, May 31, 2018 at 12:37:00PM -0400, Marvin Renich wrote:
> Package: libcurl4
> Version: 7.60.0-2
> Severity: serious
> 
> libcurl4 conflicts with libcurl3, which violates the stated purpose of
> the "must" clause at Policy 8.1 (to allow multiple versions of a shared
> library to be co-installable), even though it doesn't violate the letter
> of the must (binary package name must change when SONAME changes).
> Without the second sentence at Policy 8.1, the MUST requirement serves
> no purpose, so I have given this severity serious.

Another purpose (not stated in the policy) is that software compiled 
against the old SONAME cannot work with the new SONAME, and changing
the package name is the cleanest solution to express that through the
package dependencies.

In most cases parallel installation of several SONAME versions of
a library is a working setup, but for cases like libcurl3->libcurl4
the only thing you could argue for would be changing the wording in
policy - parallel installation is not technically feasible here.

> This means that, regardless of what Debian does with packages depending
> on libcurl, libcurl4 cannot be installed if the user has third party or
> home brew software that requires libcurl3.

libcurl3 is not part of buster, and using libraries from previous 
releases that are no longer present in a new stable Debian release is 
not strictly supported - it works most of the time, but when problems
are reported a Breaks/Conflicts against that library is usually the
solution.

> I found this because I have netsurf-gtk installed, which Depends:
> libcurl3.  netsurf-gtk is currently the same version in stable and
> unstable, but has been removed from testing.

That's due to #869600.

> ...Marvin

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: missing recommends are not RC severity

[Adrian Bunk]

On Thu, Apr 19, 2018 at 08:34:57PM -0700, Russ Allbery wrote:
> Holger Levsen  writes:
> 
> > dropping -devel@, adding -release@ and -policy@, I'm wondering if this
> > should be resolved somehow...:
> 
> > A few days ago I wrote:
> >> > >if your package recommends a package which is not available, this is a
> >> > >normal bug, not one with RC severity (and neither an important one).
> 
> > To which on Tue, Apr 17, 2018 at 01:04:47PM +, Scott Kitterman wrote:
> >> > Policy 2.2.1 pretty clearly says otherwise.
> 
> > Then on Tue, Apr 17, 2018 at 06:14:56PM +0500, Andrey Rahmatullin wrote:
> >> While the release policy says "Packages in main cannot require any
> >> software outside of main for execution or compilation. "Recommends:" lines
> >> do not count as requirements."
> 
> This is kind of a weird corner since the intent of that wording in Policy
> is more about contrib and non-free (hence the wording saying "non-main"
> package), not about packages that aren't available in a particular release
> of the archive.  I'm not sure we thought about this case when writing that
> wording.  One could be pedantic and argue that a package in main in
> unstable is not a package "outside of main" even though it's not available
> in testing, although that's a rather strained argument.
> 
> I'm quite sure from past discussion that we want to be sure packages don't
> Recommend contrib or non-free packages, and don't want to re-open that.
> But that's not quite the same thing as a package that (possibly
> temporarily) isn't available in that release, and I feel like we should
> make a separate determination whether that's supposed to be an RC bug.
>...

The most weird part of not treating this as RC is that this alone
is sufficient for a direct reject in NEW:
  https://ftp-master.debian.org/REJECT-FAQ.html

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#459427: changelog vs. NEWS handling

[Adrian Bunk]

On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> Hello Adrian,
> 
> Thank you for your continued effort to get this bug resolved.
> 
> On Sat, Mar 10 2018, Adrian Bunk wrote:
> 
> >> Please expand on why you think this is the way we have to proceed.
> >
> > you skipped the part of my email with the explanation:
> >
> >   with such a piecemeal approach
> >   we risk fragmentation based on debhelper compat level used, with every
> >   new compat level installing different files in different locations.
> 
> This is not inevitable.  What I am envisaging is:
> 
> - we hash out our preferred solution either in this bug or in the
>   debhelper bug, with the debhelper maintainer having the final say on
>   what gets implemented
> - debhelper implements all of that solution at exactly one compat level
> - the archive starts to use that compat level
> - Policy is updated.

This ensures that policy will always be horribly outdated.

> This is the standard way to make changes to Policy. The alternative is
> releases of Policy rendering many packages buggy, and that is undesirable.
>...

A new debhelper compat level making packages buggy according to policy
is what is desirable?

> Our delegation gives the Policy Editors editorial authority over the
> contents of the Policy Manual, but by means of the Policy Changes
> Process we delegate that authority back to the body of DDs.
> 
> That means that changes have to establish consensus.  How do we
> establish consensus on an issue like this, just by talking about it
> where everyone has a view?  That's extremely hard.  There's no way to
> bring the discussion to a close, and so the bug is still open after 10
> years.

Let me repeat what I already wrote earlier in this bug:

IMHO the way forward is to find a consensus text for a policy change,
Cc debian-devel on the proposal, and if no objections are raised release 
a new policy with these changes.

> What we can do in this case is shortcircuit that process of establishing
> consensus by means of debhelper.  The debhelper maintainer has authority
> over what debhelper will implement.  So he implements something.  If
> it's basically a sensible convention, almost everyone will start using
> it, even if it is not their number one choice of solution.  But then we
> have enough of a consensus, so it's no longer problematic to change

The Policy Editors are a delegation, and the debhelper maintainer is 
just a random person who happens to maintain this specific package.


Precedent is also that the Policy Editors do use their powers to 
push through even a change that makes thousands of packages buggy 
after an objection has been raised:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431#334

I begin to wonder whether I should take this personally.

> Sean Whitton

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#459427: changelog vs. NEWS handling

[Adrian Bunk]

On Sat, Mar 10, 2018 at 11:03:05PM +0200, Adrian Bunk wrote:
>...
> > > I think
> > > the most valuable starting point would to be to standardize on
> > > /usr/share/doc/package/NEWS.gz for the human-readable summary and
> > > explicitly say to never install that as
> > > /usr/share/doc/package/changelog.gz.  
> 
> On the contents of the proposal I agree with Gregor that I do not 
> consider it a good idea to install a different file to changelog.gz
> than has been in Debian for the past quarter century.
> 
> That's my personal opinion on the contents, others might differ on that.
> 
> Regarding the process, something like that should be decided before 
> installation of the human-readable summary is done by default by 
> debhelper.
> 
> A complete mess would be something like:
> - dh compat >= 12 installs NEWS to /usr/share/doc/package/NEWS.gz
> - dh compat >= 13 no longer installs ChangeLog to 
> /usr/share/doc/package/changelog.gz
> - dh compat >= 14 installs NEWS to /usr/share/doc/package/changelog.gz
>...

Sorry, I messed up and the quoted suggestion above is actually
a different suggestion, where the mess would be like
- dh compat >= 12 installs NEWS to /usr/share/doc/package/NEWS.gz
- dh compat >= 13 no longer installs ChangeLog to 
/usr/share/doc/package/changelog.gz
- dh compat >= 13 or when policy changes, some packages install a 
  ChangeLog that was previously in /usr/share/doc/package/changelog.gz
  as /usr/share/doc/package/NEWS.gz

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#459427: changelog vs. NEWS handling

[Adrian Bunk]

On Tue, Feb 27, 2018 at 10:09:59PM -0700, Sean Whitton wrote:
> Hello,

Hi Sean,

> On Tue, Feb 27 2018, Adrian Bunk wrote:
> 
> > Policy should define the naming before dh_installchangelogs should
> > change.
> 
> Please expand on why you think this is the way we have to proceed.

you skipped the part of my email with the explanation:

  with such a piecemeal approach
  we risk fragmentation based on debhelper compat level used, with every 
  new compat level installing different files in different locations.

This also referred to a proposal quoted in my email
(which happened to come from a policy editor):

> > I think
> > the most valuable starting point would to be to standardize on
> > /usr/share/doc/package/NEWS.gz for the human-readable summary and
> > explicitly say to never install that as
> > /usr/share/doc/package/changelog.gz.  

On the contents of the proposal I agree with Gregor that I do not 
consider it a good idea to install a different file to changelog.gz
than has been in Debian for the past quarter century.

That's my personal opinion on the contents, others might differ on that.

Regarding the process, something like that should be decided before 
installation of the human-readable summary is done by default by 
debhelper.

A complete mess would be something like:
- dh compat >= 12 installs NEWS to /usr/share/doc/package/NEWS.gz
- dh compat >= 13 no longer installs ChangeLog to 
/usr/share/doc/package/changelog.gz
- dh compat >= 14 installs NEWS to /usr/share/doc/package/changelog.gz

> We try to have Policy reflect changes already in the archive, rather
> than the other way around, except in situations where that can't make
> sense.

Your point of view sounds to me like
  In 15 years policy will be changed to document whatever the
  debhelper maintainer decides to implement in dh compat 12.

To me this doesn't make sense.

This bug is now over 10 years old, and at some point someone has to 
decide which files should be installed and where.

The obvious way forward would be to try to find a consensus here,
and then ask on debian-devel whether there are any objections.

If anything ends up being controverial and a decision is required, our 
constitution already makes it clear who is responsible for the decision 
(and this is not the debhelper maintainer).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#459427: changelog vs. NEWS handling

[Adrian Bunk]

On Sun, Dec 03, 2017 at 05:24:09PM +0100, gregor herrmann wrote:
> On Thu, 30 Nov 2017 20:45:51 -0800, Russ Allbery wrote:
> 
> > I think
> > the most valuable starting point would to be to standardize on
> > /usr/share/doc/package/NEWS.gz for the human-readable summary and
> > explicitly say to never install that as
> > /usr/share/doc/package/changelog.gz.  
> 
> That would mean that we have to manually add something to d/rules for
> thousands of perl packages in order to make ChangeLog, Changes etc.
> getting installed as /usr/share/doc/package/NEWS.gz.
> (Unless dh_installchangelogs gets some logic to install ChangeLog,
> Changes etc. as NEWS.gz if there is no NEWS in the upstream tarball.
> But that might be confusing …)
> 
> On Fri, 01 Dec 2017 13:34:01 -0700, Sean Whitton wrote:
> 
> > We can at least make dh_installchangelogs capable of installing both
> > changelog.gz and NEWS.gz before we change Policy.  Otherwise, fixing the
> > minor bugs is significantly more annoying.
> 
> Ack, this would be a good start.

Policy should define the naming before dh_installchangelogs should 
change.

Related is also the question whether any change at all will be
done before debhelper compat 12 - with such a piecemeal approach
we risk fragmentation based on debhelper compat level used, with every 
new compat level installing different files in different locations.

This bug has already celebrated its 10th birthday.

IMHO the way forward is to find a consensus text for a policy change,
Cc debian-devel on the proposal, and if no objections are raised release 
a new policy with these changes.

If additionally installing NEWS turns out to be the only consensus 
change then let's do that in policy now and close the topic.

If there can be consensus on more, then let's do this now.

> > If we are going to add something that says that upstream NEWS/release
> > notes should also be installed, why not standardise on the location?  It
> > seems odd to have a standard location for upstream changelogs but not
> > for upstream NEWS/release notes.
> > 
> > Or perhaps we should drop the standard location for upstream changelogs.
>  
> Having some standardization makes it easier for both users and their
> tools to quickly find what they are looking for. But yeah, I think we
> have at least 2 problems in this area:
> - no single standard on the upstream side (c.f. the GNU style vs. the
>   CPAN style(s))
> - needed changes in our tooling (dh_installchangelogs)
> 
> And we have 2 questions to answer:
> 1) Which files to install?
> 2) Under what name?
> 
> What policy could say is:
> 1) - If there is a human-facing summary, install it.
>- If there is a human-facing summary and a VCS-style log, install
>  the former but not the latter.
>- If there is no human-facing summary but a a VCS-style log,
>  consider installing the latter.
>(Without mentioning file names, or maybe as examples, as they are
>not standardized).
> 2) Install NEWS as /usr/share/doc/package/NEWS.gz and /Change.*/i as
>/usr/share/doc/package/changelog.gz if you install them.
>(That's also something dh_installchangelogs could do easily.)

This sounds like a good suggestion to me and I'd be willing to make a 
policy proposal based on that, with a wording that the maintainer "may" 
install a VCS-style log even when a human-facing summary is present.

If anyone has objections to this proposal, please speak up.

Coordinating with Niels regarding how to synchronize policy and 
debhelper changes is something I'll do after we have agreement
how the end result should look like.

> Cheers,
> gregor

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: Oppose

[Adrian Bunk]

On Wed, Aug 16, 2017 at 09:30:23AM -0700, Russ Allbery wrote:
>...
> This text is a formalization and simplification of existing practice that
> we worked out in conjuction with the reproducible builds team and that
> strikes a balance between attempting to enumerate all the causes of
> nonreproducibility (which would be quite difficult to do) and providing
> some clear guidance to maintainers about what types of output variance
> they *don't* have to worry about (since obviously packages can't be
> reproducible under all circumstances and in all environments).  The
> intention is to set a minimum bar that packages should be trying to meet,
>...

The definition of reproducibility in policy does not match any past, 
present or future practice in Debian.

And no current or currently planned reproducible testing does test
or is intended to test whether packages meet this minimum bar.

> This is directly in the center of Policy's normal role of standardizing
> and documenting best practice that has been developed elsewhere in the
> project.
>...

If it would actually standardize what is considered reproducible
in Debian everything would be fine.

> The definition is not decoupled from current practice.  It is roughly
> equivalent to the information currently captured in *.buildinfo files
> while being easily comprehensible to people who haven't studied
> *.buildinfo files.
>...

2 of the 5 items in policy require changes to .buildinfo, and for a 
third I cannot easily comprehend whether it would require changes to 
.buildinfo since it is unclear what it is supposed to mean:

- a set of environment variable values;

.buildinfo currently records only some environment variables.
If all or different ones are allowed to vary that is a change.
I am actually surprised that the latest set of suggested permitted
variations does not seem to be based on the existing list currently
used for .buildinfo

- a version of a source package unpacked at a given path;

The path is currently not in .buildinfo

- a build architecture;

What is the intended purpose of this, especially what is this supposed 
to output for i386 builds on amd64 kernel?
.buildinfo currently follows dpkg-architecture, and outputs i386.
i386/amd64 kernels is a build variation in the reproducible builds
infrastructure that does result in packages being built differently,
which makes it unclear whether this difference was supposed to be
addressed here.

> Finally, Policy in no way constrains people from filing bugs or reporting
> issues (via whatever means, such as tracker.debian.org) in packages about
> things that are not spelled out in Policy.
>...

https://tracker.debian.org/pkg/hsqldb1.8.0
"Does not build reproducibly during testing"

This statement in tracker is automatically generated based on results 
from the reproducible builds infrastructure.

Is it acceptable to claim in tracker that a package is not reproducible, 
when that package might actually be reproducible based on the definition 
of reproducibility spelled out in Policy? [1]

cu
Adrian

[1] as explained earlier, it is not obvious whether or not this
specific package is reproducible according to Policy

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Wed, Aug 16, 2017 at 03:43:00PM +, Ximin Luo wrote:
> Adrian Bunk:
> > On Wed, Aug 16, 2017 at 11:37:00AM +, Ximin Luo wrote:
> >> [..]
> >>
> >> Fair enough. I actually spotted that but thought it was better to get 
> >> "something" into Policy rather than nitpick. I guess other people were 
> >> thinking similar things. Well, lesson learnt, I will be more forceful next 
> >> time.
> >> ...
> > 
> > What is the point of getting "something" into policy, when it is known 
> > to not match existing practice and that what is being added to policy 
> > will be ignored by everyone?
> > 
> >> The sentence I amended said "most environment variables" so our intent is 
> >> clear.
> >> ...
> > 
> > This is not about "intent", this is about giving an exact definition
> > of reproducibility for Debian.
> > 
> > The definition should then match what is recorded in .buildinfo
> > and what the reproducible builds infrastructure is testing.
> > 
> 
> The exact wording that was added, was a too-loose requirement. I'm now 
> proposing to make the requirement more strict, in accordance with the tests 
> that we're running. Do you have any comments on my proposal?
>...

Will both dpkg-genbuildinfo and the reproducible builds infrastructure 
implement this definition?

Any definition is fine for me as long as it will match what is actually 
being done.[1]

> X

cu
Adrian

[1] not excluding future changes, but at the time the policy will be 
published it should match reality

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: Oppose

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
>...
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or 
> build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
> See the file ``upgrading-checklist`` for information about policy
> which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
> often creates either static linking or shared library conflicts, and,
> most importantly, increases the difficulty of handling security
> vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition `_.

I hereby oppose the addition of this to policy.

It is not true that this would be "Debian's precisification"
of reproducible builds. 

The definition does not match any past, present or future practice in Debian.

Including the people who want this change to policy, there seems to be 
noone intending to use this definition of reproducibility.

Adding this to policy would do more harm than good.

E.g. tracker.d.o saying "Does not build reproducibly during testing" 
based on a definition of reproducibility that is quite different from 
the official "Debian precisification" would only create confusion.

> Sean Whitton

cu
Adrian

- -- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlmUZAsACgkQiNJCh6LY
mLG9RhAAjr0dgpxSv9lnqM3+4AR3JeWwTaj9J118Efsr4qmSbgK9gE3HE3bL7zXG
OJHE5AqGZidx/Oyw/+TVLq3cHEi+6WfgJcwNzFeRAa7fAv+BKSJJ4T9dhOBYvmfs
YN/BfIhU8j4bQppVFtsduprdxooBx9bHWO/lFzCLl/cZOZ7RPOCya7iXcgEgWuA2
SAo96bcDeL3h5I/qM7fBLcm4Yvca219u8RoD7HqQNcmEI53CKS5qIW1cy0wkNbUy
Pqgovee2GpW7WkgqdG92E770/m2tcxdQQywVf5IeLHiSfJ0VP9dGFOoQCsnXZgvg
4GGstXzTJ2OEKMQ2QK1938Tne0S1WIG5o2zLEzOpHqw11Z9TsRg94CRm0/f/tfNt
ym35/N3qNdjERzozTQckbz4ZKCyLKJU3AIxGOH1U1caIjSNBbWY+nGAu62SzY9fb
IVdmKBkqL+c0MT4AW4yRUjFQ/EZYQNkWrh9USPAlgtWdIfjP4ERJ+60RJcRSgYvz
cJJw8DfDKYTNI6sgu0W++rhv89J4eAFdBKDmBazO5gLnFYBacgrFXW9HvwkxCcSZ
WJUlcuEalDpZrtPKGYO5arQp/vWWqXsVBzZeUphi6UbUjmCw+1M4emJh9Zk41jU3
BeTKcjh/hr0tihUvXhZKAJ85HmSkVLjPqZfY/DNiDecr9q+ZdvQ=
=i6V/
-END PGP SIGNATURE-

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Wed, Aug 16, 2017 at 11:37:00AM +, Ximin Luo wrote:
> Adrian Bunk:
> > On Wed, Aug 16, 2017 at 10:24:07AM +, Mattia Rizzolo wrote:
> >> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <b...@debian.org> wrote:
> >>
> >>> Tracker:
> >>> https://tracker.debian.org/pkg/hsqldb1.8.0
> >>> "Does not build reproducibly during testing"
> >>
> >> And indeed it's not reproducible according to policy: it's storing the
> >> build user at the very least.
> >> ...
> > 
> > What makes you so confident that this package is not reproducible 
> > according to policy?
> > 
> > According to policy, storing the value of $USER in the binary
> > is clearly permitted for a reproducible package. [1]
> > 
> > As long as the reproducible builds infrastructure varies $USER instead 
> > of following the policy definition, it is not suitable for determining 
> > whether or not a package is reproducible according to policy.
> > 
> > And what the reproducible builds infrastructure pushes as
> >Does not build reproducibly during testing
> > to tracker and DDPO is therefore not usable for determining
> > reproducibility according to policy.
> > 
> > cu
> > Adrian
> > 
> > [1] I haven't checked what exactly this package does
> > 
> 
> Fair enough. I actually spotted that but thought it was better to get 
> "something" into Policy rather than nitpick. I guess other people were 
> thinking similar things. Well, lesson learnt, I will be more forceful next 
> time.
>...

What is the point of getting "something" into policy, when it is known 
to not match existing practice and that what is being added to policy 
will be ignored by everyone?

> The sentence I amended said "most environment variables" so our intent is 
> clear.
>...

This is not about "intent", this is about giving an exact definition
of reproducibility for Debian.

The definition should then match what is recorded in .buildinfo
and what the reproducible builds infrastructure is testing.

> X

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Wed, Aug 16, 2017 at 10:24:07AM +, Mattia Rizzolo wrote:
> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <b...@debian.org> wrote:
> 
> > Tracker:
> > https://tracker.debian.org/pkg/hsqldb1.8.0
> > "Does not build reproducibly during testing"
> 
> And indeed it's not reproducible according to policy: it's storing the
> build user at the very least.
>...

What makes you so confident that this package is not reproducible 
according to policy?

According to policy, storing the value of $USER in the binary
is clearly permitted for a reproducible package. [1]

As long as the reproducible builds infrastructure varies $USER instead 
of following the policy definition, it is not suitable for determining 
whether or not a package is reproducible according to policy.

And what the reproducible builds infrastructure pushes as
   Does not build reproducibly during testing
to tracker and DDPO is therefore not usable for determining
reproducibility according to policy.

cu
Adrian

[1] I haven't checked what exactly this package does

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Tue, Aug 15, 2017 at 04:01:00PM -0700, Sean Whitton wrote:
> On Wed, Aug 16 2017, Adrian Bunk wrote:
> 
> > This is about the reproducible builds team not using policy as a stick 
> > for claiming a bar higher than what policy actually defines.
> >
> > Is it really allowed to claim that a package is not reproducible,
> > when it actually is reproducible according to policy?
> 
> Yes, if your bug is of 'wishlist' severity.

You are not answering to any of the examples I gave in the email you
answered to.

"Does not build reproducibly during testing" statements in Tracker,
and red warnings in DDPO and Maintainer Dashboard.

Is it for you as policy editor perfectly fine or a bug in the 
reproducible infrastructure when Tracker states (based on the
latest results from the reproducible builds infrastructure)
"Does not build reproducibly during testing" for packages
that are reproducible according to policy?

> Sean Whitton

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
>...
> This in absolutely no way constrains the reproducible build team from
> working on raising the bar in the future, just as the absence of this
> language from Policy did not prevent them from starting to work on this
> problem four years ago.  They should continue to work on making package
> builds more reproducible and raising the bar for reproducibility as makes
> sense for their goals and judging the impact of that.  Once any new
> requirements reach maturity and look feasible and have some project
> committment, we'll change Policy to set a new baseline for the whole
> project.  But the reproducible builds work should not *wait* for that, and
> should definitely push forward and experiment just as they have up until
> now.
>...

This is not about experimenting for raising the bar in the future.

This is about the reproducible builds team not using policy as a stick 
for claiming a bar higher than what policy actually defines.

Is it really allowed to claim that a package is not reproducible,
when it actually is reproducible according to policy?

Let me explain with examples how this information is presented 
to maintainers:

Tracker:
https://tracker.debian.org/pkg/hsqldb1.8.0
"Does not build reproducibly during testing"

DDPO:
https://qa.debian.org/developer.php?email=debian-openoff...@lists.debian.org
red "unrep" entries

Maintainer dashboard:
https://udd.debian.org/dmd/?email1=debian-openoffice%40lists.debian.org
red "(un)reproducible" entries [1]

Let's look at the mdds package, that has red unreproducible entries in
the maintainer dashboard:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html

mdds is unreproducible only in sid since more things (including the 
build path) are varied there. The information behind "differences"
confirms that the build path is the only issue.

According to policy, mdds is reproducible.

Unless policy is supposed to be completely detached from reality,
the criteria for claiming in various places that a package is 
unreproducible have to match the policy definition of reproducibility.

cu
Adrian

[1] the FTBFS entries are actually problems in the reproducible infrastructure

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote:
> Adrian Bunk <b...@debian.org> writes:
> 
> > I would expect the reproducible builds team to not submit any bugs
> > regarding varied environment variables as long as as the official
> > definition of reproducibility in policy states that this is not required
> > for a package to be reproducible.
> 
> I believe the planned next step here is to publish the *.buildinfo files,
> which contain a specification of the environment variables the build cares
> about, and then Policy can be modified to include a description of
> *.buildinfo files and how to use them.  As part of those changes, we'd
> certainly update the definition of reproducible to reference matching the
> environment specified in the corresponding *.buildinfo file.

I do understand that.

My point is that we now have an official definition what is required
for a package to be reproducible, and what is not required.

Future policy versions might change this definition,
but whatever latest policy states has to be the definition
used by both packages and the reproducible builds team.

Another example is that a package that is reproducible according to the 
policy definition must not show up as non-reproducible in tracker/DDPO 
based on results from the reproducible infrastructure.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
>...
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
>...

Is identical building on any kernel required (and tested)?

Examples:

A self-compiled kernel with CONFIG_IPV6=n

Imagine the next time Linus changes the kernel versioning,
he chooses ..
Will every reproducible package in buster build identical on the
bullseye+1 kernel 2022.11.321 ? [1]

> Sean Whitton

cu
Adrian

[1] the wheezy LTS updates are now built on buildds running stretch
kernels, and in buster we will have the similar situation that
nearly everyting in the initial release will be built on stretch
kernels while post-release updates will be built on buster,
bullseye and bullseye+1 kernels

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#844431: Revised patch: seeking seconds

[Adrian Bunk]

On Sat, Aug 12, 2017 at 11:23:14AM -0700, Sean Whitton wrote:
>...
> - for now, we only require reproducibility when the set of environment
>   variable values set is exactly the same
> 
>   This is because
> 
>   - the reproducible builds team aren't yet totally clear on the
> variables that they think may be allowed to vary
> 
>   - we should wait until .buildinfo is properly documented in policy,
> and then we can refer to that file
>...

I would expect the reproducible builds team to not submit any bugs 
regarding varied environment variables as long as as the official
definition of reproducibility in policy states that this is not
required for a package to be reproducible.

> Sean Whitton

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

/me just realized he made a stupid mistake by grep'ing Packages instead
of Sources.

Approximate data based on grep'ing Sources:
- 452 teams maintaining packages in unstable
- 3 is the median number of packages maintained by a team
- 155 teams maintaining a single package


On Mon, Aug 07, 2017 at 04:48:54PM +0300, Adrian Bunk wrote:
> 
> Approximate data based on grep'ing Packages[1]:
> - 466 teams maintaining packages in unstable
> - 8 is the median number of packages maintained by a team
> - 73 teams maintaining a single package
> 
> A package with 500 LOC might have an own team:
> https://qa.debian.org/developer.php?email=hostname-de...@lists.alioth.debian.org
> 
> cu
> Adrian
> 
> [1] grep -Ei '^Maintainer.*(team|maintainer|lists.alioth.debian.org).*'

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Sat, Aug 05, 2017 at 04:29:34PM -0700, Russ Allbery wrote:
>...
> since teams are less likely to only have a single leaf package.

Approximate data based on grep'ing Packages[1]:
- 466 teams maintaining packages in unstable
- 8 is the median number of packages maintained by a team
- 73 teams maintaining a single package

A package with 500 LOC might have an own team:
https://qa.debian.org/developer.php?email=hostname-de...@lists.alioth.debian.org

cu
Adrian

[1] grep -Ei '^Maintainer.*(team|maintainer|lists.alioth.debian.org).*'

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

One thing that is worth discussing here:

For how many teams would it bring real benefits if they no longer 
have to maintain team membership information in every source packages?

My guesstimate is that these might perhaps be 5 teams.

Why is my guestimate so low?

It only brings real benefits for teams:
1. that do not have a concept of package ownership inside the team, and
2. that maintain many packages.

Regarding the second point, there clearly is a real amount of work 
removing a person from the Uploaders of hundreds of packages.
But when a team maintains only 5 packages this is no longer a problem.

Regarding the first point, most large teams do have have the concept of 
package ownership inside the team. Sometimes with well-defined semantics 
regarding the differences between putting the team in Maintainer and the 
human in Uploaders, or putting the human in Maintainer and the team in 
Uploaders. For these teams it is no question that Uploaders is useful.

A reason why "generate Uploaders based on team member information 
stored in a core package of the team" sounds like a reasonable solution
to me is that I think a solution is required only for a handful large
teams.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Sat, Aug 05, 2017 at 03:28:57PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > > I don't understand this suggestion.  If it can be automatically
> > > generated, just generate it when you need it -- why store it in the
> > > source package?
> > 
> > What cannot be automatically generated is the other side of the 
> > intersection:
> > https://sources.debian.net/src/gnome-pkg-tools/0.19.9/pkg-gnome.team/
> > 
> > And you cannot automatically generate whom the team considers as members.
> > 
> > This is policy specific to a team, where some team members might only 
> > work in git (see the lintian example) and others might have left the
> > team recently.
>  
> I think using the uploaders: field to guess who's a team member is just a
> work-around / an estimate, as we have nothing better.

It is the official place to list co-maintainers.

>...
> ;tl;dr: I think we need a better system to manage team membership in Debian.
> (Ab)using the uploaders: field gives an estimate or datapoint today, but we
> have other means to gather this data.

No, we do not have currently any other means to gather who is considered 
a team member by a team.

And that's the problem.

> cheers,
>   Holger

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Bug#870788: Extract recent uploaders from d/changelog

[Adrian Bunk]

On Sat, Aug 05, 2017 at 03:19:29PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 04:35:35PM +0200, Bill Allombert wrote:
> > > > Note that a prerequisite for such debian/changelog parsing would be
> > > > that policy sets strict syntax and semantics requirements.
> > > 
> > > No, we do not need to block such a feature that would work for 90% of
> > > packages until we have a policy about the [ name ] syntax.  It can begin
> > > as a useful heuristic.
> > 
> > How do you get that it would work 90% of package ?
> > Using [] for non-team members is very common.
> 
> for getting the _uploaders_ it's not even required to parse those fields, as
> each upload has one uploader which is semantically strict defined already.

Policy says that Uploaders contains the _co-maintainers_.

And that also matches what most teams do.

> cheers,
>   Holger

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Sat, Aug 05, 2017 at 02:15:16PM +0500, Andrey Rahmatullin wrote:
>...
> Besides, while it doesn't imply you shouldn't make an upload that only
> changes the maintainer (unlike 5.9.5. Adopting a package), I think it's
> the usual practice to not make such upload.

For people who are orphaning their own packages it is relatively common.

Many tools work based on the O: bug and it is also required for 
coordinating who will adopt a package, so that is clearly the
important part. But the BTS forwards emails based on Maintainer.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 02:57:49PM -0700, Russ Allbery wrote:
>...
> but regardless of
> that discussion, machine-readable team information is not something we
> have now.

Policy says that Uploaders should list all co-maintainers.

Who is considered a co-maintainer is determined by team policy or the
other maintainers.

Uploaders is machine-readable.

> We instead have a partial record of some people who have
> previously worked on the package, without much information about whether
> they're currently working on the package.
>...

True, but the situation is actually better than for the Maintainer field.

There is a very popular (not team-maintained) package where the person 
in Maintainer is still reachable by email but hasn't uploaded since 2014,
and the last 80 uploads were made by the people in Uploaders.

For fringe leaf packages, it is perfectly possible that we might 
have people in Maintainer who died 10 years ago.

And disappearing uploaders in team maintained packages can be much 
easier solved than disappearing Maintainers in not co-maintained 
packages: The team can drop an Uploader without a 6 month MIA process.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 02:10:41PM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
>...
> > In a more general note, I am a bit puzzled that it is so controversial
> > that machine-readable team membership information is important and
> > should continue to be available.
> 
> Because maintaining such a field increases the burden on teams for 
> little to no benefit.

It does not bring benefit to you personally.

It is quite useful elsewhere.

> I know I haven't bothered to be sure that the
> Uploaders field in any of my packages only contains people who are
> currently actively involved in maintaining that particular packages.

Whom you officially list as co-maintainers of your packages is your
decision.

> On Fri, 04 Aug 2017, Bill Allombert wrote:
> > Nowadays orphaning is done by reuploading the package with the
> > maintainer set to the QA group rather than using a O: wnpp bug.
> 
> Good point.

Bill was giving alternative facts.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 06:20:31PM -0700, Sean Whitton wrote:
> Hello,
> 
> On Fri, Aug 04 2017, Adrian Bunk wrote:
> 
> > Autogenerating Uploaders like GNOME does [1] would be an alternative
> > approach.
> >
> > [1]
> > https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/
> 
> I don't understand this suggestion.  If it can be automatically
> generated, just generate it when you need it -- why store it in the
> source package?

What cannot be automatically generated is the other side of the 
intersection:
https://sources.debian.net/src/gnome-pkg-tools/0.19.9/pkg-gnome.team/

And you cannot automatically generate whom the team considers as members.

This is policy specific to a team, where some team members might only 
work in git (see the lintian example) and others might have left the
team recently.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
>...
> > Uploaders is not the only option for doing that, but any change should
> > include provising more reliable information - not less reliable
> > information.
> 
> In practice, Uploaders often only includes people who have ever uploaded
> the package, not everyone who is on (or still on) the team. I you'll
> have better luck with a who-uploads equivalent.

In practice, Uploaders often includes active team members who work
in git, but one specific team member does all the uploads.

I already gave the lintian package as an example for that.

And in the other direction what you describe would leave no way for
a person to make it visible that he has left the team.

> > An O: bug means that it is confirmed that the package is orphaned, and
> > gives permission to everyone to adopt the package immediately.
> 
> So just file an an Intent-To-Orphan bug. [This why I suggested to file
> the bug against the package, and not against wnpp.]
>...

There is no Intent-To-Orphan bug.

And whenever possible the process should work by first confirming
that a person or team is MIA, and then orphan everything that was 
maintained by that person or team.

In a more general note, I am a bit puzzled that it is so controversial 
that machine-readable team membership information is important and
should continue to be available.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 08:25:57AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> >
> > Think of it as a 3 step process:
> 
> [...]
> 
> > 3. for every package where the maintainer is in Maintainer or Uploaders
> >the MIA team either orphans the package, or informs team or 
> >co-maintainers through an "Updating the  Uploaders list" bug.
> 
> [...]
> 
> > The part where removing the Uploaders: requirement could cause 
> > regressions is step 3.
> > 
> > Give for a person a complete list of all packages where this person
> > was active" - if we regress on this, it means that packages will
> > continue to bitrot in cases where they can currently be orphaned.
> 
> MIA could find #3 by looking for all packages where the maintainer is
> the most recent uploader, and no other individual has recently uploaded
> the package. This would work even if Uploaders: lists people who are not
> MIA but have stopped being involved in the team.

And it would not work when the latest maintainer upload was by a team 
member who retired or was declared MIA earlier.

There are also other situations where a mapping between teams and
all members of the team can be very useful.

Uploaders is not the only option for doing that, but any change
should include provising more reliable information - not less
reliable information.

> If there was any question, filing an O: bug against the package and
> marking it affects wnpp should notify the team who can close the O: bug
> if the package is still being maintained.

This is a HORRIBLE suggestion.

An O: bug means that it is confirmed that the package is orphaned,
and gives permission to everyone to adopt the package immediately.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 06:48:27PM -0700, Russ Allbery wrote:
>...
> One approach as Holger points out: look for
> packages where all the recent uploads have been by the MIA member, which
> doesn't require the Uploaders field at all.

As I already tried to explain, this is an easy part that could be
automated. The half-year MIA process that follows is the bottleneck,
and wasting slots on teams would make the bottleneck even worse.

> I stand by my statement that as long as the team *does* have more than one
> member, not having to change anything abot package maintenance when one
> team member disappears is kind of the whole point of having team
> maintenance.  If the team is not providing that, it feels like there's not
> much point in having a team, although I guess it could be aspirational.
>...

This is how you imagine how teams should work, not a description of the
actual reality in Debian.

As an example, we do have teams that define in their policy the
semantics for "person in Maintainer, team in Uploaders".

> > When all members of a team are confirmed to be MIA/retired, this should
> > result in an orphaning of all packages maintained by the team.
> 
> One of the whole points of this discussion is that this "members of a
> team" concept is not well-defined in Debian and is probably not something
> that we *can* make well-defined in Debian.  Or, more to the point, *want*
> to make well-defined.

It is interesting how you manage to argue both based on a very specific 
definition of teams you have in mind, and based on declaring that all 
this is not well-defined and that we neither can nor want to define it.

What is needed is a machine-readable mapping between teams and their members.

Mandatory Uploaders gives a good-enough approximation of that.

Removing that without replacement would be a regression.

> >> No, I'm not -- as I pointed out in a separate message, this is a
> >> problem worth solving, but this is an MIA team problem that I think is
> >> best tackled from that angle.  If all of a team's packages are
> >> bitrotting, then the team's packages should be orphaned just like we do
> >> with an MIA single maintainer.
> 
> > This would create both longer bitrot for packages and more work for
> > an already overworked team.
> 
> Why?  I don't see how this follows; in fact, I believe the exact opposite.
> The current work that the MIA team does to track down Uploaders that
> mention MIA people on team-maintained packages and file a bunch of bugs to
> have them removed is work that they *don't* have to do in this model.
> Instead, just treat the team like another maintainer and look at whether
> that maintainer's packages are being maintained and whether that team is
> active and orphan packages if they aren't.

Declaring someone is MIA is the result of a half-year process.[1]

Doing a MIA process for a team many years (and several releases)
after it has been confirmed that all team members are MIA would
both lower the quality of Debian and create additional work.

You are trying to push the solution of making Uploaders optional
for teams, marginalizing any new problems it might cause.

Let's go back from trying to push a solution to discussing the problems 
that should be solved, and the problems different potential solutions 
might cause.

I do understand that for teams whose policy states that every team 
member maintains every package and that maintain many packages it
is not convenient to manually update uploaders. Is this the one
problem that should be solved, or are there other problems that
should be solved here?

An alternative option of maintaining machine-readable information
about team member in a different place outside the packages would
fix the problem of losing information about team membership.

Or the low-change option of documenting that the already used way of 
autogenerating the Uploaders list based on information stored in one 
core package of the team is a valid option - this allows teams with many 
packages to get rid of the problem of having to update this information 
manually in every single package.

cu
Adrian

[1] https://wiki.debian.org/qa.debian.org/MIATeam

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk <b...@debian.org> writes:
> 
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> 
> I agree, but that's not directly relevant here, since we're talking about
> team-maintained packages.  The whole *point* of team maintenance is that
> there's no reason to orphan a package just because one team member went
> away.  If that weren't the case, the package is, *by definition*, not
> team-maintained (or the team itself is MIA, which is a different issue as
> discussed below).

Your definition is completely detached from the reality in Debian.

Many (likely the majority) of teams in Debian have not more
than 1 active member.

> >> Currently, when the MIA team finds someone who is no longer active,
> >> teams have to go do a bunch of work to strip their name out of uploader
> >> fields.  That work doesn't really make Debian any better; it's just
> >> bookkeeping.  When the team has other ways of knowing the health of
> >> their packages, I'd like to let them not do this bookkeeping.
> 
> > You are assuming that the team notices without the current notifications
> > from the MIA team that a team member is no longer active in Debian.
> 
> I'm really not.  I'm pointing out that for a lot of teams, that literally
> *does not matter at all*.  Absolutely nothing changes about the
> maintenance status of many team-maintained packages if the person who last
> worked on that package disappears.
> 
> Teams often don't notice that someone is MIA because *it doesn't matter*
> for their workflow; they're happy to have people come and go.

When all members of a team are confirmed to be MIA/retired,
this should result in an orphaning of all packages maintained
by the team.

> > You are assuming that the team has a non-zero number of active members
> > left after a member becomes MIA.
>
> No, I'm not -- as I pointed out in a separate message, this is a problem
> worth solving, but this is an MIA team problem that I think is best
> tackled from that angle.  If all of a team's packages are bitrotting, then
> the team's packages should be orphaned just like we do with an MIA single
> maintainer.

This would create both longer bitrot for packages and more work for
an already overworked team.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
> 
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > What I don't understand in the point of view of the "keep Uploaders"
> > > proponents: What does this information, whether correct or not,
> > > actually give others? Are they going to email or phone these persons
> > > privately when emails to the BTS or the maintainer/team list are
> > > ignored? And what happens if they ignore these communications as
> > > well?
> > 
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> > 
> > These "Updating the  Uploaders list" bugs.
> > 
> > When the MIA team has determined that a person is MIA,[1]
> > it can send bugs informing all packages where that person
> > is listed in Uploaders that the person is no longer active.
> 
> Ok, that's a good example:
> 
> So, when we (pkg-perl) get such a list of bug reports (or, which is
> less work, a single mail from the MIA team about XY being inactive)
> what happens is that
> - we probably know that already (but it's still good to have the
>   offical confirmation)
> - we remove them from Uploaders in git
> - nothing else changes: the package will be uploaded when there's any
>   reason for it (new release, bugfix) as before when XY was still
>   mentioned in Uploaders
> 
> Dropping the Uploaders field would mean that we save the work (which
> can be quite tedious when we have to add the right bug numbers to the
> right packages' changelog entry) without any other changes to the
> maintenance of the package.

But then the information who is currently part of pkg-perl is needed in
machine-readable form and displayed by tools like DDPO and tracker for:
1. being able to inform a team that a member is MIA and inform the team, and
2. being able to detect when the last team member is MIA

Policy equally applies to packages where point 2 is far more likely to 
happen than for pkg-perl.

Autogenerating Uploaders like GNOME does [1] would be an alternative
approach.

> Cheers,
> gregor 

cu
Adrian

[1] https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:11:07PM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> 
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did not recognize that the
> > (sole) Uploader wasn't there anymore and the packages were
> > bitrotting. Without the Uploader field there would have been excactly
> > zero change to find those packages and get them back into maintainance
> > again.
> 
> I'm dubious about this assertion and would like to dig into it a bit more.
> 
> The way we hopefully would find bitrotting packages is that they are,
> well, bitrotting.  This is based on lack of uploads, open bugs, old Policy
> versions, incomplete transitions, and in serious cases, missing from
> stable releases.  While we can *also* find bitrotting packages via the MIA
> process, it shouldn't be our primary or even a major way of finding them
> since it's entirely possible for someone to be quite active in Debian
> while still neglecting some of their packages.
>...

Regressing on being able to orphan all packages of a known-MIA/retired
maintainer would be very bad.

Think of it as a 3 step process:
1. a bitrotting package indicates a potentially MIA maintainer
2. the maintainer agrees to orphaning all packages, or after several 
   failed contact attempts the MIA team declares that the maintainer is MIA
3. for every package where the maintainer is in Maintainer or Uploaders
   the MIA team either orphans the package, or informs team or 
   co-maintainers through an "Updating the  Uploaders list" bug.

Just by going through bugs, I compiled during the past 10 months a list 
of currently 250 (sic) names of people listed in Maintainer or Uploaders
of packages in unstable where I suspect the person might be MIA.

Automating this part would not be a problem, the intersection of
"in Maintainer or Uploaders of a package in unstable" and
"no email to a Debian list or the BTS in the past 12 months"
should give approximately a superset of my list.

Step 2 is actually a lot of work.

The part where removing the Uploaders: requirement could cause 
regressions is step 3.

Give for a person a complete list of all packages where this person was 
active" - if we regress on this, it means that packages will continue to
bitrot in cases where they can currently be orphaned.

> Currently, when the MIA team finds someone who is no longer active, teams
> have to go do a bunch of work to strip their name out of uploader fields.
> That work doesn't really make Debian any better; it's just bookkeeping.
> When the team has other ways of knowing the health of their packages, I'd
> like to let them not do this bookkeeping.
>...

You are assuming that the team notices without the current notifications 
from the MIA team that a team member is no longer active in Debian.

You are assuming that the team has a non-zero number of active members 
left after a member becomes MIA.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>...
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emails to the BTS or the maintainer/team list are
> ignored? And what happens if they ignore these communications as
> well?
>...

https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5

These "Updating the  Uploaders list" bugs.

When the MIA team has determined that a person is MIA,[1]
it can send bugs informing all packages where that person
is listed in Uploaders that the person is no longer active.

For small teams (e.g. 2 people in a team maintaining 1 package)
this is also a way for seeing when 0 team members are left who
are still active in Debian.

> Cheers,
> gregor

cu
Adrian

[1] or retired, all this is about what happens after it has been
determined that a person is no longer active in Debian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> > 
> > This would not be "a purely informative change".
> > 
> > Your suggested wording has the potential to create a HUGE amount of 
> > tensions.
> 
> You're right.  After sending my patch I realised that it contains the
> word "should", which is a magic word in policy, imposing a normative
> requirement.  This was not intended.
> 
> My intended meaning: it is already best practice that *other team
> members* should orphan a package if they know that no-one in the team is
> actively taking care of it *according to their judgement of 'actively'*.
> 
> Would you agree that this is already established best practice?
>...

That completely misses the problem.

If the team has remaining members, and one of these members knows that 
no-one in the team is actively taking care of a package, then what
happens afterwards is obvious.

Finding unmaintained packages is the hard part.

In a bigger team maintaining 500 packages it is a non-trivial amount of 
extra work searching for packages no-one inside the team is actively 
taking care of.

In a small team with 2 members maintaining 1 package, what you write 
obviously cannot work when the last team member becomes MIA.

With Uploaders you are able to see when all uploaders are retired/MIA,
either inside the team or from outside when the team has no active 
members left.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: debian-policy: don't require Uploaders

[Adrian Bunk]

On Wed, Aug 02, 2017 at 05:41:07PM -0400, David Bremner wrote:
> > 
> > So yes at any time they are a number of active, hard-working team, but there
> > also a larger number of phantom team that used to be active, but whose
> > packages are still maintained in Debian. It is important they carry some
> > valid information about the effective maintainers.
> 
> What are the advantages of the Uploaders field over debian/changelog?
> I can see some tooling issues, but nothing insurmountable (see
> e.g. who-uploads from devscripts).
>...

This information cannot be deducted reliably from debian/changelog

How do you express "X is no longer a member of the team maintaining 
package foo" in a way that all tooling understands it?

There is also the opposite problem of team members in Uploaders: who are 
actively working on the package in the git repository, but only one team
member does the actual uploads.

If you still can't see insurmountable tooling issues, please try to 
write such a tool. As testcase, try to find the active members of
the Debian Lintian Maintainers from the lintian debian/changelog

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:30:11PM +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> > On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > > Bill Allombert <ballo...@debian.org> writes:
> > > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> > > 
> > > >> I've also included a purely informative change which emphasises that
> > > >> packages that are team maintained in name only should be orphaned
> > > >> properly, with their maintainer field set to the QA team.  This is
> > > >> already current best practice, but it's worth emphasising, because one
> > > >> might fail to orphan a package on the grounds that "someone else on the
> > > >> team might fix it", which is not true of a lot of teams.
> > > 
> > > > You are omitting the case of a team which get reduced to a single
> > > > member, in which case the package need not be orphaned. Yet it is
> > > > important the fact is mentionned in the package.
> > > 
> > > I don't think I understand the objection.  Sean's proposed wording seems
> > > fine for that case -- it just says that the package should be orphaned if
> > > the team is not maintaining it, which shouldn't depend on the size of the
> > > team.
> > 
> > The patch also remove the requirement to list individual email of the
> > maintainers. That is what I am objecting to.
> > 
> > When a team is reduced to a single individual, it is no more a team, yet
> > the package is still maintained and need not be orphaned.
> 
> Your objection does not make sense.
> 
> The change Sean is proposing is intended to make providing the 
> information about team members in Uploaders: optional.
> 
> If are not objecting to removing the information about who is in a team,
> you cannot suggest that anything should be done based on the no longer 
> existing information about the number of team members.

Re-reading, I might understand what caused the misunderstanding:

This bug is about making providing the information about team members
in Uploaders: optional.

That's the core point discussed.

The part you were referring to is an attempt from Sean to address some 
problems caused by this change. This is not a standalone proposal.

If Uploaders: stays mandatory, we do not need new rules for orphaning 
team maintained packages that compensate for the no longer available 
information about team membership.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > Bill Allombert  writes:
> > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> > 
> > >> I've also included a purely informative change which emphasises that
> > >> packages that are team maintained in name only should be orphaned
> > >> properly, with their maintainer field set to the QA team.  This is
> > >> already current best practice, but it's worth emphasising, because one
> > >> might fail to orphan a package on the grounds that "someone else on the
> > >> team might fix it", which is not true of a lot of teams.
> > 
> > > You are omitting the case of a team which get reduced to a single
> > > member, in which case the package need not be orphaned. Yet it is
> > > important the fact is mentionned in the package.
> > 
> > I don't think I understand the objection.  Sean's proposed wording seems
> > fine for that case -- it just says that the package should be orphaned if
> > the team is not maintaining it, which shouldn't depend on the size of the
> > team.
> 
> The patch also remove the requirement to list individual email of the
> maintainers. That is what I am objecting to.
> 
> When a team is reduced to a single individual, it is no more a team, yet
> the package is still maintained and need not be orphaned.

Your objection does not make sense.

The change Sean is proposing is intended to make providing the 
information about team members in Uploaders: optional.

If are not objecting to removing the information about who is in a team,
you cannot suggest that anything should be done based on the no longer 
existing information about the number of team members.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>...
> I've also included a purely informative change which emphasises that
> packages that are team maintained in name only should be orphaned
> properly, with their maintainer field set to the QA team.  This is
> already current best practice, but it's worth emphasising, because one
> might fail to orphan a package on the grounds that "someone else on the
> team might fix it", which is not true of a lot of teams.
>...
> @@ -1149,6 +1142,12 @@
>
>  
>
> +  
> +This includes packages with a group of people or team in the
> +Maintainer control field.  They should be
> +orphaned if the team is not actively maintaining the package.
> +  
> +
>  
>  
>  
>...

Please be more thoughtful about the consequences of such changes to policy.

This would not be "a purely informative change".

Your suggested wording has the potential to create a HUGE amount of tensions.

I could name a lot of team-maintained packages where a team member 
uploads a new upstream version every 1-2 years and noone ever bothers
to handle incoming bugs.[1]

If policy does not provide a definition of "actively maintaining",
it would be a reasonable interpretation to consider a package with
no upload or visible activity in new open bugs during the past
6 or 12 months as not actively maintained.

If policy states that such packages "should be orphaned" without 
describing a proper process, it is a valid reading that everyone can do 
this without trying to contact the team prior to orphaning the package.

And it does not even help with the problem Tobias raised:

When a maintainer retires or is declared MIA by the MIA team according 
to the MIA process, how can you *find* all teams and team-maintained 
packages where this maintainer was the only or last active team member
when there is no Uploaders: field?

This information could be moved from the Uploaders: field to
a database, but then this database has to exist and maintaining
the information there has to be mandatory when no Uploaders: field
is present.

Another option would be to keep the Uploaders: requirement,
but make it more clear that autogenerating is permitted.

The GNOME team already generates Uploaders: as the intersection
of current team members and people who did the latest 10 uploads
of a package.

cu
Adrian

[1] a few people are IMHO just bad maintainers, but in the common
case there is simply too much work for too few people in a
volunteer project and new team members are always welcome

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#846970: debian-policy: Proposal for a Build-Indep-Architecture: control file field

[Adrian Bunk]

On Tue, Aug 01, 2017 at 11:56:58PM +0100, Colin Watson wrote:
> On Tue, Aug 01, 2017 at 07:47:47PM +0300, Adrian Bunk wrote:
> > 1. Debian does not currently have non-amd64 binary-all autobuilders
> > 
> > Stating that binary-all packages in the archive are always being 
> > built on amd64 would actually document the current status quo,
> > assuming source-only uploads.
> > 
> > AFAIR pixfrogger and pixbros that I converted from binary-all to
> > an explicit list of all 32bit architectures were the last two
> > binary-all packages in main that could not be built on amd64.
> > 
> > These were pretty rare cases of requiring a 32bit-only package,
> > and such a rare hack is better than mandating that Debian must
> > add binary-all autobuilders for every architecture.
> 
> This is an essentially artificial argument that depends on the current
> (IMO unnecessarily complicated) way in which Debian happens to implement
> autobuilding of Architecture: all binaries.  If they were just builds
> that happened on the normal autobuilders with a slightly different
> configuration, which would be perfectly possible, then nobody would need
> to worry about the effort of adding them for every architecture; any
> autobuilder would be able to build Architecture: all packages if it
> needed to do so.
> 
> To me, as one of the maintainers of Ubuntu's autobuilding
> infrastructure, this is a sufficiently obviously simpler approach that
> I'm quite puzzled as to why the Debian buildd maintainers chose to
> implement it the way they did; I did talk to Andreas Barth about it at
> the time that he was doing the work, but I had the feeling neither of us
> was quite understanding the other.
> 
> I can see the argument for not documenting this field in policy until
> the autobuilding infrastructure is actually able to cope with it
> (depending on how heavily one weights the downstream arguments), but I
> do think that the capability would fall quite naturally out of a
> better-designed infrastructure.  I don't agree that your "explicitly
> list all 32-bit architectures" hack is better than having the improved
> infrastructure, even though it was probably necessary at the time.

Thinking about it again, just making them binary-any would have
equally solved the problem - they would just have stayed forever
in BD-Uninstallable on 64 bit architectures.

pixfrogger and pixbros were "binary-all packages that depend and 
build-depend on a binary-any package that is not 64bit-clean".
That's a very uncommon situation, and nothing that is expected
to happen again in the future.

The only XS-Build-Indep-Architecture left in Debian is for amd64 (sic):
http://sources.debian.net/src/edk2/0~20161202.7bbe0b3e-1/debian/control/?hl=11#L11

Do you currently have any packages left in Ubuntu that need this 
building of binary-all on non-amd64?

> > 2. We were not able to build all binaries in a release
> > 
> > For aboot and palo we are shipping binaries in jessie that cannot be 
> > rebuilt in jessie since the build architecture is not part of jessie.
> > 
> > Cross-compilers are available on amd64, and this is how palo and 
> > openhackware were fixed for stretch.
> 
> This has certainly been possible in some cases, but I still think it's
> more simply done at the builder level.  And for the "build architecture
> not part of release" case, is it really worth shipping boot loaders for
> architectures where we don't ship the rest of the architecture?  The
> rare case of systems building images for older releases could be handled
> by just installing binaries from older releases.

qemu-system-ppc depends on qemu-slof and the already mentioned openhackware.

>From a build perspective this is the same problem of building binaries 
for a non-release architecture in a binary-all package, and it is
already solved with the same solution (cross-build on amd64).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#798476: debian-policy: don't require Uploaders

[Adrian Bunk]

On Fri, Jul 14, 2017 at 04:33:49PM -0700, Sean Whitton wrote:
>...
> Before doing that, at the risk of achieving nothing, I'd like to suggest
> another wording:
> 
> ... if the Maintainer control field names a group of people and a
> shared email address, the Uploaders field must be present and must
> contain at least one human with their personal email address.  An
> exception is made for packaging teams which state clearly on their
> homepage, documentation or team policy that all packages are taken
> care of by every team member collectively.
> 
> Possibly too bureaucratic, but might allay some of the concerns that
> Tobi raised: barely-established teams aren't likely to have a team
> homepage/documentation/policy document.
>...

You should double-check how many teams already have a homepage in the 
Debian wiki, such a homepage is not uncommon even for small teams.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#846970: debian-policy: Proposal for a Build-Indep-Architecture: control file field

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, Dec 04, 2016 at 07:32:29PM +0100, Christoph Biedl wrote:
> Package: debian-policy
> Severity: normal
> 
> Following a recent discussion on debian-devel[0], I'd like to
> formalize the (XS-)Build-Indep-Architecture: header mentioned there.
> 
> As an initial wording (probably 5.6.30):
> 
> This header is useful in the rare case where Architecture: all
> packages cannot be built on all architectures for reasons outside the
> maintainer's control. The value is an architecture wildcard
> identifying a set of Debian machine architectures, see [Architecture
> wildcards, Section 11.1.1], and should describe at least two
> architectures. The default is "any".
>...
> Pros:
> 
> * The maintainer can document both successful and failing architectures.
> * Thus downstream folks have a better hint which archs to avoid.
> 
> Cons:
> * This creates more complexity in the description and the parser
> * This creates also uncertaincy about the arch not mentioned

There are two additional points why this would be a bad idea:

1. Debian does not currently have non-amd64 binary-all autobuilders

Stating that binary-all packages in the archive are always being 
built on amd64 would actually document the current status quo,
assuming source-only uploads.

AFAIR pixfrogger and pixbros that I converted from binary-all to
an explicit list of all 32bit architectures were the last two
binary-all packages in main that could not be built on amd64.

These were pretty rare cases of requiring a 32bit-only package,
and such a rare hack is better than mandating that Debian must
add binary-all autobuilders for every architecture.


2. We were not able to build all binaries in a release

For aboot and palo we are shipping binaries in jessie that cannot be 
rebuilt in jessie since the build architecture is not part of jessie.

Cross-compilers are available on amd64, and this is how palo and 
openhackware were fixed for stretch.


> Cheers,
> Christoph
>...

cu
Adrian

- -- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlmAsLMACgkQiNJCh6LY
mLHeVg/9HBvcxd8rWE1A8NLi69mt7EsGWltjr5cTBRhQqptw9Rl+5U3aMBO1yuNN
MVG6vMe/71QAmny1w48PR+cyNkpeGqweO/wDoTO0IMSjFfWwXg0qYr6xOULXHTJU
Cms36EaMKXt7iOirA9m+GQz+b90h5ctu5BvGgb4gVEGo8/kZXJvjU0OxVLJChhRP
2NVknzohwau6rycviEHEGMajxsEb4VNjdSdP8uqsb4YvpDNlRWylJrMvj+T4mOX0
5wc4JOn5TAHYcmPmMecE/ZQM8ADzS/kGcIi+KZDIuTNWYfmQlC32s1INIrbZxdFF
U0wx1ceoJ3m235KmOrfwwY2s6cM8n5SC6ttZHWAVnFVt7OgdMz+7Pec6WHwvC2Hz
cCmUx2bAYvvCSRmtMbrg10K0/RnwRUqJO5DIuctoples1WVAGI1sOZ656Yg68W02
IV3sVKIgJ1mNaNFVjGppzJWNO6Z304psYF3I9iTVDECIxgbkc4OwYHJazO9k5aD5
uYWO7uLh/EiL2wTQkq6W9iY3wW+3P4u543acJ9xPYDIfYxqi40ud83VMdq4q7n0Y
jPOcpWAGAIC41IjT32iNf5BSrqIR8TO6CQG0zhYUQi6NHY+IE8Pmtt8JWdTbzlmw
ZR+GmgG773eCuzQgd3u0116LGMGEUT/jIk/HG3+ZZgzeoKKDg1Q=
=dkgN
-END PGP SIGNATURE-

Bug#844431: Status update from the Reproducible Builds project

[Adrian Bunk]

>...
> Debian Policy
> =
> 
> We are in the process of making reproducibility of packages something
> properly documented in policy.  Writing patches for policy is not easy,
> so we welcome input from everyone to be able to better consider all the
> needed facets.  See bug #844431 [16] for it.
> Also, we wish to remind everyone that Debian Policy aims at documenting
> current practices, it's not a "stick" to impose new rules.  That said,
> we believe reproducible builds to be among the best practices today.
>...

If it could be interpreted in the future to include things that are
not current practice today, it would be a stick to impose new rules.

The main problem is the lack of an exact definition what
"packages build in a reproducible manner" includes, and what not.

Bill already explained that "it is possible to reproduce" is a much 
easier problem to solve than "it will always be reproduced".

I would suggest a top-down approach to that:

What are the high-level guarantees reproducible builds plans to make 
for all packages in buster?

What exactly is required from every single package for that,
and also realistic to achieve for buster?

Once you have these plus a list of all remaining bugs, you can
go to the release team asking whether these can be considered
as release critical for buster.

At that point documenting this status quo for policy should
be straightforward.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#837478: Static libraries - PIC or PIE?

[Adrian Bunk]

On Sat, Nov 19, 2016 at 07:12:19PM -0700, Phillip Hellewell wrote:
>...
> - Now tries to link a few of the libraries statically (e.g.,
> libicuuc.a).  ld blows up with a bunch of relocation R_X86_64_32S, blah
> blah blah, recompile with -fPIC errors.

The error message is misleading, PIE is sufficient.

>...
> All they know is that for some reason they can't link most libraries
> statically without getting a bunch of weird errors.  It could take hours of
> research to figure out a workaround like -no-pie.

Submitting a bug against release-notes for having everything PIE 
releated properly documented would make sense.

> Given that GCC 6 on Debian 9 now does PIE executables by default, I think
> it becomes very necessary to consider that Debian out to build all static
> libraries with -fPIE (or -fPIC).

All static libraries in Debian will be recompiled with -fPIE before the 
release of stretch, for the ones where no uploads are happening for
other reasons binNMUs will be done.

> Otherwise you're going to get thousands
> and thousands of users having no clue why they can't link anything
> statically.  Plus if you did that you wouldn't have to build everything
> twice.  Win-Win !!!  So why not?

Building all static libraries with -fPIC (not just -fPIE) would be an 
insane amount of work, since you don't want to also build the binaries
with -fPIC.

> Thanks,
> Phillip

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#837478: Static libraries - PIC or PIE?

[Adrian Bunk]

On Sun, Oct 23, 2016 at 03:17:06PM +0200, Bálint Réczey wrote:
> Hi Adrian,
> 
> 2016-10-23 13:26 GMT+02:00 Adrian Bunk <b...@stusta.de>:
> > On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> >> Hi Ardian,
> >
> > Hi Bláint, ;-)
> 
> I'm sorry. :-)

No problem. :-)

>...
> >> This in many cases also simplify debian/rules.
> >
> > No, it would actually make building static libraries a real pain.
> 
> Could you please show an example?
> I went trough many packages and adding -fPIC was really
> straight-forward every time. OTOH packages providing both
> shared and static libraries build some parts twice like in antlr's
> case:

Usually building everything twice is done by the build system of the 
package, and debian/rules just calls $(MAKE)

> build-stamp:
> dh_testdir
> uudecode -o debian/antlr.snk debian/antlr.snk.uue
> $(MAKE) -f debian/Makefile.debian compile build_antlr
> $(MAKE) -C lib/cpp CXXFLAGS="+ -fPIC -DPIC"
> mv -f lib/cpp/src/libantlr.a debian/libantlr-pic.a
> $(MAKE) -C lib/cpp clean
> $(MAKE) -C lib/cpp
> touch build-stamp

That's a good example why this is a real pain.

You really don't want to force maintainers to dissect the build of their 
packages, especially in the normal case where just calling $(MAKE) was
working without your proposed requirement.

Just passing normal CFLAGS from dpkg-buildflags through the package 
build to the compiler is still not working in a huge number of packages 
after years, and this would be worse by several orders of magnitude.

> > Think of a normal source package building shared libraries,
> > static libraries and some programs.
> >
> > How do you want to tell the build system of the package that it should
> > build the static libraries with -fPIC, but not the programs?
> 
> It is usually already done by upstream or at least in packaging
> since we require -fPIC for shared libs.

You are completely wrong on that.

-fPIC is required and used for shared libraries.
Static libraries compiled with -fPIC are *very* rare.

Compiling with -fPIC for the shared library and without -fPIC for the 
static library is the one and (usually) only reason why all objects
are compiled twice when building libraries.

>...
> I assume non-PIC static library used in a PIC shared library is the
> specific case mentioned in the original text, which still does not
> work on any architecture.

Why do you want to forvce maintainers to go through great pain to get 
that working?

It is usually a bug when you end up linking a static library into a 
shared library, and in addition to a performance penalty you would
lose the benefit of getting a build failure for such bugs.

There are some rare cases of packages not building shared libraries. 
There might be other exotic situations where linking a static library 
into a shared library makes sense.
Requiring discussion of these on a case-by-case basis on debian-devel
as policy requires sounds pretty appropriate to me.

> >> > My current understanding is that a binNMU would recompile the the static
> >> > library with PIE (not PIC), and that this is sufficient.
> >>
> >> In most of the cases this would be sufficient, but at the time I filed the
> >> bugs the default was -no-pie, thus it was not an option.
> >
> > It is clear that the binNMUs have to happen after the change.
> 
> Yes, it was expected, but I think the changes would still be
> useful on architectures not enabling PIE because they allow
> enabling pie in reverse dependencies selectively.

Is there actually a good reason why PIE was only enabled on the release
architectures?

In any case, this would not provide any kind of reason for requiring 
to build static libraries with PIC.

>...
> Cheers,
> Balint

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#837478: Static libraries - PIC or PIE?

[Adrian Bunk]

On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> Hi Ardian,

Hi Bláint, ;-)

> 2016-10-23 10:18 GMT+02:00 Adrian Bunk <b...@stusta.de>:
> > Hi Bálint,
> >
> > there is some confusion regarding how static libraries should be
> > compiled now.
> >
> > Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".
> >
> > Why do these say -fPIC and not -fPIE?
> 
> I suggest using -fPIC, because then the shared libraries would be
> usable in shared (PIC) libraries libraries, too.

you have created a lot of confusion by mixing two separate issues.

One of the worst examples:
#837658 libfl-dev: Please build libfl_pic.a with -fPIC
#841203 nmu: flex_2.6.1-1

A _pic.a library compiled without -fPIC sounds like a clear bug,
and a binNMU that will recompile it with -fPIE won't fix that bug.

> This in many cases also simplify debian/rules.

No, it would actually make building static libraries a real pain.

Think of a normal source package building shared libraries,
static libraries and some programs.

How do you want to tell the build system of the package that it should 
build the static libraries with -fPIC, but not the programs?

> I also suggested changing the policy #837478.

Unless I misunderstand something, current policy is perfectly fine
for the PIE change, and your claims in #837478 that building static 
libraries with -fPIC would be required for PIE binaries are not
correct.

> > My current understanding is that a binNMU would recompile the the static
> > library with PIE (not PIC), and that this is sufficient.
> 
> In most of the cases this would be sufficient, but at the time I filed the
> bugs the default was -no-pie, thus it was not an option.

It is clear that the binNMUs have to happen after the change.

It would have created less confusion to not file bugs in cases where no 
maintainer action is required, ask the release team to schedule binNMUs 
for the static libraries known to need them immediately after the 
compiler change, and announce on debian-devel-announce that some 
transient build failures might be observed immediately after the 
compiler change until the binNMUs are done.

I'll sort out what binNMUs are required later today.

> I'm OK with performing binnmu-s and decreasing the severity of the 'solved'
> bugs to wishlist.

With the exception of special cases like #837658 a binNMU will 
completely solve it, and there is no point in having wishlist
bugs for something not really permitted by policy.

> Cheers,
> Balint

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#216104: Please clarify Section 2.5. required - essential

[Adrian Bunk]

Package: debian-policy
Version: 3.6.1.0
Severity: wishlist

Section 2.5. of your policy says:

--  snip  --

...
 `required'
  Packages which are necessary for the proper functioning of the
  system.  You must not remove these packages or your system may
  become totally broken and you may not even be able to use `dpkg'
  to put things back.  Systems with only the `required' packages
  are probably unusable, but they do have enough functionality to
  allow the sysadmin to boot and install more software.
...

--  snip  --


Packages you must not remove should be Essential (and tools like
apt-get don't contain any special handling for required packages).

It's often no problem to remove a required package, an example:
I've removed the required package mawk from my system years ago
and I never had any problems (gawk is installed instead).

I'd suggest to simply drop the following sentence:
  You must not remove these packages or your system may become totally
  broken and you may not even be able to use `dpkg' to put things back. 

Bug#176506: Make debconf mandatory for prompting the user

[Adrian Bunk]

On Sat, Jan 18, 2003 at 06:31:59PM +, Ian Jackson wrote:
 Adrian Bunk writes (Bug#176506: Make debconf mandatory for prompting the 
 user):
 ...
  The problem is that within the rules of your policy every single of your 
  over thousand maintainers can decide how he wants to maintain his 
  packages. Currently a maintainer can simply refuse to use debconf and 
  _noone_ can force him to use debconf. There are bugs with patches like 
  e.g. #127961 that are already ignored for a year or longer.
 
 This is, of course, not true.  The Technical Committee can overrule a
 maintainer.  Although, I think in this case it would be better to make

Yes, sorry, I forgot about the Technical Committee.

 a general rule in policy than to individually refer zillions of bug
 reports to the TC.

Yes, agreed.

 Ian.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#176506: Make debconf mandatory for prompting the user

[Adrian Bunk]

On Tue, Jan 14, 2003 at 03:54:03PM +0100, Roland Mas wrote:
 Adrian Bunk (2003-01-13 12:00:31 +0100) :
 
  I'm therefore suggesting that you change your policy to something like:
 
  --  snip  --
 
  ...
  2.3.9.1. Prompting in maintainer scripts
  
 
   Package maintainer scripts may prompt the user if necessary.
   Prompting must be done through programs like `debconf' that 
   conform to the Debian Configuration management specification,
   version 2 or higher.
  ...
 
  --  snip  -- 
 
 I agree with the spirit of the proposal, but I won't second it as is.
 Going directly from a may to a must is too quick in my opinion.
 Please make that a should first.  It'll still allow you to file bugs
 (although not serious ones), and it'll have a better chance of being
 accepted.  I'll second it, for a start :-)

The problem is:

debconf isn't new. Many packages already use it and the number of 
packages that don't use it and don't have an open wishlist bug is zero 
or at least not much bigger than zero.

The problem is that within the rules of your policy every single of your 
over thousand maintainers can decide how he wants to maintain his 
packages. Currently a maintainer can simply refuse to use debconf and 
_noone_ can force him to use debconf. There are bugs with patches like 
e.g. #127961 that are already ignored for a year or longer.

For purposes like automatic installation or upgrading of packages it is
required that _not a single_ of your over ten thousand packages prompts
the user without using debconf. Otherwise you always have to start to
special case every single package.

Debian already has a damned good infrastructure for automated tasks,
it's a shame that it's not really usable due to few packages not using
debconf.

 Roland.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#176506: Make debconf mandatory for prompting the user

[Adrian Bunk]

Package: debian-policy
Version: 3.5.8.0
Severity: wishlist


Your policy says:


--  snip  --

...
2.3.9.1. Prompting in maintainer scripts


 Package maintainer scripts may prompt the user if necessary.
 Prompting may be accomplished by hand, or by communicating with a
 program, such as `debconf', which conforms to the Debian Configuration
 management specification, version 2 or higher.
...

--  snip  --


I'm currently working on things like automated upgrading of many
( 100) computers. Debian already includes much infrastructure that
makes this task relatively cheap. For packages using debconf for
prompting the user it's easy to give the answers without pressing enter
on 100+ machines. It's a shame that most of the work is needed for
special casing the few packages not using debconf for prompting the
user.

I'm therefore suggesting that you change your policy to something like:

--  snip  --

...
2.3.9.1. Prompting in maintainer scripts


 Package maintainer scripts may prompt the user if necessary.
 Prompting must be done through programs like `debconf' that 
 conform to the Debian Configuration management specification,
 version 2 or higher.
...

--  snip  -- 


There's one problem that will arise:
Essential packages prompting the user.

There are two possible solutions for this problem:
1. essential packages have to check whether debconf is available and if
   yes have to use it
2. make debconf essential (it's already present on nearly every system
   since many packages already depend on it; it should be possible to
   remove the size of the debconf package by seperating separating 
   things like locales files away from the main package)


TIA
Adrian

BTW: Please Cc me on replies.

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#159114: acknowledged by developer (Patents can't cover software in .nl after all)

[Adrian Bunk]

reopen 159114
thanks

On Sun, 8 Sep 2002, Debian Bug Tracking System wrote:

...
 Hi,

   The relevant law, according to:
   http://www.ivir.nl/wetten/nl/row1995.html
 --
  2. The following are not regarded inventions in the sense of this law:
  - discoveries, scientific theories and mathematical methods
  - art
  - rules and methods for performing mental labour, playing, or
  running a company, as well as computer programs
 --

   I suppose hardware decoders etc may still be effected by that patent.

There remains the issue that _many_ Debian mirrors do mirror non-US which
means that the same issue might affect one or more of them.

Please make a separate patented and don't misuse non-US for this without
checking the possible legal implications in _all_ countries where servers
mirror non-US first.

   manoj

cu
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox

Bug#159114: debian-policy: non-us server is located in a country where it's possible to patent algorithms

[Adrian Bunk]

Package: debian-policy
Version: 3.5.7.0
Severity: important


--  snip  --

...
2.1.5. The non-US sections
--
...
 Programs which use patented algorithms that have a restrictied license
 also need to be stored on non-us, since that is located in a country
 where it is not allowed to patent algorithms.
...

--  snip  --


This seems to be wrong:


--  snip   --


$ nslookup non-us.debian.org
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
Server: 10.150.127.2
Address:10.150.127.2#53

Non-authoritative answer:
Name:   non-us.debian.org
Address: 130.89.175.34

$ nslookup 130.89.175.34
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
Server: 10.150.127.2
Address:10.150.127.2#53

Non-authoritative answer:
34.175.89.130.in-addr.arpa  name = debian.snt.utwente.nl.
34.175.89.130.in-addr.arpa  name = satie.debian.org.

Authoritative answers can be found from:
175.89.130.in-addr.arpa nameserver = ns1.surfnet.nl.
175.89.130.in-addr.arpa nameserver = ns1.utwente.nl.
175.89.130.in-addr.arpa nameserver = ns2.utwente.nl.
ns1.surfnet.nl  internet address = 192.87.106.101
ns1.utwente.nl  internet address = 130.89.1.2
ns2.utwente.nl  internet address = 130.89.220.2

$ 

--  snip  --


E.g. the mp3 patents by Thomson multimedia and the Fraunhofer
institute [1] are valid patents in the Netherlands.

cu
Adrian

[1] http://www.mp3licensing.com/patents/index.html

Re: Should debian policy require to use debconf for postinst scripts?

[Adrian Bunk]

On Mon, 10 Dec 2001, Anthony Towns wrote:

 On Mon, Dec 10, 2001 at 12:16:15PM +0100, Adrian Bunk wrote:
  - a package has it's documentation in /usr/doc
  - the maintainer gets a patch how to change it
  - the maintainer refuses the patch I want to have the documentation in
/usr/doc.
 
  - a package doesn't use debconf for interaction with the user while
asking the user questions at installation time
  - the maintainer gets a patch how to change it
  - the maintainer refuses the patch I don't want to use debconf.
 
  I don't get the point why it's all right to send a RC bug report in the
  first case but not in the second case.

 The point is people shouldn't be saying Oh, I don't want to do that
 for no reason whatsoever. And, indeed, they don't; they'll generally
 have a *reason* for doing so.

 The reason for the former being RC is that FHS compliance is RC
...

That's not an answery. Let me formulate my questionas follows:
Why do we _force_ our volunteer maintainers to do the FHS transition?
And why shouldn't we force our volunteer maintainers to use debconf?

 Cheers,
 aj

cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400

Re: Should debian policy require to use debconf for postinst scripts?

[Adrian Bunk]

On Mon, 10 Dec 2001, Anthony Towns wrote:

...
 aj, who'll be proposing the MUST/SHOULD nonsense be removed from the hands
 of policy when he gets some free time again

Let's play the evil maintainer game:

I play the evil maintainer who does everything with his packages that
isn't forbidden.
You (and others if they want) try to convince me that I'm wrong.

We could set some goals, e.g. I win when I get three packages statically
linked against libc (the idea comes from the thread about gnumeric
linking statically with libgal that is currently on debian-devel) into
testing and you win if you convince me not to do this...


Yes, I know this sounds ridiculous, but remember that we have 900
different people maintaining our packages - and every person has his own
personality.


cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400

Re: Should debian policy require to use debconf for postinst scripts?

[Adrian Bunk]

On Sat, 8 Dec 2001, Anthony Towns wrote:

...
 If you want every package to use debconf, that's fine and wonderful. Go
 make a list of the ones that don't, write patches so that they will, file
 bugs so the maintainer knows about them, then have a friendly discussion
 with the maintainers to make sure that they're satisfied with the patches.

Let me compare two cases:

- a package has it's documentation in /usr/doc
- the maintainer gets a patch how to change it
- the maintainer refuses the patch I want to have the documentation in
  /usr/doc.

- a package doesn't use debconf for interaction with the user while
  asking the user questions at installation time
- the maintainer gets a patch how to change it
- the maintainer refuses the patch I don't want to use debconf.

I don't get the point why it's all right to send a RC bug report in the
first case but not in the second case.


 Cheers,
 aj

cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400

Re: Should debian policy require to use debconf for postinst scripts?

[Adrian Bunk]

On Wed, 5 Dec 2001, VALETTE Eric wrote:

 I have been discussing quite a lot on different debian mailing list on a
 way to automate debian installation. The final and almost unfiform
 answer was to use debconf in non-interactive mode.

 The technical reason is that due to use of tty the following command
 does not work :

 dpkg -i pakace  EOF
 input1
 input2
 EOF
...
 So far the following packages do not follow the rule :
  1) lilo,
  2) wu-ftpd,
  3) php4-* pacakges,
  4) bind

5) exim  (our default MTA)

...
 So could the debian policy regarding package postinst script ask either
 to use debconf for automatic install or at least provide a mean to user
 to answer question asked by postinst script to be entered via scripts or
 files but no typing required.

 Thanks for any comment and sorry if that has already been discussed.

I will support a proposal that every interaction with the user a package
makes with the user during installation must be done using debconf. But
this is a post-woody thing.

cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400

Re: Should debian policy require to use debconf for postinst scripts?

[Adrian Bunk]

On Thu, 6 Dec 2001, Anthony Towns wrote:

...
 If debconf isn't good enough that everyone's not using it voluntarily
 (lilo has been converted *from* debconf), then the obvious thing to do
 is to improve debconf, not try to force everyone to make their packages
 worse.
...

Which of these cases is true?
1. debconf misses functionality needed
2. bugs in debconf
3. it's some work to use debconf

The only important thing is 1.

2. isn't really an issue because Joey Hess is really quick with fixing
bugs.

It's some work for a maintainer to convert a package that simply uses
things like cat EOM for interaction with the user to debconf - and if
the maintainer is for any reason not willing to convert his package (he
might even refuse a patch) the only way to force him to make this change
is when policy says he has to do it.

 Cheers,
 aj

cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400

Bug#109432: Section 9.6 should mention the case that a source package builds the library itself

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: debian-policy
Version: 3.5.6.0
Severity: normal


Section 9.6 of the policy says about debian/shlibs.local:

 This file is intended only as a _temporary_ fix if your binaries or
 libraries depend on a library whose package does not yet provide a
 correct `shlibs' file.



I propose to add a note that a debian/shlibs.local must be there when
the source package builds the library itself.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7gY/UmfzqmE8StAARApEcAKC9T7uEGG5Quy/VDmmXf8b0cTE5+wCgujxV
/tq9blEgDzhajH7AEEdyuv8=
=UIQv
-END PGP SIGNATURE-

cu
Adrian

-- 

Get my GPG key: finger [EMAIL PROTECTED] | gpg --import

Fingerprint: B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400

Re: woody release task needs help: package priorities

[Adrian Bunk]

On Fri, 18 May 2001, Anthony Towns wrote:

...
 Since there's a 'tetex' task, I've also dropped tetex from standard to
 optional: people who want TeX will need to choose the task now.

Current policy says:

--  snip  --

 `standard'
  These packages provide a reasonably small but not too limited
  character-mode system.  This is what will install by default if
  the user doesn't select anything else.  It doesn't include many
  large applications, but it does include Emacs (this is more of a
  piece of infrastructure than an application) and a reasonable
  subset of TeX and LaTeX.

--  snip  --


Does this mean that you are only waiting for the split of the tetex-*
packages to get the ones that don't depend on X back to standard?


 Cheers,
 aj


cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Bug#87510: I second this proposal

[Adrian Bunk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



--  snip  --

Policy should now require packages to specify build time dependencies
(i.e., packages which require ... MUST specify...)

Build time dependencies have been in policy for 18 months already.

--  snip  --


I second this. (but there must be a note that packages that build
with only essential and build essential packages don't need build
dependencies)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7BLeUmfzqmE8StAARAmBsAJ0d1Vxjt88M/Qb7blESNQsMFWveEwCffWZr
GDcHs3snbXfH9K6Dsjb2Fd8=
=E6pg
-END PGP SIGNATURE-

Is it allowed to remove old changelog entries?

[Adrian Bunk]

Hi,

I had some time ago a discussion with Paul Slootman in #85936 about the
removal of old changelog entries. He did remove at one point all changelog
entries except the latest on (and Raphael Bossek did recently the same in
some of his packages). Paul simply closed #85936 with the comment

--  snip  --

Please explain where in policy does it state that the COMPLETE
changelog from years and years has to be retained.

--  snip  --

It seems he's right and I can't find a place in the policy that forbids
the deletion of old changelog entries or did I miss something?

cu
Adrian

PS: Please Cc me since I'm not on this list.


-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Is it allowed to remove old changelog entries?

[Adrian Bunk]

On Mon, 14 May 2001, Colin Watson wrote:

...
 Also see #82790, whose maintainer apparently never keeps more than one
 changelog entry. Unfortunately, unless someone has the old changelog
 entries and can NMU, not a lot can be done about it.

After reading Thomas' answer it seems to be the correct solution to
downgrade #82790 to wishlist...

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Bug#96458: xv is NOT a native Debian package (fwd)

[Adrian Bunk]

Hi,

could someone else please read the discussion in #96458 answer Philippe?
I'm tired of this frustrating discussion with someone who tried to make
xv a native Debain package.

TIA
Adrian

PS: Please Cc me because I'm not on this list.


-- Forwarded message --
Date: 07 May 2001 17:41:23 -0700
From: Philippe Troin [EMAIL PROTECTED]
To: Adrian Bunk [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Bug#96458: xv is NOT a native Debian package

Adrian Bunk [EMAIL PROTECTED] writes:

 On 7 May 2001, Philippe Troin wrote:

  No, native vs. non-native is just the absence vs. presence of the
  debian revision suffix, but maybe I'm wrong. I could not find anything
  in the policy manual that says that native debian packages should have
  a .tar.gz source while the non-native debian packages should have a
  .orig.tar.gz + .diff.gz.


 A good explanation is in the Developer's Reference:

Developper's reference is not policy.

 --  snip  --

 5.5. Packages
 -

  There are two types of Debian packages, namely _source_ and _binary_
  packages.

  Source packages consist of either two or three files: a `.dsc' file,
  and either a `.tar.gz' file or both an `.orig.tar.gz' and a `.diff.gz'
  file.

  If a package is developed specially for Debian and is not distributed
  outside of Debian, there is just one `.tar.gz' file which contains the
  sources of the program.  If a package is distributed elsewhere too,
  the `.orig.tar.gz' file stores the so-called _upstream source code_,
  that is the source code that's distributed from the _upstream
  maintainer_ (often the author of the software).  In this case, the
  `.diff.gz' contains the changes made by the Debian maintainer.

  The `.dsc' lists all the files in the source package together with
  checksums (`md5sums') and some additional info about the package
  (maintainer, version, etc.).

I don't think there's anything in the policy that mandates that the
non-native packages must come as a .orig.tar.gz and a .diff.gz.

The .tar.gz contains the upstream source if you look into it.

Phil.

Re: Bug#96458: xv is NOT a native Debian package (fwd)

[Adrian Bunk]

On Thu, 10 May 2001, Joey Hess wrote:

...
 People who read policy like rules lawyers are often disappointed and
 often do foolish things. Please bring common sense with you when you
 open the policy manual.

When I read the policy like a lawyer I get answers like this was not
intended and when I read the policy with common sense I get answers like
the Developper's reference is not policy that Phil said in the
discussion of #96458.

I did think our policy contains the rules we follow to produce good
packages and I was proud that we have something like this - at the moment
I tend to see it as a piece of (virtual) paper that has less value than
the words of the release manager.

cu
Adrian (who waits that ajt downgrades #97040)

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Adrian Bunk]

On Sun, 6 May 2001, Chris Waters wrote:

   Didn't we already have this discussion?  The Standards-Version field
   is not a reliable indication of much of anything.  I strongly object

  Policy says:

 Policy says doesn't make the packages comply.  And you can file all
 the bugs reports you want, but that doesn't magically fix the
 packages.  And until they're fixed, you can't use them as a reliable
 indicator of FHS compatibility.  QED.

Standards-Version  3 :
a not FHS compliant package is at most a normal bug

Standards-Version = 3:
a not FHS compliant package is at most a serious bug

 We have many packages with old Standards-Versions which actually
 comply with newer standards and *are* FHS compatible, and we have
 packages with newer Standards-Versions that are NOT FHS compatible.

Please file RC bug on packages with Standards-Version = 3 that are not
FHS compatible.

 I think that if you really want to focus on FHS compatibility, you're
 better off ignoring the Standards-Version issues for now.  Its just
 another can of worms.  Picking the minimum Standards-Version for
 release is something we normally do at freeze time.

I think it's important that our packages follow a not too outdated policy
and the Standards-Version field is the indicator for this. Freeze time
is too late for picking the minimum Standards-Version for release - the
right time would be shortly after the last stable was released. An
example: It would be nice to have a minimum Standards-Version of 3.1 (that
includes build dependencies), but you can't file 1060 RC bugs at the
beginning of a freeze.

...
 Note that the next paragraph mentions filing bug reports if the
 package becomes too much out of date.  If any is too much, why
 bother to say too much?

You mustn't have to upgrade the Standards-Version field when your package
doesn't comply with a more recent policy - a package that doesn't follow
FHS will never rech Standards-Version 3.0 .

   to removing packages because of what amount to cosmetic issues, and an

  Where did I say that I want to remove the packages???
  I said that I want to send bug reports.

 RC bugs mean the package must be removed from the next release if it's
 not fixed.  Unless you can guarantee that the bugs will be fixed
 (i.e., you're volunteering to fix them yourself), you _are_ asking for
 package to be removed when you file RC bugs.

These bugs are relatively easy to fix bugs and many of them will be fixed
at a bug squashing party - and yes, I do fix many easy to fix bugs at
each bug squashing party. But BTW: When a maintainer doesn't even when
there's a RC bug starts to work on upgrading the package to comply with a
policy that is nearly two years old there's the question of he's MIA.

 Anyway, I apologize for a reminder I'm sure you don't need.  It's just
 a habit of mine, please forgive me.

 Bottom line, I think there remains a lot of work checking the subtle
 and not-so-obvious stuff in the FHS before we can confidently claim
 FHS compatibility (and even *begin* to work on actual compliance).

Reading the last three sentence I'm glad to hear that you volunteer to do
all this checks...

...
 And I think mass filings of RC bugs would be premature at best.

It's perhaps really late because we are relatively close too a freeze but
it's definitely not premature.

 cheers

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Finishing the FHS transition

[Adrian Bunk]

Hi,

I want to suggest to finish the FHS transition. This includes the
following steps:

- Packages with Standards-Version = 3.0 must follow the FHS.
  Policy version 3.0.0.0 was released 30 Jun 1999 and I consider this
  enough time for every maintainer to switch to at least this
  Standards-Version. However, there are still 253 packages in unstable
  (including contrib, non-free and non-US/*) that have an older
  Standards-Version in the control file. The list (sorted by maintainer)
  follows below. Some of the maintainers are perhaps MIA, others are
  definitely not. If noone has a good argument against this I'll send
  RC bugs in one week to force the upgrade of the Standards-Version.

- A change in the policy to remove the obsolete /usr/doc symlinks.


List of packages with Standards-Version  3.0

--  snip  --

Adam Di Carlo ([EMAIL PROTECTED])   onshore-timesheet
Adam Klein ([EMAIL PROTECTED])   ncompress
Alan Bain ([EMAIL PROTECTED]) nec
Alex Romosan ([EMAIL PROTECTED])   f77reorder
Alex Romosan ([EMAIL PROTECTED])   nte
Alex Romosan ([EMAIL PROTECTED])   vat
Alistair Cunningham ([EMAIL PROTECTED])xchain
Anders Hammarquist ([EMAIL PROTECTED])  sformat
Andreas Franzen ([EMAIL PROTECTED])   pgapack
Anthony Fok ([EMAIL PROTECTED])lexmark7000linux
Anthony Towns ([EMAIL PROTECTED])   cruft
Anthony Towns ([EMAIL PROTECTED])   distributed-net-pproxy
Apt Packaging Team ([EMAIL PROTECTED]) gnome-apt
Araki Yasuhiro ([EMAIL PROTECTED])   kcc
Arpad Magosanyi ([EMAIL PROTECTED])barracuda
Avery Pennarun ([EMAIL PROTECTED]) apmd
Avery Pennarun ([EMAIL PROTECTED]) netselect
Avery Pennarun ([EMAIL PROTECTED]) wvdial
Ben Gertzfield ([EMAIL PROTECTED])  gimp
Ben Gertzfield ([EMAIL PROTECTED])  wmifs
Bernd Schumacher ([EMAIL PROTECTED])   snmptraplogd
Björn Brenander ([EMAIL PROTECTED])   tcputils
Brad Bosch ([EMAIL PROTECTED])id-utils
Brent A. Fulgham ([EMAIL PROTECTED])   bbmail
Brent A. Fulgham ([EMAIL PROTECTED])   efuns
Brent A. Fulgham ([EMAIL PROTECTED])   openacs
Brian Bassett ([EMAIL PROTECTED])sml-nj
C. Thomas ([EMAIL PROTECTED])   wmheadlines
Carey W. Evans ([EMAIL PROTECTED])x3270
Chad Miller ([EMAIL PROTECTED]) sc
Charles Briscoe-Smith ([EMAIL PROTECTED])  bock
Charles Briscoe-Smith ([EMAIL PROTECTED])  cup
Charles Briscoe-Smith ([EMAIL PROTECTED])  gramofile
Charles Briscoe-Smith ([EMAIL PROTECTED])  infocom
Charles Briscoe-Smith ([EMAIL PROTECTED])  int-fiction
Charles Briscoe-Smith ([EMAIL PROTECTED])  jlex
Charles Briscoe-Smith ([EMAIL PROTECTED])  libggidemos
Charles Briscoe-Smith ([EMAIL PROTECTED])  propsel
Charles Briscoe-Smith ([EMAIL PROTECTED])  recite
Charles Briscoe-Smith ([EMAIL PROTECTED])  rocks-n-diamonds
Charles Briscoe-Smith ([EMAIL PROTECTED])  saytime
Charles Briscoe-Smith ([EMAIL PROTECTED])  strn
Charles Briscoe-Smith ([EMAIL PROTECTED])  xggi
Chris Leishman ([EMAIL PROTECTED])  cfs
Chris Leishman ([EMAIL PROTECTED])  urlredir
Christian Hammers ([EMAIL PROTECTED])myodbc2.50.26
Christian Leutloff ([EMAIL PROTECTED]) rxtx
Christian Meder ([EMAIL PROTECTED]) afbackup
Christian Meder ([EMAIL PROTECTED]) ftape-doc
Christian Meder ([EMAIL PROTECTED]) ftape-tools
Christoph Lameter ([EMAIL PROTECTED])wmf
Christoph Martin ([EMAIL PROTECTED]) pgp5i
Christophe Le Bars ([EMAIL PROTECTED])  doc-debian-fr
Chu-yeon Park ([EMAIL PROTECTED])rat
Clint Adams ([EMAIL PROTECTED])  set6x86
Craig Sanders ([EMAIL PROTECTED])   dlocate
Craig Sanders ([EMAIL PROTECTED])   libdevel-symdump-perl
Craig Sanders ([EMAIL PROTECTED])   libfile-tail-perl
Craig Sanders ([EMAIL PROTECTED])   speedy-cgi-perl
Craig Sanders ([EMAIL PROTECTED])   tkinfo
Dale E. Martin ([EMAIL PROTECTED])tyvis
Dale James Thompson ([EMAIL PROTECTED])   postilion
Daniel Martin ([EMAIL PROTECTED])cqcam
Daniel Martin ([EMAIL PROTECTED])tkdesk
Darren Benham ([EMAIL PROTECTED]) wmcpu
Darren Benham ([EMAIL PROTECTED]) wmdate
Darren Benham ([EMAIL PROTECTED]) wmgrabimage
Darren Benham ([EMAIL PROTECTED]) 

Re: Finishing the FHS transition

[Adrian Bunk]

On Sun, 6 May 2001, Chris Waters wrote:

  I want to suggest to finish the FHS transition. This includes the
  following steps:

  - Packages with Standards-Version = 3.0 must follow the FHS.

 Didn't we already have this discussion?  The Standards-Version field
 is not a reliable indication of much of anything.  I strongly object

Policy says:

--  snip  --

 In the source package's `Standards-Version' control field, you must
 specify the most recent version number of this policy document with
 which your package complies.  The current version number is 3.5.4.0.

 This information may be used to file bug reports automatically if your
 package becomes too much out of date.

--  snip  --

 to removing packages because of what amount to cosmetic issues, and an

Where did I say that I want to remove the packages???
I said that I want to send bug reports.

 incorrect Standards-Version (one that doesn't reflect the version of
 policy that the package _actually_ complies with) is really no more
 than a cosmetic issue (no software actually uses that field).

you must specify the most recent version number of this policy document
with which your package complies: You must upgrade this field when your
package complies with a more recent policy - and when your package does
already comply with a more recent policy nothing more than an upload with
an updated Standards-Version field is needed.

 I only have a few of the listed packages installed on my system, but
 most of the ones I checked did indeed use /usr/share/doc (and
 /usr/share/man, in those cases where man pages were present).  I
 suspect that this is due to the use of debhelper, but anyway

 Checking for FHS violations should be done by checking for FHS
 violations, not by checking an unreliable and all-but-meaningless
 field in some configuration file.
...

See above: I want to file a RC bug either because
a) the package follows a too old policy or
b) because it violates the _must_ in the polict that says that the
   Standard-Version must get updated.

a) needs discussion whether we consider packages not following the FHS
too much out of date, b) is a violation of the policy that doesn't need
discussion - that means the only question is whether anyone disagrees that
we want to have all packages in unstable to follow the FHS.

 cheers

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Bug#89807: packaging-manual still refers to /usr/doc

[Adrian Bunk]

Package: packaging-manual
Version: 3.2.1.0
Severity: normal



$ zgrep usr/doc /usr/doc/packaging-manual/packaging.text.gz 
 `/usr/doc/copyright/GPL' in the Debian GNU/Linux distribution or on
  dpkg --fsys-tarfile filename.deb | tar xof usr/doc/\*copyright | less
  file from `/usr/doc/package/copyright' to
  `/usr/doc/copyright/package'.  If it isn't then find
 * Change `/usr/doc/examples/package' to
   `/usr/doc/package/examples'.
$



This seems to include some cases for a s|/usr/doc|/usr/share/doc|



-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux r063144.stusta.swh.mhn.de 2.4.2-ac20 #2 Tue Mar 13 13:03:37 CET 
2001 i586

Versions of packages packaging-manual depends on:
ii  fileutils 4.0.37-1   GNU file management utilities.

Re: packages with really old standards version

[Adrian Bunk]

On Wed, 21 Feb 2001, Anthony Towns wrote:

 On Tue, Feb 20, 2001 at 06:27:40PM -0800, Sean 'Shaleh' Perry wrote:
  I file any bugs I detect, once I get lintian running on the archive, old
  packages beware (-:
 
  A package of 2.x policy behaves in a way different than current packages.
 
  They lack a /usr/share/doc, their manpages are not in share either.  They
  may violate other things.  Point is, these packages will be a source of 
  bugs.

 Sure, but lacking /usr/share/doc is, aiui, a non-RC issue as it stands
 (since there seems to be some sort of deadlock in working out what to do
 about it)...
...

In a message sent in this thread only a good hour before this mail you
said you want that RC are filed for packages lacking /usr/share/doc (and
all the /usr/doc problems and symlinks can go away as soon as all packages
have moved their documentation to /usr/share/doc):

--  snip  --

...
severity); and I'd definitely encourage the lintian maintainer to file
serious bugs about automatically detect-able violations of any MUST
directives in current policy (no matter what standards-version the
packages claims to comply with).
...

--  snip  --


A package that puts it's documentation in /usr/doc violates a must in
section 10.1.1. of the policy:

--  snip  --

10.1.1. Linux File system Structure
---

 The location of all installed files and directories must comply with
 the Linux File system Hierarchy Standard (FHS).  The latest version of
 this document can be found alongside this manual or on
 http://www.pathname.com/fhs/.  Specific questions about following the
 standard may be asked on `debian-devel', or referred to Daniel
 Quinlan, the FHS coordinator, at [EMAIL PROTECTED].

--  snip  --


 Cheers,
 aj

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: only release packages that have maintainers?

[Adrian Bunk]

On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote:

 Anyone have comments on the idea that the only packages we should release are
 ones that have a maintainer, not Debian QA?

Then I'll adopt all the packages that don't have a maintainer and send
RFAs for them (like I did with several of the packages tbm wanted to
remove). But I take care about them when the maintainer is set to Debian
QA, too, so I can't see the big difference.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: only release packages that have maintainers?

[Adrian Bunk]

On Tue, 20 Feb 2001, Brian Russo wrote:

 On Tue, Feb 20, 2001 at 07:56:04PM +0100, Adrian Bunk wrote:
  On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote:
 
   Anyone have comments on the idea that the only packages we should release 
   are
   ones that have a maintainer, not Debian QA?

 This isn't such a bad idea.

 
  Then I'll adopt all the packages that don't have a maintainer and send
  RFAs for them (like I did with several of the packages tbm wanted to
  remove). But I take care about them when the maintainer is set to Debian
  QA, too, so I can't see the big difference.

 Yes, well as I've said to tbm, 1) adopting a package just to 'save'
 it, without really caring/wanting it just perpetuates old crufty

I care about these packages:
- they have no open RC bugs
- I fix all other bugs I can fix without spending too much time
- they have all a Standards-Version = 3.1
  (that means their Standards-Version is higher than the one of 25%
   of the packages in Debian!)

 packages in Debian, while some of these ancient neglected packages
 are just.. neglected, others are genuinely useless I think,
 otherwise would someone not have cared, and grabbed it?

I remember that silo was orphaned for several months before someone
adopted it...

 Which brings me to 2) can we get rid of more of these old crufty
 ones? Everyone is so afraid do this, else they'll get flamed for
 being evil and removing old packages! indeed the impertinence.
...

How do you decide if something is old crufty? I believe that of Our
Priorities are Our Users and Free Software and that's why I want that
there's a good reason when a package gets removed.


cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: only release packages that have maintainers?

[Adrian Bunk]

On Tue, 20 Feb 2001, Brian Russo wrote:

 On Tue, Feb 20, 2001 at 08:57:39PM +0100, Adrian Bunk wrote:
  On Tue, 20 Feb 2001, Brian Russo wrote:
 
   On Tue, Feb 20, 2001 at 07:56:04PM +0100, Adrian Bunk wrote:
On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote:
   
Then I'll adopt all the packages that don't have a maintainer and send
RFAs for them (like I did with several of the packages tbm wanted to
remove). But I take care about them when the maintainer is set to Debian
QA, too, so I can't see the big difference.
  
   Yes, well as I've said to tbm, 1) adopting a package just to 'save'
   it, without really caring/wanting it just perpetuates old crufty
 
  I care about these packages:
  - they have no open RC bugs
  - I fix all other bugs I can fix without spending too much time
  - they have all a Standards-Version = 3.1
(that means their Standards-Version is higher than the one of 25%
 of the packages in Debian!)

 eh?
...

I was refering to the adopting a package just to 'save' it. This is the
state of the 15 packages I have currently adopted to avoid their removal
(and the last two will follow soon).

 Not all orphaned packages are like this, but there are a fair
 number. I'm not talking about the packages that have been orphaned
 for only a few months.

And I do sometimes make uploads for orphaned packages to fix bugs, upgrade
the Standards-Version and sometimes upload a new upstream version.

   packages in Debian, while some of these ancient neglected packages
   are just.. neglected, others are genuinely useless I think,
   otherwise would someone not have cared, and grabbed it?
 
  I remember that silo was orphaned for several months before someone
  adopted it...

 I'm not talking about several months, more like 1 year+, there are
 many of these in wnpp.

Since the cleanup Martin made there can't be many that are orphaned for
more than half a year with noone who intends to adopt them.

   Which brings me to 2) can we get rid of more of these old crufty
   ones? Everyone is so afraid do this, else they'll get flamed for
   being evil and removing old packages! indeed the impertinence.
  ...
 
  How do you decide if something is old crufty? I believe that of Our
  Priorities are Our Users and Free Software and that's why I want that
  there's a good reason when a package gets removed.

 If something has been abandoned for a 1 year and a half, you don't
 think it's crufty?

Not automatically.

I'm willing to spend some time on the packages that are orphaned, it
doesn't matter if they are officially maintained by QA or by me. Has
anyone a good reason why it's bad when I take care of these packages
instead of seeing them getting removed? I can't see the benefits when we
get rid of let's say 50 packages.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: only release packages that have maintainers?

[Adrian Bunk]

On Tue, 20 Feb 2001, Brian Russo wrote:

...
 example: saml
 There is 7 open bugs on it (1 serious, 6 normal, 1 wishlist)
 Standards-Version: 2.3.0.1
 upstream last touched it approximately /four/ years ago.
...

I forgot to say about this example:
Ian Zimmerman [EMAIL PROTECTED] intends to adopt this package so
there's a Debian maintainer for this package.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: packages with really old standards version

[Adrian Bunk]

On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote:

 So, I grabbed fmirror today because an admin friend suggested it.  I cd'ed to
 /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror.  I check
 the changelog and this binary-any package has not been uploaded in 2 years.  
 It
 is standards version 2.3.0.1, ICK!

 So, perhaps we should drop the bar a little.  If your package is not at least
 3.x.x, it gets held.

Just for the record: ftp.debian.org has currently 579 source packages with
standards version  3.0.0

And just out of curiosity: apt has standards version 2.4.1

And more serious: If you want to force the upgrade of the standards
version you must file 579 RC bugs on these packages.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: only release packages that have maintainers?

[Adrian Bunk]

On Tue, 20 Feb 2001, Martin Michlmayr wrote:

 * Sam Hartman [EMAIL PROTECTED] [20010220 17:04]:
  What you need to realize (and probably do) is that you have finite
  time and that if after a while you no longer have time to maintain the
 ...
  are willing to remove the packages if you fail to find someone who can
  take care of them, then I think you're providing a useful service to
  the community.

 This is what I sent to Adrian recently; I'm reposting it here since I
 think some kind of Release Notes would be nice:

 If you do something worthwhile then write good Release Notes saying
 which packages have been removed and listing better replacements if
 there are any (e.g. upsd should be removed, replacement is nut and
 possibly others).  That would be our users a better service that
 keeping packages around which are e.g. not even maintained upstream
 anymore.

And my personal opinion is that I prefer to keep a package if there's not
a _good_ reason why it should get removed (and yes - it happens that I
see a good reason why a package should get removed).

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: only release packages that have maintainers?

[Adrian Bunk]

On Tue, 20 Feb 2001, Brian Russo wrote:

...
  I'm willing to spend some time on the packages that are orphaned, it
  doesn't matter if they are officially maintained by QA or by me. Has
  anyone a good reason why it's bad when I take care of these packages
  instead of seeing them getting removed? I can't see the benefits when we
  get rid of let's say 50 packages.

 I'm not saying you don't have a right to upload -qa packages or any
 such thing. What I don't understand is if you really think they're
 useful, why you don't adopt them outright (no, not adopt then RFA).

 One of the present tasks of the -qa team is maintaining orphaned
 packages, but beyond a certain point, they must be dropped.

 Benefits of removing 50 crappy packages:
 o.Number of bugs in general goes down.
 o.Users are confronted with less crap to install
 o.Fewer collisions in the package name/file system namespace.
 o.Less load on BTS, ftp archives, mirrors, et al.

We are talking about less than 1% of the packages in Debian, less packages
than the number of new packages each week.

 o.Debian has less of a reputation for having old, worthless crappy
   packages.

When you can say why a package is worthless for everyone I think this is a
good reason for a removal.

 o.QA team can (maybe) spend time ACTUALLY doing QA instead of
   maintaining old, worthless packages that nobody visibly cares about.

I want to spend time on this packages to avoid them getting removed.

 o.If they're crappy worthless packages, what's the real benefit of
   having them any? And WHY hadn't they been adopted ages ago?

Not every user is a developer?

 o.Fewer flamewars on old crappy packages on -policy, -qa, etc.

I think there are fewer flamewars when we keep the packages...

...
 one last thought, it seems accepted that its ok for maintainers to
 ask for their packages to be removed, if this is true, would anyone
 object if i adopted a package then asked for its removal?
 i know this is silly, but then i think this whole thread is silly.

The day after the package was removed I can send an ITP and upload a new
package where I'm the maintainer and you can't stop this package from
being in Debian again...
Sorry, are we kids and everyone of us wants to be the most clever kid or
are we intelligent adults?

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Question about native packages

[Adrian Bunk]

Hi,

I have with Siggi Langauf (the maintainer of xine) a discussion in bug
#84754 whether xine is a Debian native package or not.

The facts are:
- xine is a MPEG, VCD, DVD audio/video player for X11 that runs e.g. on
  FreeBSD
- Siggi is both upstream and Debian maintainer and he include the debian/
  subdirectory in his upstream sources

Our discussion is about the following part of chapter 4 of the policy:

--  snip  --

4. Version numbering


 Every package has a version number, in its `Version' control file
 field.
...
 The three components here are:
...
 debian-revision
  This part of the version represents the version of the
  modifications that were made to the package to make it a Debian
  binary package.  It is in the same format as the
  upstream-version and is compared in the same way.

  It is optional; if it isn't present then the upstream-version
  may not contain a hyphen.  This format represents the case where
  a piece of software was written specifically to be turned into a
  Debian binary package, and so there is only one `debianization'
  of it and therefore no revision indication is required.
...

--  snip  --

My interpretation of the last sentence is:
The software has solely been written for one purpose: being turnded into a
Debian binary package.
The and so there is only one `debianization' is a conclusion that only
applies when the piece of software was written specifically to be turned
into a Debian binary package.

Siggi's interpretation is:
The software has been written with all the specific things in mind and
including anything necessary to turn it into a debian binary package.
The and so there is only one `debianization' is an explanation and not
a conclusion.



Could you please clarify whether xine is a native Debian package or not?



Thanks in advance,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: Question about native packages

[Adrian Bunk]

On Sun, 4 Feb 2001, Siggi Langauf wrote:

 Hi,

Hi Siggi,

 On Sun, 4 Feb 2001, Henrique M Holschuh wrote:

  [...]
  1. Are you likely to do small revisions that only affect the debian/
 subdir, and the source package is big ?
 
 - if yes, choose non-native, because you'll not need to reupload
the .orig.tar.gz file, just the diff, dsc and changes file.

 Currently, it's very unlikely that I release a debian-only update of
 xine. There's a new upstream version every two weeks (at maximum,
 averagely every week). Even if I would make a debian only change a few
 hours after a normal release, there are typically a few other changes in
 CVS...

consider the situation when an older version of your package is in frozen
and you must fix a RC bug but the release manager won't allow you to
upload a version that contains other changes (and the version already in
unstable contains other changes). If your package is native you'll have to
make a second branch of your upstream package.

...
 Regards,
   Siggi

cu,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: Question about native packages

[Adrian Bunk]

On Sun, 4 Feb 2001, Nicolás Lichtmaier wrote:

  Native is best choosen for packages which are not expected to be used
  outside of Debian, btw. If I were xine's upstream, I'd package it as
  non-native.  The non-native format is more flexible.

  Packaging it native is a perfectly valid thing to do, even better than
 nonnative. Why? Because the Debian packaging files can be used by anyone,
 not just Debian. Just as the .spec files are now included in many packages.

If your package isn't a native package you can still include the debian/
subdirectory in your upstream sources.

There are only two differences compared to a native packge:
- The version number is 0.3.6-1 instead of 0.3.6 .
- There's a separate Debian changelog besides the upstream changelog (that
  doesn't tell the user about FreeBSD changes when he upgrades the package
  as xine currently does).

cu,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: Question about native packages

[Adrian Bunk]

On Sun, 4 Feb 2001, Siggi Langauf wrote:

  If your package isn't a native package you can still include the debian/
  subdirectory in your upstream sources.

 Right.

  There are only two differences compared to a native packge:
  - The version number is 0.3.6-1 instead of 0.3.6 .

 Aha. There doesn't have to be a .diff.gz??

You can simply untar your xine_0.3.6.orig.tar.gz and run dpkg-buildpackage
and you'll get a xine_0.3.6-1.diff.gz that is empty.

  - There's a separate Debian changelog besides the upstream changelog (that
doesn't tell the user about FreeBSD changes when he upgrades the package
as xine currently does).

 Aehm, and it wouldn't tell the user about new subtitle support, AC3
 digital out support, the new contrast/brightness dialog, etc. Does that
 really make sense?

Noone prevents you from writing about upstream changes in the Debian
changelog, but it looks a bit funny when I see changes in the FreeBSD port
[1] when upgrading my Debian package.

 There's something else implicated by a non-native package: It's a clear
 statement that Debian is different, something many non-Debian users told
 me they don't like about Debian...

Where do non-Debian users see if the package is a native Debian package or
not and where does it make a difference?

   Siggi

cu,
Adrian

[1] I'm using apt-listchanges


-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: [PROPOSAL] Allowing crypto in the main archive

[Adrian Bunk]

On Thu, 11 Jan 2001, Wichert Akkerman wrote:

 Previously Marco d'Itri wrote:
  But is it non-US/main or non-US/non-free?

 non-US/main, since the license to the software itself is free.

But if I don't misunderstand chapter 7 (and 8) of the GPL a program
licenced under the GPL that is threatened by a patent may no longer be
DFSG-free.

 Wichert.

cu,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: [PROPOSAL] Allowing crypto in the main archive

[Adrian Bunk]

On Wed, 10 Jan 2001, Wichert Akkerman wrote:

...
  Non-free programs with cryptographic program code need to be stored
  on the non-us server because of export restrictions of the U.S.

So for the export restrictions only a non-US/non-free will be needed.

  Programs which use patented algorithms that have a restrictied
  license also need to be stored on non-us, since that is location
  on a site where it is not allowed to patent algorithms.
...

That means if you use an algorithm that is patented in Germany the package
will be in non-us? You better rename this non-US to patented/main and
add the other needed patented/contrib, patented/non-free and
patented/non-US/non-free.

 Wichert.

cu,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: [PROPOSAL] Allowing crypto in the main archive

[Adrian Bunk]

On Thu, 11 Jan 2001, Wichert Akkerman wrote:

  So for the export restrictions only a non-US/non-free will be needed.

 crypto export restrictions, yes. Right.

  That means if you use an algorithm that is patented in Germany the package
  will be in non-us? You better rename this non-US to patented/main and
  add the other needed patented/contrib, patented/non-free and
  patented/non-US/non-free.

 Why rename it? That's not needed at all.

Your non-US/non-free and non-US will include completely different
things and many people will confuse them. And your non-US doesn't really
has anything to do with the US. Your policy change implies that even a
program that's only patented in let's say Germany but not in the USA will
have to go to non-US.

 Wichert.

cu,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Bug#69311: PROPOSAL] Finishing the /usr/doc - /usr/share/doc transition.

[Adrian Bunk]

On Sun, 20 Aug 2000, Chris Waters wrote:

 I think an addendum is needed to this proposal -- if any package *has*
 had symlinks in /usr/doc, then it needs to clean them up in its
 install scripts, now, and possibly forever.
 
 This is one of the reasons I objected to the symlinks in the first
 place -- now a *whole* bunch of packages are going to have to carry
 extra cruft for an indefinite period of time -- but since we went
 ahead and implemented the symlinks, we damn well better be willing to
 pay the price.
 
 Without such an addendum, I object to this proposal.  With it, I will 
 second.  Personally, I think one of the people who crammed the symlink
 idea through should be forced to do the work of creating the proper   
 patches to policy (and maybe to debhelper).  Santiago and I (in a rare
 point of agreement) tried to prevent this mess.  We failed, but we
 shouldn't be forced to clean it up now.


Current policy says:

 Former Debian releases placed all additional documentation in
 `/usr/doc/package'.  To realize a smooth migration to
 `/usr/share/doc/package', each package must maintain a symlink
 `/usr/doc/package' that points to the new location of its
 documentation in `/usr/share/doc/package'[1].  The symlink must be
 created when the package is installed; it cannot be contained in the
 package itself due to problems with `dpkg'.  One reasonable way to
 accomplish this is to put the following in the package's `postinst':

if [ $1 = configure ]; then
  if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \
  -a -d /usr/share/doc/#PACKAGE# ]; then
  ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE#
  fi
fi

 And the following in the package's `prerm':

if [ \( $1 = upgrade -o $1 = remove \) \
 -a -L /usr/doc/#PACKAGE# ]; then
  rm -f /usr/doc/#PACKAGE#
fi



That means it's already a bug if a package doesn't remove this link in
it's prerm. (And lintian gives you a warning if you forget this.) If
policy is changed and the symlink is no longer necessary you can simply
remove these statements from the postinst and the prerm and the package
doesn't has to carry any extra cruft in the future.


 cheers


cu,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: new fields in debian/control

[Adrian Bunk]

On Sun, 16 Jul 2000, Wichert Akkerman wrote:

 Package: packaging-manual
 
 I'm adding three new fields to debian/control:
...

Sorry if I do perhaps address the wrong people, but I would like to
propose two other fields (there might be better names than the ones I
found):


Successor-Of:
As far as I know, a package isn't upgraded if it's name has changed
(e.g. fvwm2 - fvwm or cdgrab - abcde). This field is meant for this case
(the new package is Successor-Of the old package). There must't be more
than one successor of a package, and dpkg/apt should treat a package with
this field as if it still has the name it has before when upgrading.


Provides-Source-For:
For packages like qmail-src that are shipped only as source and that you
have to compile yourself. E.g., if you don't know that, it looks as if
vchkpw has an unmet dependency. A package with this field could perhaps be
automatically compiled when installing.


 Wichert.

Just my 0.02,
Adrian

-- 
A No uttered from deepest conviction is better and greater than a
Yes merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi