Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[Gunnar Wolf]

[ I am not part of the Technical Committee anymore, am answering just
  as a DD ]

debbug.tech-c...@sideload.33mail.com dijo [Mon, Mar 11, 2024 at 02:37:45PM 
+0100]:
> # The DSC needs to become meaningful
> 
> Chuck Zmudzinski filed a bug report saying that the Debian Social
> Contract (DSC) is “meaningless”:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028557
> 
> He is correct in the sense that there is no enforcement mechanism. At
> the same time, the Debian Constitution (DC) also neglects to
> acknowledge jurisdiction over DSC enforcement. This is a bug. I think
> it’s assumed that the technical committee is tasked with DSC
> enforcement. But this should be explicit and without guesswork.
> 
> Is the DSC a guaranteed protection whereby non-compliances have a
> complaint mechanism and corrective procedure?  Or is the DSC actually
> intended to be comparable to a meaningless pushover license?

No, the TC does not go around with a stick chasing violators of the
Social Contract. The SC is upheld by each individual Debian
contributor. Particularly, the Debian Developers have signed a
statement to follow this document when volunteering work for the
project. It is up to us all, as a group, to uphold it.

> (...)
> Problems in the DSC and calls for improvement thereof should itself be
> a transparent process. It was unclear to me where to submit this bug
> herein: tech-ctte, qa.debian.org, or general?

If you need to discuss this kind of documents, the right venue would
be the debian-proj...@lists.debian.org list. However, please modulate
a bit your tone, as this message feels to fall a bit towards
aggressive writing; you will find better echo if you approach trying
to understand instead of demanding action.

> The DSC shows “Version 1.2 ratified on October 1st, 2022.” But where
> and how?  The public should have transparent access to the
> discussions, decisions, and changes.

Debian is not a government, but a volunteer project. "The public" has
no rights: We have a committment to which we all (Developers) adhere
to. "We will not hide problems", of course, but if you want something
to change, please try pointing at specific issues that were not
handled correctly --- and for which the incorrect handling was done
purposefully so (i.e. hiding problems); we have more than once found
that we are stuck in a loophole we are unable to properly fix, and
cannot enforce our golden standard (i.e. the declassification of the
debian-private mailing list, that was supposed to happen for ~10
years, until we decided via an open discussion and vote that it just
was not be possible to do correctly.

> # DSC change proposal: make documentation accessible to ALL people
> 
> There is a growing problem of documentation being locked into walled
> gardens which discriminate against several demographics of people,
> such as blind people being forced to solve a CAPTCHA that requires
> vision. The access-restricted documentation problem is particularly
> rampant on the Linux Mint and (ironically) Ubuntu projects. Debian
> does not proactively impose any walled gardens on people at the moment
> but whenever a package makes reference to external documentation
> served from an access-restricted location, Debian passively allows
> this. Debian can (and should) do better than this. The problem and
> proposal is described in detail here:
> 
>   * https://linux.community/post/649372
>   * 
> https://kbin.social/m/debian/t/889598/Debian-Social-Contract-Should-all-Debian-users-inclusively-have-open
> 
> Those two links ↑ give two different views of the same article. I
> reference both because of a minor formatting bug in kbin.

The point you raise is interesting and worth discussing, although I
believe it would place too much of a burden on maintainers. But I feel
it is orthogonal to the main issue discussed.

Besides that, I completely agree with Christoph, in order for a
discussion to be taken seriously, I strongly recommend you to disclose
your name and a real address, and not do it from an unknown,
mission-specific sender.

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Gunnar Wolf]

Bastian Blank dijo [Thu, May 18, 2023 at 09:05:44PM +0200]:
> But why does the state of the package (native vs non-native) can have
> any effect on a CTTE decision?  Or do you want to say I can block CTTE
> from reaching any kind of decision just by uploading a package as
> native?  Sorry, but this does not compute.
> (...)
> Sure, but this is a direct violation of a CTTE decision.  How often do
> you think someone could do that?

During my time as a Technical Committe member, /usr-merge was the
point we most came back to. And yes, the way the TC decisions were
dodged or omitted by the dpkg maintainers was... quite depressing.

However, my reply should only be read regarding what I believe should
be done in the following ~month before the release.

Of course, I don't see the situation as ideal, nor as something that
should persist. I hope a _fixed_ dpkg is uploaded and becomes part of
Bookworm's first point release.

But, even if it were on the table (which is not AFAICT), I would (in a
strictly personal capacity) oppose the TC requiring such a patch at
this point.

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Gunnar Wolf]

Ansgar dijo [Thu, May 18, 2023 at 07:55:03PM +0200]:
> Why not?
> 
> Do you think the implications of removing the warning are unclear?
> 
> Do you think we need to explore alternative solutions?

(I am no longer part of the Committee, answering just as another
developer)

dpkg has many bits that make it special. It has been discussed whethe
dpkg should be a native package or it should become non-native; if it
were non-native, having a patch that contradicts the upstream author's
wishes would be easier (and I'm not saying that I'd be up for patching
this warning out as it is).

If we were to force a patch silencing out this warning right now and
for all of the Bookworm cycle, and the dpkg authors disagree with it,
they could remove (even omit to include it) in any updates. Upstream
has repeatedly expressed their opposition to the way usrmerge has been
brought forward, and the warning silenced specifically for Debian is
already the best compromise situation we have been able to reach --
even though we are aware the situation is far from ideal.

Re: December meeting

[Gunnar Wolf]

Sean Whitton dijo [Thu, Dec 08, 2022 at 03:15:08PM -0700]:
> Hello,
> 
> Our only agenda item is following up on Christoph's action item.
> 
> So how about this:
> 
> - if a bug is filed in the meantime, we'll meet at 6:30pm on the 20th
> 
> - if nothing comes up, we'll not meet until January, at which point we
>   can have a Jitsi session including Gunnar and Niko to say goodbye and
>   thanks, and to welcome Matthew, should the DPL agree with our vote.

Works For Me™. That way we can hopefully have one last meeting with 8
members, until two more are found and appointed! 


signature.asc
Description: PGP signature

Re: December meeting

[Gunnar Wolf]

Sean Whitton dijo [Mon, Dec 05, 2022 at 05:10:39PM -0700]:
> Hello,
> 
> We are scheduled to meet next Tuesday, but I'm not available.  We could
> either have someone else chair, or push it forward one week -- there's
> nothing urgent.  Is anyone not available at 6pm UTC on the 20th?

Hi,

I will be on vacations by December 20 -- but I don't want to be a
blocker, so please schedule the meeting regardless of me; after all,
I'm on my way out already  And we can still thank and virtual-hug
each other in fora other than meetings.

Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett

[Gunnar Wolf]

Sean Whitton dijo [Fri, Nov 25, 2022 at 03:39:12PM -0700]:
> Package: tech-ctte
> X-debbugs-cc: mj...@debian.org, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Matthew Garrett  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Matthew Garrett 
> F: Further Discussion
> ===END

My vote is:

H > F

Thanks Sean!


signature.asc
Description: PGP signature

Re: Missed chair election

[Gunnar Wolf]

Hello Sean,

Sean Whitton dijo [Thu, Oct 13, 2022 at 08:27:06AM -0700]:
> Hello,
> 
> I just realised that according to convention I was meant to start a vote
> on the TC chair when Elana's resignation took effect.  Looks like no-one
> noticed this until now.  A vote would definitely have made sense in
> August, but now it's not so long before the usual vote in January.
> 
> We could do a vote now, or we could leave it until January, unless there
> is a controversial bug filed between now and then.  In that case we
> could easily do a chair vote before voting on the bug.  The thought
> would be that the casting vote could become relevant in that situation.

AIUI, it is *customary* for the TC Chair to step down when there is
any change in the TC composition, but it is not *required*. I don't
think you are overstepping by staying Chair.

Given nobody has asked for a change, that you were reelected by
unanimity, and that we are very close to the end of our terms, I do
not think there is much point in re-appointing you just to repeat the
exercise in less than three months.

- Gunnar.


signature.asc
Description: PGP signature

Bug#1020923: tech-ctte: please clarify if atomic updates are required

[Gunnar Wolf]

Hi Ansgar,

Ansgar dijo [Wed, Sep 28, 2022 at 10:18:26PM +0200]:
> Any package relevant for successful boot. Any upgrade.
> 
> As far as I can tell, the submitter requires some guarantees
> significantly stronger than what Debian requires for essential
> packages.
> 
> In particular, boot-relevant packages are demanded to work in
> unconfigured state, with not fully satisfied dependencies (possibly not
> even unpackaged?), in partly unpackaged states, after maintainer script
> errors, and all of that in combination with system crashes that might
> result in partly written data to filesystems. And possibly in other
> interesting system states too.

Humm, as the maintainer for raspi-firmware, this definitively
addresses an area where I'm responsible. So this is naturally
interesting for me even outside my TC role.

There is a point I somewhat agree with Bug#1020920's submitter:
Packages modifying the packages involved in system boot need to be
extra careful to reduce the window of vulnerability for an unbootable
system as much as possible.

However, no matter how careful we are, I do not think it's expectable
that we can guarantee the atomic interaction mode Zack W. suggests —
There is no syscall matching "rename and create a symlink". And even
if we had one, it would most probably still become two separate
filesystem operations in the end. Of course, the supported
filesystems' code could be modified so that said operation sequence
could be added to the journal beforehand, so they can be effectively
considered as atomic, but...

