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

[Christoph Berg]

Re: Sean Whitton
> ===BEGIN
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Stefano Rivera 
> E: Timo Röhling 
> F: Craig Small 
> G: Matthew Vernon 
> H: Sean Whitton 
> 
> ===END

I vote

  H > ABCDEG > F

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

Re: debbug.tech-c...@sideload.33mail.com
> # The DSC needs to become meaningful
> 
> Chuck Zmudzinski filed a bug report saying that the Debian Social
> Contract (DSC) is “meaningless”:

Hi,

I don't think the tech-ctte is the right body to address this.

Also, please file request using a name, we'd want to know who we
are talking to.

Christoph

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Christoph Berg]

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

I vote

  C > F

Christoph


signature.asc
Description: PGP signature

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

[Christoph Berg]

Re: Simon McVittie
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?

That doesn't sound too bad to me.

> Possible solution: other ideas?

Make glib2.0-t64 use a different cache filename?

> If the solution that is chosen is a Policy violation (like deleting
> the problematic postrm) then I would also like to have clarity that the
> Policy violation is tolerable as a less-bad solution, and therefore will
> not itself be treated as a RC bug in trixie.

I would tend to treat policy as a set of rules that you normally
shouldn't break, but if there's a clear argument why it makes sense in
given case, it would be quite silly to reject that solution just
because of formal reasons.

Christoph

Re: Processed: Re: Bug#1064838: New package names break APT safety features, ability to co-install different ABIs

[Christoph Berg]

Control: reassign -1 linux

Re: Debian Bug Tracking System
> Processing control commands:
> 
> > reassign -1 tech-ctte
> Bug #1064838 [src:linux] New package names break APT safety features, ability 
> to co-install different ABIs

Please only reassign to tech-ctte after the actual discussion has
finished with an open dispute. I see you have open questions to Julian
in the bug.

Christoph

Re: /usr-move: Do we support upgrades without apt?

[Christoph Berg]

Re: Helmut Grohne
> Is it ok to call upgrade scenarios failures that cannot be reproduced
> using apt unsupported until we no longer deal with aliasing?
> 
> If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug)
> with no action calling the scenario unsupported.

I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.

Christoph

Re: Next meeting -- 12th December, 6pm UTC

[Christoph Berg]

Re: Sean Whitton
> Our next meeting is scheduled for tomorrow at 6pm UTC.

I'll be traveling to PGconf.eu tomorrow and will likely not be able
to make it to the TC meeting.

Christoph

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

[Christoph Berg]

Re: Sean Whitton
> - Bastian's recent post to Bug#1007717:
>   <20231103112032.ny3d4ieeo7wrb...@shell.thinkmo.de>>

Is that the correct bug? There have been no recent mails, and the
message-id is unknown to lists.d.o.

Christoph

Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium

[Christoph Berg]

