Re: Luca Boccassi
> > BEGIN BALLOT
> >
> > The Technical Committee declines to overrule the maintainer of
> > base-files, or issue any advice on issues concerning /etc/os-release.
> >
> > We do not think there is a clear proposal on the table for us to assess,
> > and we do not think it is appropri
Re: Sean Whitton
> It has been an honour.
Thank you!
> ===BEGIN BALLOT
>
> 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 BALLOT
> ===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: 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
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
> === 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 expe
> A user requested in Debian bug report #926637
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926637) to include
> rename.ul in Debian's alternatives system. The package maintainer replied:
>
> "The util-linux rename command does not implement the same (command line)
> interface as the alte
Re: Sean Whitton
> ===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.
Christoph
signature.asc
Description: PGP signat
> ===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 numb
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 "
> ===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 t
> * 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
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
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: 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.
> ===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 di
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: 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 p
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.
Christo
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
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: 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: 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
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
> As they say: so long, and thanks for all the fish :)
All the best for you!
Christoph
Re: Luca Boccassi
> for now we'll stay the course.
Thanks for working on this and the well-written summary mails!
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 until
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 si
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: 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 ho
> === 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 mov
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 maintain
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: 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 signa
> ===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: 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
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 th
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 p
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: 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 shoul
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
f
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
> ===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, we'
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
Re: Luca Boccassi
> The TL;DR is a request to override the base-files maintainer, and
> enable moving os-release into a new, independent and separate source
> package, so that these bugs may finally be fixed, and Debian's os-
> release may finally be made compliant with the specification.
If we ar
Re: Matthew Vernon
> The maintainer is saying that "in all but unusual installations" a
> system-log-daemon would be found installed alongside hippotat-server.
I'm inclined to say logging should be a system facility and nothing
that a "normal" package should depend on. Then if I *don't* want
loggi
Re: Sean Whitton
> > Right, but times are changing. In the past, fail2ban could depend on
> > system-log-daemon and expect files in /var/log/ to appear, but
> > systemd/journalctl keep things elsewhere.
> >
> > Perhaps that is the issue we should be discussing?
>
> What issue exactly do you mean?
Re: Ansgar 🙀
> That would be an argument to *NOT* have random packages "Recommend:
> system-log-daemon" so it is easier to not have it installed at all.
That's what I was trying to say, yes.
> Having "system facilities" that the admins decide to install or not
> install makes keeping optional stu
Re: Matthew Vernon
> Hello,
>
> I call for votes on the below ballot. The vote is open for 7 days, or until
> the outcome is beyond doubt.
I vote
C > B = D > A
Christoph
signature.asc
Description: PGP signature
Re: Helmut Grohne
> > (S) The CTTE reaffirms that avahi-daemon is the default mDNS
> > implementation in Debian trixie. Therefore systemd-resolved should
> > disable the mDNS functionality in its default installation in Debian
> > trixie.
> > (Requires a 3:1 majority overruling a de
Re: Matthew Vernon
> ===BEGIN
> The Technical Committee recommends that Paul Tagliamonte (paultag) be
> appointed by the Debian Project Leader to the Technical Committee.
>
> H: Recommend to Appoint Paul Tagliamonte (paultag)
> F: Further Discussion
> ===END
I vote
H = P > F
Christoph
signa
> === BEGIN
>
> A: Christoph Berg
> B: Helmut Grohne
> C: Matthew Garrett
> D: Stefano Rivera
> E: Timo Röhling
> F: Craig Small
> G: Paul Tagliamonte
> H: Matthew Vernon
>
> === END
I vote
H > A = B = C = D = E = F > G
Christoph
signature.asc
Description: PGP signature
Re: Matthew Garrett
> B) The Technical Committee requests that base-files create an empty
^^
> /usr/lib64 directory, even on architectures that do not use lib64. If
> systemd creates a symlink, this will then match the behaviour of
> base-files
Re: Matthew Vernon
> On 26/02/2025 16:38, Christoph Berg wrote:
> > Re: Matthew Garrett
> > > B) The Technical Committee requests that base-files create an empty
> > ^^
> > > /usr/lib64 directory, even on archit
Re: Matthew Garrett
> A) The Technical Committee affirms that base-files should own all
> top-level filesystem aliases, and packages that conflict with this must
> be patched in Debian to avoid creating any aliases that conflict with
> base-files (overrules the systemd maintainer, requires 3:1 m
61 matches
Mail list logo