That's quite an unrealistic expectation. We cannot expect to implement
actions not expressable in the set of primitives Linux exposes to
us. We cannot expect a (quite invasive I'd expect) kernel patch to be
applied just because we want to run usrmerge.

> > (2) The TC is a decision-making body of last resort.  The bug you
> >     mention was filed today.  Might this be premature?
> 
> Well, if we close it or don't act on it, people will complain and/or
> demand to remove us from Debian for not acting on it (the latter might
> be limited to people just sitting on their porch).
> 
> The other tech-ctte bug about usrmerge also suggested it would just end
> up here either way.

There is a high chance we might end up getting this bug in the TC,
given the spirits we have seen around merged-/usr. However, I agree
with Sean: This bug is too early to summon the TC.

I know that if I suggest you to bring the issue to d-devel@l.d.o it
will fuel a flamewar, but I see no other proper way to handle _this
particular mail_. Maybe the request could be phrased differently, in a
way it could encompass this bug report (i.e. "ask the TC whether we
might use sloppy techniques when upgrading, considering the risks we
take as acceptable" (of course, I don't mean your job is sloppy, it's
just an example text that will not be accepted if asked )

So... I'm also inclined to ask you to please close this TC bug, as it
is not acceptable for a TC ruling. (Also, how many rulings does it
make sense for the TC to hold on the same tired topic of merged-/usr?)

Greetings,

- Gunnar.


signature.asc
Description: PGP signature

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Gunnar Wolf]

Christoph Berg dijo [Tue, Sep 27, 2022 at 10:23:32PM +0200]:
> Re: Sean Whitton
> > Therefore, we will likely just close this bug, I'm afraid.
> 
> +1 on closing from me.

I agree this bug should be closed. I won't comment more, as there is
not much more to add without going in circles back to
already-discussed issues.


signature.asc
Description: PGP signature

Re: Is a different opinion about a license a case for the ctte?

[Gunnar Wolf]

Sam Hartman dijo [Tue, Aug 02, 2022 at 09:17:57AM -0600]:
>  
>  TL;DR: you don't have any recourse that is appropriate for this
>  situation.
>  All the hammers are bigger than your nail.

Well, hammers usually _are_ bigger than nails, otherwise... ;-)

But anyways...

>  The secretary ruled that the CT cannover overrule a delegate acting in
>  their delegated responsibility,
>  so no the CT cannot overrule ftpmaster.

Thanks for bringing this ruling up, Sam. Usually we do feel required
to answer to any questions brought up to us, although we have often
"decided not to take action" (or decided not to rule, but explicitly)
in the past.

>  The CT could give advice to ftpmaster, especially if ftpmaster requested
>  that advice.
>  I'd expect the CT would be reluctant to give non-technical advice.
>
>  The CT could set *technical policy* and I'd expect delegates would
>  generally be expected to follow reasonable technical policy established
>  by the CT or be accountable to the DPL and membership at large.
>  However, I don't really think that license standards are technical
>  enough to be technical policy.
>
>  ftpmaster could establish an appeals procedure.

Yes, that was more or less my line of thought upon first reading
Andreas' mail. I do not think licensing advice is the kind of advice
the TC is supposed to give. We do have a delegated body whose
authority is acknowledged by the whole project. And although we could
advice them to act differently, they can decide to ignore our
advice. So, if a licensing disagreement came up, the only real
resource IMO would be a GR. And I feel that would be too much for the
simple case you are presenting here.

Greetings,

Please help reschedule the Technical Committee talk

[Gunnar Wolf]

Hello, dear Content Team!

We are in a tech-ctte meeting right now. We are scheduled to have our
BoF on July 18, 14:00. However, two of the tech-ctte members will be
participting remotely, from the East coast of the USA. That means the
talk is scheduled too early.

Is it possible for you to reschedule our session to a later timeslot?

Thank you very much!


signature.asc
Description: PGP signature

Re: Next meeting -- 14th June, 6pm UTC

[Gunnar Wolf]

Niko Tyni dijo [Mon, Jun 13, 2022 at 10:46:30PM +0300]:
> > Our monthly meeting is scheduled for Tuesday 14th at 6pm UTC.  Agenda:
> 
> > People with AIs: Elana, Niko, Matthew, me
> 
> First draft for a d-d-a bits mail pushed to git.  Please fix any mistakes
> and clumsy wordings.

Thank you very much, Niko (and Elana, Myon and Matthew, who have fixed
from minor typos to clarity issues). I find the text clear and easy to
read -- and even correct! ;-)

> I ran out of steam and didn't manage a summary for #994388 . Sorry.

Uff, that's a tough one. Well, you managed to write two paragraphs
that do sum up the issue; the further issue that unfolded after the
bug was voted and closed is... *sigh* yes, steam-outting :-( I think
completely covering this one would make this into "long long ints from
the tech-ctte" :-\

Bug#1007717: Ballot and call for votes

[Gunnar Wolf]

Hello,

Sean Whitton dijo [Mon, Jun 20, 2022 at 05:31:16PM -0700]:
> Hello,
> 
> I hereby call for votes on the following resolution:
> 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

My vote is:

A > C > X > N

Thanks!


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Gunnar Wolf]

Thank you very much for drafting the ballot, Matthew!

Matthew Vernon dijo [Wed, Apr 20, 2022 at 03:31:13PM +0100]:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
> 
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
> 
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N

Thanks!


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Gunnar Wolf]

Thanks for drafting this, Matthew!

I have a small suggestion here:

Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:
> Backwards-compatibility (and the lack of a compelling argument that
> util-linux's rename is significantly superior to the perl rename) means that
> /usr/bin/rename in Debian should remain the perl rename.

I'd prefer to read "that neither 'rename' implementation is superior
to the other", maybe even explaining that "they were designed out of
different needs and meet different criteria".

> The Technical Committee resolves that util-linux's rename should be shipped
> in a binary package build from src:util-linux. If this package Conflicts
 ^built

> Matthew
> ps; my first TC resolution, please be gentle if I have the procedure wrong!

Thanks again!

Re: Next meeting -- one week early, 5th April @ 7pm UTC

[Gunnar Wolf]

Sean Whitton dijo [Tue, Mar 29, 2022 at 01:11:01PM -0700]:
> > Due to both the current interpersonal situation and the impeding
> > DebConf22 CfP, can we have our meeting a week early?  Please let me know
> > if you can't.
> 
> I think I'm the only person who is somewhere that doesn't observe DST,
> so we should move it to 6pm UTC, right, going forward?

I already confirmed on IRC, but just to have it in the mail archive: I
cannot make it at 19:00UTC. 18:00 is much better.

Thanks!

Bug#994388: dpkg currently warning about merged-usr systems

[Gunnar Wolf]

Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> I am part of that group, and that is definitely _not_ why I wouldn't
> touch dpkg with a barge pole as things stand (and have stood for
> years). You are making a gigantic leap with that assumption, not sure
> what you base it on. As a downstream and upstream maintainer in several
> large projects I fix things that don't impact me all the time, all over
> the place.
> 
> But anyway, it turns out it's all moot because - drum roll - there is a
> patch:
> 
> https://0x0.st/oNFG.diff
> 
> This was shared just now on #debian-devel IRC by user 'uau', linked
> here with explicit permission.
> 
> So it looks like you, Russ and others who chimed in this thread should
> now be in a position to test your theory that a missing patch was the
> only issue. Care to take it forward?

Wow, this is a positive turn of events! Do you happen to have more
information as to the identity of the submitter? We should be able of
properly granting attribution...

The patch seems sane from a first, very much 1m-point-of-view. Of
course, it is very situation-specific and not generalized for
following any unexpected symlinks in the directory hierarchy, but I do
not expect that to be an issue (as we are talking about a very
specific migration here). I am absolutely unfamiliar with dpkg
internals and there are some bits that jump to my eye, but I do not
think there is much use in me discussing very-minor things that should
be obvious to people who are actually involved with dpkg.

Has this diff been shared with Guillem, or included in any relevant
bug report?


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Gunnar Wolf]

Russ Allbery dijo [Thu, Mar 24, 2022 at 04:50:44PM -0700]:
> > I think it's appropriate for people to wait on such work until there's
> > guidance from the TC ensuring that such a patch will be accepted.
> > Otherwise, anyone spending time writing it is spending substantial
> > effort that may well be wasted.
> 
> I think this is a totally fair thing to be concerned about.  Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision.  Of course, I'm not a TC
> member.

I have informally talked with some other TC members; I am a TC member,
but am writing just as an individual DD.

You have said the TC has ruled to make an NMU in the past. I doubt an
NMU would fly -- The dpkg maintainer does not want to engage with the
TC, and I believe odds are high we could end up playing NMU
ping-pong. That's not in the best interests of our users nor the
project.

However, TTBOMK, no patches have been proposed. However, even given
his attitude, I trust he would apply a correctly done patch addressing
the issue at hand.

> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.

Precisely. We cannot mandate a patch to be written. We can (and I _do_
think we should) require the maintainer to remove this warning -- not
because it is false, but because torpedoing trust in the project is
not the right course of action.

> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it.  Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground.  But design of that patch is
> *not* within the TC's constitutional mandate.
> 
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
> 
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.

Completely agree here.

Bug#1004611: Resignation & call for votes to elect the Chair

[Gunnar Wolf]

Sean Whitton dijo [Sun, Jan 30, 2022 at 02:10:08PM -0700]:
> ===BEGIN
> 
> A: Christoph Berg 
> B: Helmut Grohne 
> C: Elana Hashman 
> D: Simon McVittie 
> E: Niko Tyni 
> F: Matthew Vernon 
> G: Sean Whitton 
> H: Gunnar Wolf 
> 
> ===END

