Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Ian Jackson]

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
package format with non-native version""):
> On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> > But I think that might not meet ftpmaster's review needs.  AIUI
> > ftpmaster like to review the diff qua diff, and a tarball isn't so
> > straightforward.  I had a similar idea to use an rsync batchfile as
> > the delta, which foundered on the same issue.
> 
> Note that it's not worse than using native formats, where ftpmasters get
> a single tarball anyway...

Indeed.  But I don't necessarily expect to be able to predict what
ftpmaster (or, for that matter, the dpkg maintainers) will like.

Thanks for exploring the design space!  What would be really good
would be to get agreement in principle from the key stakeholders...

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Ian Jackson]

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
package format with non-native version""):
> Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> it be a good solution?

Oh, I hadn't thought of that.

> The main limitation I see is that it would not allow to represent
> efficiently small changes to large text files (which a git-based diff
> would allow).

That may not be important.  My feeling is that it wouldn't be.

However, I think there are some other difficulties with this idea.

*Deletion* of files *is* important.  Something would have to be done
to support that.  (Tarball repacking is an abominable workflow which
we should only do when we must.)

It is important that packing and unpacking these things works roughly
the same way that things work right now for the diffish formats.  Ie,
for a package with two tarballs, the first tarball would have to omit
the Debian revision from its filename (so that it needn't be
re-uploaded), and the second tarball would have to *contain* it.
dpkg-source -b would have to calculate the appropriate second tarball
as a diff from the first.  (GNU tar has an incremental option that
could perhaps be used.)

I think, having followed this line of throught, the result looks quite
like a "3.0 (diff)" only the diff is in the form of an incremental
tarball rather than a textual patch file.

This could definitely work.

But I think that might not meet ftpmaster's review needs.  AIUI
ftpmaster like to review the diff qua diff, and a tarball isn't so
straightforward.  I had a similar idea to use an rsync batchfile as
the delta, which foundered on the same issue.

And I'm not sure that it will find better favour with dpkg upstream
than my "3.0 (git-diff)".

> I'm asking because if 3.0 (native) gets more generic by allowing
> non-native revisions, it might be an easier sell to introduce
> multi-tarballs support, than to introduce a completely different source
> format.

Mmmm.  I think there are many possibilities here which would suffice.
Right now, though, it's a bit hard to make progress without feedback
on what general direction would be most well received.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Ian Jackson]

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
package format with non-native version""):
> If it was possible to use 3.0 (native) with non-native revisions, would
> there be remaining circumstances where 1.0-with-diff is the best choice?

Yes, unfortunately.

If you have a package whose orig source code is large, and the delta
is representable with 1.0-with-diff (which is quite likely), then you
don't want to be reuploading the whole tarball each time.  That's
wasteful of everyone's bandwidth and disk space.

So you want a representation that offers delta compression.  That is
offered by the non-native formats.  The non-native formats supported
by the archive are 1.0-with-diff and "3.0 (quilt)".  The latter has
the problem with debian/patches/ living inside the source tree, which
is quite undesirable especially for "git-first workflows" (as the
draft text puts it).

> If not, maybe the fact that this is the blocking issue should be made
> explicit in (4)?

   4. We believe that there are indeed circumstances in which
  1.0-with-diff is the best choice for a particular source package,
  including, but not limited to, git-first packaging workflows.
 +This is because there is currently no other source format which avoids
 +reuploading the whole source (including upstream) for each upload,
 +and also avoids having to maintain debian/patches/ inside the
 +package tree.

Or something.

> That would be a way to state: "either dpkg maints refuses to support 3.0
> (native) with non-native revs, and 1.0-with-diff must not be considered
> deprecated; or dpkg maints supports it, and it might be possible to
> deprecate 1.0".

I would love for there to be something like 3.0-with-git-diff.  Indeed,
I filed this wishlist bug to ask if contribution would be welcome:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
but have not had any response.

The code in dpkg-source for 1.0-with-diff is quite crusty particularly
in respect of the implied behaviour wrt scanning your ".." for stuff.
The *format* of 1.0-with-diff is quite reasonable, but it lacks
support more kinds of delta.  That could be done as an extension to
1.0-with-diff, but I doubt that would be a popular direction.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1007717: Native source package format with non-native version

[Ian Jackson]

every package.  Unfortunately that is blocked
due to unfounded "security concerns".

I note that "3.0 (quilt)" with single-debian-patch exists and is fully
supported.  No-one appears to be trying to get rid of it.

> I also caution that whenever we perform a fundamental change, some
> things that used to work well, stop working well. Many improvements
> regress on other aspects that are deemed niche features. I think it is
> fair to say that use of 1.0 packaging formats is a niche at this point.
> Consistency has value, but it comes with a price of making some niche
> features impossible. We are discussing a trade-off between consistency
> and niche features here.

Mandating *more* use of patches-and-tarballs is a step backwards.

The .dsc source format (which I first invented in 1992 is now
obsolete).  We must maintain it for compatibility for a very long
time, but almost everyone is already treating git as primary.
But our git setups are not official, not coherently discoverable or
useable.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1007717: Native source package format with non-native version

[Ian Jackson]

A friend suggested some information that I could usefully provide:

Firstly, I posted to -devel a summary of why format 3.0 is not
pareto-better than 1.0.  I have c it below.

Secondly, I was asked if there was a bug against src:dpkg asking for
"3.0 (native)" to allow packages with Debian revisions.  I don't think
there is - at least, I didn't find one.  I do remember this coming up
before, but I don't seem to be able to find a record of it now.

Sean Whitton writes ("Re: Bug#1007717: Native source package format with 
non-native version"):
> I think that you are asking us to use 6.1.1/6.1.2 for most of this, but
> for I.3 are you asking for us to use 6.1.4 or 6.1.5?  "Request" seems
> more like 6.1.5 but I would like to check.

I think you mean "for I.2 are you asking".  I am not asking for the TC
to overrule the dpkg maintainer under 6.1.4.

Let me requote myself with annotations:

> On Tue 15 Mar 2022 at 04:29pm GMT, Ian Jackson wrote:
> > Please:
> >
> > Part I - belss continued use of 1.0 native format, for now at least:
> >
> >  1. Declare explicitly that there is nothing wrong with a package with
> > a native format, but a non-native version number.

 6.1(1) Decide on any matter of technical policy.

> >  2. Request that the dpkg maintainer relax the restriction which
> > prevents the use of 3.0 native with Debian revision.

 6.1(5) Offer advice.

> >  3. Consequently, declare that the recent MBF on this topic ought not
> > to have been filed against packages where simply changing the
> > source format does not currently work.  That would include at
> > least 1.0 native packages with Debian revisions.

 6.1(5) Offer advice.

> > Part II - bless continued use of 1.0-with-diff, for now at least:
> >
> >  4. Declare that sometimes the use of 1.0-with-diff can be the best
> > tradeoff between different considerations.  In particular,
> > because 1.0 is the only format which botH:
> >  (a) Optimises bandwidth and storage by reusing the upstream
> >  data when it hasn't changed.
> >  (b) Avoids polluting the working tree (package source code)
> >  with [patches], which cause trouble especially with
> >  git-based workflows.

 6.1(5) Offer advice.

> >  5. Consequently, declare that the recent MBF on this topic ought not
> > to have been filed against 1.0 with diff packages, at least
> > without some further filter.

 6.1(5) Offer advice.

Thanks,
Ian.


From: Ian Jackson 
To: Sean Whitton 
Cc: Russ Allbery ,
debian-de...@lists.debian.org
Subject: Re: proposed MBF: packages still using source format 1.0
Date: Wed, 9 Mar 2022 16:38:43 +

Sean Whitton writes ("Re: proposed MBF: packages still using source format 
1.0"):
> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
> > On 08/03/22 at 17:33 -0700, Sean Whitton wrote:
> >> Lucas, as I've had a lot to do with these git workflows and have
> >> probably done the most work documenting them, I can help with any
> >> specific follow-up questions you might have.
> >
> > Thanks!
> >
> > So the main question I think I have is:
> >
> > can we find a middleground where the git workflows don't require staying
> > with 1.0? Even if that means switching to 3.0 (quilt) using the
> > single-debian-patch approach?
> 
> dgit-maint-merge(7) works with single-debian-patch and that's what I
> use.  But it is not clear to me that there are any advantages at all to
> that over 3.0 (quilt) with single-debian-patch?

The situation here is complicated.


The tl;dr is that

 * there are several situations where 1.0-native is the best answer,
 * there are several situations where 1.0-with-diff is the best answer,

The root cause of both of these situations is that 3.0, sadly,
is not always better in every respect than 1.0.


1. Why is 1.0-without-diff not always worse than 3.0 (native) ?

1.0 native is sometimes better than 3.0 (native) because dpkg-source
refuses to build a 3.0 native package with a Debian revision in its
version number.

This prohibition exists solely because of a doctrinal objection to
native-format packages with Debian revisions.  There is no technical
reason why this restriction could not be lifted.  I sometimes upload
this way and I have never had anyone report problems[1] with it.

IMO there is nothing wrong with native format packages with Debian
revisions.  They work just fine.  For a small paockage, this is often
a good choice, because it avoids dealing with patches at all.

For anything but a small package, use of diffs is needed as a storage
and distribution optimisation.


2. Why is 1.0-with-diff not always worse than some 3.0 format ?

1.0-with-diff has the following adv

Bug#1007717: Native source package format with non-native version

[Ian Jackson]

Package: tech-ctte

(Sorry for the resend, this should have gone to the BTS the first
time; have fixed a slip in the wording.)

Please:

Part I - belss continued use of 1.0 native format, for now at least:

 1. Declare explicitly that there is nothing wrong with a package with
a native format, but a non-native version number.

 2. Request that the dpkg maintainer relax the restriction which
prevents the use of 3.0 native with Debian revision.

 3. Consequently, declare that the recent MBF on this topic ought not
to have been filed against packages where simply changing the
source format does not currently work.  That would include at
least 1.0 native packages with Debian revisions.

Part II - bless continued use of 1.0-with-diff, for now at least:

 4. Declare that sometimes the use of 1.0-with-diff can be the best
tradeoff between different considerations.  In particular,
because 1.0 is the only format which botH:
 (a) Optimises bandwidth and storage by reusing the upstream 
 data when it hasn't changed.
 (b) Avoids polluting the working tree (package source code)
 with [patches], which cause trouble especially with
 git-based workflows.

 5. Consequently, declare that the recent MBF on this topic ought not
to have been filed against 1.0 with diff packages, at least
without some further filter.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Native source package format with non-native version

[Ian Jackson]

Package: tech-ctte

Please:

Part I - belss continued use of 1.0 native format, for now at least:

 1. Declare explicitly that there is nothing wrong with a package with
a native format, but a non-native version number.

 2. Request that the dpkg maintainer relax the restriction which
prevents the use of 3.0 native with Debian revision.

 3. Consequently, declare that the recent MBF on this topic ought not
to have been filed against packages where simply changing the
source format does not currently work.  That would include at
least 1.0 native packages with Debian revisions.

Part II - bless continued use of 1.0-with-diff, for now at least:

 4. Declare that sometimes the use of 1.0-with-diff can be the best
tradeoff between different considerations.  In particular,
because 1.0 is the only format which botH:
 (a) Optimises bandwidth and storage by reusing the upstream 
 data when it hasn't changed.
 (b) Avoids polluting the working tree (package source code)
 with packages, which cause trouble especially with
 git-based workflows.

 5. Consequently, declare that the recent MBF on this topic ought not
to have been filed against 1.0 with diff packages, at least
without some further filter.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Ian Jackson]

Matthew writes:
> * We've talked about the burden already; there are people willing and
>   able to help with this, and that offer remains good, be that by
>   providing patches, MRs, help with bug reports on non-systemd systems,
>   NMUs, or some other mechanism that Michael would prefer

I think that it is worth mentioning, in this context, the burden on
the other side.  That is, the burden Debian places on those who want
to "explore alternatives to systemd", as the GR puts it.

The non-systemd community has suffered many unexplained or
poorly-explained deletions of working functionality, and several other
kinds of blockages.  Each time we need very careful escalation to the
DPL and the TC etc. [1]

This continual fight to not have working things deleted (or broken
without good reason) is *much* more work than we are asking of the
maintainers of core packages like network-manager.

The opposition we face, and the consequential burden of constant
emotional and political attrition is *the only real impediment* to
having really good support for alternative init systems in Debian.

It is also a drain on the energy of the people who would otherwise be
developing and integrating alternatives to both systemd and sysvinit.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#971515: Status as of last tech-ctte meeting

[Ian Jackson]

Russ Allbery writes ("Bug#971515: Status as of last tech-ctte meeting"):
> [much stuff]

Oh, wow, Russ.  Thank you very much.  What an excellent piece of
writing.  I agree entirely with all of it.

Ian.

(And I speak as someone who thinks that this newfangled "vendor
everything" and "just download that shit from the internet" approach
is hideously bad engineering practice.)

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Ian Jackson]

1. Basic principles

Josh Triplett writes:
> I do not believe it falls within the scope of the technical
> committee to override a decision already decided by a project-wide
> GR,

No-one is asking the TC to override the GR.  In fact, Matthew is
asking the TC to *implement* the GR.

> or to "interpret" the text of a GR issuing a nontechnical policy
> document in ways that may undermine the decision made in that GR and
> document.

Obviously the TC ought not to undermine the GR.  What counts as
undermining the GR and what counts as implementing appears to be a
matter of debate.

> Thus, I would suggest that the technical committee should decline to
> rule on any matters already decided by the GR.

On the contrary, if the GR is to be effective, it must be honoured.
That means that if an individual maintainer or contributor does not
respect the GR decision, the decision should be enforced by the
project's existing governance mechanisms.


2. Misrepresentation of the GR decision substance

> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that package.

This is true of course.  But that is the key role of the maintainer.
As recognised in the GR text.

> The GR encouraged developers to work with each other; it did not
> *mandate* developers to spend their time and energy supporting
> alternative init systems,

This is quite simply false.  End of 2nd para of the winning option:

 | It is important that the project support the efforts of developers
 | working on such technologies where there is overlap between these
 | technologies and the rest of the project, for example by reviewing
 | patches and participating in discussions in a timely manner. 

This TC bug is precisely about such a situation.  As Matthew explains
in his most recent mail, the provision of init scripts is precisely
such a situation, where by fasr the most practical way to deal with
"such technologies" (init scripts) is to acknolwedge the "overlap with
the rest of the project" (by putting the scripts in the packages for
the daemons).

That the dispute is about "overlap" is even more true about #921012,
which is about a Depends.


3. Analysis of the winning vs non-winning options

Josh looks at some of the non-winning options, and uses the fact that
those non-winning options were defeated as arguments *against* their
contents.  Our voting system is specifically set up to allow multiple
different variations on a theme, so this is not a valid approach.

> The GR contained options for requiring ("must"), or even strongly
> encouraging ("should"/"important"), developers to maintain sysvinit
> support; those options did not win.

It also contained a non-winning option (F) making it clear that bugs
like #921012 and #964139 would be treated as wishlist.

> The bug did in fact have input from the maintainer, the day it was
> filed: it was tagged as wishlist.

Indeed, the maintainer is behaving as if option F had won.


4. Purpose of the GR, and overall intent of the winning option

> One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was,
> in large part, to settle with finality many ongoing case-by-case
> disputes about alternative init system support,

I think that was the aim of the proponent.  Unfortunately, the winning
option did not support that desire.

Having spoken to a number of people both before after the vote I have
the impression that the Developers as a whole were not keen on a long
text which explicitly dealt with various matters in dispute and were
fed up of being asked these kind of questions in GRs and hoped the
project could behave like grown-ups.  Sadly this seems to have been
over-optimistic.


5. Role of the TC

Josh disputes that the TC has an appropriate role here, asserting the
GR has pre-empted the TC's role.  However:

 | Maintainers use their normal procedures for deciding which patches
 | to include.

The TC is explicitly empowered to exercise the maintainer's
decisionmaking authority, via its power to overrule a maintainer
decision.

Furthermore, the TC can clearly make its opinion known.  My view is
that the behaviour seen in #921012 and #964139 is an outrage which
ought to result in DAM action.  It would be open to the TC to make a
statement strongly criticising the maintainer's behaviour and
suggesting that the Community Team and/or DAM ought to intervene.


Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#934948: Unnecessary dependencies vs multiple binary packages

[Ian Jackson]

Hi, Simon.  Thanks for the writeup which makes things much more
comprehensible.

