Re: tech-ctte: Call for votes on TC membership of Elana and Sean

[Didier 'OdyX' Raboud]

Le jeudi, 28 mai 2020, 18.27:24 h CEST Jonathan Carter a écrit :
> Proposed delegation update, I'll go ahead if any one of you provides a
> +1, otherwise, please provide corrections if necessary:
> 
> The Technical Committee now consists of:
> 
>  * Didier Raboud  (chairman)
>  * Philip Hands 
>  * Tollef Fog Heen 
>  * Margarita Manterola 
>  * David Bremner 
>  * Niko Tyni 
>  * Gunnar Wolf 
>  * Simon McVittie 
>  * Elana Hashman 
>  * Sean Whitton 

As far as I'm concerned, I don't consider myself part of the Technical 
Committee anymore since January 1. 2020. My term lasted from March 8. 2015 [1] 
to December 31. of 2019, as on January 1. 2019, my term was already longer 
than 42 months (§ 6.2.7.1).

I believe the same goes for Tollef :-).

Two comments from a now-outsider though: 
* since https://www.debian.org/vote/2016/vote_003, the Constitution uses 
"chair" instead of "chairman", so I'd encourage communications to stick with 
this.
* as 
  - a) the appointment of the chair of the Technical Committee is an exclusive
   power of the TC (§6.1.7),
  - b) the TC had voluntarily agreed to follow an automatic re-appointment of 
   the chair after membership change [2],
 … I'd leave this information out of the DPL communication, as it could change 
right after the nomination

Best regards, and best of luck to the new TC members!

OdyX

[1] https://lists.debian.org/debian-devel-announce/2015/03/msg3.html
[2] https://salsa.debian.org/debian/tech-ctte/-/blob/master/procedures/
appointment_of_the_chair.md

signature.asc
Description: This is a digitally signed message part.

Bug#947847: please install systemd-sysusers using update-alternatives

[Didier 'OdyX' Raboud]

Le jeudi, 30 janvier 2020, 00.28:36 h CET Thomas Goirand a écrit :
> On 1/29/20 4:31 PM, Didier 'OdyX' Raboud wrote:
> > Software installed as /bin/systemd-* , created within the systemd project,
> > to fulfill systemd's view of the world, takes a reasonable hit on the
> > binaries' namespace: "systemd-*". Really, we should be thankful that the
> > systemd project actually started using /bin/systemd-sysusers and not just
> > /bin/sysusers. To extend on this, I think it's obvious that what the
> > "systemd-sysusers" binary name _says_ really is "this is a
> > systemd-specific utility".
> 
> They probably should be thanks to save the namespace, however, they
> shouldn't be for pushing for bundling many different things in a single
> software.

The way I look at this is: the "systemd software team" added a software they 
had a need (or a vision) for, and added it in their usual way: by adding it in 
their repository [0]. Then other projects noticed this new piece of software 
and found it interesting, hence started to use it, because it filled a need 
they had, or replaced older codepaths with this new tool. 

> Let's say I was proposing an alternative implementation of
> /usr/sbin/adduser (note that it doesn't have a software name in its
> path...), would you allow it? Hopefully yes, if it had the same
> functionalities, plus some other properties and improvement (like not
> being written in perl... :)

I'm not sure whether you brought this example on purpose, because Debian 
already ships adduser (in perl), and useradd (in C). And the perl version is 
the enhancement of the C version. But they don't carry the same name. And this 
matters; it's a question of honouring interface promises.

To answer your question directly: I don't think Debian should ever allow to 
pick between different /usr/sbin/adduser implementations, per system, no. But 
it could eventually be replaced, like we migrated to dash as /bin/sh: for 
Lenny it was possible to switch to dash as /bin/sh, for Squeeze it was 
enforced on all hosts.

> Why is it controversial here?

Because you're asking to replace a piece of software made by the systemd 
project, in the systemd repositories, shipped in the systemd package, 
knowingly used by other projects as being from systemd. What would be your 
stance as OpenRC maintainer if I asked you to add a update-alternatives for
/sbin/openrc-run for my /sbin/pyopenrc-run?

> Some of us have complained about the non-modularity of systemd. My idea
> was to prove them wrong, and that we can replace some of the components
> that aren't that tightly integrated.

Please don't use the Debian archive (and project) to prove other projects 
wrong, really.

> It feels like upstream also declares systemd-sysusers as an independent
> component, and kind of agree with me on this specific point.

What I read from the systemd project on [1] is "some of our software doesn't 
need to run on hosts with systemd as init". But what I understand from your 
position is "as some of the systemd software doesn't need to run on hosts with 
systemd as init, we can replace them with alternative software". If that's 
what you're saying, I don't think the conclusion follows from the observation.

But holding the systemd software (and hence their Debian maintainers) up to 
their promises (as is done in #946456) is a very good way to go, and a burden 
I feel is reasonable on the systemd maintainers' shoulders. Once, and if that 
is sorted out, packages would need to amend their dependencies to depend on 
systemd-sysusers; opensysusers could then Conflict/Provides systemd-sysusers 
for example; all this without the need for update-alternatives.

(I'd also argue that providing systemd-sysusers in its own binary package [or 
systemd-utils] mostly makes opensysusers purposeless.)

> I'm simply asking *Debian* (not systemd maintainers) to allow multiple
> implementations of the same functionality (ie: adding users using a data
> file format, which happens to have been invented by the systemd project).

It's already possible; maintainers can use opensysusers _now_.

> > My answer to this is that /bin/systemd-sysusers _is_ a systemd interface,
> > with a systemd-* name
> 
> The binary name is very deceptive and annoying. I wished it was packaged
> and maintained separately, because it has very little to do with an init
> system.

It seems you're reading systemd-* to say "comes with systemd the init system", 
where I read "systemd-*" to say "comes from the systemd project". As I said 
earlier, we should be _glad_ that the systemd project innovates in their space 
using their namespace. Just imagine for a second if they had used
/usr/sbin/adduser (because that's what it does, right?).

> > Please let's not use this as a point

Bug#947847: please install systemd-sysusers using update-alternatives

[Didier 'OdyX' Raboud]

Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit :
> This reasoning can make sense, if we agree that we should use something
> else than /bin/systemd-sysusers and standardize on something else like
> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is
> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of
> severity "serious" (policy violation).

We'd first have to agree that an alternative is actually _needed_. And so far, 
the only arguments I have read in favour of providing alternatives to
/bin/systemd-sysusers are:
* A) it is shipped in the systemd binary package;
* B) Having competing implementations is important;
* C) it comes from the systemd project;
* D) it has a systemd-* name;

Out of these, A is the most convincing, B is mildly so; C & D are absolutely 
irrelevant IMHO. If you're concerned by A, the request becomes:
> Please ship systemd-sysusers in a separate package for finer granularity and
> smaller installation size for non-systemd systems

If you're concerned by B, I don't think you need anything from systemd; just 
convince enough maintainers that a non-systemd implementation is important, 
and get them to change their scripts and dependencies to opensysusers. If you 
really want a single sysusers implementation per system (what's the argument 
there?), then go the /usr/bin/sysusers alternatives' route, and convince 
maintainers to move to that virtual package.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#947847: please install systemd-sysusers using update-alternatives

[Didier 'OdyX' Raboud]

Le mercredi, 29 janvier 2020, 12.41:52 h CET Thomas Goirand a écrit :
> I'm replying to you, but it goes also for Phillip Kern too, which had a
> similar answer.

Only words, I know, but let's try to answer technical points, not address 
people. "Talk to the space, not to individuals"
 
> My idea is to have a single entry point for programs to call the
> sysusers binary. If we collectively decide that it's going to be called
> /bin/foo, then by all means, let's do that. But I don't think it's
> reasonable to say it's going to be called /bin/systemd-bar, and nobody
> can take over this path. This is the wrong answer to the problem.

Software installed as /bin/systemd-* , created within the systemd project, to 
fulfill systemd's view of the world, takes a reasonable hit on the binaries' 
namespace: "systemd-*". Really, we should be thankful that the systemd project 
actually started using /bin/systemd-sysusers and not just /bin/sysusers. To 
extend on this, I think it's obvious that what the "systemd-sysusers" binary 
name _says_ really is "this is a systemd-specific utility".

I'm of the opinion that noone should be allowed to take over this
/usr/bin/systemd-sysusers path, indeed. Much like I don't think anyone should 
be allowed to provide an alternative to /usr/sbin/cupsd.

Let's see if I understand what you want correctly; you want Debian to allow 
replacing systemd-specific software with alternatives, right? I'm sorry, but 
this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
specific, and is used as such by systemd. If usages of it have appeared 
outside of the systemd repository, I think it's fair to say (because of the 
binary's name) that they were knowingly using a systemd-specific piece of 
software (and hence, have correctly added a "{Pre-,}Depends: systemd".

Note that I'm not saying that /bin/systemd-sysusers _cannot_ be used without 
systemd, or on a host booted with a different init system; I'm only saying 
that usages of systemd-sysusers must have appeared with full knowledge of 
using the systemd-sysusers binary from the systemd project.

> So I am in the opinion that "as long as it's properly hooked in the
> packaging system and boot sequence" simply doesn't work in this case, as
> systemd-sysusers could be called from virtually anywhere.

That's exactly the point: if it's so good that it has become used in many 
places, changing the binary behind the scenes is clearly premature at this 
point.

If I reformulate what it seems to me you're asking, it comes accross to me as 
"/bin/systemd-sysusers comes from systemd and it should be possible to have a 
system without systemd installed, therefore please force the systemd 
maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".

My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with 
a systemd-* name and I don't think it's reasonable to ask (or force) the 
systemd maintainers to allow "their" interface to be implemented by other 
software projects. Afterall, they came with the idea first, in their 
namespace.

That said, taking a step back and looking at the larger picture, if what you 
wish is a Debian in which one can pick their preferred sysusers' 
implementation, what about discussing the pertinence of a "parent"
/bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the 
systemd maintainers agreed to register /bin/systemd-sysusers as alternative to 
/bin/sysusers).

With this in place, you could go to maintainers who _have_ already used
/bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard" 
interface instead. We have this for 'httpd', 'default-mta', what about having 
a virtual 'sysusers' ?

All-in-all, I think the question you're asking is misguided: it's not because 
we technically _can_ allow any /bin/systemd-* to be provided by another 
implementation, that we should (actually, I think we should clearly _not_). 
But not having a /bin/systemd-sysusers' implementation that can be toggled in-
place through alternatives doesn't hinder you from proving that the competing 
implementation is better (faster, less systemd, etc); there are various ways 
to do this; dpkg-divert, another non-"systemd-*" parent alternative, or 
others. If /usr/bin/opensysusers-sysusers is really that good, have you tried 
talking to maintainers using /bin/systemd-sysusers to see if they would like 
to swap to it? It's not like having two competing implementations causes much 
harm here.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Thinking about Delegating Decisions about Policy

[Didier 'OdyX' Raboud]

Le vendredi, 6 septembre 2019, 11.32:06 h CEST Bill Allombert a écrit :
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> > > On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote:
> > > > >   * Most decisions are not just technical decisions, in many/most
> > > > >   cases
> > > > >   
> > > > > the decisions have answers that are all correct, but it just
> > > > > depends
> > > > > on the weight of specific trade-offs. How those are weighted
> > > > > depends
> > > > > heavily on each individual. This also seems rather unfair, as
> > > > > it's
> > > > > taking the natural and expected biases of a small set of people
> > > > > in
> > > > > the project and forcing them into the entire project.
> > > > 
> > > > Honestly, if the answers are all correct and we've been going around
> > > > in
> > > > circles since like forever, then having a small team decide that one
> > > > of
> > > > these correct answers is now the preferred one and we're going with it
> > > > (after listening to all the arguments) hardly seems unfair to me.
> > > 
> > > But then it become a steering committee and not a technical commitee.
> > 
> > Actually, it seems that the Technical Committee has kinda always been
> > doing
> > both of these things: arbitration, and steering.
> 
> The way the TC members are selected is not compatible with taking the role
> of a steering committee (which need to be properly elected rather than
> self-selected).

Agreed. For me, that's also why "steering" decisions have always been hard: 
hard because handed to the TC at a late stage, as last resort; hard decisions 
to take for the TC, with high stakes and emotions, etc. I feel it's also the 
main reason behind the refusal to _be_ the Roadmap Team from the TC.

> (To avoid misunderstanding, I am not in favor of Debian getting a
> steering committee. The steering should come from the DPL, who is
> elected)

It seems that this is what is intended by the current constitution. But we 
should really discuss what we need; and I'm not convinced that a steering 
group designated by an elected DPL [delegate] is that much better than a self-
selected group vetted by the elected DPL [TC]. If we do give powers to a 
steering group, we could (and I argue we probably should) make it a body of 
elected individuals with fixed terms (renewability, grace periods, term 
overlaps, etc are important details of course).

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Thinking about Delegating Decisions about Policy

[Didier 'OdyX' Raboud]

Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote:
> > >   * Most decisions are not just technical decisions, in many/most cases
> > >   
> > > the decisions have answers that are all correct, but it just depends
> > > on the weight of specific trade-offs. How those are weighted depends
> > > heavily on each individual. This also seems rather unfair, as it's
> > > taking the natural and expected biases of a small set of people in
> > > the project and forcing them into the entire project.
> > 
> > Honestly, if the answers are all correct and we've been going around in
> > circles since like forever, then having a small team decide that one of
> > these correct answers is now the preferred one and we're going with it
> > (after listening to all the arguments) hardly seems unfair to me.
> 
> But then it become a steering committee and not a technical commitee.

Actually, it seems that the Technical Committee has kinda always been doing 
both of these things: arbitration, and steering.

In arbitration, the TC has had to decide on disagreements; either by looking 
at current documentation or at current practice; ending up ruling about who 
was "right" [0]. It hasn't necessarily always been controversial, or between 
people in disagreement; the TC has also sometimes arbitrated questions put 
forward; pretty much on the tunes of "we're not sure what do here, could you 
tell us with a more distant view what is it that the project expects us to be 
doing?".

Now, in terms of steering, I can think of some past issues: #727708 "default 
init" obviously, #741573 "menu systems",#717076 "JPEG library", etc. In 
these 
cases [1], it hasn't really been about breaking ties, or just arbitrating 
between existing options. The TC really had to agree, and decide which was the 
right [2] path forward, for the good of the Project, really in a "steering" 
position. And by exercising that "steering" function for the project, the TC 
has taken decisions that have put some people off; mostly because, by the mere 
nature of the questions asked, it couldn't satisfy every party, while still 
allowing the project to "go on".


I have come to wonder if these two functions shouldn't be separated, in 
different bodies (eventually with different nomination rules, etc.). This 
"steering" question had also been phrased, slightly differently, by Mehdi, 
during his DPL term, with the idea of a "Roadmap team". [As I understand it, a 
Roadmap team would pilot the Debian ship with a vision on how to sail the 
sees, where the TC, when "steering", decides on a case-by-case in a ship 
without captain]. Uncomfortable, for political and availability reasons, the 
TC declined to take that role back then.

From there, does the project want/need, any of these two bodies?
- an arbitration group, with the power to break gordian knots, and help 
greasing the wheels of the project;
- a steering group, to establish and pilot a vision for the project, deciding 
on conflicting points when needed (several intensity variants are of course 
possible; from a case-by-case steering, to a much "stronger" plan 
enforcement).