My vote is:

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


signature.asc
Description: PGP signature

Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jan 14, 2022 at 11:55:17AM -0700]:
> Package: tech-ctte
> X-debbugs-cc: hel...@subdivi.de, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Helmut Grohne  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Helmut Grohne 
> F: Further Discussion
> ===END

I vote:

H > F

Thanks!


signature.asc
Description: PGP signature

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Gunnar Wolf]

Thank you very much for starting this vote, Sean.

I vote A > B > F.

> > === Resolution A ===
> >
> > The Technical Committee resolves:
> >
> > 1. The debianutils package must continue to provide the which(1) program
> >until a compatible utility is available in a package that is at least
> >transitively essential in Debian 12.
> >
> >For the Debian 12 release, we expect which(1) to be in either an
> >Essential package or a transitively Essential package (that is, a
> >package that is depended on by an Essential package).
> >
> > 2. The which(1) program must not print any deprecation warnings.
> >
> > 3. We decline to overrule the maintainer of debianutils regarding the
> >use of alternatives.  If another package takes over responsibility
> >for which(1), then the debianutils maintainers and the other
> >package's maintainers should coordinate to choose a suitable
> >mechanism, which might be either versioned Depends/Breaks/Replaces,
> >dpkg-divert, alternatives or something else.
> >
> > 4. The debianutils package must continue to provide the tempfile(1)
> >program until a compatible utility is available in a package that is
> >at least transitively essential in Debian 12.
> >
> >For the Debian 12 release, we expect tempfile(1) to be in either an
> >Essential package or a transitively Essential package.
> >
> > 5. Programs in debianutils must not be moved to /usr until we have a
> >project-wide consensus on going ahead with such a move, and any
> >programs that have already been moved must be moved back.  In
> >particular, this means debianutils must contain /bin/run-parts and
> >/sbin/installkernel for the time being.
> >
> > === Resolution B ===
> >
> > As Resolution A, except strike point (2) and renumber succeeding items.
> >
> > === End Resolutions ===
> >
> > A: Issue Resolution A
> > B: Issue Resolution B
> > F: Further Discussion
> 
> I vote:
> 
> A > B > F



-- 



signature.asc
Description: PGP signature

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Gunnar Wolf]

Simon McVittie dijo [Wed, Oct 13, 2021 at 08:13:08PM +0100]:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

My vote on the text quoted below is:

yes > further discussion

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between 

Bug#985270: Resignation + Call for votes for new Chair

[Gunnar Wolf]

Margarita Manterola dijo [Mon, Mar 15, 2021 at 10:30:59AM +0100]:
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
>  A : Margarita Manterola
>  B : David Bremner
>  C : Niko Tyni
>  D : Gunnar Wolf
>  E : Simon McVittie
>  F : Sean Whitton
>  G : Elana Hashman
>  H : Christoph Berg
> 
> ===END===

My vote is:

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

Thanks!


signature.asc
Description: PGP signature

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Feb 17, 2021 at 12:45:05PM -0600]:
> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

I vote:

A > B


signature.asc
Description: PGP signature

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Gunnar Wolf]

Package: tech-ctte
Severity: normal

Given that Philip Hands' term in the Technical Committee finished in
December, I want first of all to thank him on behalf ot the rest of
the Committee members for his good work during the term, and call for
votes to accept a new TC member.

So, voting will begin now, and end when the outcome is no longer in
doubt, or one week from now.

===BEGIN

The Technical Committee recommends that Christoph Berg  be
appointed by the Debian Project Leader to the Technical Committee.

A: Recommend to appoint Christoph Berg 
B: Further Discussion

===END


signature.asc
Description: PGP signature

Bug#978636: move to merged-usr-only?

[Gunnar Wolf]

Gunnar Wolf dijo [Sun, Jan 31, 2021 at 03:32:02PM -0600]:
> My vote is:
> 
> Y > F > N


...And to be clear: We at the TC are *not* doing detailed design
work. But I want to state (and not as part of the vote, but just as
yet another DD) that the only way I feel makes sense to continue now
is via Simon's ① option: Symlinking /bin → /usr/bin, /lib → /usr/lib,
/sbin → /usr/sbin, etc.

That will allow us to take a step later on to mandate packages not
shipping files in the no-longer-root-level-directories, but that
should be at least one further release cycle down the lane.


signature.asc
Description: PGP signature

Bug#978636: move to merged-usr-only?

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jan 25, 2021 at 11:45:55AM -0700]:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
> 
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
> 
> We do not recommend any particular implementation of the migration.
> 
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

My vote is:

Y > F > N


signature.asc
Description: PGP signature

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Gunnar Wolf]

Sandro Tosi dijo [Tue, Jan 26, 2021 at 08:47:22PM -0500]:
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time; it's a two-sided coin: it can prevent heated
> exchanges, but it can also leave a sour taste in the petitioner's
> mouth.
> 
> While i would tend to agree that it's slightly unfair, i've never been
> on the other side to judge it fully.

While we discussed the 2016/002¹ and 2016/004² GRs, about the
declassification of debian/private, we discussed the argument that any
group of people (and, certainly, any group of Debian developers) could
set up a private communication channel.

  ¹ https://www.debian.org/vote/2016/vote_002
  ² https://www.debian.org/vote/2016/vote_004

We do, yes, maintain some private communication while working
officially as the Technical Committee - and it's a known fact. We try
to maintain as little as possible contact with maintainers that are
part of a dispute... But sometimes, it's the only way to move
forward.

We have to acknowledge not all DDs have the same personal
skills. Disputes are draining for everybody, but some people might
find it even harder. Engaging directly with a person with whom you
already have a story of tension is something mnay people will do their
best to avoid.

So, yes, sometimes we will use private communications, and try to
serve as a channel between the parts through which the essence of the
communication, without the thorns and the pain, can better flow.

Of course, there is a committment that we will share the fact this
communication took place, and we will communicate the contents to the
community at large.


signature.asc
Description: PGP signature

Bug#978636: move to merged-usr-only?

[Gunnar Wolf]

Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]:
> On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote:
> > Also, as is has been discussed, if the /usr/doc/ transition was 
> > representative then this would probably take many years.
> 
> You keep using that as an argument. I think it's very disinginuous to
> point to a problem Debian had over 20 years ago[1] and say "look, we
> don't know how to do this quickly". It's not like things haven't changed
> since.
> 
> We can (and should, IMO) declare *today* that for bookworm, shipping
> files in / (as opposed to /usr) that are not compatibility symlinks will
> be RC.
> 
> You can start writing a lintian check today for the same.

I agree with you, and I think that once this TC issue/vote is settled
(which I expect to lean towards "yes", with Simon's option #1 — But I
have been surprised before more than once ;-) ), we should take steps
such as a GR to make what you suggest be enforced for Bookworm.

Keep in mind, though, that we have _many_ packages that are not
rebuilt even once per stable cycle. Many of them are not even in the
general awareness of their maintainers (or are just RC). If they
become insta-buggy, we will have to take massive action on them
(which... well, can of course be positive if we can clean them up from
many other inherited bits of cruft!)