Re: Sean Whitton
> Package: tech-ctte
> 
> I call for votes on the following resolution.
> Voting lasts for one week or until the outcome is no longer in doubt.
> 
> === BEGIN
> 
> OPTION A:
> 
> The Technical Committee formally repeals its moratorium recommending
> that maintainers of individual packages should not proactively move
> files from the root filesystem to corresponding locations under /usr in
> the data.tar.* of packages (see #1035831).
> 
> Under Constitution 6.1.5, the Technical Committee now recommends that
> maintainers consult with those driving the merged-/usr transition before
> moving files from the root filesystem to corresponding locations under
> /usr in the data.tar.* of packages.
> 
> The transition driver, which at the time of writing is Helmut Grohne, is
> using a phased approach, in which the moratorium is rolled back for only
> certain classes of packages, and changes, at a time.  In addition,
> restructuring uploads should be targeted at experimental, and left for
> three days.  This is in order that automated testing by dumat can occur.
> 
> We recommend following , as edited by
> the transition driver(s).  If there is any doubt as to whether a change
> you wish to make is appropriate, please seek explicit approval from the
> transition driver(s).
> 
> OPTION N:
> 
> None of the above.
> 
> === END

I vote A > N.

Christoph


signature.asc
Description: PGP signature

Re: Lifting the moratorium

[Christoph Berg]

Re: Timo Röhling
> * Helmut Grohne  [2023-08-26 11:39]:
> > > Who is this going to be? Do you, Helmut, feel comfortable as driver?
> > 
> > Yes, though I'm not opposed to sharing the load.

Thanks Helmut!

> It does not even have to be much, maybe a
> short paragraph such as
> 
> "Please monitor the document at  for the current transition
> status. Helmut has graciously agreed to coordinate the transition.
> Please reach out to him if you want to help with the effort, or if
> you have affected packages and are unsure how you should proceed."
> 
> in the CTTE announcement is sufficient.

I like this very much.

Christoph

Bug#1050001: Unwinding the directory aliasing mistake

[Christoph Berg]

Re: Ian Jackson
> Protecting my mental health
> 
> I will try to avoid regularly reading this thread.  I hope that now
> that I have made the suggestion, others will be able to carry the
> conversation.  I will be configuring my mail client to disregard my
> personal copies of messages sent to this bug; when I want to read
> the thread I will look at the mailing list.
> 
> Also, if you disagree with my decision to raise this now, please don't
> email me.  If you feel I have overstepped a boundary, please contact
> the Community Team or DAM.

I think this is just gross. Submitting a proposal and then telling
CT/DAM to deal with the fallout is rude.

Christoph

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

[Christoph Berg]

> ===BEGIN
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Simon McVittie 
> E: Stefano Rivera 
> F: Timo Röhling 
> G: Matthew Vernon 
> H: Sean Whitton 
> 
> ===END

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

Christoph


signature.asc
Description: PGP signature

Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera

[Christoph Berg]

Re: Sean Whitton
> ===BEGIN
> The Technical Committee recommends that Stefano Rivera  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> R: Recommend to appoint Stefano Rivera 
> F: Further discussion
> ===END

I vote R > F

Christoph


signature.asc
Description: PGP signature

Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling

[Christoph Berg]

Re: Sean Whitton
> ===BEGIN
> The Technical Committee recommends that Timo Röhling  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> R: Recommend to appoint Timo Röhling 
> F: Further discussion
> ===END

I vote R > F

Christoph


signature.asc
Description: PGP signature

Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?

[Christoph Berg]

Re: Luca Boccassi
> If we were to do a MBF against packages that in _Bookworm_ have
> introduced new files in /bin, /sbin or /lib*, would you accept the
> consequent mass unblock request?

Fwiw, I would restrict that to packages that didn't have files in
these directories before. Telling a maintainer that they should
continue install foo.service to /lib/systemd, but the newly introduced
bar.service needs to got to /usr/lib/systemd seems like a lot of extra
work and asking for bugs to happen.

Christoph

Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium

[Christoph Berg]

> === BEGIN
> 
> OPTION A:
> 
> Under Constitution 6.1.5, the Technical Committee recommends that the
> maintainers of individual packages should not proactively move files
> from the root filesystem to corresponding locations under /usr in the
> data.tar.* of packages.  So, /foo/bar should not move to /usr/foo/bar.
> 
> Files that are in /usr in the Debian 12 release should remain in /usr,
> while files that are in /bin, /lib* or /sbin in the Debian 12 release
> should remain in those directories.  If any files are moved from /bin,
> /lib* or /sbin into /usr after the Debian 12 release, they should be
> moved back to their Debian 12 locations.
> 
> This moratorium lasts until we vote to repeal it.  We expect to do that
> during the trixie development cycle, and sooner rather than later.
> We will continue to facilitate efforts to resolve the remaining issues
> that stand in the way of safely repealing the moratorium.
> 
> OPTION B:
> 
> As option A, except that only maintainers of essential and transitively
> essential packages should refrain from proactively moving files from the
> root filesystem to corresponding locations under /usr in the data.tar.*
> of packages.
> 
> OPTION N:
> 
> None of the above.
> 
> === END

I vote A > B > N.

Thanks,
Christoph


signature.asc
Description: PGP signature

Re: DEP17 feedback

[Christoph Berg]

Re: Matthew Vernon
> "- Please stop moving individual packages' files from the root filesystem
> into /usr, at least for now.", clarified in the lengthier text to mean that
> we expected this sort of move would become possible during the Debian 13
> release cycle.

The moratorium will be hard to hold up, given even now we are moving
files in the last minute before the release: #1034210

Christoph

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

[Christoph Berg]

Re: Sean Whitton
> ===BEGIN
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Simon McVittie 
> E: Matthew Vernon 
> F: Sean Whitton 
> 
> ===END

I vote F > A = C = D = E > B.

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

Re: Sean Whitton
> ===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

I vote H > F.

Christoph


signature.asc
Description: PGP signature

Re: Missed chair election

[Christoph Berg]

Re: Gunnar Wolf
> 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.

Same here, let's postpone that until after we have new people on
board. Which might be as early as the next meeting, maybe?

Christoph

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

[Christoph Berg]

Re: Sean Whitton
> Therefore, we will likely just close this bug, I'm afraid.

+1 on closing from me.

Christoph

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

[Christoph Berg]

Re: Luca Boccassi
> for now we'll stay the course.

Thanks for working on this and the well-written summary mails!

Christoph

Re: Resignation: Elana Hashman (ehashman)

[Christoph Berg]

> As they say: so long, and thanks for all the fish :)

