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 about languages
> > is probably accurate.
>
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 about languages
> is probably accurate.
Your use of English suggests to me you have native or near-native
Hello,
On Tue 06 Aug 2024 at 05:42pm +02, Helmut Grohne wrote:
> 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 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 this bug and mailing list for at
> > > least
On Tue, 6 Aug 2024 17:55:23 +0200 Wouter Verhelst wrote:
- Gioele's message is about reimplementing lsb_release in terms of
os-release.
Not really. lsb_release has already been reimplemented purely in terms
of os-release since bookworm. Even the older Python version used
os-release as the
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 this bug and mailing list for at
> > least 24h from now. Multiple participants have asked you to improve t
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-release specification is
> > > supposed t
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, 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-release specification is
> > supposed to solve? And how does unstable and testing being
> > undistinguis
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 of Conduct available at
https://www.debian.org/code_of_conduct.
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 make it contradictory with itself
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 make it contradictory with itself and everything else that
> > > uses it, so it's not a change th
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:
> >>
> >>> This is not a hard technical problem with no known solution that we
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:
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 hard s
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 trivial
> > technical problem wit
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 trivial
> technical problem with a hard social conflict at its core. What we are
That's actual
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" isn't straightforward, and there
> >> isn't
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" isn't straightforward, and there
isn't consensus that the answer should be "yes", as you would like
it to be.
De
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 hard social conflict at its core.
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 hard social conflict at its core. What we are really
blocked on is that the current owner of os-release
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 Fri, 2 Aug 2024 at 21:29, Helmut Gro
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 Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote:
> > > > > 2) Testing and unstable can continue to rem
Hello,
On Mon 05 Aug 2024 at 12:21pm +01, 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't believe anyone
>> has spoken in fav
Hello Gioele,
On Mon 05 Aug 2024 at 08:34am +02, 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 voice my support in favor of having enough information in
> /usr/l
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 current lsb_release
> > > implementation used i
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 dependency on
> > a new os-rele
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't believe anyone
> > has spoken in favour of
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 works (TM) on Debian too", or, "man this Debia
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 unstable and works correctly there
>
> * The testing migration sc
On Mon, 05 Aug 2024 at 09:02:51 +0200, Marc Haber wrote:
> On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote:
> > > If trixie was identified as trixie, and sid was identified as unstable,
> > > what compromise would be, er, compromised, precisely?
> > Unstable would become less useful at
On 05/08/24 09:38, Helmut Grohne wrote:
| The Technical Committee restricts itself to choosing from or adopting
compromises between solutions and decisions which have been proposed and
reasonably thoroughly discussed elsewhere.
The path forward is then, to freeze this discussion and «reasonab
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 voice my support in favor of having enough information in
> /us
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 dependency on
> a new os-release binary package in init-system-helpers, which is
> already Es
On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote:
> Yet I cannot (painlessly) distinguish a Debian image that
> has been created with debootstrap from one that has been created with
> mmdebstrap either, and I'm not losing sleep about it.
Still it would actually be nice to have an indic
On Mon, 05 Aug 2024 10:12:40 +0800 Sean Whitton
wrote:
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.
Hi,
as the maintainer (and upstream aut
Apologies for formatting of the following; I'm reading this using Gmail on
an Android tablet with a virtual keyboard.
I've read much but not necessarily all of the thread, so the following
might have been mentioned and dismissed already. My apologies if this is
the case.
Reading the thread, it s
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.
Also, the Release Team aren't happy with Luca's plan, so even if the TC
were to override Sa
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 works (TM) on Debian too", or, "man this Debian thing
sure is a gigantic pile of rubbish, it's so painful to
Hi Wouter,
I am continuing the off-topic part below. Earlier, in this discussion I
noted that being able to distinguish testing and unstable is rarely the
right thing to do. I'll use your nbd example to show why. Everyone not
interested in nbd autopktests may stop reading here.
On Sun, Aug 04, 20
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
> > > > both be erroneously identified as trix
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
> > > both be erroneously identified as trixie
> >
> > Isn't there the third option of adhering to the os-r
On Sun, Aug 04, 2024 at 01:00:38PM +0200, Paul Gevers wrote:
> Hi Wouter,
>
> On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst wrote:
> > In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> > currently running". That code starts off with "parse os-release", and
> > then fall
On Sat, Aug 03, 2024 at 08:07:14PM +0200, Wouter Verhelst wrote:
> For what it's worth, I do have one argument in favour of your position.
> In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> currently running". That code starts off with "parse os-release", and
> then falls ba
Hi Wouter,
On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst wrote:
In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
currently running". That code starts off with "parse os-release", and
then falls back to a horrible horrible perl script that parses
apt-cache policy output
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 go EOL and any installation
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 go EOL and any installation will
> have to move to trixie + 1 which will be forky. The sa
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 it will produce a fully c
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 it will produce a fully complete and runnable and
> bootable OS tree. The fact that they
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 each
> > must be correctly i
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 value of being able to
> > > > distinguish unstable and
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 value of being able to
> > > distinguish unstable and testing to give the package carrying
> > > /etc/os-release a permanent
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 carrying
> >> /etc/os-release a permanent ex
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 wrote:
> >> > To further clarify why the status quo with
> >>
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 carrying
/etc/os-release a permanent exception via tpu.
Thanks for chiming in - assuming for a moment that it i
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
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-release a permanent exception via tpu.
On Debian version numbe
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
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.
The TC is being asked to override how Santiago has determined the
specification applies to Debian.
The Release Team's opinion is as
Hello,
On Fri 02 Aug 2024 at 12:19pm +01, Luca Boccassi wrote:
> Sorry, but there's no other way to define this than a bug. Well, there
> are many more I could mention, but then Russ would whip out the cane
> ;-)
Russ is not the only person who finds interactions with you difficult.
Please don't
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 each
> must be correctly identified by the respective metadata
Given the state of discuss
> "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 wrote:
>> > To further clarify why the status quo with
>> VERSION_CODENAME=trixie in > sid is really bad: it used to be
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
> >>> updates or point releases. A release as in, Debi
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
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>> 40, or Ubuntu Noble, and so on.
>>
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. That's the entire reason for os-release to
> >
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
> > updates or point releases. A release as in, Debian Bookworm, or Fedora
> > 40, or Ubuntu Noble, and so on.
>
> Why would you not want to i
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. That's the entire reason for os-release to
> exist. If the answer at any point is "check os-release AND THEN
On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne
wrote:
> Hi Russ,
>
> Let me adress the essential/bootstrap aspects of this sub-discussion
> only.
>
> On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> > Given that it's included in base-files now and base-files is
essential, I
> > b
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
> > os-release but no other versio
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,
> > identifies it as trixie, which is c
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
> os-release but no other version identifying fields, you knew you were
> on testing OR unstab
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,
> identifies it as trixie, which is categorically and unequivocally
> wrong.
When involved in a di
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 trixie
> >cycle, and the equivalent
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
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 their perspective.
My initial thought is that this is really
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
Hi Russ,
Let me adress the essential/bootstrap aspects of this sub-discussion
only.
On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> Given that it's included in base-files now and base-files is essential, I
> believe it has to continue to be provided by an essential package, unless
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
> > not actually different ima
On Fri, 02 Aug 2024 at 10:31:29 +0200, Marc Haber wrote:
> On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
> > I could echo "ID=windows 3.1" into my local
> > /etc/os-release and nothing would stop me or fix it until the next
> > stable release.
>
> Not even automatically. /etc/os-r
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 figure out an acceptable way to ensure
On Thu, 01 Aug 2024 at 20:00:40 -0700, Russ Allbery wrote:
> I just know that I've seen a lot of code that uses version
> numbers or code names this way, mostly in things like Puppet rules. Most
> of the time people will probably get this right, but there are some
> obvious potential mistakes such
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
> not actually different images, but they are one and the same (two sides
> of the same co
On Thu, Aug 01, 2024 at 11:51:45PM +0200, Helmut Grohne wrote:
> Conversely, I am unsure how to distinguish testing and unstable myself.
> Say I operate an unstable system and eventually decide that my ride is
> too bumpy and I prefer running testing, I may edit my sources.list and
> after a month
On Thu, Aug 01, 2024 at 12:06:21PM -0700, Russ Allbery wrote:
> The second thing that I'm not fond of is giving testing the version number
> 13 when we plan on using 13 as the version number for the trixie release.
> I fear that if we do that, someone (probably a third-party package
> provider) wil
On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
> The TL;DR: ensure that the version of the 'os-release' package with
> the content for unstable stays in unstable and never migrates, and the
> version of the 'os-release' package with the content for testing goes
> to testing either v
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 figure out an acceptable way to ensure it
> ships everywhere. It doesn't have to be related to base
On Thu, 1 Aug 2024 at 22:52, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote:
> > This is an escalation requesting a ruling on the matter of several
> > base-files bugs around its buggy implementation of the os-release
> > specification, the most
Hi Luca,
On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote:
> This is an escalation requesting a ruling on the matter of several
> base-files bugs around its buggy implementation of the os-release
> specification, the most recent example being #1021663 and other
> instances that I coul
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:
>
> > https://bugs.debian.org/cgi-bin/bugreport.cg
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:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54
Ah, thank you. I think that answers my questio
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 those details too if required.
>
> Gener
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 those details too if required.
Generally the technical committee works best if it can consider a con
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 be fixed, and Debian's os-
> > release
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
Package: tech-ctte
Dear CTTE,
This is an escalation requesting a ruling on the matter of several
base-files bugs around its buggy implementation of the os-release
specification, the most recent example being #1021663 and other
instances that I could find with a cursory look being #1008735 and
#67
98 matches
Mail list logo