My point, I guess, is that the TC is currently doing mostly arbitration (which 
doesn't seem very controversial, but for the affected ones), and a little 
steering (which seems bound to always be controversial). And when it _does_ 
steering, it is constrained by §6.3.5 "No detailed work".

One step forward, could be to completely remove all "steering" powers from the 
TC, to make it a purely arbitration body. But who would decide on the complex 
"steering" issues; who would have decided on the default init system?

Of course, the question of how "progressive" any steering body should be is a 
complex one. As Ian puts it:

Le lundi, 13 mai 2019, 16.28:11 h CEST Ian Jackson a écrit :
> 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.

I don't necessarily agree, but I also clearly understand [3] that when the TC 
said (in #741573), that "(it) resolves that packages providing a .desktop file 
shall not also provide a menu file for the same application", it took a 
steering stance on where it saw the project going, and gave a strong pushback 
to the volunteers working on providing a good "menu" experience.

As long as the TC is this "steering group", it will be as progressive as its 
members, and I make no mystery of my fondness of a "progressive" TC on 
steering questions [4]. But if the project wants more conservative (or just a 
different) steering, then we should be discussing about how to make this 
hypothetical "steering group" more aligned with the aspirations of the project 
at 

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

[Didier 'OdyX' Raboud]

Le lundi, 4 mars 2019, 22.28:38 h CET Margarita Manterola a écrit :
> Hi,
> 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > The winners are:
> >  Option M `middle`
> >  Option H `hard`
> > 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > Dear Marga, as Chair, could you please make use of your casting vote to
> > break this tie?
> 
> I'm using my casting vote to vote in favor of M `middle` (i.e. consider
> that the desirable situation at the time of bullseye is that both directory
> schemes are allowed, all packages can be built on either).
> 
> My rationale for taking this decision is as follows:
> 
> Right now we are not ready to migrate to building on merged-usr systems in
> Debian, there are still 29 known packages that are broken and need to be
> fixed.  My expectation is that those packages will be fixed in the not so
> distant future (i.e.  before bullseye) and that after that, the buildd
> profile in debootstrap will default to having a merged /usr, so that new
> buildd chroots will use that setup.
> 
> However, we have no control over how fast individual developers and
> derivative distributions will migrate to the new format. It's possible that
> more time will be required until everyone is ready to migrate.
> 
> Additionally, as of our current understanding of the issue, there are no
> known problems for building on a non-merged system. Supporting this
> setup does not imply additional work from the point of view of our
> maintainers (for now).
> 
> In the future, it would be a bug if a problem is discovered with building a
> package on a non-merged /usr system. I understand that this would mean
> additional work to the maintainers of such a package, but at least as of
> today this is a non-issue. Eventually, when fixing such bugs becomes a
> significant burden for our maintainers, it can be decided that the setup is
> no-longer supported, but my personal recommendation would be to wait at
> least until bullseye+1. That's why I'm voting "Middle" for bullseye.

I have announced this decision on debian-devel-announce:
https://lists.debian.org/debian-devel-announce/2019/03/msg1.html

I am therefore hereby closing this bug.

Thank you to all involved parties!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> I call for vote immediately on the following resolution.
> 
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
> classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
> such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

Dear all,

with 6 votes in, and one week gone, the outcome of this vote is still in 
doubt; here's an abstract of the vote calculation (a clearsigned verbose 
version is attached):

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2

Option W passes Majority.   2.000 (4/2) > 1

  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option M `middle`
 Option H `hard`

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


So. We have a tie, and the voting period is over. I am quite confident we can 
neither continue discussing (FD lost to M and H unanimously, and to W by 2), 
nor allow smcv to vote (the voting period is over). We're left with the 
Chair's casting vote (as per §6.3.2). So…

Dear Marga, as Chair, could you please make use of your casting vote to break 
this tie?

Cheers,
OdyX-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Starting results calculation at Mon Mar  4 15:34:31 2019

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
Option W "`weak`: both directory schemes are allowed, but packages should only 
be built on hosts with classical directory schemes (or in such chroots)"
Option M "`middle`: both directory schemes are allowed, and packages (including 
official packages) can be built on hosts with either classical or "merged 
`/usr`" directory schemes"
Option H "`hard`: both directory schemes are allowed, but packages should only 
be built on hosts with "merged `/usr`" directory schemes (or in such chroots)"
Option F "Further Discussion"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   



Looking at row 2, column 1, M
received 6 votes over W

Looking at row 1, column 2, W
received 0 votes over M.

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2


Option W passes Majority.   2.000 (4/2) > 1


  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.


The Schwartz Set contains:
 Option M "`middle`: both directory schemes are allowed, and packages 
(including official packages) can be built on hosts with either classical or 
"merged `/usr`" directory schemes"
 Option H "`hard`: both directory schemes are allowed, but packages 
should only be built on hosts with "merged `/usr`" directory schemes (or in 
such chroots)"



- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 

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

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
>classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

I vote:

H > M > W > FD

OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Dear Technical Committee members,

I call for vote immediately on the following resolution.

=== Resolution ===

The Technical Committee resolves to decline to override the debootstrap
maintainers.

Furthermore, using its §6.1.5 "Offering advice" power, the Technical
Committee considers that the desirable solution at the time of `bullseye` is:

* W: `weak`: both directory schemes are allowed, but packages should only
 be built on hosts with classical directory schemes (or in such
 chroots)

* M: `middle`: both directory schemes are allowed, and packages (including
   official packages) can be built on hosts with either classical
   or "merged `/usr`" directory schemes

* H: `hard`: both directory schemes are allowed, but packages should only
 be built on hosts with "merged `/usr`" directory schemes (or in
 such chroots)

* FD: Further Discussion

=== End Resolution ===