All the best for you!

Christoph

Re: Next meeting -- 12th July, 6pm UTC

[Christoph Berg]

Re: Niko Tyni
> On Mon, Jul 11, 2022 at 12:13:43AM -0700, Sean Whitton wrote:
>  
> > Our monthly meeting is scheduled for Tuesday at 6pm UTC.
> 
> Looks like I can't make it. Sorry!

I'm traveling and likely can't make it either.

Christoph

Re: Bits from the Technical Committee

[Christoph Berg]

Re: Paul Wise
> If you don't feel each decision deserves a mail, then I think there
> should at least be a summary of decisions in a shorter time period than
> the yearly bits mail. Either a more regular bits mail or via DevNews:
> 
> https://wiki.debian.org/DeveloperNews

DevNews seems like a good place to post the "low profile" decisions.

I still don't think we should post things like rename.ul do d-d-a -
it's not of general interest to the project, and d-d-a would just
further emphasize the implicit "we had to override the maintainer
since they apparently did a bad job" part, which seems
disproportional.

Christoph

Re: please review bits/202206.txt in tech-ctte.git

[Christoph Berg]

Re: Niko Tyni
> Please review. I'd prefer to send this out before Friday (2022-07-08)
> if possible.

I pushed two minor changes.

Christoph

Bug#1007717: Ballot and call for votes

[Christoph Berg]

Re: Sean Whitton
> 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.

I vote: C > A > X > N

Christoph


signature.asc
Description: PGP signature

Bug#1007717: Updated draft resolution

[Christoph Berg]

Re: Helmut Grohne
> For the reasons above, I do think we need another variant of 4.

Your view makes a lot of sense. Would you think you could draft a "4"
variant that summarizes it? I admit I'm lost between all the details
and would like a spot to go to, and then look at the alternatives from
that viewpoint (or vote for that spot rightaway).

Christoph

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

[Christoph Berg]

Re: Sean Whitton
> * Do we want to start systematically announcing decisions to d-d-a right
>   after we make them?

I think we should make it part of the decision where to post it.
Things like the rename.ul issue do not warrant a d-d-a posting, but a
note on debian-devel might make sense.

Christoph

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

[Christoph Berg]

Re: Lucas Nussbaum
> A middle ground between (4) and (4b) could be to discourage the use of
> 1.0-with-diff in circumstances where it is not justified. Something
> like:
> 
> 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 gain more uniformity.
> 
> That opens the path to an archive where the only remaining 1.0 packages
> are the ones where there's a reason to use 1.0. (as opposed to
> currently, where we have a mix of packages using 1.0 for a good reason,
> and packages using 1.0 because nobody cared to update them to modern
> practices).

