On Mon, 7 Apr 2025 at 16:27, Helmut Grohne wrote:
>
> Dear release team,
>
> it seems likely that britney will consider the current systemd upload as
> ok for migration. However, it still does not include the changes imposed
> by the Debian technical committee. Negotiation about the inclusion of
>
FYI I have uploaded the backport for #1079329 too a few hours ago,
although it seems stuck somewhere in the ftp machinery - I checked
logs and multiple source uploads seem to be affected, so probably
nothing to worry about and just need to wait a bit:
https://alioth-lists.debian.net/pipermail/pkg-
On Wed, 7 Aug 2024 at 16:57, Christoph Berg wrote:
>
> 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.
> > &
On Wed, 7 Aug 2024 at 07:54, Sean Whitton wrote:
>
> Hello,
>
> On Tue 06 Aug 2024 at 11:45pm +01, Luca Boccassi wrote:
>
> > It's just a bunch of emails. I have no idea where that is coming from,
> > because it's certainly not the intention. Your guess abo
On Tue, 6 Aug 2024 at 20:53, Marc Haber wrote:
>
> Hi,
>
> I am in favor of your request.
>
> On Tue, Aug 06, 2024 at 05:28:57PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 16:43, Helmut Grohne wrote:
> > > I kindly ask you to stop posting to
On Tue, 6 Aug 2024 at 16:55, Wouter Verhelst wrote:
>
> On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst wrote:
> > > The question is:
> > >
> > > what is, exactly, the problem that the os-re
On Tue, 6 Aug 2024 at 16:43, Helmut Grohne wrote:
>
> Hi Luca,
>
> I kindly ask you to stop posting to this bug and mailing list for at
> least 24h from now. Multiple participants have asked you to improve the
> way you interact. I am not seeing such improvement and remind you of the
> Debian Code
On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst wrote:
>
> On Tue, Aug 06, 2024 at 10:11:05AM +0100, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst wrote:
> > > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > > > That would
On Tue, 6 Aug 2024 at 13:36, Sean Whitton wrote:
>
> Hello,
>
> I call for votes on the following:
>
> =
> 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 clea
On Tue, 6 Aug 2024 at 11:40, Matthew Vernon wrote:
>
> On 06/08/2024 11:22, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 11:10, Matthew Vernon wrote:
> >>
> >> Hi,
> >>
> >> On 06/08/2024 10:42, Luca Boccassi wrote:
> >>
> >>>
On Tue, 6 Aug 2024 at 11:37, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Tue, Aug 06, 2024 at 10:42:28AM +0100, Luca Boccassi wrote:
> > that matters. This is not a hard technical problem with no known
> > solution that we are asking for design guidance on. This is a trivi
On Tue, 6 Aug 2024 at 11:26, Matthew Vernon wrote:
>
> On 06/08/2024 11:22, Luca Boccassi wrote:
> > On Tue, 6 Aug 2024 at 11:10, Matthew Vernon
> > wrote:
>
> >> The policy question of "should testing and unstable be
> >> differentiated by os-release&
On Tue, 6 Aug 2024 at 11:10, Matthew Vernon wrote:
>
> Hi,
>
> On 06/08/2024 10:42, Luca Boccassi wrote:
>
> > This is not a hard technical problem with no known solution that we
> > are asking for design guidance on. This is a trivial technical
> > problem with a
On Tue, 6 Aug 2024 at 04:12, Sean Whitton wrote:
>
> Hello Gioele,
>
> On Mon 05 Aug 2024 at 08:34am +02, Gioele Barabucci wrote:
> > Couldn't the CTTE just rule on the question:
> >
> > * should Debian provide a way to distinguish between the two
> > similar-but-not-identical, rolling, ephemeral
On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst wrote:
>
> On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst wrote:
> > >
> > > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > >
On Mon, 5 Aug 2024 at 13:04, Luca Boccassi wrote:
>
> On Mon, 5 Aug 2024 at 08:42, Helmut Grohne wrote:
> >
> > Hi Gioele,
> >
> > On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote:
> > > as the maintainer (and upstream author) of the curren
On Mon, 5 Aug 2024 at 08:42, Helmut Grohne wrote:
>
> Hi Gioele,
>
> On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote:
> > as the maintainer (and upstream author) of the current lsb_release
> > implementation used in Debian and derivatives (src:lsb-release-minimal), I'd
> > like to
On Mon, 5 Aug 2024 at 08:39, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Fri, Aug 02, 2024 at 04:17:43PM +0100, Luca Boccassi wrote:
> > Validating is of course necessary. If the worry is around changing the
> > dependencies of base-files, I would be happy to carry the de
On Mon, 5 Aug 2024 at 09:39, Marc Haber wrote:
>
> On Mon, Aug 05, 2024 at 09:25:31AM +0100, Simon McVittie wrote:
> > * Some package, let's call it foobar, reads os-release and changes its
> > behaviour according to whether it sees trixie/testing or unstable
> >
> > * foobar_1.2-3 is in unstabl
On Mon, 5 Aug 2024 at 12:21, Luca Boccassi wrote:
>
> On Mon, 5 Aug 2024 at 03:15, Sean Whitton wrote:
> >
> > Hello,
> >
> > So far, although many people are sympathetic to the frustration at
> > distinguishing testing from unstable in practice, I don'
On Mon, 5 Aug 2024 at 03:15, Sean Whitton wrote:
>
> Hello,
>
> So far, although many people are sympathetic to the frustration at
> distinguishing testing from unstable in practice, I don't believe anyone
> has spoken in favour of overriding Santiago, besides Luca.
To clarify, do you mean "TC me
On Mon, 5 Aug 2024 at 01:07, Timo Röhling wrote:
>
> Hi,
>
> * Luca Boccassi [2024-08-03 16:15]:
> >The only question is whether they do that and then say "it's nice
> >that we have a common, standard, agnostic way of figuring this out
> >and it just
On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst wrote:
>
> On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote:
> > > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > &g
On Sun, 4 Aug 2024 at 00:25, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > A trixie image is now in development, will become stable at some point
> > next year, will gain security support where it now has none, then it
> > will pass to the LTS team, then it will
On Sat, 3 Aug 2024 at 19:28, Wouter Verhelst wrote:
>
> On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote:
> > Testing and unstable have completely separate and independent
> > archives, you can point an image builder to one OR the other, in
> > isolation, and
On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> > 1) The os-release specification must be adhered to, and it must be
> > possible to tell the difference between testing vs unstable, and ea
On Sat, 3 Aug 2024 at 12:39, Sebastian Ramacher wrote:
>
> On 2024-08-03 12:20:09 +0200, Paul Gevers wrote:
> > Hi
> >
> > On 03-08-2024 11:58, Luca Boccassi wrote:
> > > > On the use of tpu:
> > > > Personally, until now I fail to see enough val
On Sat, 3 Aug 2024 at 11:20, Paul Gevers wrote:
>
> Hi
>
> On 03-08-2024 11:58, Luca Boccassi wrote:
> >> On the use of tpu:
> >> Personally, until now I fail to see enough value of being able to
> >> distinguish unstable and testing to give the package ca
On Fri, 2 Aug 2024 at 21:06, Sam Hartman wrote:
>
> >>>>> "Luca" == Luca Boccassi writes:
>
> Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote:
> >>
> >> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wr
On Sat, 3 Aug 2024 at 10:51, Paul Gevers wrote:
>
> Hi,
>
> [Release Team member hat on, but I only voice my opinion as a member].
>
> On the use of tpu:
> Personally, until now I fail to see enough value of being able to
> distinguish unstable and testing to give the package carrying
> /etc/os-re
On Sat, 3 Aug 2024 at 05:23, Sean Whitton wrote:
>
> Hello,
>
> Luca is the upstream maintainer of the specification, but whether and
> how the specification as published applies to Debian is not simply up to
> his assertion.
To be really really precise, what I asserted is that the
implementation
On Fri, 2 Aug 2024 at 18:01, Russ Allbery wrote:
>
> Simon McVittie writes:
> > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> >> Luca Boccassi writes:
>
> >>> It is correct as-is. VERSION_ID is meant to identify a release, not
> >>
On Fri, 2 Aug 2024 at 17:07, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > That's yet another Debian-specific workaround. The point of this is,
> > again, answering the question "what is this vendor tree" _without_
> > distro specific kludges.
binary package in init-system-helpers, which is
already Essential: yes. I already did something similar in Bookworm to
force all installations to become usrmerged, and I do not recall issues
with the bootstrapping order. This would be even easier in practice as
the new package would have a single f
On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote:
>
> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> > To further clarify why the status quo with VERSION_CODENAME=trixie in
> > sid is really bad: it used to be that if you had "debian" mentioned in
On Fri, 2 Aug 2024 at 12:48, Simon McVittie wrote:
>
> On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
> > VERSION_CODENAME=trixie was added, and the problem as explained is
> > that it's present in sid too. So the only identifier we have in sid,
> > iden
On Fri, 2 Aug 2024 at 11:35, Luca Boccassi wrote:
>
> On Fri, 2 Aug 2024 at 10:15, Simon McVittie wrote:
> > So I think Luca really has two distinct change requests here, not just one:
> >
> > 1. Label testing as Debian 13 starting from the beginning of the trix
On Fri, 2 Aug 2024 at 11:39, Matthew Vernon wrote:
>
> Hi,
>
> With my jaunty TC member hat on, I would prefer if issue came to us with
> a description of both sides' perspective on the discussion that they
> would view as fair. In any case, I hope that Santiago will feel able to
> chime in with t
On Fri, 2 Aug 2024 at 10:15, Simon McVittie wrote:
> The closest equivalent of what Fedora and Ubuntu do would be to label
> both testing and unstable as though they were some sort of Debian 13
> prerelease, but not distinguish between the two. But Luca is asking for
> unstable images/chroots/inst
On Fri, 2 Aug 2024 at 10:09, Simon McVittie wrote:
>
> On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> > The second [objection from the base-files maintainer] is pushing forward a
> > philosophical explanation according to which testing and unstable are
> >
On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > It could be a dependency of something else, or it could be marked as
> > essential itself, given the content is a 5 lines text file and a symlink
> > it shouldn't be too hard to
On Thu, 1 Aug 2024 at 20:06, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > I was about to say that the proposal is in the linked bug, but it has
> > disappeared - it could be due to the bugs getting unlinked. Anyway, my
> > variant is here:
>
>
On Thu, 1 Aug 2024 at 18:33, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > There are several different ways of having different content in sid vs
> > testing, and some have been proposed in the latest bug linked above, I
> > would be happy to discuss th
On Thu, 1 Aug 2024 at 17:32, Christoph Berg wrote:
>
> 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 b
quired.
I volunteer to do the work to create and team-maintain the new package,
and provide a patch to do the move from base-files. If requested, I am
happy to do such work in advance so that you can judge based on
something concrete.
Thank you for your consideration.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
On Fri, 1 Sept 2023 at 09:23, Helmut Grohne wrote:
>
> Hi Luca,
>
> At least three DDs have asked you to stop. Why do you continue?
>
> In all of your mails to this bug, I've seen little attempt at trying to
> understand other participants. In a project as large as Debian, it is to
> be expected t
On Wed, 30 Aug 2023 at 12:57, Ian Jackson
wrote:
>
> On the burden of proof and the correctness of software:
>
> I'm afraid I see a pattern, where blanket statements are made which
> are only "mostly" or "roughly" or "generally" true. But the
> discrepancies and details matter. When we make comp
On Thu, 31 Aug 2023 at 10:48, Sean Whitton wrote:
>
> Hello,
>
> On Sat 26 Aug 2023 at 03:47pm +01, Luca Boccassi wrote:
>
> >> On Wed, 23 Aug 2023 at 10:35:42 +0100, Luca Boccassi wrote:
> >> > Suse [...] tried [symlink farms similar to those that Ian propos
On Sun, 27 Aug 2023 at 11:30, Matthew Vernon wrote:
>
> Dear Luca,
>
> On 27/08/2023 03:16, Luca Boccassi wrote:
>
> [things]
>
> You've already been asked by a couple of people to moderate your tone in
> this thread. I appreciate there is a lot of frustrati
On Sun, 27 Aug 2023 at 18:03, Sam Hartman wrote:
>
>
> TL;DR: I think I understand one of Ian's points. I explain, but do not
> believe it is compelling as an argument to switch direction.
>
> > "Helmut" == Helmut Grohne writes:
> >> I think "package management" is the wrong term here.
On Sat, 26 Aug 2023 at 11:27, Ian Jackson
wrote:
>
> Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing"):
> > On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> > > And, the approach being taken very seriously privileges Debian itself,
> > > and those well-staffed deriva
On Sat, 26 Aug 2023 at 23:19, gregor herrmann wrote:
>
> On Sat, 26 Aug 2023 15:47:51 +0100, Luca Boccassi wrote:
>
> > On Wed, 23 Aug 2023 at 20:12, Simon McVittie wrote:
> > > I would very much prefer it if we can keep this conversation respectful,
> […]
&g
and hence interpreting attempts to propose yet another different and
incompatible layout (only and solely for the benefit of the hopelessly
broken dpkg tool) as sealioning is not disrespectful, on the contrary
it is the most charitable interpretation possible.
> On Wed, 23 Aug 2023 at 10:35:42 +0
On Mon, 21 Aug 2023, 02:35 Sam Hartman, wrote:
> > "Adam" == Adam Borowski writes:
> Adam>all
> Adam> files from /lib /bin (that are not required interface, such as
> Adam> /bin/sh -- which can be symlinked) are moved within a week
> Adam> from the first upload. Rather than taki
On Sun, 16 Jul 2023 12:54:35 +0100 Simon McVittie
wrote:
> On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote:
> > In the meanwhile, I'll immediately revert the sabotage.
>
> Both of you, please don't turn this into an NMU war in the archive:
> that doesn&#x
s://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93
http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-07-11-17.58.log.html
Debian Community Team, Adam is once again sabotaging the CTTE's work
with hostile NMUs, could you please intervene? Thank you.
In the meanwhile, I'll
dpkg is allowed
> to run its course then the warning will probably go away anyway.
That assumes all derivatives track unstable/testing and have taken
action, but it is possible for derivatives to track stable only, and
those would be broken.
Kind regards,
Luca Boccassi
On Tue, 23 May 2023 at 17:48, Paul Gevers wrote:
>
> Hi,
>
> On 21-05-2023 21:22, Luca Boccassi wrote:
> > 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 unb
On Mon, 22 May 2023 at 23:07, Sam Hartman wrote:
>
> >>>>> "Luca" == Luca Boccassi writes:
>
> >> I suspect the reason you want to make this MBF is that you
> >> believe it
> Luca> will somehow make the transition easie
On Mon, 22 May 2023 at 22:40, Sam Hartman wrote:
>
> ;>>>>> "Luca" == Luca Boccassi writes:
> Luca> So what you are worried is the combination of a testing
> Luca> installation from~one year ago, that is otherwise never
> Luca> touch
On Mon, 22 May 2023 at 22:13, Étienne Mollier wrote:
>
> Luca Boccassi, on 2023-05-22:
> > On Mon, 22 May 2023 at 20:34, Sam Hartman wrote:
> > >
> > > >>>>> "Luca" == Luca Boccassi writes:
> > >
> &g
On Mon, 22 May 2023 at 20:34, Sam Hartman wrote:
>
> >>>>> "Luca" == Luca Boccassi writes:
>
> Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman
> wrote:
> >>
> >> >>>>> "Luca" == Luca Boccassi wr
On Mon, 22 May 2023 at 20:22, Sam Hartman wrote:
>
> >>>>> "Luca" == Luca Boccassi writes:
>
> Luca> Hello Release Team, If we were to do a MBF against packages
> Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or
>
On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote:
>
> On Sun, 21 May 2023 at 20:29, Christoph Berg wrote:
> >
> > Re: Luca Boccassi
> > > If we were to do a MBF against packages that in _Bookworm_ have
> > > introduced new files in /bin, /sbin or /lib*, w
On Sun, 21 May 2023 at 20:29, Christoph Berg wrote:
>
> 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 w
m, but that ship has sailed.
Thanks!
Kind regards,
Luca Boccassi
and the 'unmess' tool cause significant damage and break
cross-compatibility, so they both need to be removed.
A "mind the moratorium" message would be of course very sensible to have.
Kind regards,
Luca Boccassi
re is some reason to believe something will change within a
> reasonable period of time (which I don't see happening).
We heard so much in the past couple of weeks about how important it is
for the project not to cause issues for derivatives and
cross-compatibility use cases, even speculatively. This is not even
speculative, it is certain to cause damage (as we experienced first
hard last year), I don't see how we can ignore it after all of these
discussions.
Kind regards,
Luca Boccassi
On Tue, 16 May 2023 at 09:27, Simon McVittie wrote:
>
> On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote:
> > This sounds like a very interesting use case, and the first real one
> > mentioned, which is great to see - but I do not fully follow yet, from
> > what
nt one? It's your
executables that you ship as part of that runtime that are the entry
points that need the usual loader path for your chroot-on-steroids,
no? The loader would still be reachable as it always was in this
theoretical exercise. I am probably missing something in how this
works in details.
Kind regards,
Luca Boccassi
On Mon, 15 May 2023 at 16:18, Russ Allbery wrote:
>
> Luca Boccassi writes:
> > On Mon, 15 May 2023 at 02:26, Russ Allbery wrote:
>
> >> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh,
> >> major player in Linux distributions, and I'm
doing merged-/usr have done it without
> making this change, and it's also been working OK for us so far
> without this change.
That is absolutely true, it is not mandatory. It is one possible
solution (of many) to a particular use case being sounded out, that's
all. I don't think it was mentioned by anybody as needed, if it was,
happy to clarify.
Kind regards,
Luca Boccassi
stification for further harm to user and system expectations isn't
> compelling.
Are you able to provide an example of such "harm"?
Kind regards,
Luca Boccassi
On Mon, 15 May 2023 at 02:26, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > That's self-evidently not true, as there are other distributions where
> > that already happens, it's been already mentioned.
>
> You've mentioned this a couple of times
On Mon, 15 May 2023 at 01:14, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > Why would "software compiled on Debian" fail to work in other
> > environments? Well, there are many reasons actually, people invented
> > containers/flatpaks/snaps exactly
On Mon, 15 May 2023 at 01:07, Peter Pentchev wrote:
>
> On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> > On Sun, 14 May 2023 at 22:37, Josh Triplett wrote:
> > >
> > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > >
On Sun, 14 May 2023 at 22:37, Josh Triplett wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > The loader is still available via the old path, so external/third
> > party/local/other software works unchanged. This should negatively
> > only affec
On Fri, 12 May 2023 at 15:30, Steve McIntyre wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> >On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote:
> >>
> >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
> >> &g
On Fri, 12 May 2023 at 13:21, Simon Richter wrote:
>
> Hi,
>
> On 5/12/23 02:51, Luca Boccassi wrote:
>
> > Or alternatively, we can establish that a documentation/post-facto
> > approach is enough for derivatives, and then that's valid for all
> > changes a
On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote:
>
> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
> >>>
> >>
On Fri, 12 May 2023 at 11:40, Steve McIntyre wrote:
>
> On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
> >>
> >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >> >
>
e are discussing a bunch of
seemingly crazy options, as in, "what would _actually_ explode if we
do this or do that?", on this very d-devel thread. I posted a longer
version here some days ago:
https://lists.debian.org/debian-gcc/2023/05/msg00030.html
Kind regards,
Luca Boccassi
this context either, and it must be fixed
instead.
Or alternatively, we can establish that a documentation/post-facto
approach is enough for derivatives, and then that's valid for all
changes and transitions.
Either of these are valid approaches.
What I cannot find acceptable is that some ch
On Sat, 2022-09-17 at 02:30 +0100, Luca Boccassi wrote:
> On Thu, 2022-09-15 at 22:57 +0100, Luca Boccassi wrote:
> > On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote:
> > > Hi,
> > >
> > > the transition to usrmerge as described in [1] is planned to
>
On Wed, 2022-09-28 at 09:51 +0200, Helmut Grohne wrote:
> Hi Luca,
>
> As much as I agree with you on other matters...
>
> On Tue, Sep 27, 2022 at 09:11:18PM +0100, Luca Boccassi wrote:
> > baseless, patently false statements - I frankly find it quite upsetting
> > t
tems are merged-usr, and it also means that
changes of any kind will very likely not be held back on the off-chance
that they might not work on unmerged systems (and no testing will be
required to detect that either). There are already taints in place to
detect unmerged systems.
In other words, one is of course free to do as they wish on their
systems, but they also get to keep the pieces.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
->
bookworm that fails to boot. Should be easy enough, given it
*allegedly* affects all systems (despite of course nobody ever having
seen anything remotely like it, ever, over the course of several
years), no? We'll be eagerly waiting for a detailed and evidence-based
report.
In the meanwhile,
On Sat, 2022-09-10 at 13:37 +0100, Luca Boccassi wrote:
> On Tue, 2022-08-16 at 21:06 +0100, Luca Boccassi wrote:
> > On Thu, 2022-07-28 at 13:14 +0100, Luca Boccassi wrote:
> > > On Sun, 2022-07-17 at 00:56 +0100, Luca Boccassi wrote:
> > > > On Mon, 2021-10-18 at 1
On Tue, 2022-08-16 at 21:06 +0100, Luca Boccassi wrote:
> On Thu, 2022-07-28 at 13:14 +0100, Luca Boccassi wrote:
> > On Sun, 2022-07-17 at 00:56 +0100, Luca Boccassi wrote:
> > > On Mon, 2021-10-18 at 12:17 -0700, Sean Whitton wrote:
> > > > Hello,
> > > &
On Thu, 2022-07-28 at 13:14 +0100, Luca Boccassi wrote:
> On Sun, 2022-07-17 at 00:56 +0100, Luca Boccassi wrote:
> > On Mon, 2021-10-18 at 12:17 -0700, Sean Whitton wrote:
> > > Hello,
> > >
> > > On Wed 15 Sep 2021 at 11:46AM +01, Simon McVittie wrote:
>
On Sun, 2022-07-17 at 00:56 +0100, Luca Boccassi wrote:
> On Mon, 2021-10-18 at 12:17 -0700, Sean Whitton wrote:
> > Hello,
> >
> > On Wed 15 Sep 2021 at 11:46AM +01, Simon McVittie wrote:
> >
> > > As discussed in our last meeting, I think we should issue mo
On Mon, 2022-07-18 at 21:34 +0100, Luca Boccassi wrote:
> On Mon, 2022-07-18 at 22:10 +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Hi,
> >
> > Quoting Luca Boccassi (2022-07-18 21:03:14)
> > > It was renamed following a request on #debian-ftp
dy to move
> forward.
Very well put Sam, thank you. The governance issue comes first, the
CTTE needs to solve that, and only then it will be fair to ask for
volunteers do donate their time to work on the technical issue. The
other way around is just not going to happen.
Expecting volunteers to work in such a hostile environment and
describing their lack of willingness to do so as "it's too much hassle"
is very unfair.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
On Tue, 2022-07-19 at 13:42 +0100, Luca Boccassi wrote:
> On Tue, 2022-07-19 at 13:03 +0100, Simon McVittie wrote:
> > On Sun, 17 Jul 2022 at 14:21:30 +0100, Luca Boccassi wrote:
> > > By keeping
> > > the buildds in umerged-usr state for Bookworm, and switching
On Tue, 2022-07-19 at 13:42 +0100, Luca Boccassi wrote:
> On Tue, 2022-07-19 at 13:03 +0100, Simon McVittie wrote:
> > On Sun, 17 Jul 2022 at 14:21:30 +0100, Luca Boccassi wrote:
> > > So the reasoning behind adding the override to debootstrap in --
> > > var
On Tue, 2022-07-19 at 13:49 +0100, Simon McVittie wrote:
> On Tue, 19 Jul 2022 at 13:42:21 +0100, Luca Boccassi wrote:
> > And before release day, there's no such thing as a bookworm buildd,
> > right? Everything is built in unstable?
>
> As far as I know, bookworm bu
On Tue, 2022-07-19 at 13:03 +0100, Simon McVittie wrote:
> On Sun, 17 Jul 2022 at 14:21:30 +0100, Luca Boccassi wrote:
> > So the reasoning behind adding the override to debootstrap in --
> > variant=buildd mode is twofold.
> >
> > From a very practical perspective,
On Sun, 2022-07-17 at 14:21 +0100, Luca Boccassi wrote:
> On Sun, 2022-07-17 at 11:34 +0100, Simon McVittie wrote:
> > On Sun, 17 Jul 2022 at 00:56:14 +0100, Luca Boccassi wrote:
> > > Piuparts has been enhanced with a new test case that covers the
> > > moratorium on mo
On Mon, 2022-07-18 at 16:52 +0100, Luca Boccassi wrote:
> On Mon, 2022-07-18 at 14:32 +0200, Helmut Grohne wrote:
> > > Once deboostrap is updated and deployed on the buildds, a "usrmerge |
> > > usr-is-merged" dependency will be added to the Priority: essential
&g
On Mon, 2022-07-18 at 22:10 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Hi,
>
> Quoting Luca Boccassi (2022-07-18 21:03:14)
> > It was renamed following a request on #debian-ftp while it was in
> > NEW, as the
> > feedback was that 'usrmerge' and
1 - 100 of 115 matches
Mail list logo