Simon McVittie writes ("Bug#934948: Unnecessary dependencies vs multiple binary 
packages"):
> * All correctly-packaged Ruby libraries have a dependency on the Ruby
>   interpreter, regardless of whether they also contain a #!/usr/bin/ruby
>   executable script. This is similar to what is done for Perl and Python.
>   - Please fact-check: is this true?

I think the reason we do this for Python might be related to Python
interpreter version compatibility.  Otherwise it doesn't seem like it
serves any purpose ?

For Perl, the actual interpreter package is perl-base.  There are Perl
scripts which run with perl-base and without perl-modules.  "perl" is
most a metapackage - its main purpose is to pull in perl-modules.  It
is true that pure-Perl modules depend on perl-base, directly or
indirectly.  When the dependency is on "perl", that pulls in
perl-modules: ie, it isn't just the interpreter.  I think the primary
purpose of the dependency on perl-base (where that is what is used) is
to specify the minimum perl version.

Would anything go wrong (with Perl or Python, say) if we didn't depend
on the interpreter ?  (Assuming the dependency being dropped is
unversioned.)

I am the maintainer of a Tcl extension ("chiark-tcl") which does not
Depend on any Tcl interpreter, even though there obviously needs to be
one for it to be any use.  A package which uses this extension (eg
"sauce") Depends on the interpreter.

> Design principles
> =
> 
> (These are principles, not hard rules, so we might need to compromise on
> some of them where they conflict.)
...
> * When an executable is installed, it must work.
>   - That is, its dependencies must be sufficient.
>   - Exception: if it's in /usr/share/doc/*/examples it doesn't have to work.
> 
> * When a library is installed, it must be usable in the relevant
>   interpreter(s).
>   - That is, its dependencies, plus the interpreter itself, must be
> sufficient to import and use the library.

We have compromised on these principles on many past occasions.  The
archive is full of portmanteau packages, which contain a variety of
things with different practical dependencies.  We often write
Recommends or Suggests for the practical dependencies of less-critical
subcomponents.

devscripts is perhaps the best example.

> * When a user installs a library for one interpreter or environment,
>   in general, we don't want the package dependencies to require that
>   user to install an unrelated interpreter.

I think this design principle should generally outweigh the previous
two.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#932795: Ethics of FTBFS bug reporting

[Ian Jackson]

Simon McVittie writes ("Bug#932795: Ethics of FTBFS bug reporting"):
> For the specific question of whether a single CPU core is a "reasonable"
> build environment, my answer at the moment is "I don't know".

There are two issues here:

1. "Is a 1-cpu system `reasonable' or `supported'" (or whatever)

2. We don't have anywhere to write down the answer to these kind of
questions.  (That there was nowhere to write down the answer, in
particular, nowhere in policy, is I think a large underlying cause of
why Santiago is frustrated.  Because it means that the answer isn't
written down despite it being quite relevant.)

I think most people here would be happy to have (1) decided (one way
or the other) by the release team.  Solving (2) seems like a job for
the -policy list, since it's mostly wordsmithing.

The detailed questions you ask downthread seem like good questions to
be asking to help aswer (1) but maybe now would be a good time to
bring in -release ?

Ian.

Bug#932795: Ethics of FTBFS bug reporting

[Ian Jackson]

Santiago Vila writes ("Bug#932795: Ethics of FTBFS bug reporting"):
> Would it work, for example, if I propose a change to Debian Policy

I think the problem here is that:

 - Some packages do not build in quite sane non-buildd build
   environments, but:
 - Some build environments are too weird or too broken
 - We do not have the effort to write a exhaustive specificatio
   which will tell the difference in all cases
 - Worse, the issue is not addressed in policy at all so there
   is not even anywhere to put the answer for specific cases
 - We regard some FTBFS issues as non-RC but still bugs,
   and policy does not mention this at all

I suggest the following approach:

 - Introduce the words "supported" and "reasonable".  So

Packages must build from source in any supported environment;
they should build from source in any reasonable environment.

 - Provide a place to answer these questions:

What is a supported, or a reasonable, environment, is not
completely defined, but here are some examples:

- An environment with only one cpu available is supported.
- An environment with a working but non-default compiler
  is reasonable but not supported.

etc.

On the point at issue, do these packages build in a cheap single-vcpu
vm from some kind of cloud vm service ?  ISTM that this is a much
better argument than the one you made, if the premise is true.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

Sean Whitton writes ("Re: Thinking about Delegating Decisions about Policy"):
> The idea that Policy should always lag behind practice is something that
> I find very difficult to assess.  If you are thinking of Debian as a
> large number of people furiously innovating at the borders and
> exchanging ideas with each other in the form of uploads, then it makes
> complete sense.

Uploads are a rather blunt instrument for communication :-).

> My current strategy, when
> - it seems like something is important and should be changed, but
> - it has not yet been implemented in the archive, or
> - in some other sense lacks a clear consensus,
> is to refer the case to the T.C.
> 
> I think your suggestion is that in at least some such cases we should
> lower our standards for what is required for a clear consensus?  If so,
> am I right in thinking this would not actually require any changes to
> the Policy Changes Process?

I'm not sure exactly what you mean by "has not yet been implemented".
I am going to assume you mean "most packages have not yet been
updated", not that no packages have been changed, or the underlying
core implementation is missing, or something.

I don't recognise "has not yet been implemented in the archive" as
"[a] sense [in which X] lacks a clear consensus".

I think the fact that most packages in the archive have not been
updated to have change X does *not* mean there is not rough consensus
in the project that change X is usually a good thing.  It often means
that the bulk of the project hasn't thought about it, or that the
change is just part of our ongoing backlog of outstanding work.

Having a clear document, with authoritative status, saying that X is
usually a good thing, and how precisely X should be done, is immensely
valuable to making X actually happen, and happen well.

Furthermore, if we make recommendations that X should *usually* be
done, then in most cases only very *rough* consensus is needed.
People who disagree that X should be done in a particular case, or at
all, can not do it.

So what I am suggesting is that the policy editors should cease to
treat "many packages do not yet do X" as a reason to delay
recommending that packages should do X.

> > Additionally I think the formal proposer/seconder scheme can be
> > awkward.  Again I think the policy editors adopted it because they
> > didn't want to be in the line of fire when difficult decisions are
> > being made, and perhaps because they didn't want to try to become
> > experts in everything.  But it means that uncontroversial changes can
> > languish.
> 
> Do you (or anyone else) have any concrete ideas for simplifying the
> proposer/seconder scheme, without significantly reducing the oversight
> on changes, even uncontroversial ones?

I would suggest instead that for changes which the policy editors
like and which seem likely to be uncontroversial, the policy editors
would publish a notice giving a deadline for comments/objections.

Probably the notice would be sent to some announce list, and also CC'd
to any roles that seem specifically implicated or interested.
Possibly for small changes and normative clarifications they could be
bundled up into a digest and sent to d-d-a.

Another idea would be to make it easier to revert or suspend a change
which turns out to be controversial.  You could say that a change will
be reverted if, in the opinion of the policy editor, an
post-promulgation objection is made which raises a substantial issue
that ought to be dealt with.

While vacillation is undesirable, making it easier and less socially
costly to handle mistakes, will make it easier to make changes.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

Sam Hartman writes ("Thinking about Delegating Decisions about Policy"):
> Why the TC?
> A couple of reasons.

I'm going to go off on a rant about the TC now.  I've been told that
this mail sounds like sour grapes but I think it's important.

I think it would be a bad idea to use the TC to push forward technical
change.  I think the TC as an institution[1][2] lacks:

1. wide enough political legitimacy

2. enough sensitivity to the concerns of those other than
the maintainers or teams whose decisions are being impugned

3. even, sadly, enough of a grip on detailed technical matters

4. structured communication and decisionmaking processes, which would
IMO be needed to: systematically capture the facts, and the
implications of the options; help the "losers" feel heard, and
feel that the decision was properly made; deliver clear
conclusions, but compassionately.

I also think that the TC is far less conservative than it ought to be
and is much more willing to risk damaging (or is blind to the risk of
damaging) the project's social cohesion, in the name of what is called
technical progress but often seems to me to be a narrowing of the
project's focus.


Rather than see the TC's role enhanced, I would like to abolish it and
replace it with something completely different.

Right now it is almost useless as a tool to overturn bad decisions by
maintainers: the costs of invoking it are far too high.  This is
partly because it always implies a public flamewar[1] and partly
because the TC itself generally seems to strongly prioritise the
emotional comfort of maintainers, and the notion of "progress"; it
disregards the emotional comfort of people who want their existing
stuff to keep working, and the autonomy of a package's users.

As a tool to make project-wide decisions on the desirability of a
mandating certain kind of progress, it lacks legitimacy amongst
significant proportions of the community, because of the way it made
decisions in the past and also to an extent because of the content of
those decisions.


Ian.

[1] I should say that I think the individual members of TC are and
have been people of generally very high caliber.  IMO the failings are
emergent properties of the structure, context and framing.

[2] Much of this is, I think, ultimately my fault.  I invented this
setup.  All I can say is that I was young and naive.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

tl;dr:

 IMO a better way is for the policy editors feel more empowered to
   - lead practice rather than follow it (e.g. to follow
   rough consensus on desirable changes to Debian, rather
   than only document what is already widespread)
   - make judgement calls
 This could be done by encouraging the policy editors to amend the
 policy process, and by giving them political cover as they change
 their practice.


Sam Hartman writes ("Thinking about Delegating Decisions about Policy"):
> I imagine it won't be uncommon to get to a point where the right next
> step is to develop technical or non-technical policy about something.
...
> So, if I want to delegate deciding on a policy, who should I send it to?

Do you mean you as the DPL or you as a maintainer of some program or
sub-policy or something ?

I think you mean as DPL.  As the DPL you do not have any power to set
policy so you cannot delegate that to anyone.  An attempt do so ([1]
for example) is beyond the powers of the DPL, and therefore void.
("ultra vires" as a laywer would say. [2])


> we delegated managing the process to the policy editors, but not the
> actual policy decisions.  They make consensus calls.  They use their
> judgment in a lot of ways.

That is a decision *of* the policy editors.  When the constitution was
first adopted, and for some time afterwards, the policy editors
themselves made judgement calls about merit, rather than simply trying
to assess consensus.

Note that debian-policy is only one of the packages containing
technical policies.  Many other packages have bits of policy in them.
It is only debian-policy whose maintainers have decided to adopt this
consensus scheme and to lag practice.

IMO the biggest problem is the principle that policy should always
follow practice rather than lead it - even if the project has rough
consensus about the direction.  I really don't think that is best.

There is a missed opportunity here.  The policy editors and the policy
list have a good reputation and a lot of legitimacy.  That comes from
their practice of caution, of consulting widely, and seeking rough
consensus.

I wouldn't want to change that dramatically but a small change from
the policy editors would go a long way.  For example, to be willing to
countenance making recommendations which have rough consensus, and
seem to the editors like a good way forward, but which are followed
only occasionally or patchily.

That would not involve goring anyone's ox, so it would not undermine
the policy team's political capital.  Obviously any change might be
opposed by someone but I doubt such a change in policy practice would
meet much opposition.


Additionally I think the formal proposer/seconder scheme can be
awkward.  Again I think the policy editors adopted it because they
didn't want to be in the line of fire when difficult decisions are
being made, and perhaps because they didn't want to try to become
experts in everything.  But it means that uncontroversial changes can
languish.


> But at least under the current process, the policy editors cannot  just
> use their personal judgment to decide what policy is absent a consensus.

The policy editors collectively could decide to change the process.
The process is a creation of the policy editors, not of the DPL nor of
the rest of the project.


Ian.

[1] https://lists.debian.org/debian-devel-announce/2017/06/msg5.html
[2] https://en.wikipedia.org/wiki/Ultra_vires

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: That merged-usr is mandatory is RC

[Ian Jackson]

(sending this because I got the release team address wrong)

Ian Jackson writes ("That merged-usr is mandatory is RC"):
> Control: severity -1 serious
> 
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.
> 
> Guillem filed the bug as `wishlist' but given the controversy it seems
> to me that it should be RC if for no other reasons than social
> cohesion.
> 
> CCing the TC FYI (they have already been involved in merged-usr
> debates via #914897) and the release team, in case they have an
> opinion.  FAOD I am not a maintainer of base-files but AFAICT the
> base-files maintainer has not expressed an opinion about severity.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

That merged-usr is mandatory is RC

[Ian Jackson]

Control: severity -1 serious

In #923091, Guillem (with dpkg maintainer hat on) asks for a
base-installer option to allow installing buster without merged-usr.

Guillem filed the bug as `wishlist' but given the controversy it seems
to me that it should be RC if for no other reasons than social
cohesion.

CCing the TC FYI (they have already been involved in merged-usr
debates via #914897) and the release team, in case they have an
opinion.  FAOD I am not a maintainer of base-files but AFAICT the
base-files maintainer has not expressed an opinion about severity.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ian Jackson]

Steve McIntyre writes ("Bug#914897: tech-ctte: Should debootstrap disable 
merged /usr by default?"):
> There is a deeper worry about builds that may be done against the
> "weak" background. Although buildd chroots are easily fixed up,
> there's going to be a (small, but unknown) set of maintainers who
> might be uploading binaries from merged systems. I think we're making
> good progress on source-only uploads and building in clean chroots
> etc., but...  It's also likely not easy to pick up on "wrong" binary
> packages built this way.

I think this is a valid concern but puts it far too narrowly.


There is a persistent misunderstanding embodied in your comments here
(or rather, embodied in a significant omission): the notion that the
only reason to build a package on a Debian system is for upload to
Debian.

Once I put it like that, this notion is obviously false.  What is
happening is that the conversation is focusing on our own needs,
within Debian to help us produce Debian, to the exclusion of the needs
of our users.  That is a natural tendency of course, but we must
resist it.


Back in the wider world, of course many people build packages on
Debian systems for installation `somewhere else'.  I have done it
myself and probably many of the people reading this message have too.

What is implicitly going on here is that it is mostly-tacitly[2] being
assumed (or declared) that `I built this .deb on my laptop[1] and gave
it to my friend' is wrongheaded.

I don't think doing that is wrongheaded.  Certainly it is extremely
common; we don't have any public pronouncements saying it is somehow
wrong; and we have had little discussion where we as a project decided
that this was now a use case which we feel free to just break.


Personally I think that this is a very important thing to keep
working.  It is the very core of users' collective software freedom.

And that software freedom needs to be easy to exercise in practice.
Despite a lot of excellent tooling, chroots are still not entirely
trivial to set up and maintain.

I would invite the TC to read this manpage, which is trying to explain
to a Debian user how to change the programs on their own computer
  https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
and then consider how much even worse it would be if we had to write
about chroots too.


To TC members who are minded to uphold the current approach, I would
ask: can you please explicitly state your opinion on this ?  That is:

  Is it OK for a Debian user to build .deb on their laptop and give it
  to their friend ?  If it is OK, how will we make sure that it does
  not pointlessly break ?


I readily admit that there are many ways that this can produce a
result significantly different to the official Debian package,
particularly because the package build system may configure itself
differently in the the presence of unexpected.  The resulting package
is probably not going to be suitable for wide distribution.

But those kind of problems are (a) not serious in practice
(b) generally have obvious symptoms and (c) are easily worked around
by various means.  Working around a usrmerge-generated failure is
difficult; it usually involves doing serious violence to the upstream
build system, or perhaps horrific rules file bodges.


Thanks,
Ian.


[1] Implicitly, without using a chroot.
[2] IIRC some people suggested this explicitly in the thread in
d-devel.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ian Jackson]

David Bremner writes ("Re: Bug#914897: tech-ctte: Should debootstrap disable 
merged /usr by default?"):
> There is a draft ballot being prepared for a vote. I'm not sure when
> that will be ready.  The minutes of the last TC meeting should have more
> precise information than my memory.

Thanks.

I just read the discussion in the irc log.

I theme I identified in it was the social cost of overriding the
debootstrap maintainer.

A contrasting issue that was not really discussed is the social cost
of allowing the debootstrap maintainers to impose this transition on
the rest of the project.

(This is difficult to disconnect from the unpleasant communication
style of one of the principal usrmerge advocates on debian-devel.)


Also, I think whether Debian installs should have merged /usr by
default is a matter of technical policy which the TC ought to feel
free to address directly.

This is especially the case since none of the other possible
candidates for how to set this distribution-wide policy are useable:
the Policy editors have decided that Policy should lag implementation
rather than lead it; debian-devel didn't work; and there is no other
forum or body with sufficient breadth.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ian Jackson]

Ping ?

Is the TC engaged in this issue or should I seek another approach ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#919951: Request about the /usr/bin/dune filename

[Ian Jackson]

Anil Madhavapeddy writes ("Bug#919951: Request about the /usr/bin/dune 
filename"):
> And just to followup the query about the libdune numeric library, they
> also appear to have no plans to use /usr/bin/dune. I wasn't copied on
> their mailing list thread with the reply, but you can see it here:

1. "Appear to have no plans" is not sufficient.  If we tolerate the
ocaml package taking /usr/bin/dune, then the numerics library will
probably never be able to ship /usr/bin/dune in future.

For us to be sure this is not a problem, this should be discussed with
Dune (numerics) upstream.  Also, as Jö Fahlke says, the mail you are
quoting from was an internal communication.  We should wait and see
what the DUNE (numerics) folks' formal position is.

2. There is still some risk of confusion over the command name, even
if there is not going to be a file conflict.

3. There is very considerable risk of confusion over the source and
binary package names.

> This seems like a reasonable solution all around. The OCaml Dune Debian
> package could also be called libocaml-dune or something, if you feel that
> `dune` is too generic a name.

I think it would be much better for it to be renamed.

> The /usr/bin/dune binary name is very very hard for us to rename,
> however, since it is so embedded in so many project Makefiles.

Insofar as the authors and users of this tool have collectively
decided to unwisely (and, I'm sorry to say, apparently also
arrogantly) adopt a short, contested, confusing project and command
name, it is right that the community surrounding that tool should bear
*all* of the costs of that decision.  And if those users have lashed
themselves firmly to the mast that is not really an excuse IMO.

If DUNE (numerics) upstream can be persuaded to commit to never
shipping a binary /usr/bin/dune then I guess the situation is liveable
with.  But if DUNE (numerics) upstream do not want, now, to promise
that, then that is quite understandable.  In that case Debian ought to
reserve /usr/bin/dune for DUNE's possible future use.


The background here is that the Unix command namespace is a scarce
global resource.  People who claim a command name have a
responsibility to choose a name in a way that considers the interests
of all the users of that command namespace.

Debian is (as far as I know) the only institution which is actually
trying to manage that namespace to ensure that everything can be
coinstalled and used together.  (That of course allows people to use
Debian to make new and exciting combinations of interesting software.)

Debian should reward good behaviour and ensure that those who choose
good names, or have been using a name for a long time, do not find
someone else's tanks suddenly parked on their lawn.  (Or, even,
parked at their kerb outside their house.)

Conversely Debian does *not* have a responsibility to enable, support,
excuse, or even tolerate, bad behaviour - such as choosing a command
name which the name of well-established and easily discoverable
existing software project.  Indeed I would say we have a
responsibility to discourage it.  At the very least someone who does
that should get short shrift whenever any kind of conflict arises.


I appreciate that this is annoying if you are on the wrong end of it.

No doubt some people make these kind of mistakes without realising
that it is Not OK to simply declare certain unrelated software
noncoinstallable.

And it is particularly annoying for the users and downstreams of
software whose upstreams are careless about these matters.  But as the
user or downstream of some software you are buying into the decisions
of your upstream, for good or ill.  You are buying into your
upstream's mistakes, whether those mistakes are made out of
inexperience, ignorance, haste, insularity, or arrogance.

Certainly it is not right that the other project, whose name is being
appropriated, should suffer any inconvenience.


Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Ian Jackson]

Package: tech-ctte

In #919622 and the associated debian-devel thread,
 "Conflict over /usr/bin/dune"
  https://lists.debian.org/debian-devel/2019/01/msg00227.html
the file conflict over /usr/bin/dune was discussed.