The bit I was missing is something like "we would welcome changes to
the 3.0 format to make it usable for the remaining cases where 1.0 is
still better today". Did anyone investigate if that would be feasible?

Christoph

Re: Next meeting -- 10th May, 6pm UTC

[Christoph Berg]

Re: Sean Whitton
> Dear committee members,
> 
> Our monthly meeting is scheduled for Tuesday at 6pm UTC.  Agenda:

I'm afraid I have to send regrets for tomorrow.

> People with AIs: gwolf, ehashman, spwhitton, Myon

My AI has been resolved in the meantime (util-linux).

Christoph

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

[Christoph Berg]

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

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

Re: Chris Hofstaedtler
> I see two clear options:

Hi Chris,

thanks for the prompt feedback!

> A) Keep the status quo ("rename is not part of Debians util-linux").
>Very clear, very simple, no work.

But that's not what users want, there have been several requests to
have rename reintroduced.

> B) Finish the very old migration. Have util-linux(-extra) ship
>/usr/bin/rename; perl rename can be prename/file-rename as today,
>but would need to drop the update-alternatives symlink; versioned
>Conflicts/Provides/Replaces would probably be needed. I would also
>suggest having no binary package ship /usr/bin/rename for one
>release.

What name would you use in util-linux-extra for the time of the one
release where no package ships /usr/bin/rename? /usr/bin/rename.ul
seems most sensible to me here, which would also match the status
before starting a migration.

> Personally I am leaning towards option A) - mostly because we
> are/were already spending a lot more time on mails than what I think
> the work of option B) would entail. Also I believe the CTTE does not
> want to do any of this fine grainted technical detail design work.

We don't want to dictate *how* this should be resolved, but we are
interested in *having* it resolved, and A) isn't that.

To me, the plausible way forward here seems to be this:

* Reintroduce it as /usr/bin/rename.ul in util-linux-extra
* Have u-l-e be pseudo-essential for one release
* At this point the TC issue is resolved
* Potentially work with the perl-rename maintainers to transition to a
  different layout of the two utilities. That's then indeed outside
  the scope of the TC.

Christoph

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

[Christoph Berg]

Re: Matthew Vernon
> On 29/03/2022 00:55, Sean Whitton wrote:
> > On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote:
> > > The problem here is that if ul-extra contains things besides rename,
> > > and it conflicts with the perl rename, people will rightfully complain
> > > that they can't install /usr/bin/fincore-from-ul-extra and
> > > /usr/bin/rename-from-perl at the same time.
> > 
> > Indeed, and doesn't it violate Policy 10.1, which says "Two different
> > packages must not install programs with different functionality but with
> > the same filenames" ?  Perhaps it's an edge case.
> 
> Yeah, I don't think we serve our users by having two different packages both
> of which want to install /usr/bin/rename.
> 
> I'm still not quite sure why the previous path is so objectionable - we
> shipped /usr/bin/rename.ul for years, Debian (and derivative) users will be
> expecting it there, having util-linux-extra (WLOG) install it there seems
> like the right answer (and the one least surprising to our users)...

Hi Chris,

the TC was discussing this issue at the meeting on Tuesday.

We acknowledge that there are several possible ways to install it and
steer around the fact that there's also the "perl" rename. Probably
all of these have their warts - the above summarizes the current views
of the TC members: having util-linux-extra conflict with the perl
rename while it contains other binaries is undesirable, and a more
fine-grained solution would be preferred. Or just provide it under the
old name.

Could you outline the plan you have with bringing rename(.ul) back?
Would it be possible to give us feedback until the end of this month,
so we can wrap it up before the next TC meeting?

Thanks,
Christoph
Debian Technical Committee

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

[Christoph Berg]

Re: Chris Hofstaedtler
> >  * which binary package should contain the util-linux rename?
> >- bsdextrautils
> >- something else
> 
> util-linux-extra. Unrelatedly, other non-essential binaries from
> util-linux should also move into this package, but this is only
> tangentially related.

Hi,

I like that package name.

> >  * where should it be installed?
> >- /usr/bin
> >- something else?
> 
> /usr/bin/rename

