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 11:00, Simon McVittie wrote:
>
> On Fri, 05 May 2023 at 23:11:54 +0100, Luca Boccassi wrote:
> > In practice, I suspect that out of ~2000 packages shipping bin/ sbin/
> > lib*/, only a small fraction would end up needing to further move
> > files out
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
On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
>
> Hi Luca,
>
> I fear you are still missing too many relevant details. What sounds like
> a simple plan is severely broken if carried out in this simple form. It
> disappoints me that you continue to present it as this simple g
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 Mon, 8 May 2023 at 21:09, Russ Allbery wrote:
>
> Sam Hartman writes:
>
> > As someone who has been following this, I support the work Helmut and
> > Simon Richter have been doing.
>
> > I have more confidence in that view than the one Luca is proposi
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.
> >
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 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 Sat, 13 May 2023 at 14:59, RL wrote:
>
> Luca Boccassi writes:
>
> > I think documentation is fundamental for dealing with local
> > changes. When I say that I don't think we should worry about strange
> > local-only changes I mean exactly as you said, that I
e-control-files-debian-control
> ]
>
> I would like to drop it pretty much everywhere, most importantly
> debian/control in source packages (as often humans edit these). But it
> could be dropped in other places (CONTROL in .deb and Packages indices)
> as well.
+1 for decluttering, especially human-maintained metadata files.
Kind regards,
Luca Boccassi
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
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 04:22, Russ Allbery wrote:
> Luca Boccassi writes:
> > On Mon, 15 May 2023 at 16:18, Russ Allbery wrote:
>
> >> Note that we're not talking about complicated packages with lots of
> >> runtime like, say, Emacs. As I understand it
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
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
On Wed, 17 May 2023 at 01:05, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > It does say something interesting. When we started, the assertion was
> > that packages not relying on the symlink being present was fundamental
> > for portability and cross-compatib
, 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
>
ndary status like this (however we
> label it!), then I think we should *only* consider it as a
> compatibility layer for older software. People *could* just use old
> chroots or similar, but the need is likely to be around for a
> while.
+1 for stopping publishing installers for i386, it has been mentioned
many times but it's always worth repeating: electricity costs to keep
running i386 hardware are already way higher than what it costs to buy
a cheap, low-power replacement like a raspberry pi, that also provides
better performance.
Just to clarify, by 'soon' here, do you mean for Bookworm too, or post-Bookworm?
Kind regards,
Luca Boccassi
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
me
> circumstanced delete the empty directory owned by systemd.
>
> On Mon, May 29, 2023 at 07:24:09PM +0100, Luca Boccassi wrote:
> > Given what was discussed:
>
> I think the conclusion is drawn too quickly here.
>
> > - bookworm is in hard freeze
> > - there is
On Tue, 30 May 2023 at 14:09, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Tue, May 30, 2023 at 11:23:07AM +0100, Luca Boccassi wrote:
> > > > - unmerged-usr paths are no longer supported
> > >
> > > Then you argue that this bug would affect only unmer
e for this situation,
> I'm all ears. The placeholder file sounds ugly, but might work.
I agree, doesn't seem very worrying, and as far as I understand the
observed impact so far is on testing infrastructure, but user
functionality is not impacted, right? If needed, placeholder could be
added, or the testing infrastructure could be taught to ignore them.
Kind regards,
Luca Boccassi
86_64 are
realistically going to be around for much, much longer as you pointed
out, so to me prioritizing this use case seems more prudent and
future-proof between the two alternatives.
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
unteering
for the job? The file move moratorium would have to remain in place for
2/3/4 releases on top of that while all of this is sorted.
Helmut's idea is good because it's doable in the real world. Are there
theoretical alternatives? Most likely. But let's focus on what's possible
and really doable in the next month or so and get this over with, please.
Kind regards,
Luca Boccassi
lly
/etc) and let image builders set up required mount points, symlinks,
and so on.
To be clear, despite being in the latter group, I am absolutely fine
with going with the first option for now to finish the transition, if
it's the best and easiest way to do so, and eventually revisit it
later.
Kind regards,
Luca Boccassi
On Sun, 11 Jun 2023 at 19:07, Russ Allbery wrote:
>
> Luca Boccassi writes:
> > On Sun, 11 Jun 2023 at 18:06, Russ Allbery wrote:
>
> >> On the other, related topic, I've also been somewhat confused in this
> >> discussion why it seems like there's a
use
> isc-dhcp-client either.
>
> So maybe simply demoting the priority of isc-dhcp-client to normal is a
> better route.
> ifupdown already recommends isc-dhcp-client and if ifupdown want's to
> use dhcpcd in the future it could change this recommends.
Yes, this sounds like a better approach to me as well.
Kind regards,
Luca Boccassi
I also think that installing both ifupdown and NetworkManager on
> desktop environments is worse than only NM.
The advantage of doing that is that it's what Ubuntu does IIRC, so
there will be extra pooling&sharing of resources to maintain those
setups, and the road should already be paved for it.
Kind regards,
Luca Boccassi
der if moving packages to
> severity: standard or higher (in this case, important) requires any
> decision from the CTTE or a similar authority, before we proceed?
As mentioned elsewhere in the thread, there shouldn't be any need to
change the priority, adjusting ifupdown's dependencies should be all
that's needed.
Kind regards,
Luca Boccassi
On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote:
>
> On 2023-06-19 14:37, Luca Boccassi wrote:
> > The advantage of doing that is that it's what Ubuntu does IIRC, so
> > there will be extra pooling&sharing of resources to maintain those
> > setups, and the ro
ersonally
> happy with systemd as pid 1, but some people consider requiring systemd
> as pid 1 to be a deal-breaker, and if NM is a good candidate for being
> our default *anyway* then we might as well get that secondary benefit too.
Yes a fully working and well-integrated GUI is the most important
thing for the default (as in, desktop tasklet default), power users
can always switch to something else. NetworkManager is clearly ahead
of the alternatives in that regard.
Kind regards,
Luca Boccassi
an.org/pkg/netplan.io
> [2]
> https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Yeah I think it would be nice to do some experiments there, at least
starting with networkd and eventually considering netplan as an
additional step on top - thanks for volunteering :-P
Ultimately it seems to me that the defaults should be driven by
tasklets rather than priority - ie, make ifupdown and dhcpd-base
optional, have ifupdown depend on dhcpd-base so that if a user wants
to use that stack they can just pull in ifupdown and it works as
expected, and have the desktop task pull in NetworkManager. Then we
can decide what the default stack for servers should be after some
experimenting.
Kind regards,
Luca Boccassi
s, but it is merely a
hint to developers and maintainers of alternatives that such
functionality should be supported in whichever way is most appropriate
for their systems.
Does this change help to clarify the intentions?
Kind regard,
Luca Boccassi
On Sun, 25 Jun 2023 at 22:29, Luca Boccassi wrote:
>
> Hi,
>
> According to Lintian there are 314 packages shipping init scripts
> without a corresponding systemd unit:
>
> https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script
>
> They currently wo
On Mon, 26 Jun 2023 at 05:21, Paul Wise wrote:
>
> On Sun, 2023-06-25 at 22:31 +0100, Luca Boccassi wrote:
>
> > Now the generator is also on the way to be deprecated and removed.
> ...
> > Therefore I filed a bug against all affected packages ...
>
> Will the gen
n set
ProtectProc= so that processes run with hidepid:
https://freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc=
Kind regards,
Luca Boccassi
2023 we have much, much better
patterns to secure running services. And using hidepid (ie,
ProtectProc) and other sandboxing on services is one such pattern.
Kind regards,
Luca Boccassi
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'
On Wed, 28 Jun 2023, 06:31 Paul Wise, wrote:
> On Tue, 2023-06-27 at 09:36 +0100, Luca Boccassi wrote:
>
> > That has been implemented a long time ago, services can set
> > ProtectProc= so that processes run with hidepid:
> >
> >
> https://freedesktop.org/softw
ng which is which:
$ git shortlog -s | cut -c8- | wc -l
2318
$ git shortlog -s | cut -c8- | wc -l
7
Just from this alone, it certainly seems true that one of those is a
project that "fails as a community project" and that is "not
hospitable to community building efforts". Anyone want to guess which
is which?
Kind regards,
Luca Boccassi
s is M13 from DEP17.
Yeah, let's punt it for now, and deal with the big items first.
> I also hope that this mail results in detailed disagreements that I can
> use to refine DEP17 and to base further research on.
I hate to ask, given you have already put a lot of work on the linked
document, but a very rough ballpark estimate in how much work it would
be to implement each solution (where not available yet) would be very
useful for making decisions, I think. If it's too much effort feel
free to just tell me to go chop some wood.
Thanks for the update!
Kind regards,
Luca Boccassi
e how it's worth the risk. This is essentially a problem in
the bootstrapping tools, so solving it in the bootstrapping tools is
not only the safest approach - worst case scenario, creating a new sid
chroot might not work for a couple days, not a big deal given it
happens all the time for various reasons as we've seen this week -
it's also the right approach.
Kind regards,
Luca Boccassi
ell?
Sadly, as I found out recently for the scripts mbf, lintian.d.o is
borken and has ~2 years old stale data. We should probably consider
taking it down, given it appears fully working and can be queried, but
just returns stale data with no indication that it is stale on the
face of it, without manual checks.
Kind regards,
Luca Boccassi
al
>
> smcv
> (speaking here as an individual DD and not on behalf of the TC)
The agreement last year was that we would wait for the tech committee
indication before changing the buildds. If there is such a decision, I
can start working on that.
Kind regards,
Luca Boccassi
On Thu, 29 Jun 2023 at 13:34, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Thu, Jun 29, 2023 at 12:49:16PM +0100, Luca Boccassi wrote:
> > Essentially, this boils down to risks vs benefits. The risk of going
> > 3c is that every single Debian installation in existence breaks
on and not only there are zero actual results to
show for it, but every single time the topic is brought up on the dpkg
mailing list, the maintainer's answer is some variation of "no, get
lost". Of course it's your time, so you are entitled to use it as you
see fit.
Kind regards,
Luca Boccassi
or a minimal one. For the rest - installer and whatnot
- the installer and tasklets should pull in the required stack as
needed.
So I think not only we should not bump the priority of dhcpd-base, but
we should also change ifupdown's down to optional.
Kind regards,
Luca Boccassi
Ubuntu in the future. It has been available in Debian since
Bullseye - please help out testing it by installing it. No
configuration is required, just installing dbus-broker and rebooting.
It comes with some sandboxing by default (ProtectSystem=full), and I'm
sure it could use more.
Kind regards,
Luca Boccassi
zst
> (present)
> Size on Disk: 27.1K
>Message: Process 2919 (nginx) of user 0 dumped core.
>
> Normally there would be a backtrace in coredumpctl's output,
> indicating the last few syscalls it made before it made a blocked syscall.
> I'm not sure why that's absent here, but it makes it very hard to go
Seccomp is complex, because it is very granular. When there is no
sandboxing at all, I recommend to start from the simplest things such
as ProtectSystem and PrivateTmp/TemporaryFilesystems. Having some
sandboxing is better than having no sandboxing.
Kind regards,
Luca Boccassi
ating complex machinery to the packages
themselves, I very much prefer that, as to me it obviously seems
inherently less risky.
Kind regards,
Luca Boccassi
aid in the original mail and on the writeup that this option
requires all the affected packages to be upgraded at the same time,
and in the correct order, or things will break. What happens if any of
those packages are held back, for whatever reason? This is the
fragility aspect that I am worried about, and that is not an issue at
all if we just fix mmdebstrap to do the right thing as debootstrap
already does.
Kind regards,
Luca Boccassi
On Tue, 11 Jul 2023 at 09:44, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Tue, Jul 11, 2023 at 12:27:04AM +0100, Luca Boccassi wrote:
> > You have said in the original mail and on the writeup that this option
> > requires all the affected packages to be upgraded at the s
ntainers by sending a minor bug for every source
> package that is somehow involved. The bug would ask maintainers to move
> their files from / to /usr, how to do so, the need to do this via
> experimental first and the chances of getting an rc bug in the process.
> Do people who have n
On Fri, 11 Aug 2023 at 05:52, Helmut Grohne wrote:
>
> Hi,
>
> This is picking up on the debootstrap matter and is kinda crucial.
>
> On Thu, Jul 13, 2023 at 01:31:04AM +0100, Luca Boccassi wrote:
> > > After having sorted this out, what part of your safety conce
t;
> ```make
> $(call remove_pycache, $(CURDIR) )
> ```
Why should we do something like that by hand for every single python
source package? It doesn't make much sense. This is something that
needs to be handled in the tooling/infrastructure automatically, not
create busywork for hundreds of people.
Kind regards,
Luca Boccassi
On Tue, 22 Aug 2023 at 10:21, Helmut Grohne wrote:
> Let me also put this into numbers. Across all suites, we have around
> 2200 binary packages shipping files in aliased locations. If you
> disregard systemd units, we're left with 1030 packages. In other words,
> more than half of the binary pack
On Sun, 10 Sept 2023 at 04:36, Russ Allbery wrote:
> Licenses will be included in common-licenses if they meet all of the
> following criteria:
>
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at
On Sun, 10 Sept 2023 at 18:55, Nils Kattenbeck wrote:
>
> Hello,
>
> I am looking to generate a Debian image with only a /usr and /var
> partition as per discoverable partition specification. However, it
> seems to me like the omission of /etc leads to several issues in core
> packages and logging
On Sun, 10 Sept 2023 at 21:43, Russ Allbery wrote:
> (This does not rule out the possibility that certain carefully-crafted
> configurations with a subset of packages may work in this mode, of
> course.)
Yes, this is pretty much what we are talking about in these cases -
targeted experiments, to
On Mon, 11 Sept 2023 at 15:09, Simon McVittie wrote:
>
> On Mon, 11 Sep 2023 at 08:58:09 +0200, Gioele Barabucci wrote:
> > An even bigger prerequisite is that many upstream projects does not yet
> > support working without /etc or (orthogonally) reading their default
> > configuration from /usr.
On Fri, 15 Sept 2023 at 21:08, Sam Hartman wrote:
>
>
>
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that. You can set up a vendor directory
> such as /usr/lib where pam.d and security live.
>
> I thought about doing that for Debi
On Sat, 16 Sept 2023 at 00:46, Steve Langasek wrote:
>
> On Fri, Sep 15, 2023 at 07:44:45PM +0100, Luca Boccassi wrote:
> > In fact, Marco yesterday told me the only blocker to boot a minimal
> > Debian image with only /usr is PAM, and that's exclusively because of
> >
On Sat, 16 Sept 2023 at 11:20, Matthew Garrett wrote:
>
> On Fri, Sep 15, 2023 at 02:08:06PM -0600, Sam Hartman wrote:
> >
> >
> > Apropos of the discussion about removing default configuration from
> > /etc.
> > Upstream PAM now supports doing that. You can set up a vendor directory
> > such as
On Fri, 22 Sept 2023 at 20:41, Khalid Aziz wrote:
>
> Hello,
>
> I implemented automatic kexec reboot support to kexec-tools package many
> years ago when Debian used init. It worked well except for some corner
> cases. To support this, I also added a package config option to enable
> kexec reboot
On Fri, 22 Sept 2023 at 21:29, Khalid Aziz wrote:
>
> On 9/22/23 2:01 PM, Luca Boccassi wrote:
> > On Fri, 22 Sept 2023 at 20:41, Khalid Aziz wrote:
> >>
> >> Any comments/feedback? I intend to proceed with implementing new
> >> behavior next week after W
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : python-varlink
Version : 31.0.0
Upstream Author : various
* URL : https://github.com/varlink/python
* License
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: pkcs11-provider
Version : 0.2
Upstream Contact: Red Hat
* URL : https://github.com/latchset/pkcs11-provider
* License : Apache-2.0
Programming
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-sdbus
Version : 0.11.1
Upstream Author : various
* URL : https://github.com/python-sdbus/python-sdbus
* License : LGPL-2.1-or-later
On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>
> Dear Debian folks,
>
> coreutils can link against OpenSSL, yielding a substantial speed boost
> in sha256sum etc. For many years, this was inadvisable due to license
> conflicts. However, as of bookworm, coreutils requires GPL-3+ and
> Ope
On Fri, 10 Nov 2023 at 02:26, Simon Richter wrote:
>
> Hi,
>
> > What would you think about having coreutils Depend on libssl3? This
> > would make the libssl3 package essential, which is potentially
> > undesirable, but it also has the potential for serious user time savings
> > (on recent Intel
On Fri, 10 Nov 2023 at 11:54, Matthew Vernon wrote:
>
> Luca Boccassi writes:
>
> > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>
> >> What would you think about having coreutils Depend on libssl3? This
> >> would make the libssl3 pac
On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
>
> Luca Boccassi writes:
>
> > If we want to start nitpicking, then let's be exact: 0.61% of popcon.
> > Whether that qualifies as "plenty" we'll leave as an exercise for the
> > readers.
>
>
On Fri, 10 Nov 2023 at 13:48, Michael Stone wrote:
>
> On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
> >Per-architecture dependencies are possible though, so maybe starting
> >to add the libssl dependency only on amd64 is a good starting point,
> >
501 - 600 of 876 matches
Mail list logo
