tools that parse core files and logs.
Tools for RPM and DEB (debhelper) integration are also available [3].
--
Kind regards,
Luca Boccassi
[0] https://github.com/systemd/systemd/issues/18433
[1] https://systemd.io/COREDUMP_PACKAGE_METADATA/
[2] https://fedoraproject.org/wiki/Changes/Package_informa
On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote:
> Hello,
>
> Cross-posting to the mailing lists of a few relevant projects.
>
> After an initial discussion [0], recently we have been working on a new
> specification [0] to encode rich package-level metadata inside ELF
On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2021-04-10 at 18:44 +, Zbigniew Jędrzejewski-Szmek wrote:
> > [I'm forwarding the mail from Luca who is not subscribed to fedora-
> > devel]
> > On Sat, Apr 10, 2021 at 01:38:31PM +0100
On Thu, 2021-05-06 at 03:17 +0200, Mark Wielaard wrote:
> Hi Luca,
>
> On Tue, 2021-05-04 at 14:43 +0100, Luca Boccassi wrote:
> > On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> > > Is there a list of default keys (and their canonical spelling, upper-
> >
On Fri, 2021-05-14 at 12:41 +0200, Guillem Jover wrote:
> On Sat, 2021-04-10 at 13:38:31 +0100, Luca Boccassi wrote:
> > On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote:
> > > After an initial discussion [0], recently we have been working on a new
> > > speci
m. Being able to know at a glance to the journal exactly what
is borken, with version info, is extremely valuable to them.
Yes the version info might not be precise for a minority of use cases
that override the binary version with something different than the
source version, but that's fine as it's far and few, mostly affects
metapackages, and even then it can be documented clearly that the
reference is to the source version, not the binary one.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
altogether, followed by a debhelper change to adjust any stragglers
automatically at build time and a mass rebuild, plus MBF for the small
% that does not use dh and a piuparts test to stop migration for
anything that is uploaded and doesn't comply. That should bring the
matter to an end, without needing to modify dpkg.
Kind regards,
Luca Boccassi
On Sat, 22 Apr 2023 at 11:41, Simon McVittie wrote:
>
> On Fri, 21 Apr 2023 at 15:29:33 +0100, Luca Boccassi wrote:
> > After Bookworm ships I plan to propose a policy change to the CTTE and
> > policy maintainers to forbid shipping files in the legacy directories
> > a
On Sat, 22 Apr 2023 at 11:50, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote:
> > After Bookworm ships I plan to propose a policy change to the CTTE and
> > policy maintainers to forbid shipping files in the legacy di
On Tue, 25 Apr 2023 at 20:07, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote:
> > On Sat, 22 Apr 2023 at 11:50, Helmut Grohne wrote:
> > > On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote:
> > &
ackage, that would get awkward to say the
least.
I really would like to move toward the direction of having exclusively
/usr and /etc shipped in data.tar, and everything else created locally
as needed, and that includes files in /.
Kind regards,
Luca Boccassi
ectly, by "forced via debhelper" you mean the
proposal of fixing the paths at build time, right? But if not via
that, it means having to fix all of them by hand, which is a lot - is
it possible to fix dash instead? Or else, we could add an opt-out via
one of the usual dh mechanisms, and
On Fri, 28 Apr 2023 at 10:12, Luca Boccassi wrote:
>
> On Fri, 28 Apr 2023 at 09:09, Helmut Grohne wrote:
> > So yeah, with the exception of dash, this looks fairly good. Let me also
> > dive into dash. Unlike the majority of diverters, it diverts in postinst
> > rath
s smaller, and we get in the final state on day one of trixie
dev cycle.
Moving files between packages already requires busywork anyway, so a
bit more won't hurt that much, especially if we figure out a way to
provide the functionality with a dh addon or such to do the heavy
lifting.
Kind regards,
Luca Boccassi
On Sat, 6 May 2023 at 06:21, Simon Richter wrote:
>
> Hi,
>
> On 06.05.23 07:11, Luca Boccassi wrote:
>
> > - every package is forcefully canonicalized as soon as trixie is open
> > for business
>
> You will also need to ship at least
>
> - /lib -> usr
On Sat, 6 May 2023 at 16:11, Simon Richter wrote:
>
> Hi,
>
> On 06.05.23 21:28, Luca Boccassi wrote:
>
> [shipping usrmerge symlinks in packages]
>
> > In the far future I'd like for these details to be owned by image
> > builders/launchers/setup process
On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sat, May 06, 2023 at 04:52:30PM +0100, Luca Boccassi wrote:
> > To have a working system you need several more steps that are
> > performed by the instantiator/image builder, such as providing working
&g
iven the
> earlier evidence.
>
> On Fri, May 05, 2023 at 11:11:54PM +0100, Luca Boccassi wrote:
> > - every package is forcefully canonicalized as soon as trixie is open
> > for business
>
> I gave you scripts to prototype this (via binary patching) and
> demonstra
tively forbid *all* changes that would
> require this, i.e., require stable interfaces. However we do not do
> this.)
>
> But for all these issues we just say "meh, you are out of luck".
Indeed, if we don't worry about local random changes or random third
party packages beyond documenting what needs attention, we shouldn't
worry about them for this either. As already mentioned lots of third
party packages don't even use Debian's toolchain to build packages, so
there's nothing that we can do anyway.
Kind regards, Luca Boccassi
On Sun, 7 May 2023 at 00:44, Sean Whitton wrote:
>
> Hello,
>
> On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote:
>
> > On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
> >>
> >> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to
On Sun, 7 May 2023 at 06:55, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sat, May 06, 2023 at 09:47:15PM +0100, Luca Boccassi wrote:
> > Sure, there are some things that need special handling, as you have
> > pointed out. What I meant is that I don't think we need s
On Sun, 7 May 2023 at 12:51, Luca Boccassi wrote:
>
> On Sun, 7 May 2023 at 06:55, Helmut Grohne wrote:
> >
> > Hi Luca,
> >
> > On Sat, May 06, 2023 at 09:47:15PM +0100, Luca Boccassi wrote:
> > > Sure, there are some things that need special handling
On Sun, 7 May 2023 at 22:10, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> > The local/external aspect is already covered in Ansgar's reply and
> > subthread.
>
> I hope that we can at least agree t
ion, apart from dash for
/bin/sh (and we are about to nuke most of it!), when
moving/adjusting/fixing and whatnot. Do you have any such
counter-example in mind?
Kind regards,
Luca Boccassi
ine the approach where we don't modify
> the ELF interpreter location in parallel as a backup plan?
Yeah we definitely should do that. I think we should separate a bit
long-term vs short-term on that front, as it will help reach a
conclusion more quickly. I think that aspect is easy to revise, and
shouldn't lock us in a particular position one way or the other.
Kind regards,
Luca Boccassi
On Mon, 8 May 2023 at 09:58, Helmut Grohne wrote:
>
> On Mon, May 08, 2023 at 02:07:08AM +0100, Luca Boccassi wrote:
> > I can see we don't agree on this matter, of course, that is clear. And
> > I hope we can find common ground. But let me provocatively ask this
> >
On Mon, 8 May 2023 at 19:06, Sean Whitton wrote:
>
> Hello,
>
> On Sun 07 May 2023 at 12:03PM +01, Luca Boccassi wrote:
>
> > Sure, this is in the context of the ongoing discussion in the TC about
> > revising their side of the advice.
>
> I think it's hi
On Tue, 9 May 2023 at 05:12, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Tue, May 09, 2023 at 01:56:53AM +0100, Luca Boccassi wrote:
> > On Mon, 8 May 2023 at 19:06, Sean Whitton wrote:
> > > It's designed to stop as-yet-unknown problems happening, too.
> >
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 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 Wed, 17 May 2023 at 10:31, Helmut Grohne wrote:
>
> Hi,
>
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.
>
> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> > I don't think this is true? A
, and that's going to end in a couple of
weeks.
> - it also solves the bootstrap problem
It also is the least likely to succeed, and the most likely to cause
significant "social" upheavals.
Kind regards,
Luca Boccassi
On Fri, 19 May 2023 at 01:30, Simon Richter wrote:
>
> Hi,
>
> On 5/18/23 18:08, Luca Boccassi wrote:
>
> >> Without it, leaving them in place makes no difference for usrmerged
> >> systems, and allows derived distributions that don't need usrmerge to
>
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
o, there already is a symlink at bin (as debootstrap placed it
> > there) and thus fails. So in order to make this work, we also have to
> > modify debootstrap (and thus are in a combination of category 3 and 4).
>
> So when we will have fixed this, and waited for a release cycle, w
eues. I'm pretty sure some buildds will still be stuck
on Buster for example. I've done this last year and I'm happy to do it
again once we have a plan.
Kind regards,
Luca Boccassi
t of text on rationale. Thank you.
I would caution to avoid interpreting clarifying questions being asked
as dissent. It's good to ask questions and clarify details about
corner cases, but I wouldn't automatically write them down as
disagreement. At least that's my reading of recent part
On Sun, 11 Jun 2023 at 22:17, Timo Röhling wrote:
>
> * Luca Boccassi [2023-06-10 19:54]:
> >I would caution to avoid interpreting clarifying questions being asked
> >as dissent. It's good to ask questions and clarify details about
> >corner cases, but I wouldn'
38 matches
Mail list logo