> >  * should there be a Conflicts or Breaks relation with the perl rename?
> 
> I think this will be necessary.

The problem here is that if ul-extra contains things besides rename,
and it conflicts with the perl rename, people will rightfully complain
that they can't install /usr/bin/fincore-from-ul-extra and
/usr/bin/rename-from-perl at the same time.

Or would you solve that using alternatives, without the conflicts?

(Fwiw I believe the strict rule "alternatives only for compatible
interfaces" doesn't apply here - we are looking for a workaround, and
there is no rule saying that only hacks X, Y, Z must be used for
these. If alternatives are the best tool for the job, it should be
used.)

Christoph

Re: Next Meeting -- 8th March at 7pm UTC

[Christoph Berg]

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

I was tasked with mailing the OP with the question if they think that
rename.pl-or-what's-it-called should be in PATH or not.

Since my opinion is that things we are shipping should be in PATH (or
they aren't relevant), I refrained from sending that mail. (I couldn't
think of how to phrase the question anyway.)

Sorry for the late notice.

Christoph

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

[Christoph Berg]

Re: Chris Hofstaedtler
> Then all of this is a completely pointless exercise. Either we break
> them, or it is favorable to keeping the way things are:
> 
> A very valid way of closing this discussion is saying "our
> (Perl) /usr/bin/rename is great, people should use that".

We seem to all agree that renaming the different rename
implementations is not helpful now, but there is still the original
question if ul's rename.ul could be put back to where it was before
the bullseye release. In the same package or a separate one.

Christoph

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

[Christoph Berg]

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

I vote

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

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

Re: Sean Whitton
> Hello,
> 
> On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:
> 
> > I guess the best thing would be to introduce a new binary package,
> > but I am out of ideas on naming it. Open for ideas here.
> 
> util-linux-extra?

If it's about rename only, "rename-ul" or even "rename.ul"?

I guess it should also contain the historical name as a symlink.

Christoph

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

[Christoph Berg]

Re: Don Armstrong
> > I understand the perl group maintainer scripts switched to using the
> > /usr/bin/file-rename name. We could investigate rdeps of rename and
> > see what they use, and/or change them.
> 
> This problem goes beyond reverse dependencies; there are also a
> not-insignificant number of user scripts which on Debian expect
> /usr/bin/rename to be the perl version (and probably a similar number on
> other distributions which expect the opposite).
> 
> Not impossible to change, of course, but an ideal transition would avoid
> breaking currently working scripts and installs.

We were discussing the bug in last week's tech-ctte meeting, and the
gist of the discussion was that, in a ideal world, Debian would be
shipping the util-linux version as /usr/bin/rename to match what other
distributions are shipping, but that since we have been shipping the
Perl rename for the past 20 years, a proper transition would be very
hard. Especially in the light that this is an end-user tool and not
something we can control by a MBF and a lot of patches.

Unfortunately the current defaults seem to be that we have neither,
none of my systems has any "rename" command. OTOH that might indicate
there's a head-start on a transition introducing u-l's rename as
/usr/bin/rename.

Chris, would u-l be willing to reintroduce rename, or do you rather
want to reduce the number of commands?

Maybe if alternatives are not the correct tool, moving the u-l rename
to a separate package, and conflicting with the perl rename is better?
(Still ugly, but the situation isn't ideal.)

Christoph

Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon

[Christoph Berg]

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

I vote M = H > F.

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

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

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

Re: Simon McVittie
> 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".

I vote 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 consecutive releases, and the technical committee expects
> maintainers to 

Bug#994275: Draft resolution for reverting changes in debianutils

[Christoph Berg]

Re: Adam Borowski
> I'm even considering a MBF to go the _other_ way: change all but most
> obviously correct uses of `command -v` to `which`.

Please just don't.

Christoph

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

[Christoph Berg]

Re: To 985...@bugs.debian.org
>   A > B = C = D = E = F = G > H

I vote

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

Christoph


signature.asc
Description: PGP signature

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

[Christoph Berg]

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

I vote

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

Christoph


signature.asc
Description: PGP signature