signature.asc
Description: PGP signature

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Gunnar Wolf]

Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:
> > If you intend the scope of this bug to involve overruling maintainers'
> > decisions in packages other than NM, what other packages/bugs did you
> > have in mind? Is it just udisks2/#923387, or are there more?
> 
> I understand (but I don't think it has been explicitly stated) that the TC
> is going to decline to overrule on the question of init scripts?[0] I'm
> going to beg that question for the rest of this mail, but obviously if I'm
> wrong that will increase the scope somewhat.

I cannot say we will always decline to overrule. But -talking just for
myself, not for the whole TC- overruling a maintainer on
_anything_ is something that I really really really prefer not to
do. I understand the TC is summoned often as a last-resort decision
making body. But forcing a maintainer to do something they are against
in their own package is too harsh -- And demotivating. A maintainer
forced to go against their best decision on an a matter important to
them (otherwise the issue would not get to the TC) is very much more
likely to lose interest in keeping up the maintenance, or even their
participation in the project. 

> Please overrule the maintainer in #923387 so that it is can be used on
> systems with elogind; it has been tested and shown to work thus as well as
> being supported by upstream[1].

As it was mentioned on a previous mail to this thread, this discussion
on including an elogind dependency was done WRT network-manager. An
agreeable solution was brought forward by the maintainer. #923387
(udisks2) was just mentioned in this discussion. Maybe an amicable
solution can be tried before asking the TC outright to overrule the
maintainer?

> Mark tells us that there are not currently any other packages which could be
> used with elogind were it not for an incorrect dependency on libpam-systemd,
> so I hope we don't need to worry about the broader question any further.

Given the arguments are prone to be very similar, and the issue itself
will unfold in a similar fashion, can we try to have a different
process? One that does not bring so much heat? I hope a very similar
resolution can be had for #923387 - without needing a six-week-long discussion.

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

[Gunnar Wolf]

Hello world,

When we had our last tech-ctte meeting, 2020.10.21¹, I volunteered to
write up a summary of our positions regarding this bug. Then... Well,
life happened, and I have not had the time to sit down and write until
today -- A couple of hours before our next meeting. Several other
discussions have happened as well, most notably, the article by
Jonathan Corbet on this issue in LWN².

¹ http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-10-21-17.58.html
  
http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-10-21-17.58.log.html
² https://lwn.net/Articles/835599/

# Vendoring: Impedance mismatch with our long-established
# practices/traditions
##

I believe the issue of vendoring to be central to the discussion of
what Debian is, and what its role should be. We are very lucky to have
proponents of both sides of this issue in the Committee, and I'll try
to keep my ideas as centered as possible (of course, disclaimer: I do
hold a position, I really do not like vendoring; we have the luck of
having Elana in the ctte, as she is a developer of the affected
package, and Sean, who is a Debian Policy editor).

Elana started off with a very important and true point:

Elana>
I think this bug was sort of inevitable. Debian policy cruft is
clashing with how people actually build and distribute software
these days. we have an appeal to override a maintainer on the
basis of "policy" and the "Debian way being superior" without any
real technical examination of the merits of "the Debian way"

We are quite far from 1996, yes, and many languages have for a long
time delivered their own packaging systems, "freeing" the users from
the need of installing a myriad of little packages, and "freeing" the
distribution caregivers (and I don't only mean the developers, but
also the ftp-masters) and infrastructure from carrying this myriad of
little packages.

Elana and Sean seem to share the thought that each language ecosystem
could work with somewhat different rules:

Sean>
It might be reasonable to vendor like mad for something written in
Go but not for something written in Haskell, say

Elana>
Debian policy is specifically built around the distribution and
execution of dynamically linked C/C++ applications and
libraries. distros in general were. but modern software above that
base does not necessarily operate under the same assumptions and
it is silly to apply policy that was designed for applications
that are dynamically linked against programs that are statically
linked and are impossible to dynamically link

Simon mentioned that "our identity should be about shipping
high-quality packages, whatever that means", and mentioning that "our
packaging policy is designed for medium-sized packages", refereed back
to the discussions had long time ago over tiny Javascript snippets
packaged as packages, back in the starting days of the nodejs growth.

# DFSG-freeness checking
##

Sean and I shared the concern that excessive vendoring (say, having
tens to hundreds of libraries shipped as part of a single package)
place a very heavy burden on our ftp-masters when checking
DFSG-freeness; coupling this with the rapid change rate that
"new-wave" software development usually has, if adding / dropping
dependencies from already packaged software is usual practice,
DFSG-checks would not just have to be made in NEW, but as a continuous
process. Far from sustainable, and impossible to do by our ftp-master
team practices.

# Security issues
###

The issue of security support was also mentioned: If many packages
start shipping tens or hundreds of vendored libraries, how can we
ensure security support? This has long been a pride point for Debian
and, in general, for the Linux distributions model. We package
independent libraries, dynamically link them, and security supports
"just happens" for the users. Now, what happens in languages as Go or
Rust, where linking is done statically? They would have to be at least
recompiled when any of their constitutive libraries is updated. But
what if the libraries are vendored-in? Security issues are prone to be
hidden from our sight.

I'm pasting here a bit of the discussion that happened later during
the meeting: having this discussion K8S-specific, Elana mentioned that
"that is a big part of the tension. sometimes, you have an upstream
where the authors are less resourced and responsive than the
downstream. this case is almost certainly the opposite".

At this point, we found some friction as to _what_ we are discussing
on: Is this bug specifically on Kubernetes, which should be taken as a
special case? Or would we try to rule as the Technical Committee on
vendoring in general in the Debian ecosystem? Elana repeated her
assurance that the Kubernetes team is thorough in their
freeness-checking and security practices; I insisted on "not
discussing about K8S, but about a bundling practice to which K8S

Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Gunnar Wolf]

Michael Biebl dijo [Wed, Oct 07, 2020 at 09:53:06PM +0200]:
> Forwarding this to the CTTE, just in case they have some input on this
> proposed plan.
> (...)
> A small update here:
> v246 provides a build switch -Dstandalone-binaries=true:
> (...)
> Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
> Those binaries do not link against libsystemd-shared and have minimal
> dependencies.
> (...)
> I like this approach and think we should do the same in Debian.
> Users, which have the full systemd package installed don't have any
> negative side effects, which could result from splitting out
> systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
> 
> Restricted/non-systemd environments, like containers, can use
> systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
> dependencies.
> (...)
> If there are no objections to this approach I would proceed and
> implement it like this:
> - Build systemd with -Dstandalone-binaries=true
> - Install the standalone binaries in binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles
> - Those binaries packages would only ship /bin/systemd-sysusers resp.
> /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd

This seems like a good solution for the issue in question, and does
not seem to have any ill effects. So, yes, I'd say go for it!

Regarding Wouter's point (having systemd Provide:
systemd-standalone-sysusers, systemd-standalone-tmpfiles), it looks
sensible, but it might break down in the future if many more such
cases are spotted. But, at least for now, it does make sense.


signature.asc
Description: PGP signature

Pad from the DebConf20 session

[Gunnar Wolf]

Hello,

I am "storing" here a copy/dump of the Etherpad we scribbled on during
our DebConf20 session. I am doing nothing but to copy + send the text
expor there; in case you find it useful to see what person wrote what,
I am attaching the exported HTML - It does not have the people's names
(only internal tags to colors), but it helps find which blocks are
written by distinct people.

And, in case you want a clearer attribution, you can still refer to:

https://pad.online.debconf.org/p/16-meet-the-technical-committee

But be aware, it will disappear at some point. Oh, and for
completeness sake, the video is available at:


https://meetings-archive.debian.net/pub/debian-meetings/2020/DebConf20/16-meet-the-technical-committee.webm

It was a good and productive session IMO, but now we should do
something more.

What, how, when? Well... We all have to push for it :-|



Private discussion
(ehashman to introduce)
Proposal 1: let developers raise issues privately to the TC when they feel that 
they need advice or help in dealing with a hairy issue. Issues that need a 
public vote would still need to be raised and discussed in public, but issues 
that would lead to a "no-decision" decision, can reach a more friendly 
resolution this way. This proposal implies having a documented way of raising 
an issue privately and a set of expectations of what happens when this action 
is taken.

Sometimes you just need to hash out things in private. It can be particularly 
benefitial for issues that can be contentious. It could be a good option to 
defuse conflict.

OdyX: to some extent (at least in the [recent] past), the TC already discussed 
_some_ things in private (such as potential nominations); mostly because it's 
unreasonable to do it completely in public.
gwolf adds: it is known that the TC has a private list/alias, that it uses. "We 
have learned that private discussions are not as bad as we thought they were".

But, can somebody come with an issue to the committee _on record_ and that 
conversation being private? Of course, details on the procedure still have to 
be discussed... -> Not right now.

marga: We have a private mailing list, but it is _not meant_ to be used for 
discussion (only for minor things, such as wording)

Q: What are the issues needing a public vote?
A: When constitutional powers other than providing advice are to be invoked.
Then such private communication looks like the discretion of the people who 
happen to be members of the TC. Who are we to forbid that? :)

It should be possible for people to ask whether we would overrule or not 
without it becoming public.

We could say constructive things both publicly and privately.

"I think that the TC should formally announce that it can do informal chats 
too, and that such informal chats are not a substitute for formal 
announcements, and that'd be great." (asheesh).

Elana: Many of these discussions will end up showing conflicts between what the 
constitution says, what best practices are, and what happens in reality...

Sean: If we're not going to make this change let's be clear about why the TC is 
so significantly different from every other team that has to handle conflict 
resolution.  I don't think, as a project, we have a clear idea about this atm.

Allow the TC to be invoked early
(smcv to introduce)
Proposal 2: Modify the Constitution to allow the TC to get invoked early, 
clarifying how that works.
- We are defined as a "last resort" resource, but it's somewhat of an empty 
definition

smcv: Positions are already entrenched by the time an issue is brought to the 
TC. By the time things come to us, parties are probably are already in 
conflict. Constitution allows us to do some _non_last-resort powers which we 
don't use. (i.e. "give opinion", "unsolicited advice"). Perhaps we should do it 
more often → Maybe offering advice with TC hats instead as of "just individuals"

bremner: Can we do it? We were recently contacted informally by IRC.  How  can 
we actually do such things in practice?
Would a smaller committee be more wieldy? maybe not _everyone_ has to agree if 
one or two members is happy to provide advice. The extreme formality is for 
when things are already contentious. 

OdyX: … and it ended up being "enough members of the TC agree that it's a good 
idea, but not formally as a body, so it ended up being done".

Q: isn't there some sort of "TC consensus" that's already mostly understood 
within the TC, that any member can go around waving to people? (I certainly did 
argue at times saying "I'm quite sure that the TC would agree with me on that 
one…").

(comment by OdyX): out of my term's experience, it's very 
hard/inconvenient/time-consuming to "act as the TC", early or late. So maybe it 
would make sense to allow "invoke TC members with [to-be-defined] powers early" 
vs "invoke the TC as a body early".

marga: A tricky part is to act as a committee. Even if 

Re: Dispute resolution in Debian

[Gunnar Wolf]

Felix Lechner dijo [Wed, Jul 29, 2020 at 03:26:00AM -0700]:
> > Do you think it shouldn't have those other roles, maybe?  That would
> > correspond to the last of our proposals, I think.
> 
> As a computer project, Debian's highest decision making body should
> probably be a Technical Committee. Current committee members who like
> to adjudicate more along human lines, under my proposal, may wish to
> join the Community Team.

However, most issues that come to the TC have a _strong_ human/social
component. We cannot dissociate technical decisions with the emotional
meaning they carry to project members.

If technical excellence was the sole, or even main, requisite to
become part of the Technical Committee, I would not have
joined. Purely technical decisions are far from the norm; Debian as a
project has quite good inner coherence (which means, project members
have a quite compatible view of where they want to drive the project
to), and when the TC is asked to participate, the divergence is
usually very minor; we do deal with technical issues, but more than
that, we deal with what does each decision ultimately mean.

I don't think we can keep TC work 100% technical, or separate the
inter-human part from the TC's work.

> Debian needs more empathy. People are not logical like machines. They
> are burdened by ideas and have fears and hopes. Plus, some do not
> lightheartedly express how they feel. Solving conflicts in a unified
> system brings all that out in one place, and makes peace.

On my first reading and when I started replying, I had got your
message basically upside down. So, basically - Yes, I (now) completely
agree with you :-]