=== Rationale ===

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between
`/` and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what
_needs_ to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards "merged
`/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system
files in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example
i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for
simply dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks
by default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues 

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

[Didier 'OdyX' Raboud]

(Corrected the recipients, these mails should go to the bug).

Le lundi, 25 février 2019, 14.23:31 h CET Didier 'OdyX' Raboud a écrit :
> Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit :
> > > * B: The desireable solution at the time of bullseye is `hard`; both
> > > directory schemes should be allowed, and packages can be built on hosts
> > > with either classical or "merged-`/usr`" directory schemes.
> > 
> > Isn't this the 'middle' option above rather than 'hard'?
> 
> Actually, it's both.  The only difference between 'middle' and 'hard' is
> that in 'middle', _official_ packages can be built on either directory
> schemes, where in 'hard', they are only built on "merged-`/usr`" directory
> schemes.
> 
> The distinction I was trying to make in the table is the following:
> 
> * on which directory scheme Debian would build its "official" packages on
> (columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is
> "both", 'hard' is "merged-/usr".
> * whether .debs built on A can break on B (columns 7 & 8).  All of 'weak',
> 'middle' and 'hard' long-term statuses allow .debs to be built from either
> directory scheme and be installed on either without constraints

Wrong, actually (hit send too fast). The intent behind 'weak' was: "merged-/
usr" is allowed, but packages built on these directory schemes can break on 
classical directory schemes.

So that should have read:

* whether .debs built on A can break on B (columns 7 & 8). 'middle' and 'hard' 
long-term statuses allow .debs to be built from either directory scheme and be 
installed on either without constraints; 'weak' permits "merged-/usr" 
directory schemes, but packages built there can break on classical directory 
schemes.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit :
> > * B: The desireable solution at the time of bullseye is `hard`; both
> > directory schemes should be allowed, and packages can be built on hosts
> > with either classical or "merged-`/usr`" directory schemes.
> 
> Isn't this the 'middle' option above rather than 'hard'?

Actually, it's both.  The only difference between 'middle' and 'hard' is that 
in 'middle', _official_ packages can be built on either directory schemes, 
where in 'hard', they are only built on "merged-`/usr`" directory schemes.

The distinction I was trying to make in the table is the following:

* on which directory scheme Debian would build its "official" packages on 
(columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is "both", 
'hard' is "merged-/usr".
* whether .debs built on A can break on B (columns 7 & 8).  All of 'weak', 
'middle' and 'hard' long-term statuses allow .debs to be built from either 
directory scheme and be installed on either without constraints

> FWIW I think I'm OK with recommending 'middle' but 'hard' seems over
> the top. Ideally there should be no difference in building on merged
> /usr hosts vs. classical ones.

I concur with your ideal. I'll add this option on the ballot.

> As for buster and overriding the debootstrap maintainers on the default:
> 
> I think being able to do local builds that work on other Debian
> systems with minimal fuss (no chroots etc.) is a desirable property
> but not an absolute requirement.  I'd certainly love to see all the
> 'paths_vary_due_to_usrmerge' issues fixed for buster [1].

I concur.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le jeudi, 21 février 2019, 15.28:23 h CET Ian Jackson a écrit :
> 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 it is wrongheaded, but I do think that assuming that it is meant 
to work consistently under any circumstances, is.  There are _so many_ 
circumstances that make this exercise error-prone:

"I built this amd64 .deb and gave it to my friend for use on their RasbperryPi 
arm64 host"

"I built this .deb on my laptop on which I had installed a /usr/local/bin/
grep"

"I built this .deb an gave it to my friend who runs CentOS"

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

Frankly, while it's not _broken_ per se, it is and has always really been 
fragile.  True, merged-/usr arguably worsens _one_ aspect of building packages 
on one's host, but in ways that are really easy to detect, and warn for.

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

You seem to be conflating "building on one's host" with "outside of any 
chroot", and equating this with "users' collective software freedom" is really 
making your point a disservice.  Being able to improve, build and share binary 
artifacts of free software is _vital_, and the whole point of building 
software distributions in the first place, but insisting that these rights are 
only "truly" exercised when builds are done outside of chroots is 
disingenuine. .deb packages already have to be built using certain tools, so 
we do set the limit (of what minimal set of tools are mandatory) somewhere, 
and my point is that this limit might not be at the right place. I'd be 
totally OK with saying "the only supported way to build .deb packages from 
buster on is using by pdebuild; however, you _can_ use dpkg-buildpackage 
alone, but be aware (and you'll get warnings) that this can lead to building 
.deb packages with undesireable properties."  The second half of the sentence 
is already true, and has always been; we probably just failed at communicating 
it sufficiently clearly.

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

Then that's maybe what we should be fixing.  

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

Perhaps dpkg-buildpackage should be grown to build in a chroot by default? Or 
get an option to do that?

Really, I think we should stop considering that .debs built outside of 
"controlled environments" are more than temporary software transports. Our 
"standard" package building tools should build in such environments by 
default.

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

Yes; provided that said .deb is built in a sane (sanitized / controlled) 
environment.  As you're talking about non-chroot builds; it is OK, provided 
that the tools warn about that. In that area, I think the "Build-Tainted-By" 
are steps in the right direction.

>   If it is OK, how will we make sure that it does not pointlessly break ?

As it is already broken in many ways, your question is biased. But I think the 
good way is to normalize "proper builds", by making sure our standard tools 
"do the right thing" by default.

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

Given a Build-Tainted-By flag in the binary 

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

[Didier 'OdyX' Raboud]

Le mardi, 19 février 2019, 01.59:18 h CET Steve McIntyre a écrit :
> While I'm not necessarily disagreeing with the overall point(s) here,
> some of the points in this list of arguments seem dubious at
> best. Maybe you could expand?

Sure. Sorry for publishing a new ballot before answering.

> >* booting with `/` only is not systematically tested in Debian anymore;
> 
> I'm assuming you mean "/ without /usr" here?

Yes. Clarified this point by merging it with the "separate / and /usr" one 
above.

> >* the packaging infrastructure to install files outside of `/usr` is not
> >  standard and represents technical debt:
> 
> I have no idea what you're suggesting here.

Same here (clarified in the ballot). What I'm trying to say here is that 
installing (e.g.) libs to /lib instead of /usr/lib is usually a deviation from 
standard software building (either in upstream packaging, or in debian/rules), 
that needs to be maintained on the long-term.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le lundi, 18 février 2019, 08.58:53 h CET Didier 'OdyX' Raboud a écrit :
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and
> feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ball
> ot.md
> 
> I will submit it to vote on Friday 22.; the discussion period is open!

Thank you for the various comments. I have amended the ballot (which is more a
"explanation text + short ballot" incorporating the suggestions from the IRC
meeting as well as taking into accounts remarks on this bug.

I intend to answer some mails on that bug, and call for a vote on Sunday I
guess.

See: 
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md
for the markdown-rendered version; and below:

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

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between `/`
and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what _needs_
to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system files
in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example i386
requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for simply
dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues f

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

[Didier 'OdyX' Raboud]

Dear Technical Committee members,
(CC'ed to submitter, and debootstrap maintainers for information and feedack)

Here's the current state of the draft resolution; which `master` is at
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

I will submit it to vote on Friday 22.; the discussion period is open!

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

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib*}).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
  booting without initramfs onto a minimal root filesystem that carried just
  enough to mount the `/usr` filesystem later in the boot process. Given the
  evolution of physical hosts' capabilities, initramfs'es have been default in
  Debian (and elsewhere) for a long time, and most systems no longer have an
  intermediate state during boot in which they have only `/`, but not `/usr`,
  mounted.
* another use-case is to be able to share an identical `/usr` over a network
  link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
  over the network. It seems that an initramfs with everything needed to mount
  a filesystem over a network link directly actually has a smaller footprint.
* booting with `/` only is not systematically tested in Debian anymore;
* the packaging infrastructure to install files outside of `/usr` is not
  standard and represents technical debt:
* given its status as remnant "folklore", the distinction between what _needs_
  to be shipped in `/` and what can stay in `/usr` is often interpreted
  arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
  paths can confuse common understanding of paths precedence.

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing views
  of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and dpkg
  doesn't support this situation cleanly
  [#134758](https://bugs.debian.org/134758).

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The compatibility symbolic links `/lib` → `/usr/lib` and
`/lib64` → `/usr/lib64` are required by the various CPUs' platform ABIs (for
example i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and
amd64 requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove
them altogether. Similarly, removing `/bin` is not under consideration because
it would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only considered
for implementation with symlinks (there are no proposals for simply dropping
`/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
  [usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
  default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/` and
replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues have arisen.
Due to the fact that some buster/sid hosts have the "merged `/usr`" symlinks in
place, it has been observed that some binary packages carried some traces of
these differences (notably official packages built on Debian buildd hosts which
had been resetup).
Some such differences can actually render the built packages unuseable on
non-"merged `/usr`" systems.
For example, if `cat` is detected at build-time in `/usr/bin/cat` (where
coreutils ships `/bin/cat`), a binary hardcoding that path will try to use
`/usr/bin/cat` after installation, but that path doesn't exist in
non-"merged `/usr`" systems.
In order to mitigate this, debootstrap has been modified to let its "buildd"
variant be non-"merged `/usr`", the Debian buildds have been resetup and the
affected packages 

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

[Didier 'OdyX' Raboud]

Le samedi, 2 février 2019, 14.48:22 h CET Ian Jackson a écrit :
> Ping ?

Thank for the ping.

Gunnar and myself have started working on a draft, the latest version of which 
is available at

https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/
ballot.md

It's really work-in-progress, and hasn't had much scrutiny yet (hence why I'm 
not pasting it here).  I've started working on the various long-term 
desireable situations, but have realized I need to draw a table to wrap my 
head around this.

I hope to get it done during Monday (FOSDEM is not the ideal space+time to get 
the needed calm to think about these complex issues).

Cheers,
OdyX

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

[Didier 'OdyX' Raboud]

Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
> This might sound like a stupid question, what will happen when a package
> built on a usrmerged System will be installed on a non-usrmerged system?

FTR, I try to always assume that no question is stupid.  Only answers can be.

My understanding is that there's no universal answer to this; for a lot of 
packages, the answer is "nothing"; it will just work.  For some packages 
though, if they embed executable paths such as /usr/bin/grep where only
/bin/grep exists on the host system, this will break.

> Will binaries move from /usr/bin to /bin? Or will binaries move from
> /bin to /usr/bin?

A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
/bin/grep will make that binary end up in /usr/bin/grep; but the
/bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
directly or /bin/grep through the symlink.

An open question I think is whether dpkg should/could at one point in the 
future always unpack binaries to /usr/bin and never in /bin no matter what the 
package contains (+ setup a convenience symlink in /bin if /bin is a real dir 
?).

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

As a way to improve my understanding of the issue at hand, here's my current
collection of data points regarding the "merged-/usr" question:

* "merged-/usr" was enabled by default in debootstrap on June 13. 2018, some 
  5+ months ago. Any buster rootfs setup since has the /bin → /usr/bin 
  symlink (and other caracteristics of merged-/usr).


https://tracker.debian.org/news/965045/accepted-debootstrap-10102-source-all-into-unstable/

* With my TC hat on, I have formally asked the debootstrap maintainers
  (and specifically Hideki Yamane) if they would consider a toggle of the
  default.

https://bugs.debian.org/914897#73

* a discussion "usrmerge -- plan B?" was started on Nov. 20 on debian-
  devel@l.d.o

https://lists.debian.org/20181120211617.gxnuwxpx2hy44...@angband.pl
  
  It apparently follows #913229, #914204 and others.

* Currently, according to my `apt-file`, 259 binaries are shipped in /bin
  directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).

* There exists a 'usrmerge' package since 2015, which transforms a rootfs with 
  separate /{bin,sbin,lib} into a "merged-usr/" rootfs.  It has had 28 bugs 
  over its lifetime; of which 4 are currently open.  After successful 
  "installation" (when the postinst successfully ran the
  /usr/lib/convert-usrmerge program), /{bin,sbin,lib} are made symlinks and 
  the package can be removed.  The package doesn't include a way to revert the
  rootfs to its previous state.

* Building source packages in a merged-/usr rootfs can make the resulting
  binary packages broken in non-merged-/usr rootfs'es, because they'd be 
  embedding references to /usr/bin/grep (e.g.), which don't exist in non-
  merged-/usr rootfs'es.  To ensure this doesn't happen for packages built on 
  Debian infrastructure, debootstrap has been updated to disable merged-/usr 
  for the `buildd` variant (and buildd chroots have been rebuilt).

* According to investigation done thanks to reproducible builds (which now
  also varies the merged-/usr state of the build rootfs), and by others,
  packages affected by this problem have begun receiving either 
  reproducibility issue tags or Debian bugs:


https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
(currently: 59)


https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@linux.it;tag=usrmerge
(current total: 81; outstanding: 17)

I'll post my thoughts separately; please enhance or correct the above data
as needed!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Dear Hideki, dear src:debootstrap maintainers,

tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
default now, or are you OK letting the TC decide on this subject?

Longer version:

As you might be aware, #914897 (initially filed on src:debootstrap) has now 
been reassigned to the Technical Committee.  As, formally, the Maintainer of 
src:debootstrap is "debian-boot@l.d.o and the current Uploaders", I would like 
to make sure that the TC is not going to overrule unnecessarily.

Hideki, if I read the debootstrap history correctly, you enabled "merged /usr" 
by default in debootstrap 1.0.102.  Given the recent discussion in debian-
devel@ (starting at [0]) and on #914897, could you (or anyone speaking as with 
a "debootstrap maintainer" hat on) state if, either of:

* you would be willing to toggle the "merged /usr" default in debootstrap in a
  subsequent upload;
* you maintain that the "merged /usr" default (to yes) is here to stay.

Many thanks in advance for your consideration,

OdyX

[0] https://lists.debian.org/debian-devel/2018/11/msg00354.html

P.S. I'm aware that this might sound formal, or dismissive of Julien's
 statements.  I just _really_ don't want the TC to eventually overrule
 "the debootstrap maintainers" without need.

Re: Term limits

[Didier 'OdyX' Raboud]

Le jeudi, 22 novembre 2018, 00.16:50 h CET Margarita Manterola a écrit :
> I was about to send the mail to d-d-a as agreed in the meeting today and
> started looking into previous mails and appointments and I think we may
> have made a mistake thinking that Didier's and Tollef's terms expire
> this year.

I'm probably to be fingerpointed here, sorry for perpetuating the 
misinterpretation. :-/

> "On January 1st of each year the term of any Committee member who has
> served more than 42 months (3.5 years) and who is one of the two most
> senior members is set to expire on December 31st of that year."
> 
> On January of this year (2018), Didier and Tollef had served on the
> committee 34 months.  On January of next year (2019), they will have
> served 46 months.  So their terms are set to expire on December 31st of
> 2019, not 2018.

Re-reading it now, I interpret it the same way.

For Tollef and myself:
On January 1st of 2019, we will have served more than 42 months (aka 45
months), and we'll both be the most senior (=longest serving members)
members. So our terms are set to expire on December 31st of 2019.

(CC'ing the secretary, just out of extra precaution).

> Am I reading this wrong? If I'm not, then I guess we can halt our
> recruitment efforts?

Well, I guess so yes.

Cheers,
OdyX

Bug#904302: Call for vote on disallowing the use dpkg's vendor series in the archive

[Didier 'OdyX' Raboud]

Le lundi, 5 novembre 2018, 19.44:21 h CET Tollef Fog Heen a écrit :
>  RESOLUTION 
> 
> Vendor-specific patch series are a feature of dpkg that can be used to
> apply a different series of quilt patches when the source package is
> unpacked on different systems.  Since Debian source packages are usually
> treated as a pure transport format (like tar), this property can cause
> confusion and frustration for users.  Examples could be if only the
> series file for one vendor is updated, or a source package is unpacked
> on one system and then transferred to a system with a different vendor
> for debugging.
> 
> 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 differing source packages, or as part of the build
> process using current and future practices such as patches with
> conditional behaviour or patching of files during the build rather than
> at source unpacking time.
> 
> Since this feature is used by several packages today, we need a
> reasonable transition period.  They will be considered buggy from when
> this resolution is accepted, but it will not be considered severe enough
> to warrant immediate removal from Debian.  After Buster is released, the
> presence of a vendor-specific patch series will be a violation of a MUST
> directive in Debian policy.
> 
> 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 should be implemented in Debian Policy by declaring that a
>package SHOULD NOT contain a non-default series file.
> 
> 2. After Buster is released, use of the vendor-specific patch series
>feature is forbidden in the Debian archive.
> 
>This should be implemented in Debian Policy by declaring that a
>package MUST NOT contain a non-default series file.
> 
>  END OF RESOLUTION 

I vote A > F

Thanks for writing this resolution down!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Nice, thanks.

A minor nitpicks inline …

Le mardi, 23 octobre 2018, 21.28:40 h CEST Tollef Fog Heen a écrit :
> === DRAFT Resolution ===
> 
> Vendor-specific patch series are a feature of dpkg that can be used to
> apply a different series of quilt patches when the source package is
> unpacked on different systems.  Since Debian source packages are usually
> treated as a pure transport format (like tar), this property can cause
> confusion and frustration for users.  Examples could be if only the
> series file for one vendor is updated, or a source package is unpacked
> on one system and then transferred to a system with a different vendor
> for debugging.
> 
> 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
---^

use "or", as the list of examples has only two items?

> at source unpacking time.
> 
> Since this feature is used by several packages today, we need a
> reasonable transition period.  They will be considered buggy from when
> this resolution is accepted, but it will not be considered severe enough
> to warrant immediate removal from Debian.  After Buster is released, the
> presence of a vender-specific patch series will be a violation of a MUST
^

vendor

> directive in Debian policy.
> 
> 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).
> 
>(…)
> 
> 2. After Buster is released, use of the vendor-specific patch series
>feature is forbidden in the Debian archive.
> 
>(…)

I'm not sure how these are to be interpreted with regards to "the whole Debian 
archive" vs "unstable". I'd adopt a more Policy-like language like:
> 2. After Buster is released, packages must not use vendor-specific patch
>series.

… but it resonates with the second paragraphs. I can live with the existing 
phrasing.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le mercredi, 19 septembre 2018, 14.39:23 h CEST Philip Hands a écrit :
> How about this instead:
> 
>   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),
>  however existing use of this feature in packages should not be
>  considered release critical until after the release of Buster.

I don't think this has been mentionned yet:

The TC needs to be careful when outlining what is "release-critical" or not: 
AFAIK this is part of what's delegated to the Release Team [0]. So unless the 
Release Team defers that specific question to us, I'd recommend to only talk 
in terms of Policy vocabulary. That doesn't imply we cannot align our 
recommended timelines with Debian suite release dates, of course.

That said, specifically regarding Philip's text, the "should not" is only 
emitting a $6.1.5-style opinion towards the RT, which is probably fine.

Cheers,

OdyX

[0] https://lists.debian.org/debian-devel-announce/2014/05/msg8.html

signature.asc
Description: This is a digitally signed message part.

Bug#911225: tech-ctte: Advice on stale libraries in a higher-precedence path entry

[Didier 'OdyX' Raboud]

Le mercredi, 17 octobre 2018, 11.59:09 h CEST Simon McVittie a écrit :
> I would like advice from the technical committee on
> . I am not asking for anyone to be
> overruled.

Thanks for your bugreport, thanks also for specifying you're expecting the TC 
to act under §6.1.5.

> In #896019 and #894763, it appears that some upgraded systems somehow
> still contain a copy of libglib-2.0.so.0.4200.0 (corresponding to
> GLib from jessie) in /lib/MULTIARCH. We don't know how this can have
> happened. There are suggestions that it might have been caused by
> filesystem corruption or installed by third-party software.

It's _very_ suspicious that it's the exact same version, on two different 
architectures. I skimmed through piuparts logs and didn't note anything 
special.

Just because I don't know enough piuparts, I tried installing libglib2.0 
2.42.0-2 in a jessie chroot, upgraded it and `dpkg -i`ed the stretch version 
on top; the *.4200.* file disappears indeed.

> When it does, ldconfig sees that the obsolete library
> has SONAME libglib-2.0.so.0, and creates a symlink
> /lib/MULTIARCH/libglib-2.0.so.0. This takes precedence over the
> newer version of libglib-2.0.so.0 that is correctly installed in
> /usr/lib/MULTIARCH, resulting in the new libgobject-2.0.so.0 failing
> to load, because it uses symbols that are only present in the new
> libglib-2.0.so.0.
> 
> Possible resolutions include:
> 
> * Do nothing; consider the systems with a leftover
>   /lib/MULTIARCH/libglib-2.0.so.0.4200.0 to be an unsupported local
>   misconfiguration (this is the status quo)
> 
> * Move libglib-2.0.so.0 back to /lib/MULTIARCH permanently, at a
>   long-term complexity cost
> 
> * Take steps to delete /lib/MULTIARCH/libglib-2.0.so.0.* during upgrade,
>   taking care to avoid deleting files that are really on
>   /usr/lib/MULTIARCH in merged-/usr systems, at a significant complexity
>   cost, with some risk of deleting necessary files if we get it wrong
> 
> * Advocate merged /usr where this class of problem cannot happen :-)
> 
> Do technical committee members (other than me) have any thoughts on this?

Under the current analysis, it seems that these spurious files:
* originate from Debian-provided binary packages (the timestamps match)
* haven't been removed for some yet-to-be-found reason (dpkg/apt corner-case?)
* have appeared on two different architectures (kinda-ruling out the third-
party software hypothesis)

(I'd be very curious to know what sequence of events lead to such files being 
leftovers…)

With that in mind (and pretty much inline with what the TC offered as advice 
in #865929) and although it probably doesn't respect the Debian Policy letter, 
I'm of the current opinion that a variant of your third option above is the 
best course of action: in the preinst of libglib2.0, forcibly remove the 
offending files from /lib/MULTIARCH/ if these are not known from dpkg and 
match known checksums. Given the amount of bugs you mentionned (a handful), 
I'd start with a closed list of offendants, that you can always extend later. 
Given that it'd be a later version of libglib2.0 cleaning up traces of earlier 
versions of itself, I see no real concern with that approach.

If third party packages really unpack files in /lib instead of their private 
directory, then pulling the Debian carpet under their feet feels only fair 
game to me. And trying the automated removal of these in Debian unstable is a 
pretty good way to find out if such hypothetical cases exist.

I hope it helps!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Next Meeting - Wednesday, August 15th 19:00 UTC (tomorrow)

[Didier 'OdyX' Raboud]

Le mardi, 14 août 2018, 14.07:37 h EDT Margarita Manterola a écrit :
> Our monthly meeting will take place tomorrow at 19:00 UTC.

I'm unfortunately quite unlikely to be able to attend. :-/

Cheers,
OdyX

Bug#893200: TC Chair election

[Didier 'OdyX' Raboud]

Le samedi, 17 mars 2018, 10.25:28 h CET Didier 'OdyX' Raboud a écrit :
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A : Didier Raboud 
> B : Tollef Fog Heen 
> C : Phil Hands 
> D : Margarita Manterola 
> E : David Bremner 
> F : Niko Tyni 
> G : Gunnar Wolf 
> H : Simon McVittie 
> ===END===

I vote:

A = B = C = E > D = F = G > H

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Mar 2018 TC meeting is at 'Wed Mar 21 19:00:00 UTC 2018'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening tomorrow :

date -d 'Wed Mar 21 19:00:00 UTC 2018'
in #debian-ctte on irc.debian.org

I have updated the agenda on our new repository: 

https://salsa.debian.org/debian/tech-ctte/blob/master/meetings/agenda.md

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#893200: TC Chair election

[Didier 'OdyX' Raboud]

Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of Simon to the TC and according to our current 
procedures¹, I am hereby announcing my immediate vacation of the chair 
position, triggering a new election.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A : Didier Raboud 
B : Tollef Fog Heen 
C : Phil Hands 
D : Margarita Manterola 
E : David Bremner 
F : Niko Tyni 
G : Gunnar Wolf 
H : Simon McVittie 
===END===

-- 
OdyX

¹ https://salsa.debian.org/debian/tech-ctte/blob/master/procedures/
appointment_of_the_chair.md

signature.asc
Description: This is a digitally signed message part.

Bug#880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

Le dimanche, 4 mars 2018, 11.44:45 h CET Didier 'OdyX' Raboud a écrit :
> ===BEGIN
> The Technical Committee recommends that Simon McVittie  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Simon McVittie <s...@debian.org>
> F: Further Discussion
> ===END

I vote S > F

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

I call for votes on the following ballot to fill a vacant seat in the TC. The 
voting period starts immediately and lasts for up to one week, or until the 
outcome is no longer in doubt (§6.3.1).

===BEGIN
The Technical Committee recommends that Simon McVittie  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Simon McVittie 
F: Further Discussion
===END

signature.asc
Description: This is a digitally signed message part.

Bug#880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

As of now:

The current number of nominees is: 1
The current number of accepted nominations is: 1

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Feb 2018 TC meeting is at 'Wed Feb 21 19:00:00 UTC 2018'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening tonight :

date -d 'Wed Feb 21 19:00:00 UTC 2018'
in #debian-ctte on irc.debian.org

I have updated the agenda on our new repository: 

https://salsa.debian.org/debian/tech-ctte/blob/master/meetings/agenda.md

… but I will not be able to attend, sorry :-(

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#883573: TC decision on libpam-systemd alternative dependencies ordering (bug #883573)

[Didier 'OdyX' Raboud]

The Technical Committee was asked in bug #883573 to revisit the decision taken
bug #746578 (libpam-systemd alternative dependencies ordering to avoid init 
system changes accross dist-upgrades).

=== Resolution ===

In 2014, it was resolved in #746578 that the libpam-systemd binary package 
alternative dependency on systemd-shim and systemd-sysv shall be set in that 
order, in order to avoid unwanted init system changes accross upgrades. Debian 
Stretch has since been released.

The Committee therefore resolves that:

1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.

This means Debian's normal policies and practices take over and the
libpam-systemd package's dependencies are set free from specific ordering 
constraints.  The migration should be managed according to Debian's usual 
backwards-compatibility arrangements.

=== End Resolution ===

Please see https://bugs.debian.org/883573 for discussion of this bug

For the TC,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

The current number of nominees is: 1
The current number of accepted nominations is: 0.

(The request for accept/decline has just been sent now.)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: TC nomination procedure v0

[Didier 'OdyX' Raboud]

Le mardi, 28 novembre 2017, 09.40:45 h CET Didier 'OdyX' Raboud a écrit :
> I have finally finished drafting the "Nominations to the Technical Commitee"
> procedure. The point of it is to document current practice, and create a
> basis for discussion. It also outlines what is made public and when.

Thank you all for the discussion. It's still ongoing, but there is one point 
we have agreed upon, I think both outside and within the TC, which I have now 
documented on the nominations.md procedure file on Salsa [0]:

Regarding the nominees and their nomination acceptances, we agree that :

> - The TC *does* make public:
> - the number of nominees,
> - the number of accepted nominations.
 
I will publish these numbers on the new member bug immediately.

Cheers,
OdyX

[0] https://salsa.debian.org/debian/tech-ctte/blob/master/procedures/
nominations.md

signature.asc
Description: This is a digitally signed message part.

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Didier 'OdyX' Raboud]

> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion

I vote R > F

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: TC nomination procedure v0

[Didier 'OdyX' Raboud]

Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit :
> Having said that though, I'm also not convinced that the current
> completely private system is working very well.
> 
> Speaking as someone who's been a candidate for a number of past
> appointments now, the process feels too much like a black box to me.

The TC has had this feedback from multiple persons. There's clearly room for 
improvement here.

> You submit your candidacy, you answer some questions, and then several
> weeks or months later you learn that you haven't been chosen; and that's
> it. I know from private conversations with certain TC members that the
> reason for my non-selection was something along the lines of "there were
> other people which seemed like stronger candidates", but none of that
> was very clear, nor was it officially communicated.

(Not speaking specifically about you) An aspect to keep in mind is that the TC 
is not _obligated_ to fill two of its seats; according to §6.2.{2,3,4}, the TC 
can freely navigate between 6 and 8 seats. As the TC nomination is a 
coöptation (in that it picks project members it is willing to work together 
with), there's a strong "personal fit" aspect that comes into play, and that 
is both hard to explain, and to justify.

In practice, the TC nomination is kinda like a hiring process. There are hard 
facts, there are hard and soft skills, and there's personal fit. Not all of it 
is justifiable, or explainable, so I'm not in favour of asking the TC to 
publish the ins and outs of its coöptation decisions, be it publicly or even 
just towards the nominees. I'm well aware it is not comfortable for nominees 
though (and I experienced the same frustrations back then).

Cheers,
  OdyX

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Didier 'OdyX' Raboud]

I call for votes on the following resolution with regards to #883573.
The voting period lasts for one week or until the outcome is no longer
in doubt (§6.3.1).

=== Resolution ===

In 2014, it was resolved in #746578 that the libpam-systemd binary package 
alternative dependency on systemd-shim and systemd-sysv shall be set in that 
order, in order to avoid unwanted init system changes accross upgrades. Debian 
Stretch has since been released.

The Committee therefore resolves that:

1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.

This means Debian's normal policies and practices take over and the
libpam-systemd package's dependencies are set free from specific ordering 
constraints.  The migration should be managed according to Debian's usual 
backwards-compatibility arrangements.

=== End Resolution ===

R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
F: Further Discussion

--
  OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Didier 'OdyX' Raboud]

Le samedi, 3 février 2018, 22.22:19 h CET Philip Hands a écrit :
> On Sat, 03 Feb 2018, "Kingsley G. Morse Jr."  wrote:
> > Package: tech-ctte
> 
> I don't formally have the right to simply close this bug (as I am now
> doing), so if anyone else on the TC thinks there is any merit whatsoever
> in this bug report, please feel free to reopen it.

I concur with the closing of this bug, thank you for promptly doing so.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#886267: Voting for TC Chair

[Didier 'OdyX' Raboud]

Le mercredi, 3 janvier 2018, 17.38:56 h CET Didier 'OdyX' Raboud a écrit :
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A: Didier Raboud 
> B: Tollef Fog Heen 
> C: Phil Hands 
> D: Margarita Manterola 
> E: David Bremner 
> F: Niko Tyni 
> G: Gunnar Wolf 
> ===END===

I vote:

A = B = C = D = E = F = G

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#886267: Voting for TC Chair

[Didier 'OdyX' Raboud]

Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of Gunnar to the TC, Keith's term expiry and according to 
our current procedures¹, I am hereby announcing my immediate vacation of the 
chair position, triggering a new election. For clarity of the process, I am 
interested to continue serving as chair.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A: Didier Raboud 
B: Tollef Fog Heen 
C: Phil Hands 
D: Margarita Manterola 
E: David Bremner 
F: Niko Tyni 
G: Gunnar Wolf 
===END===

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#880014: #880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

Le mardi, 26 décembre 2017, 17.52:09 h CET Didier 'OdyX' Raboud a écrit :
> ===BEGIN
> The Technical Committee recommends that Gunnar Wolf <gw...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> G: Recommend to Appoint Gunnar Wolf <gw...@debian.org>
> F: Further Discussion
> ===END

With five votes in favour and a week gone, the result of this vote is now 
longer in doubt:

The TC recommends that Gunnar Wolf  be appointed by the Debian
Project Leader to the Technical Committee.

@Chris: it's in your hands now. 

As we're in a new year, following §6.2.7.1, Keith Packard 's term has 
expired (nominated on 2013-11-29; + 42 months ⇒ 2017-05-29). We're sad to see 
you go Keith! Please keep contributing to TC discussion if / when you can!

Cheers, and a happy new year!
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

Le mardi, 26 décembre 2017, 17.52:09 h CET Didier 'OdyX' Raboud a écrit :
> ===BEGIN
> The Technical Committee recommends that Gunnar Wolf <gw...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> G: Recommend to Appoint Gunnar Wolf <gw...@debian.org>
> F: Further Discussion
> ===END

I vote:
G > F

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#880014: #880014: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

I call for votes on the following ballot to fill a vacant seat in the TC. The 
voting period starts immediately and lasts for up to one week, or until the 
outcome is no longer in doubt (§6.3.1).

===BEGIN
The Technical Committee recommends that Gunnar Wolf  be
appointed by the Debian Project Leader to the Technical Committee.

G: Recommend to Appoint Gunnar Wolf 
F: Further Discussion
===END

signature.asc
Description: This is a digitally signed message part.

Dec 2017 TC meeting is at 'Wed Dec 20 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening on Wednesday:

date -d 'Wed Dec 20 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda is not short; we have 4 issues on our hands. Looking forward to a 
productive meeting!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Hi Julian,

Le mardi, 5 décembre 2017, 12.26:43 h CET Julian Andres Klode a écrit :
> In 746578, the CTTE decided that the dependency be swapped
> to systemd-shim | systemd-sysv in order to prevent systems
> from being upgraded installing systemd.
> 
> (…)
> 
> I thus opened bug 883569 against systemd, but mbiebl would like to
> get permission from the you first.

Thank you for filiing this bug. This is just a short answer to acknowledge it 
as well as provide visibility upon the timeframe for its resolution. As you 
might be aware from discussions on the debian-ctte@l.d.o list, we are 
currently discussing seat-filling, both concretely and meta, so our energy is 
spread accross these topics already. Also, December is notorious for being a 
dense period in the year for many, TC members included.

My hope is that the TC will be able to spend enough energy to get this ball 
rolling, with a resolution somewhere in January.

With my best regards,
OdyX

Re: TC nomination procedure v0

[Didier 'OdyX' Raboud]

Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit :
> On Tue, Nov 28, 2017 at 10:48:25AM -0800, Don Armstrong wrote:
> > My rationale is that the private "vote" isn't a vote on the appointment,
> > it's a vote to figure out whether the future appointment vote will have
> > consensus or not.

Given large sets of vetted nominees, it's can also be a "sorting" mechanism. 
We could have more consensual candidates than seats to fill at a certain point 
in time, so using a condorcet-based process (yes, that's the Standard 
Resolution Procedure) helps determining who has consensus _and_ is preferred 
at that point in time. We don't want to have to downvote someone in public, so 
we make sure the public ballot has only the preferred candidate and FD.

This implies that: a) yes, the private vote is a preliminary vote on 
appointment; b) the public vote is usually a mere formality.

(The public vote is only a formality given a relatively unanimous TC though; 
and we could have a TC split about whom they'd want to get onboard. The 
current process doesn't really address that hypothetical situation.)

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

Would you be interested in drafting a GR for that, or is that too premature?

Cheers
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: TC nomination procedure v0

[Didier 'OdyX' Raboud]

Le mardi, 28 novembre 2017, 14.26:05 h CET Sean Whitton a écrit :
> On Tue, Nov 28 2017, Didier 'OdyX' Raboud wrote:
> >   - The TC *does not* make the number of nominees or number of
> > accepted nominations public.
> 
> I'm curious to here the thinking behind this particular line of the
> procedure.

The current process is the result of multiple not-really-thought-through 
iterations, and I don't think the TC ever really had an active conversation 
about that specific item. But here's my take:

It's easier [0] to have only few "public moments" in that process.
* the TC says "we have free seats"
* (… something happens in private …)
* the TC says "we ask the DPL to fill that one seat with #{project_member}"

So to answer your question specifically; I don't think the TC hides the 
numbers on purpose, it just doesn't really go through the effort of making 
them public.

Another aspect there also is that we don't want to put anyone who entered the 
process under bad public light. Low numbers would help draw (probably wrong) 
conclusions if one knows about some nominations.

Cheers,
OdyX

[0] As in "it costs less spoons".

signature.asc
Description: This is a digitally signed message part.

TC nomination procedure v0

[Didier 'OdyX' Raboud]

Dear TC, dear Project members,

I have finally finished drafting the "Nominations to the Technical Commitee"
procedure. The point of it is to document current practice, and create a basis
for discussion. It also outlines what is made public and when.

I welcome any direct formatting or phrasing changes by anyone with commit
access, but please discuss any procedure changes you would like to see
happen here.

It's `procedures/nominations.md` in the debian-ctte.git repository [0] and is
hereby attached.

Cheers,
OdyX

[0] 
https://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/procedures/nominations.mdNominations to the Technical Committee
--

Constitutional basis


  - §6.1.6 Together with the Project Leader, (the TC may) appoint new members
to itself or remove existing members.
  - §6.3.4 Confidentiality of appointments. The Technical Committee may hold
confidential discussions via private email or a private mailing list or other
means to discuss appointments to the Committee. However, votes on appointments
must be public.

Procedure
=

This procedure assumes there is one seat to fill. Some of its steps will be
common or run in parallel for multiple seat fillings.

Call for nominations

At this point, the TC needs to fill its set of nominees with interested project
members. To achieve this, an email is sent to debian-devel-announce@l.d.o
calling for (self-)nominations to be sent to the private TC alias
debian-ctte-priv...@debian.org. Current TC members can obviously also nominate
project members.

  - Every nomination is acknowledged.
  - Every non-self nominee is informed of their nomination and is asked to
indicate if they are willing to be considered for appointment. Nominees are
informed of the conditions below.

Communication to the project:

  - The TC *does not* make nominations or their acceptances public;
  - The TC *does not* make the number of nominees or number of accepted
nominations public.

Data collection
-
In order to enhance their decision-making data, TC members will collect some
data about the nominees and publish their findings to the private alias. The
point of that data collection is to get a better understanding of their skills,
their history within the project, their effect on conversations, etc.

Communication to the project:

  - The TC *does not* make the data public.

Shortlisting and picking a preferred candidate
-
Given the above data, any current TC member *can* vet for one or multiple
nominees they would like to see on an *internal* ballot. The TC would then use
the Standard Resolution Procedure **in private** to sort the list of candidates
(+ FD).

Communication to the project:

  - The TC *does not* make the ballot with vetted nominees public.
  - The TC *does not* make the result of the **private vote** public.

Question:

  - Does this private vote respect letter and/or intent of §6.3.4 "votes on
appointments must be public"?


Check for eventual DPL veto

In order to avoid any potential drama, the TC would **privately** ask the DPL
if they would later accept the nomination of the preffered candidate.

Public vote

The TC would use the Standard Resolution Procedure **in public** on a ballot
containing only the preferred candidate and FD. Once the result is known or no
longer in doubt (but ideally, once every current member has voted), the DPL is
informed.

Appointment by the DPL
---
When they see fit, the DPL would appoint the candidate as selected by the
public vote; ideally on debian-devel-announce@l.d.o .

(This is really outside of the TC's realm.)

Welcome and Thanks
--
The TC would then:

  - Congratulate and welcome the new member
  - Thank all nominees for volunteering.


signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le samedi, 4 novembre 2017, 01.39:31 h CET Scott Kitterman a écrit :
> On November 3, 2017 9:09:31 PM EDT, Sam Hartman  wrote:
> > I think that Debian does need a decision making body of last resort.
> > I personally think these communication skills are critical for such a
> > body.
> 
> One critical thing I think the TC misses is to consider if it's time to
> invoke last resort processes or not.  My impression is that if someone
> brings an issue to the TC, there's an assumption that the TC has to deal
> with it.

That's currently quite true; unfortunately. I do think the TC has the moral 
obligation to properly _acknowledge_ all requests filed before it, it should 
really do a better "initial conditions" check.

> The last time I was involved with an issue brought to the TC, it had been
> brought after zero discussion between the person filing the bug and the
> relevant team.  Complaining to the TC about a bug that's been dormant for
> years only a few days after resurrecting discussion about it (AIUI) seems
> similarly aggressive.

Absolutely. During the TC's last IRC meeting [0], we have identified the need 
of a bug-handling checklist, which could do a lot of good there. With such 
(lightweight) formalism in place, the TC would force itself to react to issues 
by first checking if they fulfill some preliminary conditions. Off the top of 
my (tired) head:
* have the maintainers had enough time to interact with the complainant?
* have  efforts to resolve the issue via consensus been tried and failed?
* is the disagreement sufficiently well described?
* etc.

Also, it seems the TC is bound to be focused in the technical problems, and 
how to address these [1], that's just a natural consequence of its name and 
its composition mechanism. Instead of directly addressing the issue, I tend to 
think the TC could instead often start by addressing the "meta" around the 
issue: where, and how is the problem described ? was it debated, and by which 
stakeholders? is the complainant "jumping the gun" or has the discussion 
really reached a point where a formal involvment of the TC makes sense? etc.

> Diving into issues in these kinds of circumstances turns the TC into nothing
> more than a stick to beat other developers with.  I think we need something
> like the TC, but I also think part of being the decider of last resort is
> sticking to the last resort part.

I agree; to some extent. Indeed, for any use of the constitutional powers of 
the TC, it shall really make sure all reasonable venues have been tried and 
failed, as a prerequisite to discussing the technical issue. But there's a 
wide range of issues where it makes sense for TC _members_ to go out and help 
the discussion. We also want people to feel comfortable coming to the TC for 
advice. The fact that the TC uses public bugs also puts some discussions under 
different lights: it's different to have TC members participate in a 
discussion (with or without hats) than have the same conversation on a tech-
ctte bug; a TC bug is (or at least, was) quite likely to end up with a formal 
decision, even if just for closure. The mere prospect of a potential 
maintainer override ad the end of the line is certainly quite offputting; a 
side of the conversation has a finger on the trigger. That leads me to think 
the TC could sometimes close the TC issues (or reassign them) earlier, without 
necessarily stopping the conversation.

> P.S. Having been through a couple of TC issues that involved packages or
> teams relevant to me, I totally get orphaning a package.  I don't know what
> fraction of packages I maintain I care enough about to deal with a TC
> complaint over them, but I'm pretty sure it's way less than half.

That's a quite saddening statement. Could you share (eventually in private) 
for which reasons? In what way could the TC evolve to make you feel 
comfortable having a conversation with it about one of your packages?

With my best regards,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2017/debian-ctte.
2017-10-18-19.01.html
[1] For example, see the start of https://bugs.debian.org/877024
(sorry Keith :-) )

Bug#877024: Modemmanager probing of unknown Devices

[Didier 'OdyX' Raboud]

Le lundi, 30 octobre 2017, 14.06:01 h CET Ian Jackson a écrit :
> 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].
> [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.

My personal take is that waiting only two days between saying "I'm likely to 
escalate to the TC" and doing so [2,3] is quite pushy "against" the 
maintainers who haven't had a reasonable chance to react, especially after two 
years inactivity on a 5 year-old bug.

[2] https://bugs.debian.org/683839#77
[3] https://bugs.debian.org/877024#5

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

Claiming that they are unenthusiastic is far-reaching IMHO. We just don't know 
what they think of the change, really. I wouldn't necessarily interpret the 
removal from the maintainers' field as a statement of opinion on these 
proposed changes, but much more about who the process went, and was handled by 
the TC too.

Le lundi, 30 octobre 2017, 13.45:00 h CET Sam Hartman a écrit :
> Wou/ld it be reasonable for him to make an NMU to experimental, and then
> if there is no objection after testing to unstable?
> 
> In parallel, it seems desirable to see if any of the maintainers are
> active.

The latter looks like a prerequisite to me, frankly. It seems to me from 
reading the bug log again that a solution is being worked out by upstream; and 
that this solution seems fine to the people who have intervened in this very 
bug. So it looks like the solution is ahead, "just" not yet in a Debian 
package. That bug exists in Debian for 5+ years, so I really don't see the 
urgency for an NMU, and would much rather let the current maintainers include 
the upstream version which includes the fix (and configure it appropriately) 
when they see fit.

Cheers,
OdyX

Bug#880014: Call for (self-)nominations for a Technical Committee seat

[Didier 'OdyX' Raboud]

Dear Debian Contributors,

Our Constitution imposes an expiry on Technical Committee terms, and it's that 
time of the year again: Keith Packard 's term will expire on December 
31st 2017. The Technical Committee would like to thank Keith for serving since 
November 2013, in addition to all the other work he does for Debian.

To fill this seat, we are soliciting nominations, including self-nominations. 
To nominate yourself or someone else, please send an e-mail to
debian-ctte-priv...@debian.org with the subject "TC Nomination of loginname", 
where loginname is the nominee's Debian account login¹. Please let us know in 
the body of the e-mail why the nominee would be a good fit for the TC, 
specifically instances where the nominee was able to help resolve 
disagreements, both technical and non-technical. We would like to start our 
selection process on or about the first of December.

Being a member of the TC does require a time commitment. Members should be 
able to follow e-mail discussions on an ongoing basis and respond within a 
couple of days so that discussions progress. Members should ideally be able to 
spend 10 hours a month for relatively busy months, but typical time 
requirements will be less.

We are in the process of documenting how the TC implements the nomination 
process as outlined in §6.2, including clarifying what is made public (such as 
nominations) and when. Any nominee is of course free to drop off the process 
at any point in time.

Regards,
OdyX, for the TC

¹ See http://db.debian.org/ if you need to look the login up

signature.asc
Description: This is a digitally signed message part.

Bug#880014: 2018 - New TC member

[Didier 'OdyX' Raboud]

Package: tech-ctte
User: tech-c...@packages.debian.org

According to our Constitution's §6.2, Keith's term will expire at the end of
this year, freeing one seat on the TC from January 1st 2018 on.

This bug will track that process.

Oct 2017 TC meeting is at 'Wed Oct 18 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening tomorrow:

date -d 'Wed Oct 18 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda is short, and updated in git.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le jeudi, 31 août 2017, 13.58:23 h CEST Thorsten Glaser a écrit :
> Do not drop it before *after* the next release, so people have,
> at the very least, one full release of time to switch their
> scripts in a way that works with both the old and new names
> *first*, gradually.

They have Stretch for that; it has both /usr/bin/nodejs and /usr/bin/node (in 
nodejs-legacy).

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le jeudi, 31 août 2017, 12.25:50 h CEST Ian Jackson a écrit :
> 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
> > -legacy 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.

This exact argument stands against not allowing NodeJS to use /usr/bin/node in 
the first place, really. We accepted to enforce that change for the /usr/bin/ 
namespace "first-come-first-served" reason. We imposed a quite heavy 
administrative burden of either targetting /u/b/nodejs additionally or (finding 
out and) installing nodejs-legacy for anyone wanting to use NodeJS on Debian.

Now, there are two categories of scripts affected by this discussion:
* All scripts which support /u/b/nodejs *in addition* to /u/b/node. These do 
so _because_ of a Debian-specific change, and removing the /u/b/nodejs symlink 
is not going to break those.
* All scripts which support /u/b/nodejs *exclusively*. These do so _because_ 
of a Debian-specific change, and don't support *any* non-Debian-derivative 
target (checked Fedora's nodejs RPMs: no /u/b/nodejs). Maintainers of those 
scripts have at one point decided to support only Debian{, and derivatives}.

There are _plenty_ of changes that one needs to care about in a stable 
upgrade: things like mandatory postfixing of Apache configuration files, 
removal 
of specific Python3 versions, removal of upstart, etc. Having to change a 
shebang isn't a big deal given the amount of things one has to check accross a 
stable release upgrade.

All that to say that despite the very small cost of keeping the symlink 
around, I do see value in closing the Debian-specific /u/b/nodejs chapter *at 
some point*. We should not clutter our future releases indefinitely with 
convenience symlinks for historical reasons, especially not when these were 
created _by_ Debian and have only been _in_ Debian.

Le jeudi, 31 août 2017, 13.52:00 h CEST Jérémy Lal a écrit :
> How about printing a "nice" warning explaining it would be a good idea to
> move to /usr/bin/node ? Then in next next release drop the nodejs symlink.

This seems like a very good plan to me: let /u/b/nodejs spit out a deprecation 
warning to stderr / syslog but pass all arguments to /u/b/node in Buster; 
remove it entirely in Bullseye & get proper release note entries for both 
Buster and Bullseye.

Cheers.
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit :
> Leave /usr/bin/nodejs there for at least one more release.

I'll just note for the purpose of the TC discussion that as of nodejs 
6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs → node 
symlink still exists, so at this point, I don't consider there is material for 
a TC decision either way, but it's an important conversation to be had.

Jérémy: could you maybe clarify your plan and your rationale? This would help 
putting everyone on common grounds.

Cheers,
OdyX

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

[Didier 'OdyX' Raboud]

Le mardi, 29 août 2017, 12.32:19 h CEST Sam Hartman a écrit :
> > "Thorsten" == Thorsten Glaser  writes:
> Thorsten> Hi,
> 
> >> * Restore /usr/bin/node following CTTE #862051 Let's try to drop
> >> /usr/bin/nodejs before buster.  Replaces and Conflicts
> >> nodejs-legacy.  Closes: #754462.
> 
> Thorsten> please do NOT completely replace an ABI between releases.
> Thorsten> Leave /usr/bin/nodejs there for at least one more release.
> 
> 
> I agree.
> Even if you get everything in Debian fixed, you won't know about user
> scripts that have been designed around what Debian does.

Right.

Searching for "/usr/bin/nodejs" on github [0] shows around 27'500 occurences.

> Giving people a release to deal with transitions is a great thing to do
> when there's no good reason not to.
> Maintaining a symlink for a release seems a low cost.

True. On the other hand, the fact that Debian "created" /usr/bin/nodejs also 
means it's on Debian's hands to eventually remove it.

For good reasons, Debian forcibly introduced a special-case when Node.js first 
appeared in a stable release through only shipping it under /usr/bin/nodejs. 
That forced hundreds of projects to cope with that, probably often through 
supporting both /usr/bin/node and /usr/bin/nodejs I suspect.

I'm quite convinced that large parts of the Node.js ecosystem will cope well 
without any /usr/bin/nodejs available in stretch.

So I'm not convinced it's really worth the trouble to keep it around for 
another stable release; I'd probably be fine with a swap of the setup we had 
(with the convenience symlink in a different and not-installed-by-default 
package).

> For that matter I really can't see a good reason to ever drop the
> symlink.

I want Debian to be able to move on and ahead; cleaning up past special-cases 
from our stable releases is good. We only support stable-to-stable upgrades 
for good reasons and removing such convenience symlinks falls in the same 
category as cleanup of maintainer scripts' code for oldstable-to-stable paths. 
I would strongly support removal of the symlink in bullseye.

Cheers,
OdyX

[0] https://github.com/search?utf8=%E2%9C%93=%22%2Fusr%2Fbin%2Fnodejs
%22=Code

Re: Agust 2017 TC meeting is at 'Wed Aug 16 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

Le vendredi, 18 août 2017, 08.40:46 h CEST Niko Tyni a écrit :
> Oh, no worries. Thanks for handling the bug!

If you have longer thoughts about that issue, please send them to the bug. As 
we aren't voting on them anyway, they provide good value for the community.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Agust 2017 TC meeting is at 'Wed Aug 16 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening tonight:

date -d 'Wed Aug 16 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

I won't be able to attend, unfortunately. I suggest that as we just had 
DebConf, we could cancel this one. On my list anyway:
* https://bugs.debian.org/865929 needs to get closed (fil volunteered)
* launch a discussion about our recruitement process on -devel (will do that)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

DebConf17 TC BoF and meeting

[Didier 'OdyX' Raboud]

Hi there,

as you know from the DebConf17 schedule, the 'Meet the TC' BoF is scheduled 
monday evening at 17:00 local time in room Rex.

I've prepared some slides:

https://reveal.odyx.org/Debian/201708-Meet-the-Debian-TC.html
https://reveal.odyx.org/Debian/201708-Meet-the-Debian-TC.pdf

They're not definitive, all comments welcome!

We should also try to gather together before that, just to prepare what we 
want to say, in which order etc. I propose to gather together at 16h on 
Monday.

See you there!

Cheers,
OdyX

Re: Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Didier 'OdyX' Raboud]

Le jeudi, 3 août 2017, 08.53:09 h CEST Didier 'OdyX' Raboud a écrit :
> Le mardi, 1 août 2017, 11.01:10 h CEST Sean Whitton a écrit :
> > On Thu, Sep 29, 2016 at 02:55:31PM -0400, Sam Hartman wrote:
> > > We also approved the decision that packages should not include both a
> > > menu file and a desktop file.
> > 
> > For reference, Policy currently says that packages should include a
> > desktop file, and may also include a menu file for the sake of old
> > window managers.
> > > The action to draft language for that has stalled in the policy
> > > process.
> > 
> > Is there a policy bug that got stalled?  If not, maybe this bug should
> > just be reassigned to policy?

I now gathered some old memories and remembered that there was indeed a bug 
about this that got stalled: #707851 (which was the TC bug). See from message 
#475 (September 2015), where I tried to push a wording quite similar to yours 
to Policy:

> +Applications that are registred in the desktop menu shall not also
> +provide a Debian menu file for the same application.

So https://lists.debian.org/debian-policy/2015/09/msg00024.html is the start 
of the thread that stalled.

I read the arguments back then as critics against the TC decision itself, not 
discussions about the wording. My argument back then (and it has not changed) 
is that now that the TC decision is made, it should find it's way into the 
Policy.

So… I'm fine with your wording, but thought it'd be useful to point at the 
previous discussion about this very subject.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Didier 'OdyX' Raboud]

Control: reassign -1 debian-policy 4.0.0.4
Control: affects -1 + tech-ctte

Hi Sean,

Le mardi, 1 août 2017, 11.01:10 h CEST Sean Whitton a écrit :
> On Thu, Sep 29, 2016 at 02:55:31PM -0400, Sam Hartman wrote:
> > We also approved the decision that packages should not include both a
> > menu file and a desktop file.
> 
> For reference, Policy currently says that packages should include a
> desktop file, and may also include a menu file for the sake of old
> window managers.
> 
> So the change that was approved is:

For reference, the TC decision was announced on d-d-announce:
https://lists.debian.org/debian-devel-announce/2015/09/msg0.html

And, as far as I could tell, although the specific commit has made its way into 
Policy, point 2 of the TC decision still needs wording:
>2. In addition to those changes, the Technical Committee resolves
>   that packages providing a .desktop file shall not also provide a
>   menu file for the same application.

So yes, point 2 corresponds to your:
> - delete that paragraph
> - add a new paragraph saying "if there is a desktop file, there should
>   be no menu file"

Point 3 & 4 are up to the maintainers of 'menu'; point 5 & 6 just state where 
in policy the fine-tuning of the menu integration should happen.

> This is not strictly equivalent to "packages should not include both a
> menu file and a desktop file", but given that we have deprecated menu
> files, it seems like the right way to reflect the change.

At the risk of sounding procedural, "right way" or not, the TC has used its 
power under §6.1.1 and set policy for that change.

> > The action to draft language for that has stalled in the policy
> > process.
> 
> Is there a policy bug that got stalled?  If not, maybe this bug should
> just be reassigned to policy?

We filed that bug at times when the policy team seemed unable to get to that 
subject on its own; we also set to work on specific wording ever since (without 
success), and finally decided to assign some of us to work on that during 
DebConf17.

That said, now that thanks to new forces, the process seems vivid and strong 
again, it does indeed make sense to reassign that to Policy. I'm hereby doing 
this, marking the TC as "affected". We'd still be happy to help on the 
wording, ideally during DebConf!

Many thanks in advance for your energy to get this to closure!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Didier 'OdyX' Raboud]

Le samedi, 29 juillet 2017, 22.05:34 h CEST Tollef Fog Heen a écrit :
> === Resolution ===
> 
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
> 
> The Committee therefore resolves that:
> 
> 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.
> 
> === End Resolution ===
> 
> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote R>F

-- 
OdyX

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

[Didier 'OdyX' Raboud]

Le mercredi, 19 juillet 2017, 21.35:33 h CEST Tollef Fog Heen a écrit :
> === DRAFT Resolution v2 ===
> 
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
> 
> The Committee therefore resolves that:
> 
> 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.
> 
> === End DRAFT Resolution v2 ===

Thank you for that draft; we can vote on it as far as I'm concerned.

Cheers,
OdyX

July 2017 TC meeting is at 'Wed Jul 19 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening in two days:

date -d 'Wed Jul 19 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda was updated accordingly in git; please make any necessary changes 
or additions.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#865485: Voting for TC Chair

[Didier 'OdyX' Raboud]

Le mercredi, 21 juin 2017, 22.21:57 h CEST Didier 'OdyX' Raboud a écrit :
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> H: Niko Tyni 
> ===END===

I vote

B > E > D = C > F = G = H > A

-- 
OdyX


signature.asc
Description: This is a digitally signed message part.

Bug#865485: Voting for TC Chair

[Didier 'OdyX' Raboud]

Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of Niko to the TC and according to our current 
procedures¹, I am hereby announcing my immediate vacation of the chair 
position, triggering a new election. For clarity of the process, I am 
interested to continue serving as chair.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A: Keith Packard 
B: Didier Raboud 
C: Tollef Fog Heen 
D: Sam Hartman 
E: Phil Hands 
F: Margarita Manterola 
G: David Bremner 
H: Niko Tyni 
===END===

-- 
Cheers,
OdyX


signature.asc
Description: This is a digitally signed message part.

Re: Technical committee appointment

[Didier 'OdyX' Raboud]

Hi there Niko,

Le mercredi, 21 juin 2017, 15.06:33 h CEST Chris Lamb a écrit :
> I am very happy to follow this recommendation and hereby appoint Niko Tyni
> (ntyni) to he Committee effective immediately.

Congratulations, and welcome!

There are two things you need to know now:
* we have an introduction sheet for new members on our repository, which I 
recommend that you read (and enhance freely as you see fit):

https://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/plain/
intro_sheet.md

* we have a (somewhat) regular schedule of IRC meetings, every third Wednesday 
in a month at 19 UTC, in #debian-ctte on irc.debian.org. You read correctly, 
that's in about 3 hours from now. It'd be great if you could attend!

See you there, and congratulations again!

OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#836127: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

> ===BEGIN
> The Technical Committee recommends that Niko Tyni  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> N: Recommend to Appoint Niko Tyni 
> F: Further Discussion
> ===END

With six votes in favour and a week gone, the result of this vote is now 
longer in doubt:

The TC recommends that Niko Tyni  be appointed by the Debian Project 
Leader to the Technical Committee.

@Chris: it's in your hands now; I'm hereby closing this bug as not a concern 
for the TC anymore.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

June 2017 TC meeting is at 'Wed June 21 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening tomorrow:

date -d 'Wed June 21 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda was updated accordingly in git; please make any necessary changes 
or additions.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#836127: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

Le mardi, 13 juin 2017, 20.08:38 h CEST Didier 'OdyX' Raboud a écrit :
> ===BEGIN
> The Technical Committee recommends that Niko Tyni <nt...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> N: Recommend to Appoint Niko Tyni <nt...@debian.org>
> F: Further Discussion
> ===END

I vote:

N > F

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#836127: Call for Votes for new TC member

[Didier 'OdyX' Raboud]

I call for votes on the following ballot to fill a vacant seat in the TC. The 
voting period starts immediately and lasts for up to one week, or until the 
outcome is no longer in doubt (§6.3.1).

===BEGIN
The Technical Committee recommends that Niko Tyni  be
appointed by the Debian Project Leader to the Technical Committee.

N: Recommend to Appoint Niko Tyni 
F: Further Discussion
===END

signature.asc
Description: This is a digitally signed message part.

May 2017 TC meeting is at 'Wed May 17 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The monthly Debian Technical Committee Meeting is happening tomorrow:

date -d 'Wed May 17 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda was updated accordingly in git; please make any necessary changes 
or additions.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Next TC nomination

[Didier 'OdyX' Raboud]

Dear all,

during its last IRC meeting [0], the TC agreed to attempt to fill the 
currently remaining TC seat with the people already nominated in the previous 
round. In other words, we are not currently looking for new nominations.

That said, a new TC seat will become available at the end of 2017 due to 
Keith's term expiry, so we will be looking for new nominations then.

Cheers, for the TC,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2017/debian-ctte.
2017-04-19-19.00.html

signature.asc
Description: This is a digitally signed message part.

Bug#860520: Voting for TC Chair

[Didier 'OdyX' Raboud]

Le mardi, 18 avril 2017, 08.58:03 h CEST Didier 'OdyX' Raboud a écrit :
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> ===END===

I vote:

B > E > D = C > F = G > A   

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#860520: Voting for TC Chair

[Didier 'OdyX' Raboud]

Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of David to the TC and according to our current 
procedures¹, I am hereby announcing my immediate vacation of the chair 
position, triggering a new election. For clarity of the process, I am 
interested to continue serving as chair.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A: Keith Packard 
B: Didier Raboud 
C: Tollef Fog Heen 
D: Sam Hartman 
E: Phil Hands 
F: Margarita Manterola 
G: David Bremner 
===END===

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#836127: Call for Votes for new CTTE Member

[Didier 'OdyX' Raboud]

Le lundi, 3 avril 2017, 20.15:46 h CEST Philip Hands a écrit :
> ===BEGIN
> 
> The Technical Committee recommends that David Bremner  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to Appoint David Bremner 
> B: Further Discussion
> 
> ===END

I vote A > B

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: No TC Chair election yet

[Didier 'OdyX' Raboud]

Dear TC,

Le mercredi, 4 janvier 2017, 11.17:47 h CEST Didier 'OdyX' Raboud a écrit :
> We have this in our procedures:
> > Re-appointment of chair after membership change
> > 
> > When new members are appointed to the CTTE or within three months of a
> > member resigning from the CTTE, the current chairperson should
> > announce their intention to vacate the position within two weeks.
> 
> We have had two TC term expiries 4 days ago, the three-month timer has
> therefore now started. As I hope we can finish the new members' appointment
> procedure in this time, and as the procedure will trigger a new chair
> appointment anyway when the two new members are appointed, I am _not_
> announcing vacation of the chair position now. The intention here is to
> spare some energy for the new member's appointment,

Given that the three months period has now passed, and in the spirit of 
sticking to existing procedures, I'm hereby announcing my intention to vacate 
the TC chair position within two weeks, effective by April 14.

Note that I am interested and willing to continue to serve in that position 
though.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

March 2017 TC meeting is tonight at 'Wed Mar 15 19:00:00 UTC 2017'

[Didier 'OdyX' Raboud]

The March Debian Technical Committee Meeting is happening tonight, sorry 
for reminding us of that so late.

date -d 'Wed Mar 15 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda was updated accordingly in git; please make any necessary changes. 
I'm unfortunately unlikely to be able to attend, even less chair.

Cheers,
OdyX

[0] Pointed by https://deb.li/tcmeetings

signature.asc
Description: This is a digitally signed message part.

Re: February 2017 TC meeting was yesterday

[Didier 'OdyX' Raboud]

The meeting has now happened, and the meeting log and notes captured by the 
MeetBot are available on the MeetBot archive [0], and have been pushed to the 
TC's git repository [1]. Here come the summary.

Meeting summary
---
* Next Meetings?
  * AGREED: There seems to be consensus in favour of a fixed
time-in-the-month.

* Review of previous meetings' TODOs

* #850887 Decide proper solution for binutils' mips* bug
  * ACTION: hartmans to close #850887 'decide proper solution for
binutils\' mips* bug'

* #846002 blends-tasks must not be priority:important
  * ACTION: OdyX to coordinate with marga (eventually with Mithrandir's
help) to close #846002 with the vote's result.

* #839570 Browserified javascript and DFSG 2 (reopening)
  * AGREED: hartmans do close that one in the next hour.

* #839172 TC decision regarding menu policy not reflected yet
  * AGREED: keithp & OdyX to find some time to prepare an initial
"discussion-ready" patch for the 'Debian menu' Policy in Debian
policy

* #836127 New TC members
  * ACTION: OdyX to start private Standard Resolution procedure to sort
out the most favored candidates.

* Additional Business

[0] http://meetbot.debian.net/debian-ctte/2017/debian-ctte.
2017-02-22-19.00.html
[1] https://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/

signature.asc
Description: This is a digitally signed message part.

February 2017 TC meeting is tomorrow at 'Thu Dec 22 18:00:00 UTC 2016'

[Didier 'OdyX' Raboud]

The February Debian Technical Committee Meeting will happen tomorrow, sorry 
for reminding us of that so late.

date -d 'Wed Feb 22 19:00:00 UTC 2017'
in #debian-ctte on irc.debian.org

The agenda was updated accordingly in git; please make any necessary changes.

For now, I suggest to try the "Third Wednesday of every month, 19:00 UTC" 
schedule, and have added all 2017 meetings following that rule in the 
meetings.ics file [0], for now. There's a point to discuss this in the agenda

See you in a day, on IRC!
OdyX

[0] Pointed by https://deb.li/tcmeetings


signature.asc
Description: This is a digitally signed message part.

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

[Didier 'OdyX' Raboud]

>  RESOLUTION 
> 
> Background
> 
> The blends-tasks package was uploaded in April 2016 setting its priority to
> important.  The result of this change was that the package started getting
> automatically installed by debootstrap, with the intended effect of causing
> the list of tasks shipped by the package to be displayed by tasksel in the
> debian-installer.
> 
> Even though the debian-installer maintainer complained in May 2016 that he
> did not agree with this approach with regards to including external
> packages in the default tasksel screen, the important priority remains
> until today.
> 
> In December 2016, changes were made in the tasksel package so that it no
> longer automatically displays external tasks as part of the
> debian-installer.
> 
> The current state is that chroots created by debootstrap in unstable or
> testing include the blends-tasks package, although the shipped tasks are
> not getting displayed during the default installation.
> 
> In #846002, the Technical Committee was asked by Holger Levsen to rule on
> the priority of the blends-tasks package.  In the discussion that followed,
> the Committee was asked by Ole Streicher to additionally rule on whether
> the Blends selection should be part of the Debian Stretch installer and who
> should maintain the list of options displayed to the user in the future.
> 
> Using the power of the Technical Committee to make a decision when asked to
> do so (§6.1.3):
> 
> 1. We acknowledge that the decision of which tasks to display during
> installation falls within the jurisdiction of the debian-installer
> maintainers.
> 
> 2. In the Committee's opinion the use of important priority is not
> appropriate for the blends-tasks package according to the definition in the
> Debian policy (§2.5).  As it was set only as a means to an end, and since
> it no longer does what was intended, we recommend that this change gets
> reverted.
> 
> 3. We encourage the debian-installer maintainers to work together with other
> teams -including the blends-tasks maintainers- to provide useful and
> popular package selections through the debian-installer in future releases.
> 
>  END OF RESOLUTION 

I vote A > FD

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le mercredi, 11 janvier 2017, 22.38:33 h CET Sam Hartman a écrit :
> I heard back from doko today.  We can expect a reply tomorrow.  We also
> talked briefly about the issue.

Good. Thanks for this work.

> Realistically, i cannot imagine the TC coming to any final decision on
> something like this in under three weeks.  That timeline seems fairly
> aggressive actually.

Right. It implies that every involved party (Lisandro, the Release Team, 
Matthias, and the TC members) can provide a high bandwidth to that issue.

> However, I think the TC could act much more quickly in an interim
> capacity.

Yes.

> I personally believe that having packages building is a better interim
> state than the status quo.  There are risks to an interim measure.  We
> could have packages in the archive that build but fail to function
> correctly.

Ack.

> Depending on what we do long term, we could end up replacing
> packges currently in Stretch with packages we can no longer rebuild.

The worst case is needing to rebootstrap mips' stretch either from jessie, or 
in a cross-bootstrap situation, right ?

> I personally think that when I weigh those risks against my estimate of
> their probability, I think it makes sense to adopt an interim measure.

I agree.

> Roughly I propose to override the maintainer and permit an NMU to be
> made for this issue.

It would be much preferable if Matthias would accept that patch, or revert to 
the previous working version. But if it needs an NMU, so be it.

(Mid-term, I want to understand how it can make sense to change Debian's
 binutils' tracked branch (2.27→2.28) three days before the transition
 freeze.
)

> The decision stands until the maintainer fixes the bug or Stretch
> releases, or another resolution is passed (presumably with a more
> permanent decision).

Absolutely.

> Yes, that means that the maintainer could reintroduce the bug and revert
> the NMU immediately on the release of Stretch.

Absolutely. I wouldn't support a resolution enforcing that NMU in unstable 
forever. New release cycles are our reset button, really.

> I propose to be very agressive in calling for a vote on the following
> ballot.
> I plan to call for a vote in 24 hours if I get support from at least one
> TC member and no objections from within the TC or release team.

Let this mail be my support !

> Also, within that time, we should hear from doko.  His input may change
> my thinking even for an interim measure.

Yes, absolutely. There was only one mail from Matthias on the #844227, only to 
NAK the NMU, on an RC bug opened since November, his input is long overdue!

> 
> 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.
> 
> The committee requests the release team to support the interim nature of
> this solution and if a permanent solution is adopted before the release of
> Stretch, to consider including that solution in Stretch even if the freeze
> criteria would not normally permit such consideration.
> 
> In addition, the committee requests the stable release managers for Stretch
> to consider including the eventual upstream solution for this issue into a
> stretch update.
> 
> This interim decision stands until the release of Stretch, until it is
> replaced by resolution, or until the binutils maintainer fixes #840227 in
> some other manner.
> 
> 
> Choice 1:  Approve the Resolution (3:1 majority)
> Choice 2: Reject this Interim Measure
> Choice 3: Further Discussion
> 

I agree with the ballot including Ian's suggestion, and think we should start 
the vote as early as this week-end.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Dear Ian,

while I see where you come from, and can empathize with some of your points, I 
think that Daniel's following of upstream practices in using full paths is 
both fairly common, and a valid practice in Debian Packages.

Le mercredi, 11 janvier 2017, 17.13:44 h CET Ian Jackson a écrit :
> 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.

Asking the TC to declare the above seems _very_ premature to me. In 
particular, in the frame of §6.3.6, I don't think enough efforts have been put 
in resolving this via consensus. Rather, I think it _is_ a resolved issue 
(over the course of years), but that you happen to disagree with the 
consensus.

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

>  * Provide an informal opinion that this policy ought to apply to
>gpg-agent as requested in #850657.

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.

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.

I'd be in favour of closing this bug above Further Discussion.

Cheers,
OdyX

P.S. No need to reply asking me to focus on a different issue…

signature.asc
Description: This is a digitally signed message part.

Re: December 2016 TC meeting is at 'Thu Dec 22 18:00:00 UTC 2016'

[Didier 'OdyX' Raboud]

Le mardi, 20 décembre 2016, 09.34:07 h CET Didier 'OdyX' Raboud a écrit :
> Reminder: this is in two days @18:00 UTC.

The meeting is tonight, but I have a schedule clash with a family event, 
unfortunately. I'll try to follow on my mobile, but can't promise full 
availability.

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.
- regarding #836127 (new TC members), it doesn't look like we'll be able to 
spend much time on that before the end of the year. It needs someone to drive 
this process through. I (personally) would welcome opinions from the two soon-
not-TC-members-anymore about the nominees though.

As for the rest of the issues we have, they got bounced way down my TODO list, 
unfortunately; there was no progress on that front.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Didier 'OdyX' Raboud]

Le vendredi, 9 décembre 2016, 15.03:14 h CET Colin Watson a écrit :
> On Fri, Dec 09, 2016 at 08:58:10AM -0500, Sam Hartman wrote:
> > However, the time at which Debian has last synced with upstream does
> > matter.
> > Six years is a long time.
> > Moreover, I believe that the standard you've used to evaluate whether
> > failing to sync for six years was acceptable is inconsistent with best
> > practices of the project.
> 
> As a maintainer who has sometimes had cause to do similar things, I'm
> concerned at the standard being applied here.  Could you perhaps review
> the history around groff 1.18.1.1 -> 1.20 for comparison?  This is a
> case that's all over and done with seven years ago, so should be free of
> emotive associations by now, and the history can be read through
> reasonably quickly.

Thank you for the example case, including its references.

> Now, my perception of this case is that there was a complex blocking
> issue with the new upstream release that affected a minority of users,
> and therefore I chose to hold back the new upstream until it could be
> handled in a way that did not cause serious regressions.
> 
> (…)
> 
> If the TC thinks my actions in the past were reasonable, then I would
> like any ruling here to be a bit more nuanced about cases of delayed
> syncing with upstream, reflecting whatever important differences you see
> between the two cases.

By a quick glance, your past actions _were_ indeed reasonable. And commenting 
on what differentiates this example with 'global' is a worthwile exercise.

What I see as fundamental difference here was your use of #196762 as a single 
point of contact for the problem you were facing with groff 1.19, in which you 
explained, commented and followed up on what the problem was, what were your 
thoughts, asking for help, and updating this bug regularly. You also used this 
single point of contact in later bugs:
> Unfortunately, for technical reasons (see bug #196762), it is extremely
> difficult to upgrade to the new upstream release.

All-in-all, although there are appeareances of equivalence between the two 
packages' histories, I certainly see fundamental differences in how the "new 
upstream version has problems that are hard to fix" question was addressed.

There can be valid, strong and solid technical reasons to hold back on new 
upstream versions, but what matters for us as a distribution, is how we 
collaborate and communicate about these blockers. Our SC's "We will not hide 
problems" is not to be understood strictly as "our bugtracker is public" only; 
it is a much larger concern that we should share, so as to make our 
collaboration as frictionless as possible, as well as make the technical 
problems not only reside in the package maintainer's heads, but to share them 
with the project.

That's really the thing I miss most in 'global's history: it shouldn't need a 
TC bug to get the 'htags' problem described properly, on a public, standalone 
bug.

Things like
> (we) are currently discussing changes to the CGI mechanism which may alter
> several things about how this is currently arranged.
in #590053, or the discussion in #574947 where Ron claims to have reached a 
private agreement that is not confirmed by upstream authors are un-
comprehensible for outsiders, which are left without a clue upon what needs to 
be fixed, or done.

The problem I have with how 'global' is maintained is not at all technical. 
Holding back on an old version because of 'htags' breakage _was_ a good 
technical decision back then. But the way this hurdle was (not) documented is 
just not how I want to see maintainers collaborate and "not hide problems" for 
packages in Debian.

The fact that the hurdle is _still not_ properly and publicly documented 
doesn't open room for helping the maintainer, doesn't bring clarity to 
newcomers and therefore puts the maintainer in sole responsiblity. Wei Lui 
expressed that problem clearly in #816924 (March 2016):
> I'm aware of the disagreement between Ron and Shigio, but it's so
> frustrating that no resolution has been found for so many years. There
> were talks about possible designs proposed by Ron and / or Shigio but
> it is just impossible for us users to do archaeology dating back to
> 1999 with no useful references whatsoever.

Another difference I see is this urge you felt. Two months after groff 1.19 
was released, you filed this bug documenting your concerns with it and no less 
than three months later, you wrote:
> I'm beginning to get a bit itchy about falling too far behind upstream
> here.

As a matter of fact, I do _expect_ maintainers to get itchy when they fall too 
far behind upstream. If Ron had documented the problem from the start (or at 
any later point in time, really), users would have found it, and debated ways 
out, patches, etc. This bug would have included upstream developers for a 
discussion _in public_. That bug would have helped joining forces, helped the 
maintainer determine the 

Bug#841294: global maintainer : Draft ballot

[Didier 'OdyX' Raboud]

With the precious help of Phil and Sam, here comes a draft ballot. It is 
attached to this mail, and has been committed to the TC's git repository [0].

It contains the following ballot options:
> - Option A - Reaffirm Ron Lee as 'global' maintainer (§6.1.2)
> - Option B - Declare Wookey as 'global' maintainer (§6.1.2)
> - Option C - Decline to rule, consider case closed
> - Option FD - Further discussion

I hereby open the discussion period, and welcome any amendments on the 
background, rationale, ballot options or the closing words, of course. Please 
apply english wording and all 'obviously consensual' fixes directly in git.

I would like to be able to start a vote on Monday.

-- 
Cheers,
OdyX

[0] https://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/
841294_global/draft
# Background

* In #841294, the Technical Committee was asked to overrule the
  maintainer of the 'global' package to get a new upstream version
  packaged.
* As a matter of fact, at the time #841294 was filed, the 'global'
  package's latest upload to unstable had happened in October 2010,
  despite several requests for newer 'global' upstream releases and
  bugreports.
* The discussion, involving various people ranging from bugreporters,
  Debian contributors, the 'global' maintainer, and some TC members, has
  clarified two lines of argumentation around the maintenance of the
  'global' package':
   - global is fine as it is, version numbers are no silver-bullet, and
 there are severe problems in the new upstream versions, that are
 being discussed with upstream.  New features could always be
 backported to the Debian version if worthwhile bugs were reported.
   - there's a rightful expectation to get new upstream versions, even if
 they introduce regressions or functionality losses. No amount of
 upstream problems justify holding new versions back over multiple
 release cycles.

# Rationale

* Our Social Contract's "We don't hide problems" implies that
  maintainers go through reasonable effort to make their packages'
  problems visible; and the usual way is to use the Debian bug tracker.
  It also implies reporting upstream flaws to upstream, ideally in public.
  Adding references to the BTS would avoid the impression that nothing had
  been done.
* Integrating recent versions of upstream software is a maintainers'
  duty, as Debian is a primarily a software distribution; distributions
  exist to facilitate users' access to upstream software. Uploading recent
  versions and making them available to Debian users on a somewhat regular
  basis is our way to find, address and correct problems brought in by new
  upstream releases. The 'experimental' suite exists explicitly for the
  purpose of testing software not immediately suitable for release towards
  future stable releases.
* If the maintainer decides that our users will be best served by not
  upgrading, this should be explicitly stated.  The README.Debian file
  of the package would be a good place to do this, as well as in response
  to bugs requesting upgrades.
* The argument that features could easily be backported would carry
  significantly more weight if there was evidence of patches for past
  bugs being acted upon in a timely manner.

# Ballot

- Option A - Reaffirm Ron Lee as 'global' maintainer (§6.1.2)

- Option B - Declare Wookey as 'global' maintainer (§6.1.2)

- Option C - Decline to rule, consider case closed

- Option FD - Further discussion

# Closing words

We invite all interested parties to contribute in good faith for the
best possible 'global' package. Filing bugs with appropriate severities
is every user's duty, and it is important that those who understand the
package best continue to provide their best inputs.


signature.asc
Description: This is a digitally signed message part.

December 2016 TC meeting is at 'Thu Dec 22 18:00:00 UTC 2016'

[Didier 'OdyX' Raboud]

The December Debian Technical Committee Meeting will happen at

date -d 'Thu Dec 22 18:00:00 UTC 2016'
in #debian-ctte on irc.debian.org

The meetings.ics file [0] and the agenda were updated accordingly in git;
please make any necessary changes.

The meeting poll has also been updated for the January & February meetings,
please update your preferences.

[0] Pointed by https://deb.li/tcmeetings

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Didier 'OdyX' Raboud]

Le vendredi, 9 décembre 2016, 04.55:20 h CET Ron a écrit :
> > If you haven't yet, I urge you to use our standard interface to report
> > such
> > bugs; please make sure issues like this one are public on our bugtracker,
> > with correct found/notfound version markers.
> 
> Do you really want entries in the tracker for buggy code that was never
> in Debian, because I nacked Punit uploading things he didn't understand
> with a vague promise to maybe look at them later?

That code is now in Debian (experimental), so yes, I do expect you to act in 
good faith and report bugs you see. You are obviously quite versed in how 
'global' works, and that's undoubtedly valuable to produce the best possible 
'global' package.

> Now we're talking about what to do among a wider group of people, given
> that it still looks like nothing material will change.  The system works?

It doesn't: it shouldn't take 3 stable releases to get a new upstream release 
for a leaf package.

> That report led to both me and the reporter having a (very) long
> discussion with upstream about how to resolve the real problem that
> you keep assuming we never tried to do anything about.

By "(very) long discussion", do you mean these 8 mails ?

http://lists.gnu.org/archive/html/bug-global/2010-08/threads.html#6

As far as I could see, this is the only thread in all of bug-global's (public) 
history in which you contributed, hence your only public input to upstream 
about how >> 5.7.1 versions have problems in your opinion.

Is there another public bug tracker somewhere that I missed?

Did you have other conversations with upstream? If so, where can we find them?

> > If all the problems come from "the htags from v6", what is blocking you
> > from at least providing the latest 5.x versions?
> 
> We are providing the latest 5.x version that didn't break the interfaces
> we need.  I'm talking about v6 here, because v6 is what we are talking
> about moving to next.

Fair enough. Sorry for assuming the breakage was in from 6.0 on.

I'm purposedly not answering to the rest of your email, as I think the TC now 
has enough information to issue a decision.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Didier 'OdyX' Raboud]

Le jeudi, 8 décembre 2016, 18.14:12 h CET Tollef Fog Heen a écrit :
> Using open like in the code snippet above is pretty much inexcusable in
> this day and age.

Fair enough, thanks for the explanation.

Ron: could you point us to your report of this problem to the upstream 
bugtracker or list? What was the answer you got?

-- 
Cheers,
OdyX

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Didier 'OdyX' Raboud]

Just commenting to some specific points as, despite an explicit request, you 
have failed (and spectacularly so) to provide brief answers. That's not 
helping a quick and clear path towards resolution.

Le jeudi, 8 décembre 2016, 23.32:44 h CET Ron a écrit :
> On Mon, Dec 05, 2016 at 10:13:05PM +0100, Philip Hands wrote:
> > Perhaps you'd be kind enough to either confirm or correct my perceptions
> > of the current situation:
> >   Version 6 includes a CGI script that one is expected to install in a
> >   manner so hopelessly insecure that we'd not accept it in Debian.
> 
> For the version (…) that I nacked, which is where this appeal to the ctte
> started from, that's absolutely true.  Not only did it have the 'chmod 777'
> interface to enable it, it had little gems in it like this too:
> 
>  open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern |");
> 
> Which for those who don't speak it, is perl for "anyone can execute
> arbitrary shell commands by typing them into a web browser", since
> $pattern is an unsanitised, untrusted, input from the query string.

If you haven't yet, I urge you to use our standard interface to report such 
bugs; please make sure issues like this one are public on our bugtracker, with 
correct found/notfound version markers.

This also applies to group who has uploaded the experimental version: please 
version-close bugs that this version fixes.

For that specific Perl problem, I'd love to be enlightened in how the version 
in 6.5.5 is significantly worse than the code in 5.7.1-3's global.cgi.tmpl:

http://sources.debian.net/src/global/5.7.1-3/htags/global.cgi.tmpl/?
hl=152#L152

> It also made changes that guarantee everyone will need to fork it
> for distro use, because it now hardcodes a fun mix of paths, like
> /opt/local/bin for perl and /usr/local for global et al.

That's a _very_ typical distro maintainer's job, really.

> It is what we now have enabled in the package that Wookey uploaded to
> experimental.

At least now we have a version in Debian we can compare with. Noone has 
claimed it would be perfect, but uploading this new version (to whichever 
suite, really) was your duty as maintainer and you failed to do so in 6+ 
years.

> > Are there any other regressions that you are aware of in v6?
> 
> In terms of the upstream code, the issues with htags are the main
> 'showstopper' I'm currently aware of.  But I haven't tested the
> rest of it anywhere near exhaustively yet either.
> 
> In terms of the package currently in experimental, there's a bunch
> of issues with it that would need to be fixed if we were going to
> want it in Stretch. 

Please file these as bugreports, with appropriate severities. This is the only 
way we will all be able to have a clear picture of what makes each version the 
most suitable to release in Stretch.

> There's little things like it still having .la files in it, and
> static libs for things that are supposedly 'plugins'.  Which aren't
> a big deal on their own to fix, but again suggests that if 'obvious'
> things like that were missed, there's a good chance there will be
> more issues than what I've already seen in a cursory review.

I don't really appreciate how you're sniping at the maintainers and uploaders 
of the version currently in experimental, while doing the job to keep up with 
recent versions of global was _your_ duty all along. What about actually 
_helping_ making this global version as good as you think it should be?

> What I'd _like_ to see a good consensus on though, is a little more
> than that - because I don't think "should we ship v6 in Stretch" is
> the right question, or rather a _sufficient_ question.  Because if
> the answer to that is "yes" - then we still have the question of
> "what should we do with htags in v6", and that's actually the one
> where things go all pear-shaped if we get it wrong.
> 
> And even if the answer to it is "no", then that question _still_
> remains as "what should we do with htags in v6 for stretch+1" ...

The question was supposed to be asked, and answered in september 2011, when 
global 6.0 was released. This question should have been answered for squeeze, 
eventually wheezy, really.

> Because people saying "it's irrelevant, uploading 'something newer'
> is overwhelmingly more important" completely misses the point that
> uploading something newer unavoidably involves someone answering
> that question.

Uploading newer versions of upstream software is constantly about compromises, 
functionality losses, and new functionalities. That's just how software 
development works, and Debian is constantly following up on the new versions 
of all sorts of software. With your approach, we'd have Gnome 2, KDE 3, 
PostgreSQL 8.4 and GCC 4.4 in stretch, just with some compatibility patches, 
because we'd have been too conservative. That's not the sort of Debian 
releases I want to see.

> And ignoring the issues around it totally leads to fun paradoxes
> like OdyX saying that one 

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Didier 'OdyX' Raboud]

With my Debian Printing Team member hat:

Le mardi, 6 décembre 2016, 10.18:23 h CET Philip Hands a écrit :
>   What is a print server? (CUPS) web server? (apache2)

The "print server" entry in tasksel should be rethought, as it nowadays only 
depends on CUPS, and recommends various helper drivers & co. If one really 
wants to setup a shared print server, they would install CUPS on a pristine 
Debian and configure CUPS from there on. If CUPS is "only" meant to be used as 
local print server, it should really be a recommends of the desktop tools 
caring about printing.

I don't really see the point anymore about having this entry in the d-i tasks 
selection; and would suggest to remove it entirely, and (eventually) add an 
entry in the Release Notes saying "if you want a print-server, install CUPS".

Btw, there's https://bugs.debian.org/824645 for which I put up a cleanup 
patch, but I can't push it. :/

OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Maintainership

[Didier 'OdyX' Raboud]

Le vendredi, 2 décembre 2016, 16.00:36 h CET Ian Jackson a écrit :
> On debian-project I posted a suggestion in respose to Zach in the
> thread about maintaintainership.  See below.

I've answered to parts of the debian-project thread.

> Do the TC think a resolution such as that below would pass ?

Frankly, I don't know.

> Supposing such a resolution were passed, would it make a practical
> difference to how you approach petitioners and maintainers ?

It would; in such that I would probably also resign, with exactly the same 
reasoning as Phil's.

Giving advice to the TC through trying to change how its members are supposed 
to think, discuss, and wheigh arguments; is paternalizing and would be a 
strong sign of misconfidence from the project. On the other hand, changing the 
repartition of powers through amending the constitution is fine for what I'm 
concerned. I supported the TC's term expiry GR, for instance. Changing the 
majority requirements would be fine too.

-- 
Cheers,
OdyX

Bug#841294: Global Ballot Thoughts

[Didier 'OdyX' Raboud]

Le mercredi, 30 novembre 2016, 14.11:43 h CET Sam Hartman a écrit :
> I'd really like to see the TC offer at least the following advice:
> 
> 1) We believe that strong evidence is required to hold back integrating
> new versions of software like global.  The burden of proof is on those
> who propose not to update, not on those who would like Debian to contain
> current upstream features.
> 
> 2) This burden has not been met with regard to htags and regressions
> related to htags.
> 
> 3) Delays in discussion of this issue over the year suggest that having
> more people involved in maintaining the global package would help
> address  a perception that the maintainer is blocking forward progress.

Absolutely. This would be a the very minimal statement I'd like us to emit. 

> I don't think I'd support giving global to someone else.

I would support handing global to new maintainers, really. We have 4 persons 
who have contributed to the newly-available package in experimental:
https://tracker.debian.org/news/820174
Their total work is a magnitude more than what was given to the package by the 
current maintainer in the last 6 years.

>  I don't think we even need to say "Ron you did something bad."  I do think
>  that Ron contributed to  a harmful perception that damages those who would
>  use and contribute to global in Debian.

I wouldn't support a decision where we state that Ron did something bad. It 
would be unneeded blaming (especially in a TC decision), and unnecessarily 
agressive.

I'd support a decision handing the package to better hands though. For me, it 
is now obvious that there exists a group of maintainers out there who would do 
better service to the maintenance of global, than is currently done.

> If we can find a path forward that gets a new global into Debian, I'd be
> happy only offering advice.  If we get stuck doing that, I think we need
> to overrule something.

Sure, absolutely. But its really also a question of timing, and allowing Ron 
to tell the TC (in direct words, through further NAK'ing, or through inaction) 
"fine, I've won another release with global v5 in, I'll let the package go 
after the release of stretch", we will have rewarded stop-energy and inertia, 
over service to our users.

Although we probably haven't reached consensus, I'd like to see this subject 
move forward; what about the following ballot (with options to be refined, of 
course):

A) Using §6.1.5, the TC offers advice (insert Sam's advice above) about the 
maintenance of src:global.
B) Using §6.1.2, the TC decides that the src:global maintainer is now (insert
 name)
C) Further discussion

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Didier 'OdyX' Raboud]

The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up 
the different outcome possibilities, which would help forming our opinions.
Not all these options are exclusive, or would need an actual TC decision.

Here we go:

A) 'global' stays maintained as it currently is.

This would imply:
 - no new 'global' upstream release before stretch,
 - no 'htags removal' warning in stretch,
 - possibility for the maintainer (and/or other interested parties) to start
   maintaining a 'global6'; this wouldn't offer any guarantee for a more
   recent version of 'global' in stretch. This would also imply having two
   'global' packages in certain suites.

B) A fresher version of 'global' is uploaded to experimental 'soon'
   (with or without interested parties' help; with or without a TC decision)

This would imply:
 - any interested party would file (and close) Debian bugs for issues and
   regressions (with appropriate severities), to make the 'fitness for a
   stable release' assessment easier, and earlier.

C) After the release of stretch, a fresher version of 'global' is uploaded to
   unstable with the explicit goal of making it available in buster.

This would imply:
 - any interested party would file (and close) Debian bugs for issues and
   regressions (with appropriate severities), to make the 'fitness for a
   stable release' assessment easier.
 - after migration to testing, this would make the fresher version of 'global'
   available for backporting to stretch-backports.
 - the version of 'global' released in stretch could carry 'htags removal'
   warnings;

D) A fresher version of 'global' is uploaded to unstable 'soon', targetting
   stretch (with or without interested parties' help; with or without a TC
   decision)

This would imply:
 - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
   in a TC vote);
 - any interested party (including the maintainer) would file (and close)
   Debian bugs for issues and regressions (with appropriate severities), to
   make the 'fitness for a stable release' assessment easier.
 - that this fresher version of 'global' would reach 'fit for release' status
   before the Stretch release.

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);

-- 
Cheers,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-11-22-16.59.html


signature.asc
Description: This is a digitally signed message part.

Re: November 2016 TC meeting is at date -d 'Tue Nov 22 17:00:00 UTC 2016'

[Didier 'OdyX' Raboud]

Le mardi, 1 novembre 2016, 12.36:54 h CET Margarita Manterola a écrit :
> The November Debian Technical Committee Meeting will happen at
> 
> date -d 'Tue Nov 22 17:00:00 UTC 2016'
> in #debian-ctte on irc.debian.org

It has now happened, and the meeting log and notes captured by the meetbot are 
available on the meetbot archive [0] and have been pushed to the TC's git 
repository. [1] I'm hereby attaching the summary.

-- 
Cheers,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-11-22-16.59.html
[1] https://anonscm.debian.org/cgit/collab-maint/debian-ctte.git
#debian-ctte Meeting



Meeting started by OdyX at 16:59:51 UTC. The full logs are available at
http://meetbot.debian.net/debian-ctte/2016/debian-ctte.2016-11-22-16.59.log.html
.



Meeting summary
---
* Next Meetings?  (OdyX, 17:01:31)

* Review of previous meetings' TODOs  (OdyX, 17:03:15)

* #841294 Maintainership of 'global' package  (OdyX, 17:05:28)

* #841294 Overrule maintainer of "global" to package a new upstream
  version  (OdyX, 17:06:39)
  * ACTION: OdyX to try summarizing this conversation (with its various
possible outcomes) as a ballot proposal during the end of this week.
(OdyX, 17:44:07)
  * ACTION: everyone getting up-to-speed with the subject :)  (OdyX,
17:44:22)

* #839570 Browserified javascript and DFSG 2 (reopening)  (OdyX,
  17:45:20)
  * ACTION: hartmans to writing closing mail for #839570  (OdyX,
17:47:31)

* #839172 TC decision regarding menu policy not reflected yet  (OdyX,
  17:47:41)

* #836127 New TC members  (OdyX, 17:48:33)
  * ACTION: marga to set timeline  (OdyX, 17:57:15)
  * ACTION: everyone building their opinions on the candidates  (OdyX,
17:57:29)

* Additional Business  (OdyX, 17:57:45)
  * ACTION: OdyX to announce the December meeting, and setup February
meeting poll.  (OdyX, 17:59:33)

Meeting ended at 17:59:51 UTC.




Action Items

* OdyX to try summarizing this conversation (with its various possible
  outcomes) as a ballot proposal during the end of this week.
* everyone getting up-to-speed with the subject :)
* hartmans to writing closing mail for #839570
* marga to set timeline
* everyone building their opinions on the candidates
* OdyX to announce the December meeting, and setup February meeting
  poll.




Action Items, by person
---
* hartmans
  * hartmans to writing closing mail for #839570
* marga
  * marga to set timeline
* OdyX
  * OdyX to try summarizing this conversation (with its various possible
outcomes) as a ballot proposal during the end of this week.
  * OdyX to announce the December meeting, and setup February meeting
poll.
* **UNASSIGNED**
  * everyone getting up-to-speed with the subject :)
  * everyone building their opinions on the candidates




People Present (lines said)
---
* OdyX (79)
* marga (34)
* hartmans (26)
* Mithrandir (24)
* keithp (18)
* fil (9)
* aba (7)
* jcristau (3)
* MeetBot (2)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


signature.asc
Description: This is a digitally signed message part.

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Didier 'OdyX' Raboud]

Hi there,

I've been mostly VAC, and only now found enough time to properly read 
through this bug log. In the interest of transparency and to help the TC 
reach a consensus (also through understanding what the other members' 
understanding, ideas and positions are), here comes my current 
understanding of the problem at hand.

As preamble, I will upfront state that I have _not_ looked in the precise 
details of the so-called 'htags' functionality, as, the rest will show, my 
current viewpoint on the problem is that it doesn't matter.

* src:global hasn't had a Debian upload since October 2010, for wheezy , 
  and no new upstream-release Debian upload since September 2007, for 
  lenny (although there was on upload yesterday)
* there was no src:global upload to experimental
* its maintainer, Ron Lee, failed to provide timely and comprehensive answers
  to various requests through bugreports over the years. On #574947
  specifically, a bug filed in March 2010, Ron's first answer in April 2013
  boiled down to "we're in freeze now, no".
* Ron claims to have had various private conversations about src:global with 
  various parties about the problems that a new upstream upgrade would pose.
* How the 'htags' functionality is implemented in newer upstream releases
  seems to be at the heart of what Ron sees as making these "unsuitable for
  release with the distro".
* There is arguably frustration on all sides of the discussion about upgrading 
  src:global to newer upstream releases, both sides arguing that they are
  doing the right thing for Debian.

Now. I'd like to write down some considerations about the Debian namespace.

Debian, as a Free Software distribution, ships various software made by 
various upstream authors, thereby filling the Debian source packages, binary 
packages, and binaries namespaces. Upstream's global_*.tar.gz is shipped as 
src:global source package, producing the 'global' binary package, shipping the 
/usr/bin/global binary [0].

The TC has had various discussions about uses and abuses of these various 
namespaces (especially the 'binary packages' and 'binaries' namespaces) in the 
past, usually in cases of conflict. Various developers also often safeguard 
the namespaces by launching discussions upon ITPs proposing too generic names. 
How we handle these namespaces of ours is certainly an important topic for the 
project. (But don't mistake me, the 'global' name isn't the problem here).

All these namespaces are also interfaces of what we as a project create, with 
the community of our users. The most important of these three is arguably the 
binary packages namespace, which is the usual interface with the software we 
ship. It has been customary to have a one-to-one mapping between upstream 
projects, and binary package names, and in all cases where we decided 
otherwise (iceweasel, cupsys, nodejs, …), it has imposed a lot of 
documentation and convincing for our users to get used to these.

All in all, I think there is a reasonable expectation from our users to have 
our namespaces match the rest of the ecosystem; there is an expectation that a 
given 'foobar' upstream, iff packaged for Debian, gets to be shipped as the 
'foobar' binary package. And I think that extends to versions as well; it is 
expected that our releases ship with 'reasonably recent' versions, as well.

(
 I know, Debian stable releases aren't known for the freshness of their
 packages. There's still an expectation from our users
)

Outside of special times with regards to releases (that is, outside frozen 
times), it is quite customary for packages to 'catch back' on new upstream 
releases. This has multiple effects: it prepares the new _functionalities_, 
and bug fixes for the next stable release; it also often comes with 
regressions and new bugs; annoyances and headaches for users and maintainers 
alike. Uploading new upstream releases and letting them be consumed by a 
portion of our userbase (unstable & testing users), is a way to share the 
burden, and _discover_ what those regressions and bugs are; identify, then try 
to fix or document these.

As you have understood by now, I think it is a reasonable expectation from 
package users to get new upstream releases between stable releases. The 
upstream software evolves independently of Debian, and if we're not forking 
the upstream software, we owe updates to our users as part of our "package
maintainers" duty. It's also our role to ship the newer works of our upstreams 
to our users. (To clarify: I'm not saying there can't be exceptions.)

Now, coming back to src:global, there was a first request in March 2010 
(#574947, 5.8.1) to get a new upstream release, before the squeeze freeze, 
only answered late during the wheezy freeze (at that time, 6.2.8 was 
released). The other request (#816924, 6.5.2) landed in March 2016, 9 months 
before the stretch release. For me, it looks like the squeeze, jessie _and_ 
stretch release cycles have 

TC overriding delegates' decisions

[Didier 'OdyX' Raboud]

Dear secretary,
(CC'ing FTP Master and TC for information)

The TC has recently been running in circles with different considerations 
about its possibility to override delegate's decisions. I'm therefore hereby 
requesting an interpretation of the constitution on the following questions:

* Generally, can the Technical Committee override delegates' decisions?
  - How does the last sentence in §2 [0] apply?
  - Would it then do it under §6.1.2 (simple majority) or §6.1.4
(3:1 majority)?
  - Is this only possible for "The Developers by way of GR" through §4.1.3 ?

* Specifically, given the current delegation of the FTP Masters [1], assuming a 
decision about non-suitability for the 'main' suite for a specific package 
according to their interpretation of the DFSG, could the TC override their 
decision to let the package enter 'main' nevertheless?

* In general, given the FTP Masters current delegation and the constitution, 
which of the 'Developers by way of GR' or the FTP Masters have the powers to 
decide about suitability for 'main' (aka 'DFSG interpretation') ?
[Feel free to leave this eminently political and complicated question 
unanswered for now; I suspect the answer might be 'it is currently undefined'; 
in which case we could have a larger debate in the community.]

For the avoidance of doubt: It is very unlikely we will be overriding the FTP 
Masters in #839570, but the question keeps popping up and having it resolved 
one way or the other would help reduce the amount of noise in the discussion.

-- 
Cheers,
OdyX

[0] "In the list above, a person or body is usually listed before any people 
or bodies whose decisions they can overrule or who they (help) appoint - but 
not everyone listed earlier can overrule everyone listed later." (where the TC 
is listed before Delegates)
[1] https://lists.debian.org/<20121017091648.ga32...@upsilon.cc>

signature.asc
Description: This is a digitally signed message part.