On Thu, 6 Jun 2024 at 10:02, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi Helmut,
>
> Quoting Helmut Grohne (2024-06-06 09:28:52)
> > I have just uploaded
> > * base-files
> > * bash
> > * dash
> > * glibc
> > * util-linux
> > to unstable. These were the last remaining packages shipping ali
On Thu, 6 Jun 2024 at 09:07, Gioele Barabucci wrote:
>
> Hi,
>
> setting LC_ALL=C.UTF-8 in d/rules is a common way to fix many
> reproducibility problems. It is also, in general, a more sane way to
> build packages, in comparison to using whatever locale settings happen
> to be set during a build.
ed to switch to close_range, which is
very simple to use and documented at:
https://man7.org/linux/man-pages/man2/close_range.2.html
Please enjoy your extra file descriptors responsibly.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
ot;I have an old machine
under the desk and can build some trivial packages", I am afraid.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
On Fri, 14 Jun 2024 at 11:54, wrote:
>
> Then it's not a problem in the first place. If you can't reproduce a bug with
> a reasonable effort, then it is unconfirmed and you can stop worrying about
> it. A bug that can't be reproduced, effectively doesn't exist.
>
> That's not a reason to stop su
On Fri, 14 Jun 2024 at 13:21, Mourad De Clerck wrote:
>
> > PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
> > bumped early at boot from 1048576 to the max value that the kernel
> > allows, which on amd64 is currently 1073741816.
>
> Hi,
>
> It seems some proprietary software
On Tue, 9 Jul 2024 at 14:44, Simon Richter wrote:
>
> Hi,
>
> On 7/9/24 17:57, Matthias Urlichs wrote:
>
> >> Agreed: either it's drop-in compatible or we may as well switch the
> >> default to NM and/or systemd-networkd.
>
> > Well, here's a heretical thought: why don't we do that anyway, at leas
On Tue, 9 Jul 2024 at 18:02, Simon McVittie wrote:
>
> On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote:
> > On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
> > > I believe NM does not have a fixed configuration format, but only a dbus
> > > API.
> >
> > It's perfectly fine to edit co
On Thu, 11 Jul 2024 at 12:12, Lukas Märdian wrote:
>
> On 11.07.24 11:13, Marco d'Itri wrote:
> > On Jul 11, Philip Hands wrote:
> >
> >> I've only seen netplan mentioned in passing in this thread so far.
> > Because I believe that Netplan is the answer to a question that nobody
> > asked here.
>
ntributors with more than 100 commits, and 2 with more than 10, and
2 of them are Canonical employees:
569 Lukas Märdian
310 Danilo Egea Gondolfo
39 Simon Chopin
38 Danilo EgĂŞa Gondolfo
11 Robert Krátký
Same stat, for the same period, for systemd:
6650 Yu Watanabe
5415
On Sun, 14 Jul 2024 at 21:26, Philip Hands wrote:
>
> Luca Boccassi writes:
>
> > Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'.
> > In the last ~2.5 years, in netplan.io's github repo, there are only 2
> > contrib
On Sun, 14 Jul 2024 at 19:21, Simon McVittie wrote:
>
> On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote:
> > Luca Boccassi wrote:
> > >Networking is not static, it constantly changes in the kernel,
> > >sometimes in dramatic and incompatible ways.
>
On Sun, 14 Jul 2024 at 19:21, Simon McVittie wrote:
> Dependency size and maintenance
> ---
>
> I also notice that the netplan.io package would bring GLib, Python,
> python3-dbus and python3-yaml into the dependencies of the base system,
> among others. As an upstream a
On Mon, 15 Jul 2024 at 14:36, Lukas Märdian wrote:
> = "How to do networking on Debian?" =
>
> If we have to tell our users and sysadmins to do "X" on Debian server systems
> (using ifupdown or potentially sd-networkd), while doing "Y" on Debian desktop
> systems (using NetworkManager), while doin
On Tue, 16 Jul 2024 at 00:26, Steve Langasek wrote:
>
> On Mon, Jul 15, 2024 at 03:47:16PM +0100, Luca Boccassi wrote:
> > Assuming that's really needed, and it's far from clear that different
> > use cases should really use the exact same things, using
> >
On Tue, 16 Jul 2024 at 14:05, gregor herrmann wrote:
>
> On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote:
>
> > I suspect having something that's agnostic about the underlying
> > implementation as our default would be rather better for the non-systemd
> > options that people care about, …
On Tue, 16 Jul 2024 at 14:46, Daniel Gröber wrote:
>
> Hi Luca,
>
> On Mon, Jul 15, 2024 at 02:50:17PM +0100, Luca Boccassi wrote:
> > Let's put some hard numbers on the table given this is an important
> > detail. The following is all starting from a defaul
On Thu, 1 Aug 2024 at 10:36, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi Otto,
>
> Quoting Otto Kekäläinen (2024-07-28 00:38:40)
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable true open collaboration on all Debian package
On Thu, 1 Aug 2024 at 09:49, Jonas Smedegaard wrote:
> Quoting Otto Kekäläinen (2024-08-01 07:30:18)
> > You have for sure developed an optimal workflow for yourself.
>
> Then I have failed: I have strived towards a collaborative workflow.
>
> Just not a web-centered collaborative workflow, but an
On Thu, 1 Aug 2024 at 13:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a Ă©crit :
> >
> > run a CI before uploading, even a very basic one is just fine, better
> > than nothing.
>
> Thanks for the remider ! I will have a closer
On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> wrote:
> >The vast majority of people who
> >are forced to use emails do so for work via a
> >work-mediated/administered interface that tries to make it somewhat
&g
On Thu, 1 Aug 2024 at 21:57, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi
> wrote:
> >On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
> >>
> >> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> >> wrote:
> >> >T
On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote:
>
> On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> [...]
> > To pick a random example, a less well known, less used, less
> > popular distribution like Nixos has 7000+ contributors listed on
> > Github.
, S390,
> > PPC)?
> > What about the others?
>
> There's also jitterentropy-rngd which does the trick but I haven't
> looked at the security implications.
> Â -- Guido
FWIW I've been using jitterentropy-rngd and rng-tools in production for
years, in Azur
Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi"
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 930413 by -1
* Package name: python-applicationinsights
Version : 0.11.9
Upstream Author : Microsoft Corporation
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi"
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 930413 by -1
* Package name: vsts-cd-manager
Version : g2649d23
Upstream Author : Microsoft Corporation
* URL : https://github.com/microso
Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi"
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 930413 by -1
* Package name: azure-cosmos-python
Version : 2.3.3
Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/az
to work fine with the instance we use at
$work. It would be great if we could get the plugin back into Buster
before the release.
--
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 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
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
ople diverting /sbin/init to
/var/lolcat or whatever. Clear documentation that tells "if you did X
look at Y and do Z" is the bare minimum I'd think.
But again, I do think we need to try and define what it is that we
want to support here. If we are serious about it, then we should
codify it, and hold any future changes to the same standards, wherever
they may come from. If we are not willing to do this, then I have to
ask why.
Kind regards,
Luca Boccassi
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
1 - 100 of 294 matches
Mail list logo