Bug#965080: Resignation + Call for votes for new Chair

[Gunnar Wolf]

Margarita Manterola dijo [Wed, Jul 15, 2020 at 09:05:23PM +0200]:
> Package: tech-ctte
 > 
> [Resending as a bug rather than a mailing-list email. Sorry!]
> 
> Dear TC members,
> 
> I am calling for the election of a new Chair of Debian Technical
> Committee by announcing my resignation as chair effective one week from
> now. In accordance with Section 6.1.7 of the Debian Constitution, the
> vote runs until all members have voted, or until my resignation takes
> effect.
> 
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
>  A : Philip Hands
>  B : Margarita Manterola
>  C : David Bremner
>  D : Niko Tyni
>  E : Gunnar Wolf
>  F : Simon McVittie
>  G : Sean Whitton
>  H : Elana Hashman 
> 
> ===END===

My vote is:

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


signature.asc
Description: PGP signature

Bug#963112: Request for advice on katex rejected by ftp masters

[Gunnar Wolf]

Pirate Praveen dijo [Fri, Jun 19, 2020 at 12:47:51PM +0530]:
> The general case was discussed earlier and a recommendation was given at 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54
> 
> I'd like a confirmation from you if katex was following your
> recommendations or not. I think katex should be a separate binary
> package because it is shipping a user facing executable. But ftp
> masters don't agree with my interpretation.
> 
> Their rejection mail and explanation is given below.

Hello Praveen,

You raised this same question to me via private mail; I prefer to
answer copying the rest of the Committee, and in a public way.

I completely lack context regarding KaTeX (tried downloading its
sources, but I am a complete JS newbie and didn't get a hold on it
anywhere; don't know what components of it are packaged or not, nor
how is your proposed katex package structured, etc.), hence, there is
no way for me to express an opinion here. I do feel there is too much
soreness still expressed between you and the ftp-masters.

So, refering to the same mail you quote, the guidelines Simon
carefully worked out begin with:

1. When there is disagreement about the level of splitting necessary
   between binary and source packages, we encourage maintainers and
   the ftp team to communicate respectfully, and in particular
   acknowledge that each other's goals are valid, even if arguing that
   those goals should be outweighed by higher-priority goals.

   We also encourage maintainers to be as clear as possible about the
   purpose and relationship of the various parts of a source package.

This is, yes, hard to achieve - but we should strive to communicate
better before getting angry and calling in the cavalry.

Simon continued with some design principles, that I understand often
impact node.js work: "We should not have very large numbers of very
small binary packages" and We should not have very large numbers of
very small source packages". Is this the case you are arguing for?

I don't want to rehash the whole set of guidelines; I want to
understand the disagreement you are presenting.

And finally, as David already argued - We cannot overrule delegates'
decisions. The final call on whether to accept a package is
ftp-masters'. Can we ask them to better state their reasons? Probably
yes, but that's -I think- about the limit of our action scope.


signature.asc
Description: PGP signature

Re: DebConf20 Moves Online

[Gunnar Wolf]

David Bremner dijo [Tue, Jun 16, 2020 at 09:41:16AM -0300]:
> I created a placeholder talk submission for "Meet the Technical
> Committee". IIUC, the other committee members need to be manually added
> by the debconf admins. Once that happens we can work on an abstract.

And given I am a DebConf admin, well... I am waiting for a bit of
modifications from the Wafer admins (I'm missing a permissions bit),
but I can add you all as soon as you have a DC20 user. So, if you
intend on participating on the BoF, please register for DC20 and give
me your usernames.

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

[Gunnar Wolf]

Hello Jonathan!

Jonathan Carter dijo [Mon, Jun 01, 2020 at 08:30:11PM +0200]:
> 2. The last ctte update linked from
> https://www.debian.org/intro/organization is
> https://lists.debian.org/debian-devel-announce/2018/03/msg5.html,
> and it does indeed seem to be the latest appointment update.

Right, we should be keeping things up to date more often. I guess this
fell through the cracks :-|

> Personally I find it a bit strange that we don't announce the expired
> terms, or even that Margarita is now the chair. I think it's a
> high-profile enough team in Debian that we should be announcing these
> kinds of changes, so, I'm adding that to this email. If you think that I
> rather shouldn't, let me know and I'll gladly remove it again, or
> otherwise suggest a change.

Thanks for explicitly doing this!

> I also renamed "chairman" to "chairperson" as it has become the de facto
> designation in Debian, if you'd prefer I change it to something else or
> revert it, let me know.
> (...)
> Margarita Manterola is the current chairperson of
> the Debian Technical Committee.
> 
> The Technical Committee now consists of:
> 
>  * Margarita Manterola  (chairperson)
> (...)

Please note the correct term we voted on in a GR is "chair", not
"chairperson":

https://www.debian.org/vote/2016/vote_003

Greetings!

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

[Gunnar Wolf]

Sean Whitton dijo [Thu, May 28, 2020 at 09:39:16AM -0700]:
> > 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 
> 
> I don't believe that odyx, philh or tfheen are members anymore; their
> terms expired.  marga is the current chair.

We still haven't managed to get rid of Phil. His time will come,
sooner or later, but in the meantime you will have to enjoy his
presence (I always do).


signature.asc
Description: PGP signature

Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

[Gunnar Wolf]

David Bremner dijo [Wed, May 20, 2020 at 05:03:16PM -0300]:
> ===BEGIN
> The Technical Committee recommends that Sean Whitton  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Sean Whitton 
> F: Further Discussion
> ===END

I am happy to vote:

S > F


signature.asc
Description: PGP signature

Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

[Gunnar Wolf]

David Bremner dijo [Wed, May 20, 2020 at 05:10:26PM -0300]:
> ===BEGIN
> The Technical Committee recommends that Elana Hashman  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Elana Hashman 
> F: Further Discussion
> ===END

I am happy to vote:

S > F


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Svante Signell dijo [Wed, Jan 29, 2020 at 08:15:36PM +0100]:
> > It's not like having two competing implementations causes much 
> > harm here.we technically _can_ allow any /bin/systemd-* to be
> > provided by another implementation, that we should (actually, I think
> > we should clearly _not_).
> 
> Of course the name should not be systemd-*. That would conflict with
> systemd upstream, and a lot of other stuff too!

Humh, where did you quote this snippet from? It includes bits from
OdyX's mail, but it's wrapped over itself. It also shows as if it were
my text (which is _not_).

> > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are
> > to allow alternative implementations of /usr/bin/system-brewmycoffee,
> 
> no way!

Please keep on reading for the full paragraph...

> > we should first push to an alternative /usr/bin/brewmycoffee, get the
> > systemd maintainers to "subscribe" to it using our great alternatives
> > system, and provide our /usr/bin/open-brewmycoffee.
> 
> Why should they be subscribing? There are other people within Debian
> who can provide alternatives.

I tend to convey that, if Debian is to support more of one
argument-compatible implementations of brewmycoffee (one of which is
systemd-brewmycoffee), I feel the systemd maintainers should be
sensible and allow its use, via the alternatives system, as
/usr/bin/brewmycoffee.

Of course, it is highly likely they will be seen as the reference
implementation and others should attempt to adopt a compatible
interface arguments-wise.

> > And I think that now, that not so many packages have yet adopted
> > systemd-derived facilities, is a great time to set this as a good
> > practice.
> 
> Is this your interpretation of the GR?

It my impression, at least.

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

[Gunnar Wolf]

Thomas Goirand dijo [Wed, Jan 29, 2020 at 04:07:21PM +0100]:
> 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).

Yes for the general case, no for specifics.

I mean - We should encourage people to use /bin/sysusers. Now, if
systemd-sysusers grows a piece of functionality that open-sysusers
is not willing to adopt (or vice versa), following past examples, I
believe a package set to predepend on systemd-sysusers should be able
to call /bin/systemd-sysusers — And a package set to predepend on
open-sysusers can do likewise.

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

[Gunnar Wolf]

I just want to subscribe with a very big +1 to what OdyX has said here:

Didier 'OdyX' Raboud dijo [Wed, Jan 29, 2020 at 04:31:09PM +0100]:
> (...)
> > 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.

/usr/bin/systemd-* is clearly implementation-specific. Now, if we are
to allow alternative implementations of /usr/bin/systemd-brewmycoffee,
we should first push to an alternative /usr/bin/brewmycoffee, get the
systemd maintainers to "subscribe" to it using our great alternatives
system, and provide our /usr/bin/open-brewmycoffee.

And I think that now, that not so many packages have yet adopted
systemd-derived facilities, is a great time to set this as a good
practice.


signature.asc
Description: PGP signature

Re: #932795 - Setting up minimum build system expectations?

[Gunnar Wolf]

Hello all,

Dear Release Team members, I am reaching out to see what is your
position regarding bug #932795, which in turn references
#907829. Thing is, I want to push a bit before we (Tech-Ctte) to have
a possible decision for our next meeting (2019.08.21).

In short - This bug started off quite aggressively between two
developers, and I don't think it's easy to deescalate. But I think
that there is a good way to solve the situation - _if_ the Release
Team is willing to accept one more power / responsability.