The rough consensus of the debian-devel thread was that /usr/bin/dune
ought definitely not to be taken by the ocaml build system, and that
the best claim on it was the C++ library which already provides a
number of /usr/bin/dune?* binaries.

Instead, the maintainers of the ocaml package reassigned the bug
against their `dune' package to the whitedune package, which
previously provided /usr/bin/dune as a compat symlink.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622

They used the phrase
  "As discussed on debian-devel"
which is very misleading because it makes it sounds like there was a
consensus for this course of action, whereas the opposite is true.

Apparently as a result of this there was an NMU of `whitedune' to drop
the symlink /usr/bin/dune.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58

The maintainers of the ocaml `dune' have now uploaded `dune' (the
ocaml package) with /usr/bin/dune and Breaks+Replaces to claim the
file.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#99

Meanwhile there seems to have been no contact with the maintainers of
the C++ library which is the only hit on Wikipedia for
  https://en.wikipedia.org/wiki/Dune_(software)
(Amazingly, this is still true at the time of writing even though
I referred to this fact in the debian-devel thread.)

Note that this ocaml tool `dune' was previously known as `jbuilder'.
It has nothing to do with Java AIUI.  No-one has suggested a plausible
charitable explanation for why the ocaml upstream made such
egregiously bad naming mistakes twice in succession.

Additionally the binary package name `dune' for the ocaml tool is bad,
too.


Please would the Technical Committee:

 * Declare that no-one is allowed the name /usr/bin/dune other than
   the C++ library dune-common or its friends.

 * Declare that no-one is allowed the binary package name
   /usr/bin/dune other than the C++ library dune-common
   or its friends.

 * Declare that the ocaml build system should choose a new source
   package name and use it henceforth.

I am about to file an RC bug against the `dune' package, blocked by
this one.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: debating the wrong thing

[Ian Jackson]

Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> systems would no longer be supported.  In this case someone would have
> to write a unusrmerge program to convert systems with merged-/usr to
> systems with unmerged-/usr.

Currently merged-usr is broken because it can build packages which do
not work on non-merged-usr systems.  It would be quite wrong (both
technically and socially) to react to this lack of foresight, lack of
consultation, and lack of testing, by pressing forward.

What I am suggesting in this bug report is that we revert to the
status quo before the default was changed to usrmerge, that is:

[Adam:]
>> 2. supporting both merged-usr and unmerged-usr

But actually of course "supporting" it in the way that it is currently
"supported" (according to usrmerge proponents) in stretch, sid, and
buster: if you enable it you may build packages which are not
generally useable (and perhaps you may experience other bugs).

This question is urgent for buster because the longer the current
situation continues the more systems there are that build broken
packages.

It is also urgent for stretch-backports.  The backports maintainers
have said that they want to keep stretch-backports in line with
buster.  Regardless of the wisdom of that policy, the current
situation in stretch-backports seems very bad to me.

The easiest way to fix stretch-backports (without also generating a
need to persuade the backports maintainers to waive their usual
policies) is to revert buster.


When we have stopped generating more lossage, we can start to think
about whether we want to transition to usrmerge as default, whether to
make it mandatory, and if so how the transition should be handled, and
on what timescale.

We have at least two sketches of transitions plans.  That longer-term
conversation is a much more complicated one with many more options and
many more factors.

We need the space to discuss those options properly without being
distracted by what is IMO currently a crisis in stretch-backports and
buster.


Ian.

Bug#914897: debating the wrong thing

[Ian Jackson]

Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> It is very demotivating to have discussed and implemented something
> mostly years ago, for people then to come and complain "let's not do
> this at all" years later.

We were told it would be optional.  Unfortunately it turns out that
the design is broken and it cannot sensibly be made optional.
It is not the responsibility of the wider community to review your
design for an optional feature.

Nor does a failure to review and object to your design of an optional
feature mean that you are entitled to assume consent for making the
feature default or mandatory.

Debian is full of optional features.  I'm sure many of them are broken
in one way or another.  Obviously one can't spend one's life going
round trying to abolish everything one thinks is somehow broken, or
foolish.  That would be really nasty.

The problem comes when a niche optional feature, with wide-ranging
implications, is suddenly promoted to the default, without proper
consultation and without a proper transition plan.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ian Jackson]

Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled 
merged /usr by default"):
> On 11/28/18 2:49 PM, Ian Jackson wrote:
> > This is a special case of a general problem: buster systems with
> > merged-/usr sometimes build packages which are broken on
...
> I'd suggest that this should be fixed by not shipping any packages that
> aren't built on buildds.

It would be quite a radical departure for Debian to no longer support
"I built this package for my mate to install on their computer".

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ian Jackson]

Control: reassign -1 tech-ctte

Dear Technical Committee.  I don't know if you are all aware of the
discussion surrounding this, so I will recap:

Recently debootstrap was changed to do merged-/usr by default, so that
/bin -> /usr/bin etc.

It was discovered that when this change took effect on the Debian
buildds, the buildds started to build packages which do not work on
non-merged-/usr systems.

This is a special case of a general problem: buster systems with
merged-/usr sometimes build packages which are broken on
non-merged-/usr systems.

Some people have suggested that this should be fixed by making
merged-/usr mandatory for buster.  However, there is no transition
plan for this as yet and I don't think Debian is ready to commit to do
that.

So I believe that this change should be immediately reverted in sid
and buster, so that we do not prejudge the situation by increasing the
number of buster installs in the field which generate packages which
are broken on non-merged-/usr systemss.

I filed this bug against debootstrap but its maintainers do not agree:

Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled 
merged /usr by default"):
> We already have a change queued to revert it for build chroots.  I don't
> believe anything more is warranted at this stage.

Obviously I disagree.  I think the question is urgent.  Please would
you rapidly overrule the debootstrap maintainers.

