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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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: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 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 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 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 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 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 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 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.
> > &
ption 1, or the Fedora-option).
All in all, we have 2 real-world case studies.
- Fedora tried the usrmerge method, and succeeded
- SUSE tried the symlink-farm method, and (it appears) failed
Aside from all theoreticals and hyphoteticals, this seems to me to be a
pretty important real-world data p
merged-/usr.
>
> Given all new installations have been merged-/usr for years, it seems
> to work sufficiently well for real-world use.
And on top of new installations, old installations of Ubuntu upgrading
to 21.10 and/or the soon-to-be-released 22.04 have been forcifully
migrated too. They are not blocked, unsupported, or broken.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
al and the hundreds of
others are not.
In the end, at the very least this is a _workable_ proposal. It might
not be ideal, but we know it can work. What's your counter-proposal?
Sitting back and just saying "someone better get a fix into dpkg",
without neither doing it nor explaining _how_ that could ever be
possible is not a workable proposal, it's just doing nothing while
letting the clock run.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
On Thu, 2022-03-24 at 16:22 -0700, Russ Allbery wrote:
> Luca Boccassi writes:
>
> > If it was possible to do it, it would have already happened, and we
> > wouldn't be discussing it at all, it would have just been done.
>
> Has someone written a patch against
On Fri, 2022-03-25 at 14:30 +0100, Helmut Grohne wrote:
> On Fri, Mar 25, 2022 at 10:46:01AM +0000, Luca Boccassi wrote:
> > Let me reverse the question: this stuff has been known and going on for
> > what, 3 years? Why do _you_ think it is that nobody has stepped up to
> >
On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote:
> Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> > I am part of that group, and that is definitely _not_ why I wouldn't
> > touch dpkg with a barge pole as things stand (and have stood for
> > years).
On Fri, 25 Mar 2022 18:04:14 + Luca Boccassi
wrote:
> On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote:
> > Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> > > I am part of that group, and that is definitely _not_ why I
wouldn't
> > > touch
On Tue, 2022-03-29 at 08:24 +0200, Helmut Grohne wrote:
> Hi Luca,
>
> On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote:
> > Also worth noting that a couple of days ago, the author wrote on
> > #debian-devel that some time ago the patch was presented to the dpk
our core packages works in _reality_ (as
opposed as how we think it does or should work), doing what's best for
our users given the realities in the wider world, and how to deal with
a situation that is by now beyond disfunctional. I understand that it
might hurt to hear that the project one really cares about is in a bad
spot, but hiding these problems behind perceived technical issues is
not going to help resolve them.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
be necessary, the
normal apt upgrade/install process works as expected, and the
transition happens from a maintainer script and it does not require to
be ordered before or after any other package installation or upgrade.
All software has bugs by nature, and this will be no exception. But
with Ubun
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 moving files manually between their location in the
> > root
>
On Sun, 2022-07-17 at 14:12 +0100, Simon McVittie wrote:
> On Sun, 17 Jul 2022 at 11:34:36 +0100, Simon McVittie wrote:
> > On Sun, 17 Jul 2022 at 00:56:14 +0100, Luca Boccassi wrote:
> [some discussion of the transition to merged /usr]
>
> Please note that #994388 has been c
previous
> conversations.
>
> On Sun, Jul 17, 2022 at 12:56:14AM +0100, Luca Boccassi wrote:
> > A MR is pending for debootstrap [1] to make use of this new package and
> > file flag when --variant=buildd is passed, so that buildds can continue
> > to be unmerged-usr unti
On Mon, 2022-07-18 at 17:53 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Hi all,
>
> Quoting Luca Boccassi (2022-07-18 16:42:03)
> > On Mon, 2022-07-18 at 16:04 +0200, Johannes Schauer Marin Rodrigues
> > wrote:
> > > Hi Luca & Helmut,
> > >
>
On Mon, 2022-07-18 at 13:03 -0700, Tianon Gravi wrote:
> On Sun, 17 Jul 2022 at 06:21, Luca Boccassi wrote:
> > That's because we will do all builds on unmerged-usr, until we are
> > sure
> > everything is switched over (and the autopkgtest/piuparts can also
> > b
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
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 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 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 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: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: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
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 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
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 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 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 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
->
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,
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
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
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
>
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
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
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:
> >> >
>
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 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 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 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 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 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 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
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
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
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
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 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
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
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
m, but that ship has sailed.
Thanks!
Kind regards,
Luca Boccassi
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
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 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 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 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 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 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 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
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
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
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
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
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 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
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 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 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 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 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 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
1 - 100 of 115 matches
Mail list logo