I am expressly _not_ including 932...@bugs.debian.org as a recipient
to this mail, as I'd like not to resonate too much with the affected
people at first. Of course, I am including an open mailing list. /me
crosses fingers ;-)

If, in a fashion similar to issuing release qualifications for
architectures, the Release Team indicates which is the minimum
acceptable build environment for a FTBFS to be considered RC.

I don't want to repeat all the reasoning that was given on the
{bug,list}, so I'll just point at a couple of meaningful messages:

- I think Ian Jackson's mail
  <23862.65026.843324.814...@chiark.greenend.org.uk> is quite sensible
  and sane. Of course, it would be up to the RT to define the minimum
  levels considered "reasonable" and "supported" for each
  release. Of course, this could include RAM, number of cores, free
  disk space available — And be flexible to add other criteria not yet
  considered if deemed necessary

- We might at some point hit packages that FTBFS with 4GB RAM, which
  would be tricky -to say the least- to build them in 32-bit systems,
  as Ansgar mentioned in <87ftmwd1yh@43-1.org>

- In this message, the submitter explains what is requested from the
  TC. I am, however, reaching out to the RT because I think this is a
  problem that should be addressed, and not on a case-by-case
  basis. <20190725112242.og3gey4fmpwnt3od@nucold>

- The submitter makes a point on the amount of packages presenting
  build failure (4%), plus the economic difference it takes for him to
  hire a better server. https://people.debian.org/~sanvila/single-cpu/

Thank you all for your comments,

- Gunnar, wearing his tech-ctte hat






signature.asc
Description: PGP signature

Bug#932795: How to handle FTBFS bugs in release architectures

[Gunnar Wolf]

Santiago Vila dijo [Thu, Jul 25, 2019 at 01:22:42PM +0200]:
> > Or are you asking the TC for advice, or are you asking us to use a
> > different one of the TC's powers?
> 
> Advice first.

OK, good this is made explicit. Thanks.

> > There are many aspects of a build environment that might be considered
> > reasonable and might not, and they are generally evaluated on a
> > case-by-case basis. A working build environment needs "enough" RAM (a
> > lot more for gcc or WebKit than for hello); it needs "enough" disk space
> > (likewise); it needs a writeable /tmp; it needs a correctly-installed
> > Debian toolchain (I hope you wouldn't argue that it's RC if a package
> > FTFBS with a patched gcc in /usr/local/bin); it needs to be on a
> > case-sensitive filesystem (I hope you wouldn't argue that FTBFS on
> > FAT/NTFS/SMB would be release-critical); it needs to not have weird
> > LD_PRELOAD hacks subverting its expectations; and so on.
> 
> Ok, my build environment:
> (...)
> The only thing it did not have was more than one CPU, but AFAIK that's
> not something that may be considered as a misconfiguration.

I agree with this. It might be considered too little by some people,
but it's not documented.

> > For the specific question of whether a single CPU core is a "reasonable"
> > build environment, my answer at the moment is "I don't know".
> 
> That's basically the first question I'd like to have answered by
> the TC, yes. I would express it this way:
> 
> Does "build-essential" imply multi-core?

_My_ take is that, as it currently stands, it should not be implied.

> I believe there is a wide consensus that a package which does not
> build with one CPU is a bug (I'm *not* talking about severity here).

Right. Nobody said the bug was worth closing - it was only
downgraded. But this "only" had important practical implications.

> Even if we ever wanted to allow packages to "need" more than one CPU
> for building, I'd like to believe that we would do so by introducing a
> new control field for that, say, Build-CPU, instead of making
> multi-core mandatory for all packages.
> 
> The great paradox of all this is that we would be better by having
> this stupid Build-CPU field and enforcing it than not having anything
> at all. Fixing a Makefile bug may take time and effort, but it may not
> be argued that adding a "Build-CPU: 2" line to debian/control would be
> an unbearable burden for maintainers.

I am not sure about this - First of all, the issue needs to be
identified (not always the case, if nobody is building packages on
single-core systems), so most probably it would not be introduced
without a bug roundtrip plus new upload. But second, and I think most
important: how many extra fields would this need? Build-CPU,
Build-RAM, Build-HDD spring to mind... But many other more detailed
bits could creep their way in if we were to open up to this. And
anyway, this has to go to the Policy editors anyway.

> At least that way Debian Policy would say the truth again. It will be
> possible again to build a package on a system having build-essential,
> the build-dependencies and the number of CPUs in the Build-CPU field.

My opinion, based on what we talked about this bug during DebConf and
the people I talked with, is that we should provide an advice
following roughly:

- The Release Team are empowered to set the base requirements to build
  packages for a given release (starting with Bullseye, I don't think
  there's any reason to change qualifications for Buster)

- Get this documented, quite probably in the RT delegation.

Of course, we have to get this moving within the TC, but I hope we can
do this before our next meeting (August 21).


signature.asc
Description: PGP signature

Bug#932795: Ethics of FTBFS bug reporting

[Gunnar Wolf]

Don Armstrong dijo [Tue, Jul 23, 2019 at 06:06:59PM -0700]:
> I think this discussion is great and good to have; thanks for starting it!

I completely concur.

> As a point of order, the TC isn't responsible for deciding whether bugs
> are RC or not. That responsibility belongs with the Release Managers.
> 
> [I don't think that should stop the TC from facilitating the decision
> and the baseline being enshrined in policy so the RMs can rely on it to
> decide whether it is RC or not.]

As we are at DebConf (from which most of the participants of this
thread so far are sorely missed), we have been exchanging some
heigher-bandwidth interactions.

I feel you are expressing the consensus we have found so far
informally. Thing is, the release managers have not been invested
formally of this power - But I think this is the way to be pursued. I
quite liked Ian's proposal of introducing "supported" and "reasonable"
as long-standing concepts that could be enshrined in our basic
documents (i.e. constitution) and in delegations. That way, they could
be rephrased - The Release Team delegation's task description can then
include keeping an updated qualifications for supported build
requirements, and thus, for determining whether a bug report regarding
the minimum characteristics of a system, determine whether the FTBFS
bugs it generates are RC or not.

[ I would like to write more, but Well, three beers are already in
  my system, as it is customary by 22:30 at DebConf. ]

Re: Concluding "What should happen when maintscripts fail to restart a service?"

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jun 21, 2019 at 02:36:05PM +0100]:
> My reading of the conclusion to #904558 is that the recommendation to
> form a working group is a recommendation that can be directed only to
> the developer body as a whole, not to the Policy process.  That's
> because actually implementing in the archive some new mechanism for
> maintscripts is a prerequisite to any Policy change requiring packages
> to use that new mechanism.  In other words, what the working group would
> be tasked with doing is beyond the scope of the Policy process.  We do
> design work as part of the Policy process, but we don't write code.
> 
> Assuming that the T.C.'s recommendation is the right way to proceed
> here, and someone doesn't come up with any other way to unblock things,
> the wontfix+stalled status will remain until and unless the working
> group actually forms, designs and implements something, and starts using
> it in the archive.  There is no role for the Policy process (and thus no
> role for the Policy Editors qua Policy Editors) until that occurs.
> 
> So, by all means insist on the recommendation, but so far as I can tell
> that's something which does not involve either the Policy process or the
> T.C., but simply the body of Debian contributors qua contributors.

I completely agree with you - My idea to kickstart this at DC19 is not
for TC and Policy Editors leading a session, but rather us (as
individuals) expressing the issue at a BoF trying to get more eyeballs
(and, more important, more brains) on it.

> Stepping back a bit, tagging this bug wontfix+stalled is part of the
> broader attempts, in which the Policy Editors are engaged, to more
> sharply delineate the boundaries of the Policy process.  We want to get
> to the point where the only bugs that we have listed are either
> highly actionable, or tagged wontfix.  For a bug to be highly actionable
> is for it to be the case that someone with enough time and background
> knowledge can sit down, think through the problem, and come up with at
> least a first version of a change proposal.
> 
> I think that a large number of very-difficult-to-action bugs strongly
> discourages people from getting involved.  It makes Policy seem like a
> sprawling, unmanageable morass of difficult problems.  That isn't how
> things are, because while there are indeed a lot of hard problems, they
> are largely independent of each other, and tackling individual
> debian-policy bugs really does improve Debian.  However, it is much
> harder to see that when half of the open bugs are more than five years
> old yet not tagged wontfix.

Right. This is a bug where I was quite happy that the TC decided to
declare it outside of its functions - And it is just fitting that it's
outside the Policy as well. We don't have a commonly implemented
practice to document / show / follow. This should go to the developer
body at large.


signature.asc
Description: PGP signature

Re: Concluding "What should happen when maintscripts fail to restart a service?"

[Gunnar Wolf]

Hello Sean,

> In #904558 I asked the T.C. for advice about how to move #802501
> forward.  Their ultimate response was to recommend that a working group
> of developers come up with some method, other than exiting nonzero, for
> a maintscript to indicate that it failed to restart services.  Let me
> take this opportunity to thank all those who were involved in #904558.
> 
> In this message, I seek to explain my understanding of what the closing
> of T.C. bug #904558 means for debian-policy bug #802501, and those
> merged with it.  Apologies for the length.  I wanted this general sort
> of reasoning to be recorded somewhere for reference in future
> discussions.

Thank you for providing this framing and for helping us (me, at
least!) better understand the circumstances of your bug filing. Quite
probably, I should have probably read #802501 during the #904558
discussion (and it's a very short bug FWIW), but didn't. Understanding
the bug follow-up policy of the Policy Editors makes me more at ease
with what we (TC) decided — We were not the first ones to fail to find
an always-good solution :-|

Now, I would more than welcome this bugs to be pushed to the right
areas: To d-devel, or to a new, specialized working group tackling the
issue. Both in the bugs and in our discussions, it is often repeated
(quoting here Sam, from #802501) «as a distribution, I think we should
explicitly encourage people to consider the consequences on
dist-upgrade and other operations». Inconsistently failing is *not*
OK, and nobody implied it that way...

So,

> The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
> addition to the 'wontfix' tag.
> 
> ~ ~ ~
> 
> In #904558, I did not ask the T.C. to rule on what maintscripts should
> do when they fail to restart a service.  Rather, I asked them to weigh
> in on the decision between the options described above, given that the
> Policy Changes Process had failed to achieve consensus.  However, in the
> message closing #904558, the T.C. indicated that they declined to issue
> a ruling about what maintscripts should do when they fail to restart a
> service.  So the second option described above, corresponding to the
> 'ctte' usertag, has been taken off the table.
> 
> That leaves us with the question of whether to leave #802501 open, in
> the absence of the possibility of closing it by having the T.C. make a
> call.  Given that this bug has already been filed (at least) twice, I
> think it would be best for us to leave it open.  So I'm tagging
> wontfix+stalled.

I want to interpret this wontfix+stalled, and the TC answer ("The
Technical Committee does not engage in design of new proposals and
policies") don't mean this problem will just lay dormant and unsolved
forever. As Marga said in her mail closing this bug, «While we
recognize that this is a problem worth fixing, this is not something
that we can fix as a body and need the help of the Developers to do
it.»

I want to insist on our recommendation to create a work group of
developers to tackle this issue. Maybe we can start it off as a BoF
session in DC19?


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Mon, Feb 25, 2019 at 02:58:09PM +0100]:
> === 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 ===

My vote is:

H > M > FD > W


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sat, Feb 02, 2019 at 03:38:01PM +0100]:
> 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

FWIW, crediting me at the same level as you is a gross overstatement
of my lone commit fixing minimal changes. It is clearly your work -
And all of the consecutive edits (which I completely support) add to this.

Re: Bug#914897: debating the wrong thing

[Gunnar Wolf]

Svante Signell dijo [Wed, Dec 05, 2018 at 02:03:19PM +0100]:
> > If we keep merged-/usr as default then we can /recommend/ people to
> > install usrmerge to switch to merged-/usr; reducing the difference
> > between newly-installed and existing setups is a good idea IMHO.  I
> > think I filed a report for this two years ago.
> > 
> > Maybe we should also mention somewhere that it might be useful to not
> > switch build environments (yet).
> 
> How about this case:
> 
> - Make as default non merged-/usr for all buildds.
> - Make a choice of non merged-/usr or merged-/usr in the installer.
> - Users wanting merged-/usr install the usrmerge package and convert to 
> merged-
> /usr.
> 
> - We have two alternatives here:
> 1) For those not wanting merged-/usr: 
>All is fine.
> 
> 2) For those having merged-/usr installed:
>Re-run usrmerge to convert all newly installed packages to merged-/usr.
>Is this possible or is installing that package a install-once-only?

