> ===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
>
> ===E
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
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
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
> === 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
> * 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
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.
> ===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
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
> ===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
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
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
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
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 com
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
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
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
> ===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
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
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
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
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: 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.
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
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
Re: Luca Boccassi
> for now we'll stay the course.
Thanks for working on this and the well-written summary mails!
Christoph
> As they say: so long, and thanks for all the fish :)
All the best for you!
Christoph
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
Re: Sean Whitton
> Therefore, we will likely just close this bug, I'm afraid.
+1 on closing from me.
Christoph
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
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
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
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
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
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
> ===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
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
> === 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
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: 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
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
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
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
> ===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
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,
45 matches
Mail list logo