After we have ceased introducing new lossage we can have a proper
conversation about what the plan ought to be for buster and bullseye.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Tollef Fog Heen writes ("Bug#904302: Whether vendor-specific patch series 
should be permitted in the archive"):
> Second draft:
...
> The Committee recognises that there is a need for packages to behave
> differently when built on different distributions, but this should be
> done by using different source packages, or as part of the build
> process, using current and future practices such as patches with
> conditional behaviour, patching of files during the build, rather than
> at source unpacking time.

This is all good but can I suggest using the phrase `differing source
packages' rather than `different' ?  `Different' might mean source
packages with different source package name.  `Differing' more clearly
refers to source packages of the same name but which are different to
each other.

Thanks,
Ian.

Bug#904558: What should happen when maintscripts fail to restart a service

[Ian Jackson]

Wouter Verhelst writes ("Re: Bug#904558: What should happen when maintscripts 
fail to restart a service"):
> Perhaps the error handler should also be configurable by policy-rc.d, as
> I hinted to before.

I think this is a key point.  We do not have to make a single decision
which everyone has to be happy with.  We can instead continue to be
all things to all people.

I think the best answer would be:

 * Individual maintainers decide for themselves whether to treat
   service (re)start failure as postinst failure, based on their own
   perception; maintainers may make different decisions for different
   init systems.

 * If the maintainer has no particular reason to diverge the right
   answer is usually to fail the postinst with init systems that do
   not provide service supervision; but to not fail the postinst with
   ones that do.  (I think from earlier messages that this is how the
   default implementations already work.)

 * The administrator should be able to override this policy question
   globally for the whole system, or on a per-package basis.

This is probably a manageable amount of actual work: the prescription
for individual package sis roughly what they do right now.

The support for configuration in something like policy-rc.d has a few
design decisions to be made but doesn't seem really difficult.  Also
nothing blocks on it.  The TC would simply be saying "this would be a
good thing to have".

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Ian Jackson]

Sam Hartman writes ("Bug#904302: Whether vendor-specific patch series should be 
permitted in the archive [and 1 more messages]"):
> So imagine that Ubuntu and several other downstreams care more about
> security and hardening than they do about backward compatibility and
> they choose to change a number of gcc and other tool defaults in support
> of that.  I realize my example is not entirely hypothetical, but I want
> to emphasize I have not researched to get all the details right, because
> it doesn't matter.
> 
> Especially if multiple downstreams or individual users who build from
> source might want the change, I think carrying the delta in  the Debian
> source package can be valuable.  It needs to be balanced against a lot
> of other concerns.

I agree that carrying a switch-on-able delta in the Debian package
would be a good thing there.  So, the meat of the change should
definitely go to Debian or maybe even to upstream as a
--with-extra-hardening configure option or some such.

This should be enabled via DEB_BUILD_OPTIONS, or a commented-out line
in the rules file, or by reading /etc/compilers/hardening-enabled at
build- or runtime, or something.  Not by looking at `the vendor'.

A scenario why this is needed can be seen from this scenario:

Suppose someone wants to try to maintain a distro which is like
Debian, but which takes some subset of packages from Raspbian.

The obvious way to do this is to import most packages from Debian and
the other packages from Raspbian, and to fix up the bugs which occur
at the interface.

If packages in Debian and Raspbian use dpkg-vendor --is raspbian to
decide whether to do the Raspbian thing, then there is no way to make
this work because there is no correct answer: the answer to whether a
package should do the Raspbian thing depends not only on which distro
we are building or running on, but on which package it is.

In practice if I were maintaining that distro I would be tempted do
some kind of hideous hack to make the output of dpkg-vendor depend on
the name of package we were building.  Because how else will I do it ?
Playing whack-a-mole with dpkg-vendor calls would be impractical.

If the Raspbian-specific features are enabled by carrying a changed
source package in Raspbian, then things will mostly DTRT and generally
problems will occur only when the delta-enablement is done via some
kind of indirection, and the indirection messily crosses the `cutoff'
between the Raspbian-originated and Debian-originated packages.

Ie I only have to manually fix the problems that irreducible, not ones
introduced by ill-advised calls to dpkg-vendor.

> And yes, in many cases dgit is the answer.  That said, if I were
> maintaining the same package both for Debian and for the downstream I
> work on, I might well value having a single source tree enough to use
> dpkg-vendor or lsb-release or something to switch.

In that case, that is convenient for you but it is wrong for your
downstreams and users.  We should be discouraging such tradeoffs.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Ian Jackson]

Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be 
permitted in the archive"):
> On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
> > IMO policy should recomend the use of separate source packages as the
> > prefered solution to the problem that vendor-specific patch series were
> > supposed to address.
> 
> In this case please make an explicit decision on whether build-time 
> patching is the recommended replacement for vendor-specific patch 
> series, or what kinds of build-time patching will no longer be 
> permitted.

Surely the TC can recommend X without outlawing Y.

> It is not clear at all which of the above exactly you want to have 
> removed from the archive and moved as permanent deltas downstream.

Speaking personally, I think that packages should almost never look at
dpkg-vendor (or equivalent, eg looking at lsb_release).  Any switching
on vendor is probably a bug.  The reasons why switching on vendor is
probably wrong have been rehearsed earlier in this discussion.

But I am not asking the TC to outlaw the use of dpkg-vendor et al
because:

 * The dpkg vendor series feature is uniquely weird and bad.  (Both in
   principle, and because of what are arguably lesser design bugs.)

 * Unlike the dpkg vendor series feature, the use of dpkg-vendor (or
   equivalent) at build- or run-time is not directly in the way of my
   project to improve our source code management processes.

 * I think an effort to outlaw switching based on vendor would
   generate a much bigger fight which is not worth having.

 * I hope that my programme of making it easier to handle divergence
   properly, by having actually different source code, and carrying
   that delta indefinitely, will tempt people away from these kind of
   vendor-switching approaches.

Another way to look at this is that in general, where possible, I
think transitions to new things should be done by making the new thing
attractive rather than by going around forbidding or breaking the old
thing.

Sadly the vendor series feature is too broken, and causes too many
problems for others, for that.  The problems of switching on vendor
are real but much less severe so taking the carrot rather than stick
approach is much more sensible.

But of course a body like the TC should certainly recommend good
practices rather than troublesome ones.

> The TC was asked to make a decision, and a decision turning a clear 
> situation into a blurry "it is permitted but kinda recommended against" 
> would only create future conflicts.

We have a lot of things in Debian where one approach is recommended,
but other approaches are permitted or tolerated.  This does not in
general seem to result in conflicts.

> A 1:1 vendor-specific patch series -> build-time patching change
> would be a mostly technical change. As already said this could
> even be implemented before buster.

Because I think dpkg-vendor is the wrong answer, I don't want the TC
to recommend that.

Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should 
be permitted in the archive"):
> However if someone reads the prohibition against vendor-specific patch
> series, and is left wondering what is the best way to deal with this
> situation, then it would probably be helpful to give them a hint.

Quite.

Ian.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Philip Hands writes ("Re: Bug#904302: Whether vendor-specific patch series 
should be permitted in the archive"):
> IMO policy should recomend the use of separate source packages as the
> prefered solution to the problem that vendor-specific patch series were
> supposed to address.

That would be great.  (I suspect that it is rather controversial,
though, even though I think it is obviously correct...)

If there is consensus in the TC that this is the best approach,
putting something about it in the TC resolution as a recommendation
would have about as much weight as putting it in policy, and avoid
jurisdictional questions.

Ian.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be 
permitted in the archive"):
> On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
> >   The Committee therefore resolves that:
> > 
> >   1. Any use of dpkg's vendor-specific patch series feature is a bug for
> >  packages in the Debian archive (including contrib and non-free),
> 
> This misses an important part of the previous proposal:

I think Phil was just intending to leave the recitals part alone, and
proposing only a change to the operative part - not to delete the
recitals.

>   The Committee recognises that there is a need for packages to behave
>   differently when built on different distributions, but this should be
>   done as part of the build process, using current and future practices
>   such as patches with conditional behaviour, patching of files during the
>   build, rather than at source unpacking time.

However, now that we are talking about the recitals I would like to
suggest that the recitals should include *maintaining different source
packages in different distributions* as one of the suggested options.

IMO it is far superior to patches which are conditional (at runtime or
at build-time) on dpkg-vendor and I would not like to see that
perpetuated.

Ian.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Sean Whitton writes ("Bug#904302: Whether vendor-specific patch series should 
be permitted in the archive"):
> I would be grateful if you would micromanage just enough that there
> isn't anything controversial left for people to disagree about :)

That seems like a generally good rule for TC decisions.  It avoids
another aspect of the same issue coming back to the TC; and it avoids
setting in stone things that haven't been thought through in the TC
context (and which are best answered by whatever the usual process
is),

In this case I don't think the details (of the transition away from
use of this feature, or the policy wording) are controversial; except
that the timetable, and the consequences at various times for a
package that still has a vendor series, might well be.

No-one seems to have proposed anything but "bug, RC after buster", but
of course opponents of the change are focusing on that and if the TC
just says "these are a bad thing" then an opponent of the change might
well reasonably say "OK I agree this is a bug but it is not RC" or "I
intend to fix this in buster+2".

So, borrowing Phil's text and editing slightly:

  1. Presence of any dpkg vendor-specific patch series is a bug for
 packages in the Debian archive (including contrib and non-free).
 Such a bug should be considered release critical, but not until
 after the release of Buster.

The consequences for what to write in policy, want to do in lintian,
how the release team should handle these bugs, etc., all follow
clearly from that text, except for implementaion details that can be
thrashed out in the relevant fora.

I changed "use of [the] feature" to "presence of [the] series" to
avoid the possibility that someone would disingenuously argue that a
series.ubuntu file, in a package in Debian, is not "use" of the
feature.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: That's a free software issue!

[Ian Jackson]

Anonymous writes ("Bug#904302: That's a free software issue!"):
> If Debian want patches it has to support this process with tools. The
> attitude Debian owns all source packages is wrong. Sharing source
> packages among different vendors is more efficient. Different patch
> series may be the best solution in some cases.

I do agree with the underlying ideology behind these ideas.  I think
code sharing between different distros in the Debianish ecosystem is
very important and I certainly don't think that `Debian owns all
source packages', whatever that means.

Indeed, in my technical Debian work I am writing tools which I hope
will support people who want to diverge from Debian, and retain and
carry those divergences in the long term.  I have long been frustrated
that it is too difficult to do this.

The problem I have with the vendor series feature is narrower and more
technical.  For all the reasons I and others have explained, I think
the vendor series feature is a very poor way to support divergence and
diversity.  It does more harm than good.

The background to this is that I think that Debian source packages,
which I designed in the mid 1990s and which were since extended with
`3.0 (quilt)' [1], are a clumsy system which has been obsoleted by the
new generation of distributed version control systems, especially git.

.dsc format source packages are bad enough for the newcomer to Debian,
without the very weird vendor patch series feature.  And the vendor
patch series feature makes migration to better source code management
tools harder.

So in summary I think the real way to promote divergence by Debian's
derivatives, and code sharing amongst derivatives, is to use to the
full the features of very capable modern revision control systems.

TBH I don't expect this to convince you.  And I found many of your
comments rather overblown.  It would be helpful if you could avoid
wild accusations.

But, if you really want to help promote software freedom for Debian's
derivatives and users, by addressing issues to do with package source
code management tooling: please consider trying out dgit and maybe
suggesting it to Debian's downstreams as a way to get the source code
from Debian.

Please also consider advocating that Debian maintainers should use
dgit for their uploads.  If you're very keen you could come and help
out with work on making git-debrebase become a useful tool for
downstreams.

Ian.

[1] To be clear, although I have a lot of criticisms of `3.0 (quilt)',
it is much better than what was being widely done in Debian
beforehand.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should 
be permitted in the archive"):
> Possibly also with something like this?:
> 
>  Post-Buster this should be implemented in Debian Policy by
>  declaring that a package MUST NOT contain a non-default series
>  file.
> 
>  The approach adopted to allow existing usage is left to the
>  discretion of the Policy Maintainers.

Nit-picking, you might want to say

   The approach adopted to tolerating existing usage before then
   is left to the discretion of the Policy Maintainers.

Ian.

Bug#904558: What should happen when maintscripts fail to restart a service

[Ian Jackson]

Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail 
to restart  a service"):
> Ian Jackson wrote:
> > When I wrote that, it didn't occur to me that anyone would think that
> > a failure by a postinst script to perform an intended operation should
> > be treated any other way than a failure of the postinst script.
> 
> That was perhaps also written before we started to realise that maintainer 
> scripts are actually best avoided

I don't think that makes any difference.

Whether things are implemented by handcoded code in postinst, or
dh-generated templatey postinst, or some kind of declarative system,
is important for manageability of our codebase etc. etc.

But it doesn't have any bearing on what the error handling should be
like.  Any kind of declarative or automatic system or whatever ought
to have similar error handling: failure to perform an intended
function is an error and should not be ignored.

See for example the handling of errors which occur during trigger
processing.

One of the things that I am most proud of in dpkg is the comprehensive
and thoughtful error behaviours.


> > If the postinst fails, then the user has the opportunity to fix the
> > root cause and rerun dpkg-source --configure --pending.  That will
> > then repair the system completely.
> 
> \u2026 causing a snowball of errors in an awkward half-upgraded
> environment is nasty.
> 
> The problem comes when you don't yet have the right tools installed to be 
> able to fix the problem. We see that scenario often enough in #debian where 
> someone has a failed upgrade and we try to collect more information via 
> pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover 
> that the relevant tool isn't installed and because apt is sufficiently 
> unhappy about broken packages and a half-completed upgrade, you can't ask it 
> to install the tool at that point in time.

This is a bug in apt, plain and simple.

Of course it is a design error, but that does not make it a bug.
There is nothing conceptually incoherent in installing strace while
cupsd and its dependencies are broken.  dpkg will happily do it.

I agree that in the absence of a fix to this, some workarounds would
be good.  Perhaps
  dpkg --configure --force-postinst-fail broken-package
?

> In the upgrade scenario, while you're trying to fix one particular
> problem, you're also in a completely untested half-upgraded
> situation and so latent bugs in any number of other tools may also
> be exposed.

dpkg is designed so that it is in general only the _configuration_ of
other packages which is blocked, not their actual upgrade.  So
hopefully you should be in a reasonably coherent state.


> So while ignoring errors is wrong, so is making it harder to fix them. This 
> isn't a question of absolutes.

As I say I think it is a bug in apt that when you have an error, apt
makes it hard to fix the error by insisting that you can't do anything
(even install diagnosis tools) until you have fixed the error (which
you can't do).

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904558: What should happen when maintscripts fail to restart a service

[Ian Jackson]

Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail 
to restart  a service"):
> Ian Jackson:
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
> 
> I think this is the core question.  I largely agree with Ian here that
> having postinsts fail is not that big a deal if they can't make forward
> progress, but also we're being asked to advice on what happens when a
> maintainer script fails to restart a service.  I disagree with him on
> whether failure to start/restart a service should be considered a
> configuration failure.

I think whether it is a configuration failure depends on ...

> I think the general rule should be that the success/failure of the
> postinst script should signal whether the package considers itself ready
> to provide whatever API it exists to provide (disregarding the case of
> Essential packages here, since those are special).

... that.  I think I'm in agreement with you on that.  But ...

> This means that failure to start a daemon should generally not cause the
> postinst to fail.

... I disagree with that.  I think that in the usual case, if the
daemon is broken, and the package's purpose is to provide that daemon
service, then the package probably isn't providing its API.

Maybe part of the difficulty we are having with this conversation is
that we are lacking in examples.  This bug and the "parents" #780403
and #802501 are all entirely abstract.

Would someone care to give some examples of packages which with both
behaviours ?


Also:

> The API provided by a package being in the configured state is not
> whether the relevant daemon is running or not; that is runtime and can
> and will change many times while the package is in the configured state,
> so dpkg dependencies are not useful for expressing "this service must be
> running".

I disagree with this.

dpkg dependencies are not just about what sets of packages can be
coinstalled.  They also imply sequencing of package setup.  And since
starting daemons is part of package setup, dpkg dependencies imply a
sequencing of daemon startup.

That is actually necessary in the case where the startup of daemon B
can only successfully completed if daemon A is up,

>  (There's also the case where the service is running on a
> separate host, which is often the case for services such as databases
> and where the use of Depends is inappropriate.)

In that case, there would be a Recommends or Suggests instead, I would
have thought.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904558: What should happen when maintscripts fail to restart a service

[Ian Jackson]

Margarita Manterola writes ("Bug#904558: What should happen when maintscripts 
fail to restart  a service"):
> Sorry that it took so long to get back to this bug.  The other bug took
> all the attention.
...
> If a postinst fails (for whatever reason), the package is left in a
> broken state (Failed-Config) which in general makes the package
> management system unhappy.

The other effect is that the package's dependencies are not
configured, so their postinsts do not experience a broken situation.

> It seems that the only reason why one may want to do this is to call
> the attention of the sysadmin so that they can solve the problem.
> However, in a world where a large number of users are running automatic
> updates, leaving the package management system in a broken state is
> pretty sad, not very visible and rather confusing for the user when
> they finally encounter it.
> 
> Is there an another use case for leaving the package in Failed-Config
> that we missed?

If you deliberately cause the postinst to succeed when the package is
nonfunctional, then the package's r-dependencies will be configured
(ie have their postinsts run) in the broken state.

The r-dependencies' postinsts may then do wrong things.  They may
leave the r-dependencies in anomalous states.  If one takes the
argument you make above to its logical conclusion, all those postinsts
should also report success.

The result is system where the only thing that is happy is the package
management systme, and the records of the root cause of the problem,
and how the failed operations might be reattempted, have been lost.

I guess you will infer from what I write above that "reporting errors
causes the next layer to be unhappy", and "reporting errors causes the
user to be unhappy" to be extraordinarily bad arguments.

There may be good reasons not to treat daemon startup failure as a
postinst failure, but the argument above is not one of them.

> It's unclear why the service (re)start needs to be a special case.

Service (re)starts are more likely to fail for unrelated reasons.
Also some packages are able to provide much of their intended API even
without the daemon.

I think the general rule of thumb should be that a daemon startup
failure should be treated as a configuration failure.

I'm content with a situation where maintainers Feel free to diverge
from this if there are reasons to do so.

> I personally think that it would make sense for the policy to at least
> recommend what should happen with regards to maintainer scripts and
> typical operations that are performed in them.

There is already a section on error handling in scripts, which (IMO
correctly) says that shell scripts should use set -e.

When I wrote that, it didn't occur to me that anyone would think that
a failure by a postinst script to perform an intended operation should
be treated any other way than a failure of the postinst script.

(In the usual case.  There are of course lots of situations where the
right approach is some kind of error recovery, or the operation was
attempted "just in case", or something, in which case more subtle
error handling is called for.)

> And, while I'm open to be convinced otherwise, I don't see any benefit
> from postinst (particularly postinst + configure) ever failing.

Frankly I'm disturbed to be reading this, here.  See above.

If the postinst fails, then the user has the opportunity to fix the
root cause and rerun dpkg-source --configure --pending.  That will
then repair the system completely.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Ian Jackson]

Adrian Bunk writes ("Bug#904302: Why outlawing vendor-specific patch series 
would be a bad idea"):
> The main misconception is that there would always be *the* source.
> 
> Steps you might have before the compilation starts:
> 1. dpkg unpacks upstream sources
> 2. dpkg applies patches
> 3. debian/rules unpacks upstream tarballs as part of the build
> 4. debian/rules applies patches based on distribution
> 5. debian/rules applies patches based on release
> 6. debian/rules applies patches based on architecture

I disagree that (4) should ever be relevant.  There should never be
any patchese applied conditionally based on dpkg-vendor, for the
reasons I explained very recently in response to the liferea example./

We don't ever do (5), do we ?  Please tell me we don't.  We can have
different source code in our different releases.

I can see that (6) might be needed in some exceptional cases but
normally there is a better way.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Ian Jackson]

Iain Lane writes ("Bug#904302: Why outlawing vendor-specific patch series would 
be a bad idea"):
> On Fri, Aug 17, 2018 at 09:49:00AM +0200, Tollef Fog Heen wrote:
> > > One obvious solution if vendor-specific series files get outlawed in 
> > > Debian would be to switch from ubuntu.series to manual patching in
> > > debian/rules based on dpkg-vendor(1).
> > 
> > Or it would mean that Ubuntu would carry a XubuntuY version and do
> > manual (or automatic, based on whatever tooling they have available)
> > merges from Debian, marking it clearly as a different work.

Quite.

If an Ubuntu user downloads the liferea source code from Debian, to
see what Debian's version is like, they should *not* get the Ubuntu
branding and default feed changes.

What this example shows is that, when a derivative wants a program to
behave differently for these kind of reasons, this should generally be
done by *actually changing the source code*.

Ubuntu already has machinery for automatically merging from Debian.
That machinery should be used.  And improved, if necessary.

> I would like you to consider - and I think this is part of what Adrian
> is raising too¹ - this kind of case where the Debian maintainer *wants*
> to support particular derivatives in their source package in Debian and
> is willing to test it properly.

The matter might be different for changes which are to deal with the
presence or absence of particular things in the derivative.  In that
case, the change can simply be made to Debian.  But it should be
conditional not on dpkg-vendor, but on whatever the actual difference
is.

In general, I think package builds should not pay any attention to
dpkg-vendor.  Can I please add that request to the TC's deliberations ?


> Having this facility avoids the need for any kind of source package
> delta resolution process needing to take place

This is, of course, false.

The vendor series file *is a source package delta resolution process*.
It's just a terrible one.

>  which might add arbitrary delays between a new package being
> uploaded to unstable and becoming available in the derivative's
> unstable suite.

If new updates are not be merged automatically, by a robot, in a
timely way, then that is a tooling problem.

Note that if there is a vendor series, *other* changes made in Debian
to the upstream files in the package will be silently ignored.
This is incredibly counterintuitive and undesriable.

> TBH I'm not sure what I'd ask -ctte to do with this argument. If you do
> decide to outlaw the vendor-specific series, maybe advice (6.1.5) to
> relevant developers to consider designing a way to better support
> derivative specific patches within Debian.

"Derivative-specific patches" covers two kinds of changes:

1. Changes which are direct differences of policy or preference in the
derivative, such as changes to the default liferea feeds, or changes
to which package(s) are available.

2. Changes which are consequential on other changes.  Eg, changes to
cope with different (build-)dependencies.

No changes of type (1) should never appear in Debian source packages,
for the reasons I have explained.  Therefore the mechanism you are
suggesting "relevant developers" should design ought not to exist.
Instead, if carrying patches downstream is too hard, that should be
fixed.  And indeed I and others are working on that.

Changes of type (2) should be ideally be dealt with by detecting the
situation at build-time where possible, but that should be done by
looking at which of the alternative build dependencies is installer,
or whatever, not by checking dpkg-vendor.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

(switching from the bug to debian-ctte & secretary@)

Sean Whitton writes ("Bug#904302: Whether vendor-specific patch series should 
be permitted in the archive"):
> On Sun 29 Jul 2018 at 07:52AM +0200, Tollef Fog Heen wrote:
> > I believe his request might also be considered under §6.1.1, since we're
> > being asked about a policy change.  (After talking to Sean in person, he
> > said he intended it under §6.1.3, not §6.1.1, though.)
> 
> I think technically it's §6.1.3 because according to the policy team
> delegation, we decide what goes into the policy manual.

Insofar as the policy delegation claims to delegate to the policy
editors the final decisions on what goes into policy (rather than
merely the routine task of editing the document) [1], it is ultra
vires.  The DPL cannot delegate a power they do not have.

Or to put it another way: even if the policy editors did not refer a
question to the TC, the TC could effectively overrule the policy
editors by using its power in 6.1.1.  Obviously this certainly ought
only to be considered after attempts to solve the problem another way
have been fully explored (6.3.6).

> But it certainly falls under at least one of §6.1.1 and §6.1.3, and not
> §6.1.4.

Obviously I agree with this.

Thanks,
Ian.

[1] I don't read the delegation that way, but for this purpose the
wording of the delegation doesn't matter.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Ian Jackson]

Colin Watson writes ("Bug#904302: Whether vendor-specific patch series should 
be permitted in the archive"):
> ...  My opinion from experience with this feature is that those
> derivative maintainers would have an easier time if they used
> patches with conditional behaviour (or maintained a local branch, of
> course, although that was part of what source package management
> features like this were trying to reduce).

Obviously I agree with the conclusion, but I would like to propose a
different way of looking at this:

The Debian archive and derivative archives, and the .dsc source
package formats, including "3.0 (quilt)" currently including the
vendor series feature, *are a version control system*. [1]

The vendor series feature *is a way to represent a branch*.
We should consider its merits in those terms, by comparing it to other
technology we have for handling branches.

In the current system [1], the obvious competing way to represent a
branch is for the derivative to actually change the source package.
If vendor series are forbidden, the same effect can always be achieved
that way.

Compared to changing the source package, the vendor series appears to
offer a reduction of maintainer friction.  This is a relatively minor
benefit.  (Note that resolution of any merge conflicts during rebase,
or whatever, is still necessary; the only benefit is a small degree of
automation and a slight reduction in different files etc. on
maintainer systems.)  However, that convenience comes at too high a
price.  In particular, the invisibility of the vendor series - that
very lack of friction - means that the vendor series is often wrong.

Conversely, derivatives must already have means for merging or
rebasing their own delta-represented-as-changes-to-the-source-package,
so as to track Debian.  (Vendor series cannot, for example, represent
changes to files in debian/.)  Those mechanisms are often fairly well
developed, and if they are insufficient they need to be improved [2].
And people can inspect the differences by comparing source packages.

So I think it is nearly always better, even without considering global
effects, to represent any needed derivative delta as a changes source
package, than to represent it as a vendor series.[3]

But forbidding vendor series has the global benefit that no-one who
deals with source packages from Debian derivatives has to write code
to deal with, and spend mental energy on, yet another way to represent
the delta.

Thanks,
Ian.

[1] By modern standards, an appallingly bad one.  I would argue that
it all made sense in 1993 (when the best alternative was CVS) but
nowadays we have much much better tools.  This is why I am engaged in
a project to provide something much better than .dsc, based on git.

[2] Tracking Debian is IMO still too hard.  I am working on that.

[3] That does not mean I think that changing the source package is
always or even mostly the best answer; often other approaches will be
better still.  It just means that vendor series are worse than
changing the source package.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Next Meeting: Wednesday, May 16th 19:00 UTC (today) - Currently no topics

[Ian Jackson]

Wouter Verhelst writes ("Re: Next Meeting: Wednesday, May 16th 19:00 UTC 
(today) - Currently no  topics"):
> On Wed, May 16, 2018 at 08:59:35PM +0200, Margarita Manterola wrote:
> > As David mentioned in IRC and I mentioned in person to the people in
> > Hamburg, it is a bit worrying to not have anything to discuss,
> 
> Why is it worrying?
> 
> The TC not having things to discuss means everyone in Debian is getting
> along nicely. That's great! :-)
> 
> (well, okay, that's the theory)

Sadly I think it is more likely that people in Debian have given up
trying to use the TC to resolve any differences of opinion they may
have.

debian-devel has become the most obvious escalation route.  (Along
with attempts to resolve disputes in one side or the other's favour
through chnages to policy and/or lintian.)  And, indeed, recently
no-one there diagreed when I wrote this in a thread about autopkgtest
regressions blocking testing migration:

   > a regression in a reverse dependency can come due to one of the
   > following reasons (of course not complete):
   ...

   I think you need more information about process and authority, and
   what to do if the maintainers disagree, or if one or the other does
   not respond.  We don't have a good formal mechanism for resolving
   disagreements, and our NMU rules are restrictive and opaque, so this
   is not so easy.

And later in the same mail I therefore proposed this wording, which
was adopted:

 If you find that you are not able to agree between you about the
 right next steps, bug severities, etc., please try to find a neutral
 third party to help you mediate and/or provide a third opinion.
 Failing that your best bet is probably to post to debian-devel.

Of course in cases of serious disagreement, using a mailing list turns
into a war of attrition.  Luckily most of our contributors have
spotted this failure mode and avoided it.

Instead, when the maintainers of a package, or a core team, dig their
heels in about something we care about, and block our work or break
things we are relying on, we shrug our shoulders and go and do
something else with our life.  Perhaps something not related to
Debian.

I think that a substantial proportion of the project even think that
this is how things should work.  But it does not mean that everyone is
happy.

Regretfully,
Ian.

Bug#877024: marked as done (modemmanager should ask before messing with serial ports)

[Ian Jackson]

Philip Hands :
> You'll be pleased to note that the original bug in this case has now
> been closed as a result of a newly uploaded package version:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#101
> 
> Thanks to all involved for bringing this to a successful resolution,
> at which point the TC bug becomes moot, so I'm closing it now.

Oh, excellent.  Thanks in particular to Mathieu Trudel-Lapierre for
uploading the new upstream version (with the appropriate policy
patch).

Ian.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before 
messing with serial ports"):
> Ian, any comment about this 1.8-rc1 version with the filter policies
> implemented?

Thanks for the ping.  I haven't had a chance to test it, but if it
behaves as described earlier here then (with the appropriate policy) I
think it would DTWT.

I will try to get around to teting it.

Regards,
Ian.

Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

[Ian Jackson]

Margarita Manterola <ma...@debian.org>:
> I'm sorry this took so long to be actioned by us. This is on me.
> 
> In previous bugs that have been raised to the technical committee
> it has already been discussed and agreed that the technical
> committee does not have the power to overrule official Debian
> delegates.  This covers the decisions taken for example by the
> FTP Masters or the Release Team.
> 
> Thus, we are closing this bug now, as it's not actionable.
> 
> We suggest that you work together with the FTP Masters in
> figuring out a solution to this problem.

I'm not sure I agree with this.  Firstly, it's not clear that the
acceptance or not of packages is a decision "for whom noone else has
responsibility" in the words of the Constitution ?  (That's funny
wording because it should say "for which" since decisions are not
people...)

Secondly, the request could be actioned by a non-binding statement by
the TC.

Thirdly, when you decline a complaint, I think the TC should give real
information about escalation routes.  "Work together with the FTP
Masters" is not the correct escalation route.

You should have advised Pirate that:
 * Pirate should first escalate the matter with leader@d.o,
   because although the DPL does not have the power directly to
   overrule the ftpmasters, the DPL _does_ have ultimate
   responsibility for the ftpmaster team and therefore does have a
   supervisory role.
 * If that does not yield an appropriate outcome, Pirate has the
   option of a General Resolution.
 * Alternatively, this could be seen as a question of policy.  It
   seems unlikely that ftpmster would act cotnrary to a clear
   statement in Debian Policy about when circular build-deps are
   acceptable.

I wouldn't be saying all of this if I agreed that Pirate's complaint
is without merit.  I think our general approach to circular
build-dependencies needs to be clarified.

Personally for example I think it's quite ridiculous that the only way
to get from the Haskell binaries in jessie to the Haskell binaries in
stretch is an undocumented chain of recompilations of packages from
snapshot.d.o.  If we let Haskell do that, why are we being so hard on
JavaScript ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

[Ian Jackson]

Julian Andres Klode writes ("Re: Bug#883573: Reevaluate libpam-systemd 
systemd-sysv dependency ordering (746578)"):
> I think another major problem (with bug 883555) though is that systemd-shim
> is not Multi-Arch: foreign like systemd-sysv. In that case, systemd-shim was
> first marked for install, but then for removal as systemd-shim:foreign was to
> be installed. And then it picked systemd-sysv somehow. In summary, 
> libpam-systemd:foreign
> is currently not installable if systemd-shim is installed.

I think that perhaps systemd-shim should be marked M-A foreign.  Its
function is to provide a dbus service which AIUI is not
architecture-dependent.  I can easily upload such a change at this
stage of the buster cycle.

> > FAOD, I regard myself as a caretaker for system-shim.
> 
> Then please adopt the package?

I definitely don't feel the sense of knowledge or ownership that would
be appropriate for that.

> On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote:
> > One question I have is about this: "several packages now require just
> > systemd-sysv".  Can someone refer to some examples, please ?
>
...
> $ grep-aptavail -FDepends systemd-sysv --and --not -FDepends systemd-shim 
> -nsPackage | grep -v ^jak
> friendly-recovery
> gpsd
> mandos
> micro-httpd
> munin
> numad
> pk4
> prometheus
> prometheus-node-exporter
> runit-systemd
> systemd-cron
> gpsd
> micro-httpd
> numad
> pk4
> prometheus
> prometheus-node-exporter
> systemd-cron
> freeipa-server
> tinysshd
> tinysshd

What ?  Why do these packages depend on system-sysv ?  (I mean, for
systemd-cron it's kind of obvious but for most of the others it is
not.)  I checked gpsd as that was something I thought I knew something
about and that Depends on netbase | systemd-sysv, which is rather
different and seems OK.

I reran your search in sid with --not -FDepends netbase and got a
shorter list.

  freeipa-server
  friendly-recovery
  lava-dispatcher
  lava-server
  mandos
  micro-httpd
  munin
  numad
  pk4
  prometheus
  prometheus-node-exporter
  runit-systemd
  systemd-cron

That still seems to have quite a few false positives (micro-httpd,
mandos), as well as some minority packages that seem to have gained or
maybe always had unfortunate specific init system dependencies
(freeipa-server, friendly-recovery).  I haven't investigated them in
detail.

Do you have an example package that is causing the installation
failure ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

[Ian Jackson]

Don Armstrong writes ("Bug#883573: Reevaluate libpam-systemd systemd-sysv 
dependency ordering (746578)"):
> On Tue, 05 Dec 2017, Julian Andres Klode wrote:
> > I thus opened bug 883569 against systemd, but mbiebl would like to
> > get permission from the you first.

I think it would be sensible for the TC to explicitly grant or
withhold permission.

> As systemd-shim does not (appear to?) have an active maintainer, and
> this should be moot for stretch->buster, I don't personally see a
> problem. [Perhaps a NEWS entry or something in the release notes might
> be a nice gesture?]

FAOD, I regard myself as a caretaker for system-shim.

> Does anyone have a counter-argument?

I don't.  The argument presented in the head article seem to make
sense to me.  But I don't feel I understand all the implications.

One question I have is about this: "several packages now require just
systemd-sysv".  Can someone refer to some examples, please ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: TC nomination procedure v0

[Ian Jackson]

Wouter Verhelst writes ("Re: TC nomination procedure v0"):
> It's a vote that will have effect on the appointment of a person to the
> TC. The constitution specifically wants appointment votes to be public.
> Without wanting to comment on the letter, I think this is contrary to
> the intent.
> 
> To be clear, I also think the consitution is wrong to require that such
> votes are public. I think the TC should not have to make appointments in
> public, for the very same reason that we also have secret ballots on DPL
> votes. However, I think the correct course of action here is not to
> ignore the constitution and explain that by some clever choice of words,
> but rather to amend the constitution to make it be in line with that
> rationale.

I suppose it would be worth explaining why I drafted this the way I
did, and what I intended.

The current system, with a private process including non-binding
filtering votes etc., followed by a public rubber stamp, is exactly
what I had in mind, and I still think it is the best way.

The reasons why most of the process has to be private are obvious.
The reasons for the formal binding vote to be public are less so, it
seems.

So: In a situation where there is rough consensus and every TC member
is content that the process is appropriate, then the public vote is
indeed a formality.  That's simply a reflection of consensus generated
during the private discussion.

Often some participants in that consensus might have preferred
different candidate(s), considering the matter in a vacuum, but think
it more imporant to not to do the inevitable public personalised
discussion of possible appointments, than to force this issue.  Such a
TC member will vote with the rest of the committee in the formal
public vote.  That is fine.

But: if there is a lack of consensus on process, or a TC member feels
strongly enough to publicly dissent on a particular candidate, or
whatever, it is vital that that such a TC member has a way to dissent
which is simultaneously formally effective, and verifiable from
outside the TC.  And likewise, that TC members who vote to overrule a
publicly dissenting member must do so in a way that is visible from
outside.

The alternative is a situation where, even when there is a serious
disagreement, TC members can mislead outsiders about the ultimate
position they took when the matter was finally decided by a vote.

Luckily such misleading statements are (I think) hypothetical, but the
question of dissent, and the need for formal public dissent, is not.
Sam Hartman indeed abstained on a recent TC appointment vote out of
unhappiness with the process.  That is precisely the kind of thing
that cannot be done if the final vote is secret.

So that is why the private process within the TC must be ratified by a
public vote.  (And it also ensures that any votes or polls which take
place in the private process are indicative, but are not binding on TC
members in the final vote.)

Ian.

Bug#881339: let's find a solution

[Ian Jackson]

Paolo Greppi writes ("Bug#881339: let's find a solution"):
> [some stuff about babel]

Can someone point me to a clear summary of ftpmaster's position ?

All I could find is this

  
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-November/022197.html

Which contains the single sentence

  | it is strange that the package Build-Depends: on itself!?

Lots of language compilers build-depend on themselves so surely there
is more to this.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Ian Jackson]

Thanks for your mail.  I have trimmed vigorously the parts I agreed
with :-).

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: 
Concerns about the Technical Committee"):
> That said, I actually think in some cases we need to spend more energy
> rather than less.  Minimizing energy spent on the process is not one of
> my goals.  I think that the TC in particular may need to spend more
> energy to have a chance of people feeling valued even when there is
> disagreement.

That may be true.  I think perhaps what I mean is that we are not
spending our energy well.

Unstructured mailing list discussions work reasonably well when
everyone feels that everyone else is on the same side, and everyone is
trying to understand the issues and feel they will be able to come to
a consensus, or at least a conclusion that everyone finds tolerable.

When things get more difficult, they become sprawling horrors.
Participants (quite understandably) feel the need to respond to
everything their now-opponents say.  People feel under time pressure.
It becomes difficult to see the wood for the trees.  Because the
parties are replying directly to each others' emails, there is ample
opportunity for misunderstanding, and all the escalations of minor
aggressions or poor word choices etc. into meta-disputes and anger.

I think it would be better if we asked participants to write a much
smaller number of longer and more comprehensive statements.  The TC
would have to explicitly forbid the use of the email-thread-based
debate style, even as a supplement (perhaps, by blocking it from the
TC's list).  If after however many (small number of) rounds of
refinement/response are permitted, one party decides they need to add
something to their statement of their case, they should have to ask
permission.


> Interestingly, the one area where I think conserving energy is important
> is the one you call out: minimizing the energy people need to spend
> responding to a complaint.
> Even there, I think that in a case where the TC thinks it is likely to
> ask a maintainer to make a change (or override the maintainer) it is
> reasonable to expect the maintainer/respondant to spend enough time to
> explain their position well enough that the TC understands it.

Yes, I absolutely agree.  But I think your suggestion that the TC
should evaluate an incoming complaint, to see if there is a case to
answer, before expecting anything from the maintainer, would be very
helpful.


> I also think the court emphasis on justice and "right" is harmful.  As I
> said in my blog entry, technical correctness is an important factor, but
> I think it is a less important factor than maintaining our community.

IMO injustice _itself_ undermines community.

When you say you want to put "community" ahead of "justice", what I
hear is that you want to put the opinions of some people ahead of
others, because they might be hurt more if the decision goes against
them, or because the are more important to the project somehow.

After all, if we are not to put some people's opinions ahead of
others, what we are left with is making decisions based on the merits,
which is what I am thinking of as justice.

That's not to say that we should not try to maintain our community.
Certainly we should try to reduce the damage done by disputes.

And "merits" does not usually mean technical merits.  Normally it
means thinking about whose interests are more vitally at stake.  It
often means thinking about those for whom the status quo is least
tolerable.


> However, because of who we are, we tend to emphasize technical
> correctness.

I agree with you on this part though.  It is very rare that a dipute
before the TC is mostly technical (let alone entirely technical).

The things people are usually arguing about are:

* Tradeffs between the interests of users with different use cases.

* Whose job is it to do some work that people think is desirable - or
to put it another way, who will bear the pain of the fact that the
work has not yet been done.

* Who is allowed and required to review (and, ultimately, if they see
it as necessary, block) others' work.

* To what extent must a maintainer permit contributions (and,
therefore, maybe to carry patches) that others care about, but which
the maintainers feel are not worthwhile (or even, inappropriate).

These are all, ultimately, questions of politics: they concern the
balance of competing interests, and the location and scope of power
and control.


Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Ian Jackson]

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: 
Concerns about the Technical Committee"):
> I am discussing how we handle conflict because I hope we can do a better
> job of helping  people feel valued even when we do not agree with their
> technical positions.

You've perhaps heard me say this before, but I think the TC process
lacks structure and that if the TC set out the process more formally,
things might go less awry.  (And also it would involve less of an
investment of energy by all the partipants, particularly the
respondents to a complaint.)

One of the most toxic things that can happen in any kind of dispute is
for there not to be a clear understanding of what the rules are,
within which the dispute will be conducted.  Ie, who is allowed to do
and say what, and when.

When people disagree about the metarules, community disintegrates
because people feel that not only are their opponents disregarding
their needs, but they are also playing foul.


I know that some people disagree, but I think that the TC should take
on much more of the trappings of other formal dispute resolution
mechanisms that we find in wider society.  Particularly, the TC should
be more like a civil court or tribunal.

Courts are of course stressful, but I think that stress is usually the
result of the underlying dispute.  (Courts in some jurisdictions are
awful, too, of course, and I'm not suggesting we set up professional
advocates with a vested interest in prolonging and exacerbating
disagreements...)

One big advantage of court-like formality is is that it provides
neutral (and possibly even constructive) ways to express and handle
the disagreement.  And of course it can avoid arguments over the
ground rules.

There are other models: mediation, perhaps.  But mediation is just
facilitated negotiation, and explicitly excludes the question of
justice or rightness.  What really matters for the outcome of
mediation is not who has the best arguments, but what are the parties'
"best alternatives to negotiation".

So the TC should formally adopt rules of procedure, saying how and
when issues should be brought to the TC, and how the TC will handle
them.  The rules should cover questions of when TC members should use
their ability to call for votes, and add amendments.  They should say
what interval is normally appropriate before asking the TC for help.
The rules will need to be bent on occasion, of course - but the rules
themselves should say who can grant permission to bend them.

The TC rules could also limit the email discussion, at least by
default - one of the most exhausting things about the TC right now is
the never-ending email threads.

It would also IMO be a good idea for the TC to explicitly adopt some
"form letters" that should be used in various circumstances.  If there
were a standard TC-approved text for the message saying "I feel
strongly enough about this, and you don't seem to agree, so I think I
will ask the TC for help soon" then that text could be made suitably
collegiate and refined over time, and there would be no arguments
about the tone of someone's email.


> I was not planning on discussing systemd again.

Thanks.  I don't think doing so is going to be illuminating.  It will
just reopen wounds.

Ian.

Re: Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Sam Hartman writes ("Re: Bug#877024: Modemmanager probing of unknown Devices"):
> No, that was not the tone of Ian's message.  I wish it had been.

I'm sorry that my message didn't come across as Sam writes:

> He wrote the patch and said roughly "Hey, I know you don't like this,
> and I think we need some outside help  deciding which of us is right.
> I'm going to give you a bit of time in less I've got it all wrong and
> you're OK with this approach and then I'm going to ask for help."

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Sam Hartman writes ("Re: Bug#877024: Modemmanager probing of unknown Devices"):
> I wanted to make you aware of a status update.
> The maintainer who has been doing most of the uploads on modemmanager
> stepped down after receiving my query.

Oh.

> As a matter of process, it's not clear that there's an active maintainer
> of modemmanager.  Speaking as an individual, but not as a TC member (I
> haven't talked to anyone else), I think it would be reasonable to treat
> modemmanager as a package that is under-maintained at the moment in
> which you've found a bug you care about, approaching things and
> balancing the same as you might in any similar situation.

Yes.

I think that means in this case (since there is some controversy)
explaining what I intend to do and seeing if anyone objects.

Concretely, that means that I should be thinking about uploading the
experimental upstream probing change branch to Debian experimental.

> With more of a TC hat on, I am very reluctant to rule on this issue
> without an active modemmanager maintainer.  I don't think there is a
> compelling need to do so, and I don't want to rule out the possibility
> of a modemmanager maintainer coming along later and presenting an
> argument about how we should balance this issue.
> I don't think the lack of a ruling will be a blocking force at the
> current time.

I can see why the TC might want to avoid making a final ruling without
proper input from the maintainers.

But, should I upload to experimental, and later, to sid, as I have
proposed ?  It's not quite clear whose permission I need.  To some
people I have already overstepped the mark[1].

The dev ref says "Have you geared the NMU towards helping the
maintainer?" and it all seems rather awkward to me to claim I am
"helping the maintainer" when AFAICT the maintainers are quite
unenthusiastic about these proposals.

I would welcome a decision by the TC (or informal comments, for that
matter) saying simply that they think it would be appropriate for me
to do those uploads.

Thanks,
Ian.

[1] Apparently referring the matter to the TC a mere 5 years after
the maintainers rejected changing the behaviour is too hasty.  I
accept of course that the way I recently brought my renewed awareness
of this problem to the attention of the maintainers wasn't ideal.

Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Tollef Fog Heen writes ("Bug#877024: Modemmanager probing of unknown Devices"):
> Given there's no indication they were made aware of your bug filing that
> I could find, I don't think that's a conclusion we can make.

In my message on the 25th of September I wrote, in prose, that I
intended to escalate this issue to the TC:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#77

I got no response, so I filed #877024.  When I did so, the BTS sent
this mail CC the maintainers:

   From: ow...@bugs.debian.org (Debian Bug Tracking System)
   To: Ian Jackson <ijack...@chiark.greenend.org.uk>
   CC: debian-ctte@lists.debian.org,
pkg-utopia-maintain...@lists.alioth.debian.org
   Subject: Processed: modemmanager should ask before messing with serial ports
   Date: Wed, 27 Sep 2017 20:51:06 +

   Processing control commands:

   > block 683839 by -1
   Bug #683839 [modemmanager] modemmanager fiddles with ttyUSB devices without 
asking first
   683839 was not blocked by any bugs.
   683839 was not blocking any bugs.
   Added blocking bug(s) of 683839: 877024

   -- 
   683839: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839
   877024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877024
   Debian Bug Tracking System
   Contact ow...@bugs.debian.org with problems

This is indeed not an ideal as a way to draw the escalation to the
maintainers' attention.  (None of the traffic in #683839 explicitly
mentions the TC.)  I should have used X-Debbugs-CC to CC my initial
report of #877024 to the maintainers.  Sorry for not doing that.

I'm happy to wait a bit longer to see if the maintainers have an
opinion.

Thanks,
Ian.

Bug#877024: Modemmanager probing of unknown Devices

[Ian Jackson]

Sam Hartman writes ("Bug#877024: Modemmanager probing of unknown Devices"):
> Hi.  In #877024, the TC was asked to rule on whether modemmanager should
> continue to probe USB devices that might not be modems.
> 
> There's been significant involvement from upstream leading to a new
> optional behavior that is less aggressive about probing unknown devices.
> 
> Would it help the maintainer for the TC to rule on this issue?
> 
> Do you have any input into the TC process you would like to give?

Thanks for asking these questions, Sam.

FAOD, currently, it seems that the Debian maintainers don't have time
to address this issue in Debian.  That is fine of course.  No-one is
obliged to do work, even if their name is in the Maintainer or
Uploaders field.

It looks like the conversation with upstream is going constructively
and will yield something that should be satisfactory to them, and to
me, at least.

I intend to carry on and try to help do the Debian part of this, with
NMUs as seem appropriate.  My earlier email suggesting an upload to
experimental is part of that.  If the modemmanager maintainers would
like to step in then that would be great of course.  Just let me know.

My main goal is that we should not let this bug go unfixed in buster.

So, addressing the need for a TC decision:

If there is no objection from the modemmanager maintainers to the
general direction which has been proposed and discussed here
(including the use of the `strict' probing policy), and no objection
to NMUs (on a relaxed timescale, but eventually targeting sid and
hence buster), then I don't see the need for a TC ruling.

If there are objections of detail then I think we should be able to
resolve them amicably.  I'm happy to take guidance.

It is mostly if there is an objection about the principle of the
approach that modemmanager should take, or an objection to NMUs, that
a TC decision might be needed.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Wouter Verhelst writes ("Re: Bug#877024: modemmanager should ask before messing 
with serial ports"):
> On Wed, Oct 18, 2017 at 09:18:37PM +0200, Aleksander Morgado wrote:
> > How about waiting a bit until patches reviewed and tested upstream?
> 
> The whole point of experimental is "to test and review stuff". It's fine
> if things break there; that's what it's for.

Precisely.

> Having packages in experimental allows for more widespread testing. It
> would seem that in this kind of situation, you would actually want
> that...?

That was my thinking.

For upstream: things in "experimental" are not automatically installed
on user systems (well, unless the user has been exceptionally
foolish), and do not automatically propagate to places where they
might be so installed (let alone, be released).

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before 
messing with serial ports"):
> FYI, already implemented an initial approach, ready for testing:
> https://lists.freedesktop.org/archives/modemmanager-devel/2017-October/005969.html
> 
> In the Debian case, you would want to use "--filter-policy=STRICT"
> when starting ModemManager.

Thanks.  This is very encouraging.  I would like to test this.

My testing approach would probably be to prepare a Debian package of
this version, based on the existing Debian package.

It might be useful for me to upload such a thing to experimental so
others can try it too ?  Would the Debian modemmanager maintainers
object to that ?

I will do that upload: to DELAYED, picking some suitably cautious
version number, unless I hear to the contrary.  (And I'll wait at
least a week for a reply to this question.)

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing 
with serial ports"):
> This is part of the discussion we had in the MM mailing list for such
> a solution:
> https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html

Thanks, this looks constructive.

Of the heuristics in that mail, most seem to me to be very sound
justifications for thinking that the device is safe to probe.

The one big exception is this:

 | * If vid is a known modem vendor (e.g. huawei, zte, sierra, u-blox,
 |  telit), it's a modem and we probe the tty.

This is a hostage to the future, since of course we don't know what
devices might be manufactured by a particular vendor in the many-years
life of a Debian release.

I guess that if we in Debian don't like that particular heuristic it
would be possible for us to disble just that one ?

I don't understand this one:

 | * If kernel driver of the TTY is option/sierra/qcserial,

but maybe it is OK.

Ian.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing 
with serial ports"):
> [Ian Jackson:]
> > Many such modems present as USB serial devices, eg ttyACM or ttyUSB.
> > Consequently, modemmanager has the ability to open serial ports and
> > probe them to see if they respond to Hayes-style AT commands.  That
> > functionality is currently triggered automatically by default, even
> > for USB serial ports whose USB device IDs are unknown to modemmanager,
> > or whose device IDs correspond to generic USB-to-serial adapters.
...
> A clarification here, ModemManager doesn't automatically probe
> usb-to-serial converters, those are "greylisted" so that they're
> only probed on "manual scans". Of course, the vid:pid needs to be
> known to MM and in the greylist, for this to happen.

Thanks for the clarification.

The greylist is nevertheless never going to be complete.  My initial
message in #877024 lists some of the consequences, many of which
actually occurred with generic USB-to-serial adapters (or generic
USB-to-serial chips).

Ian.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing 
with serial ports"):
> Hey Ian!
> > Since the maintainers and upstream evidently disagree with this
> > tradeoff, it has been necessary for me to ask the TC to step in.
> 
> The maintainers don't actually disagree. Why didn't you bring this
> issue to the ModemManager mailing list in the first place? I
> personally don't follow any downstream ModemManager bug, and we even
> have a bug open upstream:
> https://bugs.freedesktop.org/show_bug.cgi?id=85007

Thanks for your response.  It's excellent to see someone taking an
interest in this bug.

However, I have to say that that upstream bug log does not really
suggest to me that upstream thinks that the current probing behaviour
is unacceptable.  It has been open since 2014 and if the bug is to be
believed the modemmanager default behaviour in upstream has not
changed.

The key part of your response in #683839 is as follows:

  Asking the user... well, what would we ask? Should we ask "is this a
  modem" for every TTY we find? Is it better to annoy thousands of
  users each time a TTY is found instead of blacklist for all of them?
  We try to keep the blacklist in stable releases updated and stables
  happening each 2-3 months.

Your concern here is precisely the user convenience which I am saying
needs to be traded off for safety and reliability.

"Every TTY" is rather hyperbolic, of course.  We are only speaking
here of tty devices which might be modems.  modemmanager already
refrains from autoprobing builtin serial devices ttyS* and I assume it
ignores things like multiport serial cards.  So we are speaking mostly
of USB-attached serial ports.  And we only need confirmation the first
time one is plugged in.

As I have explained, a blocklist is not sufficiently safe or reliable.

A passlist of things known definitely to be modems (not generic USB to
serial chips) would help reduce the user query burden.

  Plus, there isn't always a "user" to ask
  when a modem is plugged in, ModemManager (as NetworkManager) don't
  really require a GUI to work and lots of headless systems out there
  use it.

In those situations, obviously, I would expect use of a command-line
tool or configuration file.


> >  * Say that, in the absence of a better solution, my patch should
> >be applied to modemmanager.
> 
> I commented about that patch in bug 683839, please don't apply it,
> it would break all modems not only those with TTYs.

Sorry about that.  I wasn't able to get modemmanager working with my
MBIM device (which I'm now using in Hilink mode, hence without
modemmanager, anyway) so I wasn't able to test that path.

Please can you point me to the right place to make this change ?
I can try revising my patch by myself but it will be more likely
to be right if you help.

> Again, I'd have suggested to bring this patch to the ModemManager
> mailing list before just saying that the patch should be applied in
> absence of a better solution...

As a Debian user, experiencing a problem with the default
configuration of my Debian system, and trying to use Debian's
governance processes to escalate the bug, it is appropriate for me to
use a Debian channel for this.

But I really appreciate you taking an interest.

> An easier thing would be to allow just "dpkg -R
> modemmanager", there should be no other package depending on the
> daemon itself.

That's no help because someone might have (for example) both a modem
and a braille display, or whatever.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing 
with serial ports"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > This has gone far enough.  I would like to remind you of Constitution
> > 6.3(5)
> 
> Here's what I prefaced my first remark with:
>  (speaking as a Debian user, not as a TC member)
> Perhaps I should have added this to each message I sent?

You snipped the following part from my email:

  Note the point about forums.  If you want to engage in "design of new
  proposals", for example your suggestion to drop modemmanager from
  default installs, you should do that on the relevant mailing lists for
  modemmanager, or network-manager (which normally pulls it in), or
  debian-devel.

  It is not appropriate to use the TC list to advocate a novel and
  radical proposal in this way.

Ian.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Keith Packard writes ("Bug#877024: modemmanager should ask before messing with 
serial ports"):
> That requires fixing the package instead of just getting it out of the
> way, a significantly harder thing to manage.

This has gone far enough.  I would like to remind you of Constitution
6.3(5)

 | The Technical Committee does not engage in design of new proposals
 | and policies. Such design work should be carried out by individuals
 | privately or together and discussed in ordinary technical policy
 | and design forums.
 |
 | The Technical Committee restricts itself to choosing from or
 | adopting compromises between solutions and decisions which have
 | been proposed and reasonably thoroughly discussed elsewhere.

Note the point about forums.  If you want to engage in "design of new
proposals", for example your suggestion to drop modemmanager from
default installs, you should do that on the relevant mailing lists for
modemmanager, or network-manager (which normally pulls it in), or
debian-devel.

It is not appropriate to use the TC list to advocate a novel and
radical proposal in this way.


I can see that a naive reading of this dispute is "Ian hates desktoppy
stuff and that's why he hates modemmanagaer and that's why he hates
this modemmanager behaviour".  But it is not accurate.  The
functionality in modemmanager is important to lots of people.  The
fact that I'm not using modemmanager right now is more to do with the
exact vagaries of hardware support than anything else.

All I am saying is that modemmanager must not, even if it seems
convenient, take these IMO unacceptable risks with people's serial
ports.  That is, the safety, security and software reliability of the
users with "stuff" connected to their serial ports should take
precedence over the convenience of the users who need modemmanager.

And this is true even if they are the same people: someone who has
"stuff" connected to their serial ports, and also needs modemmanager,
should find that Debian has prioritised not putting them at risk and
not breaking their stuff, over making their telephony experience more
convenient.

Since the maintainers and upstream evidently disagree with this
tradeoff, it has been necessary for me to ask the TC to step in.


I would like the TC to, overruling the maintainers:

 * Confirm the principle that modemmanager (and indeed other software
   in Debian) should not probe serial devices unless:
  - the user has given explicit permission; or
  - the device is known, for whatever reason, to definitely
 be a modem (or whatever kind of thing the program wants)

 * Say that, in the absence of a better solution, my patch should
   be applied to modemmanager.

 * Explicitly say that the TC expects the decision to be implemented
   in a way that the maintainers approve of, if possible, so long as
   that doesn't involve a large amount of additional work.

Thanks,
Ian.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing 
with serial ports"):
> Yeah, I was just thinking that it would be easier to stop installing
> support for modems by default than to actually fix modemmanager to
> behave itself. It's certainly how I work -- apt remove modemmanager
> solves a world of problems for me.

But I should be able to use the same laptop to (1) control my machine
tools or talk to my rpi or whatever (2) go online with a usb mobile
modem when I'm out of the house.  Possibly even simultaneously.

And, people shouldn't have to install support software to get their
internet to work.

Ian.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Ansgar Burchardt writes ("Bug#877024: modemmanager should ask before messing 
with serial ports"):
> It's not useless.  At least not when using UMTS via USB dongles which I
> would guess more people use than ham radio.  (Some of these USB dongles
> also emulate network cards and provide a DHCP server instead IIRC.)

Right.  These kind of dongles are very common.  My last one (which
died recently) was one.

Also, AIUI modemmanager contains code to do things with the new-style
MBIM dongles (which can also be done with the cli tools in
mbim-utils).  But I definitely wouldn't suggest disabling its ability
to work with AT-command modems, as they are still being sold.[1]

Ian.

[1] I think.  I tried to buy one and ended up with one which is
switchable between MBIM and Hilink instead.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Package: tech-ctte
Control: block 683839 by -1

modemmanager is a program for handling modems, particularly
usb-connected mobile-telephony modems (aka "3G/4G sticks" etc.)

Many such modems present as USB serial devices, eg ttyACM or ttyUSB.
Consequently, modemmanager has the ability to open serial ports and
probe them to see if they respond to Hayes-style AT commands.  That
functionality is currently triggered automatically by default, even
for USB serial ports whose USB device IDs are unknown to modemmanager,
or whose device IDs correspond to generic USB-to-serial adapters.

I.e., if one is running a normal Debian installation and plugs in a
usb-to-serial converter, modemmanager will open the device and send AT
commands to it, to see if it is a modem.

This behaviour is IMO unaccaptable, as a default.

Serial connections are used to connect a wide variety of equipment
including industrial robots, electronic test equipment capable of
generating hazardous voltages, accessibility hardware, scientific
instruments, and embedded computers.

In the worst case (luckily, as far as I know, hypothetical):

 * This behaviour could cause someone personal injury, if a real-world
   device connected to the serial port misinteprets modemmanager's
   probe (or if its control firmware crashes) and makes hazardous
   movements or some such

Symptoms which have been observed include:

 * User's braille display stopped working during system boot
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621851
   With a less resourceful user, that might make the computer
   completely unuseable.

 * Random number generator "interfered with"
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840697
   Ultimate consequences not clear from the bug report, but if the RNG
   driver software has poor error handling it might include poor
   quality random numbers and therefore weak cryptographic keys.

 * GPS no longer recognised at boot
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798193
   (Not as trivial a problem as it sounds, as it could prevent the
   system being used as a navigation aid.)

 * "Breaks" apcupsd
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32

 * User's Palm Pilot PDA crashes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#52

 * User's 1-wire DS9097 interface is messed up, requiring a
   reboot to become functional again
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#72

 * My 3D printer reported protocol violations on startup
   and host software could sometimes not connect to printer
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#5

Other possible consequences which have been hypothesised are:

 * Simply opening the port and enabling RTS might enable radio
   transmissions in a ham radio context
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#42
   (Resulting in possibly-illegal radio interference.)

 * Simply opening the port and enabling RTS switches some scientific
   equipment into remote control mode, disabling the front panel
   and perhaps leading to hazardous situations.  (pers. comm)

 * Some 3D printers will reset when RTS is toggled, interrupting
   any print job (causing real world lossage in the form of wasted
   feedstock and printer time)
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32

In August 2012 I experienced this bug and filed #683839 with severity
`important'.  The maintainers apparently do not agree with my analysis
and there has been no action by them since then other than efforts to
maintain the blocklist.

In the intervening time many users have reported manifestations of
this problem to #683839 and to other bug reports.  The reactions from
the maintainers have consistently been to try to get individual
devices blocklisted, even though as has been explained repeatedly,
this is not really sufficient.  The maintainers have not engaged with
the arguments against blanket probing.

Note that safe behaviour does not necessarily mean that every time the
user plugs in their modem, they have to confirm its use.  Other
solutions are possible, for example asking for explicit permission
from the user, the first time any particular device is seen, that it
is OK to probe that device.  (Similar behaviour is already implemented
for USB HID devices - keyboards etc. - because of the security
implications.)

I'm afraid don't really want to do the work of writing a better UI.
But I have provided a simple patch which at least makes the behaviour
safe.

IMO at the very least, for buster, we should apply that patch - or an
equivalent - and then the maintainers can consider how to improve the
UI/UX to explicitly ask permission, if they think that is desirable.

We should also consider whether to backport any of the resulting
changes, or include them in stable updates of some kind.

Thanks for your attention.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>

Re: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Ian Jackson]

Jérémy Lal writes ("Re: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) 
experimental; urgency=medium"):
> So, a short NEWS entry explaining /usr/bin/node is now available by default,
> and that /usr/bin/nodejs will stay available indefinitely ?
> Or even nothing and just a changelog entry ?

I would go for the latter, personally.

My philosophy is that a NEWS entry is something you use when people
have to change something.  The best packages do not need NEWS entries
because they simply keep working.  Starting to provide /usr/bin/node
and keeping /usr/bin/nodejs means that no-one has to change anything,
which is perfect - and therefore we don't need to bother users.

It's true that NEWS might be used when a new opportunity arises that
means many users might want to change something, even though they
don't have to.  I would reserve that for situations where the user's
existing setup is (likely to be) hazardous or seriously suboptimal,
especially in a non-obvious way.

Existing scripts that use /usr/bin/nodejs are not as portable to other
OSes as they could be, but of course the script's author will probably
be aware of that already.  It doesn't seem to me to be the kind of
opportunity for remedying a significant defect that would warrant a
NEWS entry.

However:

One thing you I would consider is that it would be nice if scripts in
Debian packages were made more portable to other distros.  So Debian
packages should gradually change to use /usr/bin/node.  I am very
conservative about these things because I like to keep backporting
(within Debian) as easy as possible.  So if I were the maintainer of a
node.js package which had scripts mentioning /usr/bin/nodejs, I would
probably make that change in buster+1 rather than in buster.

In buster+1 you should probably consider asking for a lintian warning
about references to /usr/bin/nodejs.  Not because you intend to drop
/usr/bin/nodejs ever (why do that - see previous emails) but because
it would be better, as I've just discussed, for Debian packages to
contain fewer hurdles to adoption elsewhere.

Regards,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Ian Jackson]

Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental; 
urgency=medium"):
> I guess that one could do something like moving the symlink into another
> -legasy style package, and recomend that from the main package for one
> release to keep upgrades happy. Then drop the recomendation, and wait
> for popcon to show that people are not installing the package any more.
> Then remove the package in testing early in a cycle and see if anyone
> reports bugs about it.

Even that would be quite unfriendly, because third party scripts might
easily be deployed onto new Debian installs as well as existing ones.

Also, it is imposing an administrative burden on all Debian users (the
metadata for the -legacy package, spurious search hits, etc.).  That
burden might be small but would be completely unjustified.

Ian.

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Ian Jackson]

Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental; 
urgency=medium"):
> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
> until it's no longer needed - be it other debian packages or other user
> scripts.

Earlier you said only "other Debian packages":

   My plan was to simply keep /usr/bin/nodejs around for some time
   until no debian package rely on it.

Now you say "other user scripts".  I don't know how you would ever
tell whether "other user scripts" were relying on it.  There is no way
to for us to tell what people are doing on their computers (and nor
should there be).

> If it was to be really removed, it shouldn't be done without some
> deprecation warning and time for users to notice and change their
> code.

Why would you bother with a deprecation warning, and forcing a lot of
users to change their code ?  Why not just leave the symlink
permanently ?

Ian.

Bug#862051: Allow nodejs to provide /usr/bin/node (draft resolution)

[Ian Jackson]

Tollef Fog Heen writes ("Re: Bug#862051: Allow nodejs to provide /usr/bin/node 
(draft resolution)"):
> > Tollef Fog Heen writes ("Bug#862051: Allow nodejs to provide /usr/bin/node 
> > (draft resolution)"):
> > > 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
> > > 
> > > This means Debian's normal policies and practices take over and the
> > > nodejs package is free to provide /usr/bin/node.  The migration should
> > > be managed according to Debian's usual backwards-compatibility
> > > arrangements.
> > 
> > Can you please say that /usr/bin/nodejs should remain indefinitely.
> > Otherwise someone may get it into their head to get rid of it.
> 
> I think that's covered under the last sentence and don't think we should
> add any extra restrictions on nodejs.

I think a natural reading of "Debian's usual backwards-compatibility
arrangements" applied to /usr/bin/nodejs would arguably involve
keeping it only for a realease or two.  But in fact, there is no
reason to ever delete it (except for punishment purposes, as I discuss
above).

But I guess I will take that message as a promise of your support if
my fears come to pass.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#862051: Allow nodejs to provide /usr/bin/node (draft resolution)

[Ian Jackson]

Tollef Fog Heen writes ("Bug#862051: Allow nodejs to provide /usr/bin/node 
(draft resolution)"):
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
> 
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node.  The migration should
> be managed according to Debian's usual backwards-compatibility
> arrangements.

Can you please say that /usr/bin/nodejs should remain indefinitely.
Otherwise someone may get it into their head to get rid of it.

(For Debian to remove it would be to punish people who follow the
previous TC decision and had due regard for the sanity of the global
command namespace.)

Ian.

Bug#862051: Refer #862051 to ctte

[Ian Jackson]

How about this:

  1. The CTTE decision in from 2012-07-12 in bug #614907 is repealed.
  2. The nodejs package shall be free to provide /usr/bin/node.
 Eventually, packages which use node.js will use /usr/bin/node,
 and the nodejs-legacy package will become obsolete, and be
 removed.
  3. All of this should be managed according to Debian's usual
 backwards-compatibility arrangements, and without needlessly
 breaking anything.
  4. /usr/bin/nodejs should continue to exist indefinitely.

Ian.

Re: Bug#862051: Refer #862051 to ctte

[Ian Jackson]

Anthony DeRobertis writes ("Re: Bug#862051: Refer #862051 to ctte"):
> On 07/14/2017 12:57 PM, Tollef Fog Heen wrote:
> > Fair point.
> >
> >3. Once a new nodejs package providing /usr/bin/node is in the
> >   archive, other packages in the archive are free to depend on the
> >   nodejs package and use /usr/bin/node .
> 
> That should probably be a versioned Depends, at least until a stable 
> release includes /usr/bin/node in nodejs. Otherwise upgrades may break.
> 
> OTOH, is this paragraph (or 2, for that matter) really needed? They're 
> just restating (somewhat imperfectly) Policy and/or normal practice in 
> Debian, which presumably come back into effect anyway once the 
> 2012-07-12 decision is repealed.

It would be better to simply say "following Debian's existing backward
compatibility practices" or something, than trying to restate it all.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

[Ian Jackson]

Adam D. Barratt writes ("Bug#857257: Re: Supporting configuration file changes 
between versions in unstable/testing"):
> On 2017-03-09 9:41, Pirate Praveen wrote:
> > I request CTTE to declare this bug as not RC.
> 
> That's not something that the Technical Committee has a remit to do.
> 
> The determination as to whether a bug is release-critical is delegated 
> to the Release Team. So far as I can tell you haven't approached them to 
> discuss this, so you can't be asking the TC to override a decision by a 
> delegate either, as there hasn't explicitly been one.

To be fair to Pirate, Andreas Beckmann suggested #856606 that if
Pirate disagreed with Andreas, Pirate should go to the TC.

I don't think any of the Release Team have been asked yet.

Sadly, there isn't a "reportbug release.debian.org" category for
"please determine RCness of #".  So I am just emailing
debian-release@l.d.o on this mail.


To debian-release:

The question is whether #856606 is RC.

I think you will find the best summary of the arguments in this
message:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856606#37

Ian.

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

[Ian Jackson]

Sam Hartman writes ("Bug#846002: blends-tasks must be priority:standard and not 
make a mess out of tasksel menu"):
> My reading of that is that the consensus of the TC is that the D-I team
> should make this decision.

I can see why Ole is frustrated.  I don't think this is a proper
conclusion for the TC to reach.

The request to the TC was for a review of a technical decision.  That
means that the TC ought to review the technical decision, not simply
say that the people who made the decision were the ones who should
make it.

A proper conclusion for the TC to reach might be something like:

  We agree with the D-I team's decision for stretch.

  We want to see this improved in buster.  If no solution
  (satisfactory to all sides) is found within 6 months of buster being
  open, we should be asked to revisit the decision.

Or

  We feel that Phil's proposed new menu question is a good way of
  solving this problem, and that the problem is important enough and
  the risk low enough that we want to see this in stretch.

  Accordingly we ask that the D-I team make arrangements to include
  a new question along the lines which have been suggested.

It seems that the TC prefer the first of these but are unwilling to
come out and say so.

> I'm not sure the TC as a whole has a consistent rationale.

Firstly: it's one thing not to have a consistent rationale.  It's
quite another to duck making decision because you can't agree on a
rationale.

Secondly: if there are competing rationales, let each TC member with a
rationale put their own forward.  The matter can then be resolved by a
vote.

I wish the TC were more willing to have divided votes.  It is not
necessary for the TC to reach internal consensus.  It would be much
better to have a 3:2 TC vote on something like this, than weeks and
months of delay followed by a lack of any concrete decision.

> I believe there are important issues to balance in terms of number of
> prompts, style of user interaction, and risk we're willing to take at
> various points in the release process.  I believe the D-I team has
> traditionally balanced those issues quite well, so I'd delegate this
> decision to them.

I think it is quite wrong for the TC or its members to delegate their
decisonmaking back to the maintainer(s) that the petitioner is in
disagreement with.

If those maintainers cannot explain themselves sufficiently to
convince the TC, then the decision should go against them.

Conversely, if those maintainers _do_ explain themselves sufficiently
to convince the TC (as seems to have happened here), then the TC
should say "we have been convinced of XYZ by the maintainers".

Ian.

Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

[Ian Jackson]

Sam Hartman writes ("Bug#850887: [TIMELY for TC members] Interim Ballot 
Proposal: #850887 binutils mips"):
> [stuff]

Thanks for pushing this issue, for your IMO correct approach to the
process, and for your clear and straightforward communication.

> 
> In #850887, the Debian Technical Committee was asked to choose a
> solution for #840227, a bug that prevents a significant number of
> packages from building on the mips architecture.  Given the upcoming
> Stretch freeze, this issue is urgent.
> 
> As an interim measure, using its powers under section 6.1.4 of the
> Debian Constitution, the Technical Committee overrules Matthias
> Klose's decision to revert the NMU of binutils fixing #840227.  The
> committee requests Lisandro Damián Nicanor Pérez Meyer to make a new
> NMU fixing #840227.

You should explicitly state whether you want this NMU to be DELAYED.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 1 more messages]

[Ian Jackson]

Josh Triplett writes ("Bug#850967: Clarify /usr/bin/foo should not be hardcoded 
even in upstream parts"):
> I find it surprising that this has ended up in front of the Technical
> Committee before it has, for instance, ended up on debian-policy or
> debian-devel for discussion.  While Policy would not make a change that
> would instantly declare a large number of packages de-jure buggy, those
> two lists nonetheless seem like the right place to have this discussion
> outside the context of any particular package.

Maybe I should have tried -devel.  -policy is no good because the
policy process cannot make controversial changes.  (As an aside, the
process also so little rewards the policy editors with autonomy that
it's not an attractive task, so the policy maintenance is slow due to
lack of effort.)

Stuart Prescott writes ("Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> Nikolaus highlights two failure modes that we see sufficiently often that 
> #debian even has boilerplate help text to deal with them:
>
> [python things]

Thanks for the data points.  This is troubling.  I know that Python
has historically had confusing approaches to its include path
management.

> By giving the local admin the ability to override tools using their
> PATH we give them great power and flexibility at the expense of
> robustness. We give the user a loaded gun, help them aim it at their
> foot and then stand back.

Perhaps this is indeed true for Python.


Anyway, I don't think this request of mine is going anywhere.  I'm
definitely still unconvinced about gpg-agent (#850657) and I'm
disapointed, but there is no point wasting any more of anyone's time
about this.

I suggest that the TC close #850967 NFA, and that the Debian gnupg
maintainers tag #850657 wontfix (and perhaps close it).

I won't promise to stop asking Debian maintainers of other packages to
make this change, when it trips me up.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 2 more messages]

[Ian Jackson]

I see that I am Wrong On The Internet and my efforts not to distract
the TC have been futile.  Sorry.  Now I am falling subject to the same
problem but I really cannot let all of this go unchallenged.

Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> On Wed 2017-01-11 12:13:44 -0500, Ian Jackson 
> <ijack...@chiark.greenend.org.uk> wrote:
> > I think this argument is utterly wrong in principle.  It is contrary
> > to the whole point of Debian.
> 
> We clearly disagree here, though i think Ian might be overstating his
> case for rhetorical effect.

Certainly not.  Our primary priority should be to make it easy for
users to make their own choices.  The argument being made here is that
it should be made harder for users to make certain modifications
because that produces confusing bug reports.  Outrageous!

If there were a significant risk of *users* being troubled by their
own old locally-built stuff in /usr/local, then that would be a good
argument.  (For example, this might be true in the case of a program
which has an unstable command line API which means that it is not
compatible with other versions of its callers.  But of course such a
thing probably wouldn't be on PATH at all.)


Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> I'll note that the practice of hard-coding paths is fairly common.

It is a common bug.  There are many common bugs.  That does not stop
them being bugs.

Of course upstream projects often do this because they need their
software to be installable in nonstandard locations and still find all
of their pieces.  So such a thing is not necessarily a bug in an
upstream package.  But this is not necessary in Debian packages, and
then the restriction serves no purpose.

> One common cause for this is programs that don't want to rely on PATH
> for calling exec.  Systemd is a particularly interesting example.
> ExecStart and related arguments in systemd units are required to include
> full paths.

Do you really think that bringing utterly broken systemd behaviours
into this conversation would help ?  It's certainly raised my blood
pressure.


Didier 'OdyX' Raboud writes ("Re: Bug#850967: Clarify /usr/bin/foo should not 
be hardcoded even in upstream parts"):
> Dear Ian,
> >  * Say that this applies even when the program needs to find pieces of
> >the same (or closely related) package.
> 
> Reading this literally (which is what the Debian Policy is for),
> this would ask the Debian project to patch literally all its
> archive. For instance, that covers literally all shebang lines.

That shebang lines don't work this way is unfortunate but I'm not
suggesting it should be changed.

> I went and read #850657, and found myself agreeing with all points
> made by Daniel: if you want a gnupg that runs your custom gpg-agent
> for debugging purposes, building a patched src:gnupg is there for
> you; we provide source for a reason.

Have you ever talked some non-Debian person through the process of
building their own patched version of some program on their
Debian-derived system ?  This is not entirely straightforward, even if
they are an experienced software developer.  You will find yourself
making apologies (and also missing steps out, and making false
assumptions about the reasonableness of Debian source packages).

If you think this is so easy, I would welcome patches to this tutorial
manpage:
  
https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user=0=0=Debian+unstable+sid=html=en

Even though we can probably improve this (and we certainly should,
where we can), it's never going to be as easy as putting a wrapper
script on the path that invokes the subprogram with strace, or
whatever.

And it's complete overkill if what you wanted was to strace something
to see where it was going wrong (often you can't strace the parent for
some reason), or apply a ulimit, or pass a command line option that
the developers have for some reason decided shouldn't have a
corresponding config file option, or replace the program with a copy
of "true" or "false" to test the error handling, or whatever.

> All-in-all, I think that the decisions you would like the TC to
> issue would be against the project's consensus, and (which is more
> important for TC decisions) wouldn't be technically sound.

In many cases there is no way of ascertaining project consensus other
than a GR.  What you see in the mailing lists is the views of those
who are loud, stubborn and thick-skinned.  (FAOD a GR for this issue
would be ridiculous.)

But in this case, we can see fairly easily.  We have a large body of
software written specifically by Debian contributors to be part of
Debian.  We could see what that software does.

My experience is that in softw

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Ian Jackson]

Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> [some stuff]

Please concentrate on the MIPS binutils bug.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> Ian, in the future please x-debbugs-cc me when you take our discussions
> to the tech-ctte :)

Sorry, I should have thought of that.

Thanks for your reply.  There are some things I might want to respond
in it but I don't want to distract the TC any further from #850887.
This issue isn't urgent, even though it is quite wide-ranging.
So, I won't press this now and instead I'll wait for a TC member to
pick it up.

Regards,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Ian Jackson]

Package: tech-ctte
Control: block 850657 by -1

Policy 6.1 says
| Programs called from maintainer scripts should not normally have a
| path prepended to them.

Ie, programs that are on PATH should be found via the PATH rather than
by hardcoding /usr/bin/foo or whatever.  In general, I think we
normally, at least in software written specifically for Debian, apply
this not just to maintainer scripts but to all program execution.

However, this is not always uncontroversial with some upstreams.  This
causes a particular problem when the upstream is also heavily involved
with the Debian maintenance.


I would like the TC to:

 * Declare that Debian policy should be clarified to say that programs
   in Debian (not just maintainer scripts) should not hardcode the
   location of the binaries in /{usr/,}{bin,sbin} they execute.

 * Say that this applies even when the program needs to find pieces of
   the same (or closely related) package.

 * Say that where technically feasible, this should usually be done
   for other kinds of search paths (LD_LIBRARY_PATH, PYTHONPATH,
   PERLLIB, etc.), too.

 * Provide an informal opinion that this policy ought to apply to
   gpg-agent as requested in #850657.


I don't know if it is necessary to rehearse the arguments about this
issue for the TC, but I will try to do so briefly.


The argument in favour of finding programs (and libraries) on the
PATH:

This allows substitution and wrapping of programs (by adding a
directory to PATH containing a stunt version of the program, or by
adding a wrapper or replacement to /usr/local or ~/bin).  This can be
useful in a wide variety of situations.  It is a well-known debugging
technique.  It can be used by individual users, to modify the
behaviour of their system.  It can be profitably used by things like
test suites and audit tools.  It can be used by depending software to
work around bugs.

Most of these uses can be satisfied in some other way, but the other
ways have downsides.  For example, moving the actual binary aside is a
possibility (and supported by things like dpkg-divert); but it affects
the whole system, so requires administrator privilege; it is
unsuitable on a multiuser machine or for test suites; and if done
ad-hoc it is too easy to forget to put back and leave the system in a
weird state.

Explicit configuration or command line options to change which
subcommands are used are a good thing, but: they are usually fiddly
and certainly not always provided; this can often involve complicated
nesting (eg run `foo' with --bar-program pointing to a stunt `bar'
script which passes --wombat-program pointing to your stunt `wombat'
script); and lack of such an option at any level stymies this
approach.


I will quote the counterarguments from Daniel Kahn Gillmor, as they
are fairly typical of the responses from upstreams:

  In this bug report, you're asking a tightly-coupled suite of tools to
  invoke each other via the PATH, which offers another avenue of potential
  breakage; upstream regularly receives reports from people who *don't
  even know what version of gpg their system is running* because of
  multiple copies of the thing having been installed in various places on
  their system (either deliberately or incidentally, but in either case
  forgotten about by the local sysadmin).

  It's entirely reasonable for a tightly-coupled suite to want to invoke
  its own tools in this situation.  we have enough to debug in GnuPG as it
  is :/

Perhaps this is indeed a problem for some upstreams.  But I have two
responses to this which I think are each sufficient to rebut it:

Firstly, we are talking about this in the context of Debian.  In
Debian we have `reportbug', which the majority of people use to file
bug reports.

It would be simple for reportbug to report on these kind of anomalous
situations and mention them in the bug report.  It could, for example,
check to see if there is overlap between the package being reported
(and its dependencies), and /usr/local.  I don't know if it does
already, but if it doesn't and someone feels the information is
valuable, then I'm sure the patches to reportbug would be welcome.

Secondly, I think the possibility that users may do things upstream
consider undesirable, and even cause lossage, is precisely software
freedom.

The thrust of the upstream argument here is that users must be
prevented from messing with their software in certain ways because it
makes those users' bug reports too hard to deal with.

I think this argument is utterly wrong in principle.  It is contrary
to the whole point of Debian.


Thanks for your attention.

Ian.

PS: Please give the MIPS binutils bug priority.


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: December 2016 TC meeting is at 'Thu Dec 22 18:00:00 UTC 2016'

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Re: December 2016 TC meeting is at 'Thu Dec 22 
18:00:00 UTC 2016'"):
> But in short, in case I can't attend at all:
> - regarding #846002 (blends-tasks), I see the discussion still going
> on without a clear-enough gordian knot for the TC to cut. Technical
> solutions are being discussed, and it doesn't seem to me that more
> TC involvment (in addition to Phil's) would be of much help now. The
> TC should definitely keep an eye on that subject though.

There are two separate potential disputes there now:

 * If the choice is between what we have, and dropping the blends from
   the installer menu, which is better ?  There has been little
   movement from either side on this key point and it remains
   outstanding, despite sterling efforts by some people to find a
   compromise.

   I think the TC is going to have to make a ruling on this, one way
   or another.

 * Is it too late to implement anything better ?  That seems to be the
   suggestion from some quarters, although apparently there is some
   difficulty with getting even review effort, let alone effort to
   help with implementation.

I would suggest that the TC should not delay.  Delay makes the problem
worse.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ian Jackson]

Wouter Verhelst writes ("Bug#846002: blends-tasks must not be 
priority:important (was Re: Bug#846002: Lowering severity)"):
> On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
> > How about one or both of:
> > 
> >   bare-bones -- nothing selected
> >   minimal-server -- ssh and nothing else
> > 
> > Is there any objective way of working out what other combinations would
> > be popular, rather than just guessing?
> 
> Note that the whole point of tasksel was, originally, to show just that.
> Things have simply gotten out of hand.
> 
> If you're going to update tasksel, it might be good to keep that in
> mind...

Quite.  I thought Phil's original suggestion

  -->  standard desktop (will install $DESKTOP)  <--
   standard server  (includes ssh)
   other use cases

was good but perhaps even too long.  Anyone who wants anything ommore
complicated can cope with tasksel.  Even someone who wants a server
can very likely cope with tasksel.

Bear in mind that every option on this list needs to be read even by
the most inexperienced user.  There should be nothing on it that does
not need to be there.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Ian Jackson]

Philip Hands writes ("Bug#846002: blends-tasks must not be priority:important 
(was Re: Bug#846002: Lowering severity)"):
> Perhaps we need an aditional option at the boot prompt for a vanilla
> install, that sets priority=critical or some such, so that one gets the
> equivalent of hitting return thoughout the installer, and only get
> prompted for the user & passwords, the point at which you're going to
> trash your disk, and not much else.

I don't think the current installer asks too many questions.  The
timezone and locale are unavoidable.  The disk partitioning is
unavoidable unless you want to make an express-disk-wiper image :-).

Perhaps the right answer is to prefix the tasksel question with a
pre-question, asking the user to choose between
   Default desktop install
   Choose selection(s) of packages ("tasks")

Then the tasksel menu becomes less critical.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Global Ballot Thoughts

[Ian Jackson]

Sam Hartman writes ("Re: Bug#841294: Global Ballot Thoughts"):
> I am not prepared to override  those seeking global6 either.

I don't know quite how to put this.  I'm afraid that what I say is
going to sound quite aggressive and hurtful.  But I think it is a very
important point that needs to be made:

By actively resisting the idea that the TC should swiftly make a
concrete and definitive decisioin, you are very directly reinforcing
the blockage which is preventing the prospective global (6)
maintainers from improving Debian.

So you _are_ overriding those seeking global (6).  (TC members who are
saying nothing are contributing to the blockage too: with power comes
a responsibility to use it to right injustice, where one can.)


You've no doubt heard the famous quote by Paulo Freire:

  Washing one's hands of the conflict between the powerful and the
  powerless means to side with the powerful, not to be neutral.

But you are doing more than washing your hands.  You are yourself in a
position of power, and you are actively using that position to
reinforce Ron's.

I know that you do not _set out_ reinforce Ron's position of power
over his victims.  That is not your goal.  You are trying to come to
an amicable settlement.  You are trying to get everyone to be nice.

But when people are being oppressed, it is quite wrong to make the
feelings of the perpetrator a primary consideration.  First help the
victims, by relieving them from the grasp of their oppressor.

This is all very dramatic language.  Of course I know this is "only
Debian" and of course no-one is dying here.  But the principles are
the same.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Maintainership

[Ian Jackson]

On debian-project I posted a suggestion in respose to Zach in the
thread about maintaintainership.  See below.

Do the TC think a resolution such as that below would pass ?

Supposing such a resolution were passed, would it make a practical
difference to how you approach petitioners and maintainers ?

Ian.


From: Ian Jackson <ijack...@chiark.greenend.org.uk>
To: Stefano Zacchiroli <z...@debian.org>
Cc: debian-proj...@lists.debian.org
Subject: Re: Replace the TC power to depose maintainers
Message-ID: <22593.38530.975380.276...@chiark.greenend.org.uk>
Date: Fri, 2 Dec 2016 15:42:58 +

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
> 
> This is the obviously right solution.

Hey, I have an idea that maybe you will support, which takes us much
more in that direction and may reinvigorate our existing processes:

 DRAFT GENERAL RESOLUTION STARTS

 OPTION A

 1. Our priority is our users and free software.

 2. Debian maintainership is a position of power and responsibility.
It is an earned position, which arises from work and leadership.
Maintainership should continue so long as the good leadership
continues.

 3. We give advice to the Technical Committee:

 4. The Technical Committee should consider all opinions and options
based on their merits, not based on the authority of the speaker.

The opinions of the current maintainer are as relevant as the
opinions of other contributors, users, and other stakeholders.
But they are no more relevant.

 5. Specifically, when making any decision with respect to a package,
the TC should not pay attention to the formal maintainership
status of the package.

On the other hand, it is relevant to give more weight to a
contributor who has a strong record of contributions to the
package; shows depth and accuracy of knowledge about it; or has
shown consistently good communication, stewardship and leadership.

 6. Our advice specifically includes decisions on who the maintainer
should be, under Constitution 6.1(2), or whether to overrule the
maintainer, under 6.1(4).

 7. The constitutional 3:1 majority is a sufficient safeguard against
undue interference with the work of individual maintainers.

 OPTION B

 (1-6 as above)

 7. We amend the Constitution section 6.1(4) to remove the words
"requires a 3:1 majority" and "this requires a 3:1 majority".

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Global Ballot Thoughts

[Ian Jackson]

Sam Hartman writes ("Bug#841294: Global Ballot Thoughts"):
> Like you I want to see global6 for stretch.
> I'm not sure I want to see it bad enough to override someone.
> I'd rank doing so above FD though but below a pure advice option.

Why are you prepared to override[0]

  Andrew Bailey, Era Eriksson, Markus Grunwald, Thomas Viehweger,
  Hongzheng Wang, Vincent Bernat, Pranith Kumar, Punit Agrawal, Volker
  Mische, Johannes Stezenbach, Wei Liu, Alberto Luaces, Pierre-Elliott
  Becue, Wookey

but not prepared to override

  Ron Lee

?

Have you been reading debian-project ?  From my point of view[1]
perhaps I should give up on trying to persuade TC members.

After all if the TC does not transfer maintainership in such an
extreme situation as this, my job of perusading DDs to vote to give
responsibility for these decisions to someone else is very easy.

Ian.

[0] I have listed all the people who explicitly requested a new
version (assuming, I think, that they are Debian users who want to use
global 6), and the people who have done work to prepare new versions,
in chronological order.  I have excluded Shigio Yamaguchi because I
think their primary status is upstream.

[1] My point of view of trying to fix Debian's totally nonfunctional
processes for dealing with unwarranted blocking by maintainers, which
is a drum I have been banging for years and years now.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package a 
new upstream version"):
> In offline discussions with Wookey, we came to the realisation that
> reading the various bug reports (including this one) it is not very
> clear how global (upstream) is structured, the functionality it
> provides and bits that are holding back the debian update.

Thank you for your clear and excellent explanation.


On to some questions it raises for me:

> Optionally, "htags" can generate a dynamic index (which reduces disk
> space usage) but requires an http server setup to be able to serve the
> pages. In this scenario, you will also need to be able to execute CGI
> scripts as the symbol lookup is done when serving the http request (as
> opposed to pre-processed when using static pages).
> 
> And this last bit (integration with system web server) is the
> functionality that had security concerns raised by Ron [etc.]

So, to be clear, it is this functionality which is dropped in the
package that you and Wookey uploaded to experimental/delayed ?

But AIUI this functionality remains:

> In addition to the above mechanisms, upstream also provides "htags"
> which can be used to generate an HTML version of the index. "htags"
> uses the index created by "gtags" and the source tree as input and
> generates html files which allow you to navigate the source code in
> the browser. By default, htags generates static pages which means you
> can browse the code in a local browser without requiring a web server.



So the impact for a user of the existing functionality the regression
is not that their entire workflow is disrupted.

Rather (unless the software is improved) they have these choices:

 - Put up with pregenerated html indices.  Is the only downside
   of this that they use additional disk space, and presumably
   cpu time to generate them ?

 - Run the htags server on a high-numbered port somehow.  (Is there
   some kind of simple scriptery provided, to do this?)

 - If the machine is not really multi-user, tear down the security
   boundary defending the webserver from their user account, and give
   their user account access to the webserver cgi directory (or plumb
   it in with symlinks).  (Are there any instructions or scripts for
   this?)  (Also this assumes that the source code is not super
   secret.)

I don't know much about this, but several of these choices seem likely
to be plausible choices for many if not most current users of htags.


FAOD none of this changes my view about the proper resolution of this
TC petition.  But answers might help clarify the discussion.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Wookey writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> OK, as Punit and I have prepared a current 6.5.5 which would be a
> candidate for a 'modern' release, and I think it's useful to have such
> a version available for people to test and file bugs against, I will
> do a 5-day delayed NMU to experimental. Putting it in experimental
> does not imply automatic transtion to stretch, nor block uploads via
> unstable, so seems a reasonable thing to do.
> 
> This version is not perfect, but it is current with updated
> packaging. I'll include details of the known issues in one of the
> 'please can we have a new version' bugs. I think it's more useful to
> have the current state of play avalable than for me to keep messing
> with it privately.

Hooray, thank you.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#841294: Overrule maintainer of "global" to 
package a new upstream version"):
> E) the 'global' package is handed to other maintainer(s)
> 
> This would imply:
> 
>  - overruling the 'global' maintainer's decision (§6.1.4, implies
>3:1 majority in the TC vote);

No, handing the `global' package to other maintainer(s) would be a
decision under 6.1(2).  Quoting that section:

In cases where Developers need to implement compatible ...  stances
(for example, if they [Developers] disagree about [various things],
 ** or about who should be the maintainer for a package) **
the technical committee may decide the matter.

6.1(2) does not have a 3:1 requirement.

Ian.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> It's ok, we get it.  You've got an axe to grind, and boy are the sparks
> flying off it thick and hot!

My axe is the same one I often have in Technical Committee
discussions.  It is the axe of challenging the unaccountable power
exercised by despotic Debian package maintainers, within the fiefdoms
of their countless petty autocracies.

My axe is the axe that would chop aside the barriers erected by those
who dislike other people's software, and who use their position to
obstruct and to destroy.  My axe is the axe that would clear the path
for collaboration.

My axe is the axe of freedom for Debian's users and contributors.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> I made this timeline to show how Ron thinks it is appropriate to deal
> with this package.
> 
> Messages to #574947 and #816924, combined
> Each # is one email
> Each P is one email containing a patch or link to updated package
> Each U is one upload

I should say that this timeline drastically _under_represents the
change in Ron's engagement with the technical problems in this
package, following TC referral.

Many of his copious mails in the TC thread are each in themselves
longer than _all his pre-TC mails on this topic combined_ !

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> These are the only two references I could find in the whole of this
> bug (#841294) from you to your own earlier messages.  In fact #574947
> contains only FIVE responses from you over a period of SIX YEARS.
> #816924, filed in March 2016, contains none.

I made this timeline to show how Ron thinks it is appropriate to deal
with this package.

Messages to #574947 and #816924, combined
Each # is one email
Each P is one email containing a patch or link to updated package
Each U is one upload

   Users and   Maintainer   Notes
contributorsactivity

  #  Mar 2010   Request for 5.9.3
 Apr 2010
 May 2010
 Jun 2010
 Jul 2010
 Aug 2010
  #  Sep 2010
 Oct 2010 U Last-ever maintainer upload
 Nov 2010   [ last new-upstream-version
  P  Dec 2010  upload was in 2008. ]
 Jan 2010
 Feb 2010
  #  Mar 2011
 Apr 2011
 May 2011
  #  Jun 2011   User reports success
 Jul 2011   with Dec patch for 5.9.x
 Aug 2011
 Sep 2011
 Oct 2011
 Nov 2011
 Dec 2011
 Jan 2012
 Feb 2012
 Mar 2012
 Apr 2012
 May 2012
 Jun 2012
  #  Jul 2012
 Aug 2012
 Sep 2012
 Oct 2012
 Nov 2012
 Dec 2013
 Jan 2013
 P#  Feb 2013
  #  Mar 2013
 ##  Apr 2013 #
 ##  May 2013 #
 Jun 2013
 Jul 2013
 Aug 2013
 Sep 2013
 Oct 2013
  #  Nov 2013
 Dec 2013
  #  Jan 2014
 Feb 2014
  #  Mar 2014
 #P  Apr 2014 ##
 May 2014
     Jun 2014 #
 Jul 2014
 Aug 2014
 Sep 2014
 Oct 2014
 Nov 2014
 Dec 2014
 Jan 2015
 Feb 2015
  #  Mar 2015
 Apr 2015
 May 2015
  #  Jun 2015
 Jul 2015
 Aug 2015
 Sep 2015
 Oct 2015
 Nov 2015
 Dec 2015
 Jan 2016
 Feb 2016
###  Mar 2016
  #  Apr 2016
 May 2016
 Jun 2016
 Jul 2016
 Aug 2016
 Sep 2016
###  Oct 2016
   ------- tc referral --


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> On Tue, Nov 08, 2016 at 02:52:29PM +, Ian Jackson wrote:
> > Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
> > upstream version"):
> > > I think you missed the bit about "comprehending the problem and building
> > > consensus on solutions"
> > 
> > Somehow I missed the part where you helped contributors to "comprehend
> > the problem" and enabled them to "build consensus on solutions"
> > between March 2010 and mid-October 2016.
> 
> Yes, you did.  And you managed to miss it despite the fact I gave links
> to the public discussions in my first reply here and that other people
> in those have referred to the private discussions we had too.

I assume you are talking about:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166

These are the only two references I could find in the whole of this
bug (#841294) from you to your own earlier messages.  In fact #574947
contains only FIVE responses from you over a period of SIX YEARS.
#816924, filed in March 2016, contains none.

It is true that 574947#131, in April 2014, contains an explanation of
an underlying technical difficulty.  But it also contains a strong
NAK, and this wording:

   I am very interested in seeing this all fixed, but someone is going to
   have to find a middle ground that both meets the minimum sensible
   expectations for distro Best Practice for this, and that Shigio is
   willing to accept.  Several of us have tried several times, but maybe
   you will have more luck with that.

It is not appropriate for the Debian maintainer to firmly NAK at the
same time as asking contributors to set direction.  574947#166 is,
like most of your messages, a very short mail saying "please fix it"
without any proposed technical approach.

I do not deny that there is an underlying technical difficulty.  But
in the absence of someone doing some substantial engineering to make
the questionable upstream feature packageable, there is a simple
choice:

Either we stay with the current, ancient version; or we disable the
troublesome feature (or ship it in a broken state, where it is
necessary to be root to use it).

The tradeoff you have chosen is to privilege hypothetical users of a
niche feature, in favour of a clamour of users wanting the benefits of
the new upstream version.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> I think you missed the bit about "comprehending the problem and building
> consensus on solutions"

Somehow I missed the part where you helped contributors to "comprehend
the problem" and enabled them to "build consensus on solutions"
between March 2010 and mid-October 2016.

No, wait, that's because you didn't.  You basically just said "no".

Maintainership of this package should be transferred to maintainer(s)
who are capable of encouraging and leading a community, rather than a
maintainer who simply obstructs (and only responds with fine words
when is a threat to their authority).

The leadership aspects of maintainership are the only essential
capacities of a Debian maintainer and with respect to this package,
your record is of failure.

It is obvious that there are a variety of possible technical
approaches, most if not all of which are better than maintaining the
status quo for half a decade.  I have confidence that if the package
were wrested from your control, and the petitioners made maintainers,
the technical aspects would be resolved adequately.

The real problem here is not technical.  This is a management failure.

Ian.

Full disclosure:

 * I know Wei Liu as a work colleague and friend and encouraged him to
   participate in this bug report;

 * As Ron may remember, I previously encountered him in a previous
   situation that came before the TC, relating to codecs and mumble.
   It's some years ago now but IIRC I found myself disagreeing with
   Ron.

 * I have formed my opinion about `global' by reading the bug logs.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Tollef Fog Heen writes ("Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> [Ron:]
> > I'm appalled at the status quo.  My concern is that we don't make
> > that even worse with uninformed decisions.  In the absence of good
> > information, sometimes the best thing to do is be patient until
> > more of it arrives.
> 
> I agree with this.  On the other hand, waiting forever isn't productive
> either, which I think is where a lot of Vincent's frustration comes
> from, that it's hard to know when we've waited «long enough».

Some years ago.

> I'm leaning towards dropping htags, since that seems to have problems
> security-wise (the idea of generated CGIs don't fill me with joy, at
> least, and hopefully not many others either), and also has a lot less
> value today than it used to back in the days.

I don't think the TC should be stepping in to make these kind of
decisions about the package.  Rather, the TC should give the package
to the people who want to do the work and are currently blocked.

There is IMO no indication that the prospective new maintainers would
do a bad job or that their strategy for dealing with this CGI problem
(to wit, removing the feature) is inappropriate.  The maintainer's
comments about this are FUD.  The level of demand for this feature
would have to be very substantial for it to justify leaving this
package at such an ancient version for years and years.  Also, it is
not right to reverse the burden of proof this way: the maintainer is
suggesting that the feature could only be removed, to unblock a new
upstream version, if it could somehow be proved that people don't need
this feature.  Well, we don't know how many people use this feature
but we do know that the package right now is in bad shape.

The maintainer here has only engaged on this issue because the TC has
become involved, despite extensive efforts by several contributors to
unblock things.  IMO explanations now are too late.

Furthermore, the TC should make a decision rapidly so that a fixed
version of the package can be in stretch.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Ian Jackson]

Vincent Bernat writes ("Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> Ron Lee is the current maintainer and disagrees on some issues with
> upstream and therefore don't want to update to a more recent
> version. See bug #574947:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947

Looking at the bug logs, Ron has failed in the one non-delegatable,
non-negotiable task for the Debian maintainer of a package: namely, to
make appropriate decisions with respect to the package and then to
communicate those decisions.

Even if the decision to keep the new upstream version out of Debian is
correct, Ron has failed to provide a coherent explanation.  He has
failed to engage with those who were willing and ready to do the work.

I think the package would be best served by having a new maintainer.

(Sadly I don't think the TC is likely to agree with me.  Historically
the TC has very very slow to act against maintainers who block other
people's work and who do not communicate properly.)

Anyway, good luck.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Ian Jackson]

Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2 
(reopening)"):
> Perl's Configure or SQLite are other examples of code with similar 
> issues currently in Debian, and it would be helpful if the TC would 
> start by gathering an overview of the different cases and how they
> are similar or different.

You've mentioned sqlite3 several times in this thread, but I couldn't
find a corresponding bug report against src:sqlite3.  Did I miss one ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#839570: Browserified javascript and DFSG 2 
(reopening)"):
> Would the following ballot be a better fit ?
> ==
> C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
> FD: Further Discussion
> ==

I think this would be an extremely unsatisfactory outcome.

Once again, we have a situation of ongoing disagreement.  It runs on
and on.  The people involved are trying to properly escalate the
situation.  If the TC produces this unrationalised dismissal, the
dispute will continue to rumble on.

It must also be very frustrating for the petitioners that the
decisionmaking process is deflecting their arguments, and not engaging
properly even to state disagreement.  The point about Perl's Configure
is very well made.

Personally I actually disagree with the petitioners as to the right
action to take, but I think they are entitled to a proper resolution
of their complaint.

I think the TC has many reasonable options.

 * You could say that you think you aren't authorised, by the
   constitution, to overrule a decision on DFSG-ness, and invite the
   petitioners to consider a GR.

 * You could say whether or not you actually agree with the
   petitioners about the DFSG-freenees of the browswerified JS.  If
   your decision is that the JS is non-free then you should explicitly
   express some opinion about the situation with Perl's Configure.

 * If you agree with the petitioners and think you are
   constitutionally authorised, you could resolve to overrule.  I
   doubt anyone would gainsay the TC, other than by GR.  If you agree
   with the petitioners and don't think you are constitutionally
   authorised, you could issue advice.

 * With respect to Perl's Configure, one possible answer that has not
   been considered is to declare that you agree that there is a
   software freedom problem, but to distinguish the proper action with
   respect to Configure on the basis of several possible factors.  For
   example, one might argue that an exception should be made in the
   same way as we have collectively previously made exceptions for
   certain freedom problems; or that while the Perl situation is a
   problem, people agree that it should be fixed, and that it does not
   justify introducing new problems; or whatever.

 * If you feel that the issue isn't ripe because ftpmaster haven't
   formally made a decision, then TC members should explicitly invite
   ftpmaster to provide a decision (and there should be a deadline
   set).  I agree with the complaint that this point, as taken so far
   by members of the TC, is overly bureaucratic.

If the TC can't get consensus on any particular form of words, then
the right answer is not to try to gain consensus on dismissing the
petitioner with no explanation.

Instead, if there is not consensus on the various questions raised by
the petitioner, the TC should vote on various suitable options.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.