AFAICT, this would mostly cover the issues, at least as far as I
understand them. There is still one extra point: Computers used by
Debian contributors to build their packages on. If I build my package
on a merged-/usr system, it might end up breaking in non-merged
systems.

Throwaway binary uploads seems like a safe bet for this issue. Now -
Are we ready to do it?


signature.asc
Description: PGP signature

Bug#914897: debating the wrong thing

[Gunnar Wolf]

Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
> (...)
> So, let's enumerate possible outcomes:
> 
> 1. no usrmerge
>   1a. no moves at all (no effort needed!)
>   1b. moves via some dh_usrmove tool, until /bin is empty
> 2. supporting both merged-usr and unmerged-usr
> 3. mandatory usrmerge
>   3a. by Bullseye
>   3b. by Buster
> 
> Unless the TC decides for 2., all this work will be a pure waste of yours
> and maintainers' time.

...One thing I fear here, that's also not being clearly debated AFAICT
(although the "urgency" of this report points in the right direction)
is that if the TC decides towards anything but 2 or 3b, we will have a
hard time reaching and following through the freeze targets proposed
by the Release Team. Which is something we don't want.

> With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in
> 3a "for now").  With 3b you need some way to make sure existing systems are
> converted (also with 3a except for far more time for testing).

I agree with your assessment. There are still too many mails I haven't
read, though, and I cannot commit my hypothetical vote so far, but I
think the sanest way will be to revert the change in debootstrap.

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

[Gunnar Wolf]

Tollef Fog Heen dijo [Mon, Nov 05, 2018 at 07:44:21PM +0100]:
>  END OF RESOLUTION 
> 
> A: Approve resolution, disallowing the use of dpkg's vendor series
> F: Further Discussion

I vote:

 A > F

Thanks,


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Anonymous dijo [Sat, Sep 29, 2018 at 05:06:58PM +0200]:
> Dear Chair

Dear Anonymous,

Although it is of course completely fine for you to contact us
anonymously, in cases such as this one, having a "name" will help your
case. Do you actually use this? Have you worked with the issue? Is it
bothering you?

Anonymous opinions are acceptable. But Debian is a socially cohesive
group of people. It helps us to match opinions with people. Would help
your point.

Anyway, thanks for your mail.


> (...)
> Patch series are supported by git-am and git-format-patch. There is no
> better approach to incorporate patches. I fear circumventing the policy
> with "QUILT_SERIES=debian/patches/$(dpkg-vendor --query vendor).patch
> quilt push -a" in debian/rules. The patch series separates vendor
> specific code properly. If policy is against vendor specific code it has
> to accept patch series at least. They are a last resort to make
> independent patches.

Well, IMO this would be precisely the _right_ way to do this: The
source you have on disk at source package unpacking time is the same
everywhere, and you can see precisely what would happen when building
in Mint, Ubuntu, Debian or $whatever. This would not be circumventing
policy — It would be following it with minimal friction to what you
already have.

> Builds for different vendors are not a standard use case at all. Identic
> source after unpacking is possible with dpkg-source --skip-patches
> anyways. A hint about different series during unpacking can be useful
> but changing policy because someone was confused is unbelievable. Usage
> of the right tools is good practice and should not forced with power.
> 
> The decision is based on wrong assumptions and implications, arguments
> are weak, valid objections ignored. This is abusing Debian policy and
> technical committee against free software! Debian needs patches
> regardless of policy.

I do not share that feeling; I think we argued constructively with
people that were against this outcome, and while there is not
universal consensus, expressed issues were taken into account.


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Stuart Prescott dijo [Wed, Sep 19, 2018 at 12:18:24PM +1000]:
> (...)
> That was perhaps also written before we started to realise that maintainer 
> scripts are actually best avoided as they tend to be complicated, fragile, 
> difficult to do right and make upgrades harder for the package manager. In 
> the intervening two decades, we've gone from "maintainer scripts are cool" 
> to "the best maintainer script is the one that doesn't exist".
> 
> So yes, ignoring errors seems wrong but…
> (...)
> … causing a snowball of errors in an awkward half-upgraded environment is 
> nasty.
> 
> The problem comes when you don't yet have the right tools installed to be 
> able to fix the problem. We see that scenario often enough in #debian where 
> someone has a failed upgrade and we try to collect more information via 
> pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover 
> that the relevant tool isn't installed and because apt is sufficiently 
> unhappy about broken packages and a half-completed upgrade, you can't ask it 
> to install the tool at that point in time.
> 
> In the upgrade scenario, while you're trying to fix one particular problem, 
> you're also in a completely untested half-upgraded situation and so latent 
> bugs in any number of other tools may also be exposed.
> 
> So while ignoring errors is wrong, so is making it harder to fix them. This 
> isn't a question of absolutes.

I completely agree with Stuart here. Yes, of course, there is a reason
for maintainer scripts to exist, and if they fail to set up things
around the package, of course, the user _needs_ to know something is
off in their system.

But that should happen _very_ seldom. As Stuart says, helping
non-technical users out of this situation can be quite hard, and quite
discouraging for the user. We have to make sure the scripts are as
foolproof as possible — and failing to stop or restart a daemon it
should _never_ cause the system to enter such a state.


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jul 30, 2018 at 12:01:35PM +0800]:
> > ...Although if we make a policy change in this, it will require
> > cooperation of the dpkg developers if we don't want to go into 6.1.4
> > (which we don't).
> 
> Sorry, I don't follow.
> 
> Surely policy can disallow things in packages even though those things
> have support in dpkg.  For example, dpkg lets packages connect to the
> Internet to download and embed dependencies, but we forbid that.
> 
> Whether or not the feature is removed from dpkg seems orthogonal to the
> T.C. bug I filed.

You are right. Sorry for the noise.

Still, I would like to have Guillem's opinion.


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jul 30, 2018 at 09:30:04AM +0800]:
> > I believe his request might also be considered under §6.1.1, since we're
> > being asked about a policy change.  (After talking to Sean in person, he
> > said he intended it under §6.1.3, not §6.1.1, though.)
> 
> I think technically it's §6.1.3 because according to the policy team
> delegation, we decide what goes into the policy manual.
> 
> But it certainly falls under at least one of §6.1.1 and §6.1.3, and not
> §6.1.4.

...Although if we make a policy change in this, it will require
cooperation of the dpkg developers if we don't want to go into 6.1.4
(which we don't).

I am explicitly cc:ing Guillem here. Guillem, please take a look at
this bug and give us your PoV!


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Sean Whitton dijo [Mon, Jul 23, 2018 at 09:22:17AM +0800]:
> As a Debian Policy delegate I hereby request that the Technical
> Committee decide whether a proposal that has been submitted to modify
> the Debian Policy Manual should be accepted:
> 
> #850156 [n|  |  ] [dpkg-dev, debian-policy] Please firmly deprecate 
> vendor-specific series files
> 
> I am making this request because we have not been able to establish
> consensus, but I think this bug is one that we should not just leave
> sitting open against debian-policy: if the proposal is eventually
> accepted, then leaving the bug open means more vendor-specific series
> files in the archive that then have to be removed.
> 
> There are currently at least 18 source packages which use
> vendor-specific series files.  I have not been able to determine an
> upper bound.
> (...)

Hi,

FWIW, I did a first reading only of the issue, and I find it quite
agreeable. I think it boils down to the principle of least surprise.

There are many alternative and less-obvious ways where a package can
be programmed to act differently depending on where it is being built,
but having it act at source-unpackaging time effectively hides things
and potentially leads to longer head-scratching periods. #ifdef-like
mechanisms are ugly and might carry some reliability issues, but I
think they are preferable as they are so very explicit.

So... I'd like to have some more discussion on this, particularly I'd
like Mike to explain in a nutshell his views. I have not yet read
#850156 (which I really should before stating a definitive viewpoint).


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Margarita Manterola dijo [Wed, May 16, 2018 at 10:41:53AM +0200]:
> Hi!
> 
> The next meeting is scheduled to take place today at 19:00 UTC.
> 
> There are currently no open issues in our bug tracker.
> 
> As far as I know, there are no pending TODOs.
> 
> We have agreed to postpone recruiting efforts until September, as all our
> seats are currently taken.
> 
> Are there any other topics that people would like to discuss?

I will most likely not make it to today's meeting, I am in the middle
of a heavy paperwork shuffling process that requires me to criss-cross
the city repeatedly. Which is not exactly my definition of fun.

So, I'm happy to miss a probably non-controversial meeting :-]


signature.asc
Description: PGP signature

Bug#893200: TC Chair election

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sat, Mar 17, 2018 at 10:25:28AM +0100]:
> 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===

I vote:

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

Thanks!


signature.asc
Description: PGP signature

Bug#880014: Technical committee appointment

[Gunnar Wolf]

Chris Lamb dijo [Fri, Mar 16, 2018 at 06:14:37PM +]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear fellow developers,
> 
> As defined by our constitution (§6.2.2), the Debian Technical Committee
> has recommended the appointment of Simon McVittie (smcv).

Yay! Welcome on board!

> I am extremely happy to follow their recommendation and hereby appoint
> Simon as a member of the Technical Committee, effective immediately.>
 
> For reference, the nomination of Simon may be followed at
>  and the Committee now consists of:
> 
>   * Didier Raboud (chairman)
> (...)

I have to pick a nit here - I know this mail probably comes from a template
and you are repeating what used to be true here. But, according to GR
003 in 2016¹, Didier is the "Chair" of the Technical Committee, not
the "Chairman".

¹ https://www.debian.org/vote/2016/vote_003

Thanks!


signature.asc
Description: PGP signature

Bug#880014: Call for Votes for new TC member

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sun, Mar 04, 2018 at 11:44:45AM +0100]:
> 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

I vote:

S > F


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Fri, Feb 09, 2018 at 09:14:49AM +0100]:
> 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

I vote:

R > F



signature.asc
Description: PGP signature

Bug#880014: Call for Votes for new TC member

[Gunnar Wolf]

As we agreed on the January #debian-ctte meeting¹, even though action
has been taken on this bug (and thus I am a new TC member), there is
still one open seat to fill. Even though it's not high priority to
fill this position, this bug will remain open until a second TC member
is appointed.

(Nomitations welcome!)

¹ http://meetbot.debian.net/debian-ctte/2018/debian-ctte.2018-01-17-18.58.html


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Gunnar Wolf dijo [Mon, Feb 05, 2018 at 12:57:47AM -0600]:
> - Enough RC bugs (or evidence of regressions, could even be links to
>   blog posts from people complaining about how systemd is bad or
>   whatever)

Just to be clear - Yes, you linked to the list of bugs on systemd. No
piece of software as widely used as systemd is expected to be
completely bug-free; the list of bugs is as long as I'd expect it to
be, but there is only one grave bug (#784682, resolved) and only one
serious bug (#889144, open). Looking for bugs in unstable yields ~10
open serious bugs, but that's quite expectable at this point on the
release cycle.


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Philip Hands dijo [Sat, Feb 03, 2018 at 10:22:19PM +0100]:
> 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.
> 
> Cheers, Phil.

Thanks for swiftly doing this, Phil.

Kingsley, answering to your point: The Technical Committee is not an
investigative body. If you want us to devote countless hours, as the
TC back in 2013-14 did, and expose to endless flaming again... Please
back your request with:

- Enough RC bugs (or evidence of regressions, could even be links to
  blog posts from people complaining about how systemd is bad or
  whatever)

- Clear reasons why the outlook back in 2014 should need to be
  reevaluated; "enough time has passed" is not a reason.

I clearly agree with Phil closing this bug.


signature.asc
Description: PGP signature

Bug#886267: Voting for TC Chair

[Gunnar Wolf]

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

Thanks a lot for making me a part of the TC, I'm most honored by it!

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

My vote is:

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


signature.asc
Description: PGP signature

Re: TC nomination procedure v0

[Gunnar Wolf]

Sean Whitton dijo [Fri, Dec 01, 2017 at 01:57:01PM -0700]:
> > 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.
> 
> Okay, thanks.
> 
> A point on the other side is that it is good for the project to know
> whether or not there is a healthy number of people putting themselves
> forward for the TC.

That is a fair point - At some point, I also¹ had the impression the
TC was short of nominations. It can be healthy for applicants to know,
not the identities perhaps, but the amount of people volunteering for
the position.

¹ also, as AFAICT Wouter had this impression as well


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Sam Hartman dijo [Fri, Oct 27, 2017 at 08:18:48PM -0400]:
> 
> As a member of the technical committee, I've grown increasingly alarmed
> as I think about the impact of the issues that come to us.
> Yes, we're giving answers.  However, I think we are doing a lot of harm
> to the members of our community in the process, and I would like to
> explore whether we can do better.
> 
> I've written a blog entry describing my concerns.  It's on Planet, and
> you can see it at https://hartmans.livejournal.com/97174.html

I read your blog post earlier today, and it left me wanting to come
back to it. I'll take this as the cue to do so :-]

> I've reached a point where I'd like to share my concerns and ask "anyone
> else feel similar?  Anyone else want to work on solving this?"

The problem you point out is (surprise, surprise) a hard and recurring
one. I cannot look at it from the TC perspective, as even though I am
now trying to follow the public discussions in the ctte list, it would
be silly if I didn't admit to occasionally (hey, it's you who
mentioned the init system discussion!) kill whole threads when they go
over the level of detail I am comfortable in dealing with.

I understand your frustration stems from the much more recent (and
swift) issue with modemmanager. I was also surprised with the time it
took to be resolved, but the seeming uneasiness that still comes out
of this. Other than this point, from my (again: Incomplete)
perspective, the CTTE today works amazingly well and frictionless. I
am sure that Debian as a project is way more mature than when I
joined, almost 15 years ago. Makes sense: A good portion of us are
still around, and we have surely matured individually! Newcomers who
join us no longer have to grow thick skins, because that is no longer
the project's identity. Thankfully.

You mention, "our community is more important than technical
correctness". This might be, if any, the recurring lemma for the
period I have been involved in Debian. I feel we are getting much,
much better at it - But human issues are just harder. And, as a CTTE
member, you are subject to be the receiver of much of that
attention. It's easy to reach a technically sound decision, but it's
hard to uphold it without someone somehow getting sore about it. I
don't know how inevitable this is, but I recognize it happens in many
different areas. And a few sore people "hurt" more than a silently
sympathetic big crowd.

I know the domains we work at within the project are quite orthogonal,
and that's why I'm drawing a parallel with what we have done (OK, bad
joke... Anyway...) We did the keyring migration, pushing towards it in
late 2014. We had many people questioning procedures and requirements,
but IIRC only *two* felt we were pushing them aside. The decision was
unequivocally sound technically, but it hurt socially (mainly to those
that were socially or physically disconnected from the "core"). This
year, we had a sort-of-rehash with the set of DD retirement notices
(and corresponding DM retirement actions) we saw since late August. We
saw some interesting, constructive criticism in d-private; DDs can
refer to late September and early October for the related discussion
in debian-private.

And, yes, one or two sore cases will suck a lot of energy and
bandwidth. And will leave a *great* process with few but very
resounding unhappy tones clinging to it.

Anyway — If this serves in any way as motivation, I do hold the CTTE
as a *great* team in the project, and I do look up to you and others
who have volunteered and been selected to be a part of it. I am very
glad it outgrew being "just" a technical decision body and assumed its
social place, as your post shows: Technical and social go hand in
hand, we cannot expect to hold a technical decision without hurting or
empowering some of the involved parties.

So... don't know what else to say. Of course, there are no recipes. We
are just people, we are a bunch of individuals working together on
something we all think is worth our time (and that's as far as "doing
consensually things together" goes). I hope this mail (or whatever
other mails sum up in this thread) helps you feel better a sense of
togetherness and shared purpose again.


signature.asc
Description: PGP signature