On Apr 21, Mathias Gibbens wrote:
> While that might work for them, it obviously doesn't at a higher
> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
> for any comments or suggestions on my plan for packaging the MinIO
> Client. Following what several other
On Apr 19, José Luis González González wrote:
> I even tried to reach dash maintainer privately and he is not even on
> the package's field (queried by dpkg), there's someone who is obviosly
> fake instead: Andrej Shadura
I have met Andrej a few times and I am quite sure that he is real.
Or
On Apr 07, Wookey wrote:
> I think that's a mistake, and I'm not a fan. Because so far as I can
> tell 'use salsa' actually means 'maintain your packages in git'. So
> far as I can see it is not possible to use our existing 'uscan, patch,
> sbuild, dupload' type workflows with Salsa. And that's
On Apr 07, Bernd Zeimetz wrote:
> There are more than enough ways to keep the entries based on dns
> records in your l3 firewalls uptodate, I can't see how this should
> warrant to keep yet another patch Jan^WMarco.
Not for the form *.domain.tld.
--
ciao,
Marco
signature.asc
Description: PGP
On Apr 07, José Luis González wrote:
> I want to know why Debian 12 was released with those two Sylpheed RC
> bags, report the incident to you all, know what to do with the
> maintainer and kindly request that someone better at the job takes over
> Sylpheed maintainance, or otherwise I will
On Apr 05, Simon McVittie wrote:
> I find that having the upstream source code in git (in the same form that
> we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> but excluding any files that we exclude by repacking) is an extremely
> useful tool, because it lets me
On Apr 02, Colin Watson wrote:
> You could use a drop-in unit to wrap sshd in tcpd, as suggested by the
> Fedora wiki page? This would avoid exposing sshd's process space to
> libwrap and all the stuff it links to by default.
This would require to switch to socket activation of sshd, which is
On Apr 02, Colin Watson wrote:
> At the time, denyhosts was popular, but it was removed from Debian
> several years ago. I remember that, when I dealt with that on my own
> systems, fail2ban seemed like the obvious replacement, and my impression
> is that it's pretty widely used nowadays; it's
On Apr 01, gregor herrmann wrote:
> > I switched long ago all my packages from tar archives to the git
> > upstream tree. Not only this makes much easier to understand the changes
> > in a new release,
> That's not mutually exclusive. When adding an additional git remote
> and using
On Mar 31, Russ Allbery wrote:
> Most of this is pregenerated documentation (primarily man pages generated
> from POD), but it also includes generated test data and other things. The
> reason is similar: regenerating those files requires tools that may not be
> present on an older system (like
On Mar 30, Christian Kastner wrote:
> >> Another big question for me is whether I should really still
> >> package/upload/etc from an unstable machine. It seems that it may be
> >> prudent
> > If we do not use unstable for development then who is going to?
> Are you both talking about unstable
On Mar 30, Jonathan Carter wrote:
> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine. It seems that it may be prudent
If we do not use unstable for development then who is going to?
I think that the real question is whether we should
On Feb 28, Helmut Grohne wrote:
> Please allow me to push back on this one as well by raising a few
> concerns.
Also, I think that the benefits from doing this are tiny, and just
adding /usr/sbin/ to the $PATH would solve almost everything.
--
ciao,
Marco
signature.asc
Description: PGP
On Feb 22, IOhannes m zmölnig wrote:
> While I like the idea in general, I wonder how I could override these
> automatic additions.
> I think there are some packages that even demote `${shlibs:Depends}` to
> Recommends.
E.g. inn2 does:
override_dh_shlibdeps:
dh_shlibdeps
On Jan 25, Wookey wrote:
> Luca is quite right here. Ultimately this can only be fixed by these
> ecosystems understanding that software in these languages cannot be
> sensibly used in distributions until they support modularity and
> stability. The rust people make the excuse that they are 'too
On Jan 24, Peter Pentchev wrote:
> This might be a minority, optimistic, rose-tinted-glasses kind of
> opinion, but I believe that the state of the Rust ecosystem today
> (I have no experience with the Go one) is quite similar to what Perl and
> Python modules were 25, 20, bah, even 15 years
On Jan 10, Michael Biebl wrote:
> While we could ship such a udev rule for udisks, I don't think it will
> properly solve the issue. The device will still show up in nautilus, plasma
> etc and mounting is just an additional click away.
The threat model here is: somebody connects a crafted USB
On Nov 20, Craig Small wrote:
> Also why is killall5 not a candidate too?
Probably because it makes no sense outside of sysvinit, except that as
a footgun.
(Also, is it equivalent to pkill --inverse?)
--
ciao,
Marco
signature.asc
Description: PGP signature
On Sep 28, Bastian Germann wrote:
> Okay. What do you suggest for "team maintained" packages where there is no
> active team member?
> File MIA processes for each of the uploaders? And then? The MIA team's bugs
> are not RC bugs,
> so you cannot even NMU them based on the MIA bug.
After having
On Sep 16, Steve Langasek wrote:
> While I have applications downstream which also care about empty /etc, the
> current situation is that this wouldn't help because almost all the
> PAM application configs in Debian reference one or more of
>
On Sep 16, Russ Allbery wrote:
> However, and this is very important, *no one has decided that you get to
> do that work in Debian*.
I am confident that I have never said otherwise.
> Right now, any base system package maintainer could decide that putting
> configuration files in /etc makes
On Sep 15, Sam Hartman wrote:
> But for the most part PAM appears to just override on a file-by-file
> basis.
Just like udev, kmod, dbus, etc...
PAM is not different.
> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the
On Sep 16, Josh Triplett wrote:
> If we're talking about developing a solution that doesn't already exist,
> why not have that solution *be* the
> notification-and-diff/show-the-defaults mechanism you're describing? For
> instance, provide a declarative mechanism to say "this file/directory in
>
On Sep 10, Russ Allbery wrote:
> So far as I know, no one has ever made a detailed, concrete proposal for
> what the implications of this would be for Debian, what the transition
> plan would look like, and how to address the various issues that will
> arise. Moving configuration files out of
On Sep 10, Nils Kattenbeck wrote:
> 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 in becomes impossible.
> Is
On Sep 10, Enrico Zini wrote:
> I like this. I'd say that even if a license is shorter than 25 lines I'd
> appreciate to be able to link to it instead of copypasting it.
Me too.
> I like to be able to fill the license field with a value, after checking
> that the upstream license didn't diverge
On Aug 15, Jonas Smedegaard wrote:
> The proper approach is IMO one of these:
Or else, if you know that they do not actually need to be rebuilt: just
disable in the makefile the target which causes them to be rebuilt.
This is what I do in my packages.
--
ciao,
Marco
signature.asc
On Jul 21, Bastien Roucariès wrote:
> Ok found it call mountlo outdated
> will need a small patch for linux uml, but may be worthwhile
> Last version seems to be outdated 0.6 and carried by slitaz distribution.
> May be time to revive it
It looks like a good long term solution, but as long as
On Jul 21, Matthew Garrett wrote:
> > You are totally correct.
> > Kernel team, please blacklist HFS/HFS+ for automounting.
> Isn't this a userland policy decision? udisks will happily trigger a
> module load for hfsplus if udev has identified it, and I don't think
> there's a trivial
On Jul 11, Sam Hartman wrote:
> 1) It's an extra layer. You can ignore it when reading the config (at
> least if you aren't too surprised by your config ending up in /run).
> But it is extra complexity, especially in a situation like " run dhcp on
> my ethernet" that is relatively simple.
I
On Jul 04, Andrey Rakhmatullin wrote:
> Cool but looks like a lot of work.
I do not think that this is really a lot of work.
> Is it possible to do this without
> applying the flags one by one and testing the result? Is it easier to
You may intimately know what the daemon needs to do and how
On Jul 04, "Trent W. Buck" wrote:
> * If it runs its own process manager (e.g. postfix's "master"),
> don't bother trying to harden it.
I disagree. It may not be possible to use NoNewPrivileges, but at least
file system hardening is usually trivial to enable for most daemons.
> * If it
On Jul 03, RL wrote:
> (One of the issues for services that send email is that it is very
> easy to break exim)
NoNewPrivileges breaks by design anything which depends on suid, so Exim
and (in the default configuration) Postfix.
I agree that we should do much better in terms on sandboxing,
On Jul 02, Peter Pentchev wrote:
> On the other hand, the bugs have been open for an year and a half now...
For something which has worked just fine for many years.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jun 22, Martin-Éric Racine wrote:
> The point has always been to ship some ifupdown-supported DHCP client
> by default. This can be done either by keeping the default client's
> priority to important or by making ifupdown Depends on one. I prefer
> the later.
It would be totally unacceptable
On Jun 09, Bjørn Mork wrote:
> > as we all know every Debian maintainer can veto any systemic changes
> > that they do not like.
> I don't think qusr-merge would not have happened if this was true. And
> I believe you know that very well.
Actually merging /usr happened in a suboptimal way
On Jun 08, Raphael Hertzog wrote:
> In the same spirit, I'd like to throw an idea... could we decide that
> base-files is the first package to be configured as part of the bootstrap
> protocol and change base-files maintainer's scripts into statically linked
> executables so that they can work
On Jun 06, Simon McVittie wrote:
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
Agreed. I will be more blunt: an i386 port which cannot run old i386
binaries would be
On May 18, Steve Langasek wrote:
> So maybe the best workaround in the short term, if there's no immediate data
> migration path, would be to change the inn2 source to use unsigned long in
> place of time_t in the data format?
I do not think that inn2 is going to be a problem, because it has
On May 17, Helmut Grohne wrote:
> Given the feedback, I am convinced that changing PT_INTERP is a stupid
> idea regardless of whether it is technically feasible. There must be a
> better way. Let's step back a bit.
Me too, I was never persuaded.
> 4. Change the bootstrap protocol. In essence,
On Apr 27, Helmut Grohne wrote:
> The origin of this thread was a proposal to adapt dpkg. Your mail
No, Marc is right. The origin of this thread is trying to find
workaround because the dpkg maintainer refused long ago to implement
a simpler solution.
--
ciao,
Marco
signature.asc
On Apr 12, Helmut Grohne wrote:
> As much as I like unprivileged operation, I think this change may expand
> privileges beyond what we expect. At present, ping limits an
> unprivileged user to a minimum spacing of 2ms and prevents a flood ping.
> Of course a user can just run multiple ping
On Mar 10, Stephan Verbücheln wrote:
> On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> > In the future the initramfs will (usually) be static as well.
> Can you provide more information on that?
Due to multiple reasons, mostly related to secure boot and boot
On Mar 10, Stephan Verbücheln wrote:
> Apart from the fact that UEFI Secure Boot is an overly complex monster
> which is basically broken[1] by design, my understanding of it is also
> that it does not protect configs, initramfs etc. in /boot. It only
> protects the kernel image and loaded
On Mar 08, Alexey Kuznetsov wrote:
> 1) grub can ask for a login/password, then MD5 the text and unlock the LUKS
Forget about this part: encrypted /boot/ is pointless from a security
point of view and this complexity does not belong in the boot loader.
Once you accept this then you will end up
On Mar 08, Philipp Hahn wrote:
> Do we do our users a service by keeping that dead horse alive for another 2+
> years? While being quite stable it had a steady stream of security issues:
Yes, unless you know of other implementations with that features set.
--
ciao,
Marco
signature.asc
On Mar 07, Philipp Hahn wrote:
> Is it a good idea to keep it alive for another 2+ years in
> Debian-12-Bookworm or should it be removed now?
> https://packages.debian.org/source/bookworm/isc-dhcp
I do not think that it should be removed at this point, since there is
a need for the complex
On Feb 22, Peter Pentchev wrote:
> So I've seen this idea floating around in the past couple of years
> (and in some places even earlier), but I started doing it for
> the couple of pieces of software that I am upstream for after reading
> Daniel Stenberg's blog entry:
>
On Jan 20, Simon McVittie wrote:
> For the systemd-sysv-generator case, the LSB init script is only run if
> there is no native systemd unit of the same name, which itself triggers
> a Lintian warning (albeit quite a common one); so hopefully if maintainers
> are removing lsb-base dependencies
On Jan 03, Adam Borowski wrote:
> Debian's default sysctl settings should reside in procps (as it owns
> /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> package.
Nowadays systemd is a source of common sysctl settings among different
distributions.
--
ciao,
Marco
On Jan 02, Noah Meyerhans wrote:
> I'm entirely happy to reassign this request to systemd and have the
> setting applied more broadly. The question that arises then is what to
> do about the file-level capabilities on the ping binary. Ideally we
> drop them entirely (including the setuid
On Jan 02, Noah Meyerhans wrote:
> With that in place, unprivileged users are able to excute ping for both
> IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> file-based attribute on the ping binary or acquired via setuid). But
> since that applies system-wide, not just to
On Jan 02, Peter Pentchev wrote:
> I personally would prefer giving the administrator a way to change that.
> Maybe add a low priority debconf question with a "ping is not setuid"
> default, then mention that debconf setting in a comment in the file that
> the package installs in the sysctl.d/
On Dec 09, Andreas Tille wrote:
> I would consider asking upstream about this for sure but the code is in
> maintenance mode and there is no Git repository to step back in history.
> The only way to go would be to take configure.ac from a later version
> and find out how it can be tweaked to
On Nov 13, Robie Basak wrote:
> This seems inconsistent to me. Where is the expectation that TMPDIR must
> be unset if dropping privileges coming from? Obviously for users of
Where is the expectation that $TMPDIR is writable by any user but the
current one?
I do not believe that it is expected
On Nov 13, Simon McVittie wrote:
> I think you can both be right. The symptom here is a maintainer script
> failing, but if I'm understanding Marco's argument correctly, he's
> saying that the root cause is that when you switch between execution
> environments, not all of the environment
On Nov 12, Otto Kekäläinen wrote:
> Instead of manually trying to manage TMPDIR env variable in various
> places, we should have a standardized way to run maintainer scripts in
> clean shell sessions that have all env variables set automatically
> correctly.
This is not about maintainer scripts,
On Nov 10, Robie Basak wrote:
> Thank you for the report. Adding debian-devel@ and the libpam-tmpdir
> maintainer for wider discussion.
>
> On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote:
> > On my systems, I use libpam-tmpdir, which provides each user with a
> > private
On Nov 01, Sebastian Ramacher wrote:
> > this change is only targeted at two archs, which I'd hope could cope with
> > it.
> If we ignore/break MA: same co-installability, sure.
Sure, but this means that a much smaller subset of packages will need to
be rebuilt on all architectures.
--
ciao,
On Oct 14, Vincent Lefevre wrote:
> > This is obviously convenient on Guillem's part, but we have to optimize
> > systems by default for the general case and not just for dpkg -i.
> This dpkg FAQ says that this is not beneficial for just dpkg,
> but also "for any application in the system".
On Oct 14, Vincent Lefevre wrote:
> > This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to
> > recommend awful things in the past.
> But it is still considered in the present times by the dpkg developers.
> Bug 923423 was closed several hours ago based on this dpkg FAQ:
This
On Oct 14, Vincent Lefevre wrote:
> The /etc/fstab file is created using by default ext4 with just
> the errors=remount-ro option. However, the Debian FAQ recommends
> the nodelalloc mount option to avoid performance degradation and
> preserve data safety:
This is not "the Debian FAQ" but "the
On Sep 30, Sean Whitton wrote:
> ARC is meant to be an alternative to this, eventually, right?
Right, but it has been such for so many years now that I am not holding
my breath waiting for it.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Sep 18, Bjørn Mork wrote:
> So if you don't want another round of pointless discussions, then I
> suggest that you start working on those bugs now. That's the smart thing
In other words, you are saying that if we don't do what you want then
you will keep rehashing the same old arguments.
On Aug 15, Ansgar wrote:
> To not look like forged mail, the "From" header field (not the
> envelope) has to be validated with either DKIM or SPF. disroot.org
> says this is supposed to be the case for mail from their domain:
Not exactly. DMARC validation requires that at least one of DKIM or
On Jul 14, Marc Haber wrote:
> >And I see you uploaded ~immediately - why even bother with an ITP?
> Is it proper procedure to upload without an ITP?
Is there any point in an ITP if you are already ready to upload the
package? No.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jun 30, Stephan Verbücheln wrote:
> As far as I understand it, the main point of BabaSSL is to add support
> for Chinese developed ciphers and algorithms.
Is supporting Chinese cryptography standards a goal for Debian?
If it is then they should be available to all packages, but if it is not
On Jun 22, Lance Lin wrote:
> Yes, from my understanding it is a "drop in" replacement for OpenSSL. One of
> my packages (Workflow) uses it but can also use OpenSSL.
>
> I think this package will be beneficial to the Workflow users and downstream
> OS's.
Can you explain exactly what benefits
On Jun 17, Lance Lin wrote:
> - BabaSSL is a modern cryptographic and secure protocol library
> developed by the amazing people in Alibaba Digital Economy.
What is the plan? Are there any current or new packages which will
depend on it?
--
ciao,
Marco
signature.asc
Description: PGP
On Jun 06, Holger Levsen wrote:
> > Is this really worth the effort, considering that probably RISC-V is
> > going to be our last port for a very long time?
> you mean like 640kb should be enough for everyone? :)
More like "free ABI is eating the world".
I do not see much future for the
On Jun 06, Paul Wise wrote:
> There are lots of packages that need porting to every new architecture
> that comes along. There are others that don't require porting but
> benefit in some way from porting to some aspect of the architecture.
Is this really worth the effort, considering that
On May 05, Marco Gaiarin wrote:
> override_dh_auto_configure:
> dh_auto_configure -- --docdir=${prefix}/usr/share/doc/vchanger
Direi che deve essere --docdir=\${prefix}/...
> e comunque i file vengono installati nella cartella di prima:
Questo potrebbe essere un bug del makefile.
--
On Apr 28, Paul Wise wrote:
> During the discussions about NEW on debian-devel in recent times, I had
> the idea that instead of the current mechanism of sending REJECT mails,
> Debian could switch to using the BTS for most feedback on NEW packages.
This looks like a good idea to me, but I think
On Apr 19, Sam Hartman wrote:
> For example I would thinki it would be entirely reasonable for someone
> to want to include a version of Debian installer for use with qemu in an
> environment that needed to be DFSG free.
> Similarly, I think it would be reasonable for someone to want to provide
On Apr 19, Steve McIntyre wrote:
> What would I choose to do? My personal preference would be to go with option
> 5:
> split the non-free firmware into a special new component and include that on
> official media.
I agree, and actually I have been supporting this position for 20
years (time
On Apr 06, Krzysztof Sobiecki wrote:
> Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess?
Install the usrmerge package and hopefully everything will be fixed.
> Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg
> advised me to do?).
Maybe.
> As a Debian user
On Mar 14, Paul Wise wrote:
> AFAICT OnSuccess/OnFailure services don't recieve the output of the
> succeeding/failing service. So the mail sending service needs to dig
> around in the systemd journal. Or make the service output go to a file,
> FIFO or socket and then send that to a mail.
Yes,
On Mar 11, Simon Richter wrote:
> We currently don't have a good mechanism for leaving configuration behind on
> purge, which we've historically done with user accounts to avoid reuse of
> UIDs that may own resources, so we'd still have to create the declarations
> from a postinst.
While this is
On Mar 06, Lucas Nussbaum wrote:
> I think that we should reduce the number of packages using the 1.0 format, as
> (1) format 3.0 has many advantages, as documented in
> https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to
> standardization of packaging practices, lowering the
On Mar 04, Baptiste Beauplat wrote:
> Looking at your email headers, I would guess that gmail is already doing it.
>
> X-Google-DKIM-Signature: v=1; a=rsa-sha256...
>
> There is somewhat some irony in Gmail blocking email without a DKIM
> signature while they are using a non-standard header
On Jan 23, Richard Laager wrote:
> It might be technically possible to build a binary package with different
> versioning, but even if it is: 1) I don't know how, and 2) I'm not sure
> whether that's a good idea, especially compared to the alternatives.
I did it long ago, I think for kmod taking
On Jan 19, Paride Legovini wrote:
> That's what I had in mind, but the other option:
>
> > Another option would be to have src:ntpsec build the bin:ntp dummy
> > package and remove src:ntp entirely.
>
> also looks sensible to me after all. No strong opinion.
I think that this would be better
On Jan 18, Michael Biebl wrote:
> I think Fedora prefers chrony instead of ntpsec.
Fedora even uses btrfs, so who cares. :-)
The interesting point is that RHEL switched to chrony for RHEL 7.
Also, I want to add that chrony is not just better as a client, but also
as a NTP server.
On Jan 17, Bernhard Schmidt wrote:
> What do you think?
chrony is MUCH better since Debian 10, I agree that it should be the
preferred NTP client for when systemd-timesyncd is not enough.
You can definitely spend your time on something more fun and more
useful.
--
ciao,
Marco
signature.asc
On Dec 30, Scott Kitterman wrote:
> I would too. It would be nice if systemd-resolved had some mechanism to
> support this kind of functionality. If you're going to replace resolvconf,
> then you ought to actually replace it.
systemd-resolved is supposed to forward queries to the upstream
On Dec 12, Giuseppe Sacco wrote:
> debug1: Sending command: scp -v -f key-transition-2014.txt
> Timeout, server master.debian.org not responding.
MTU.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Dec 10, Marc Haber wrote:
> Is there any way to fire up a pid-1-systemd isntance inside a debspawn
> container, so that the container could have an IP address and run its
> own sshd? Or is there any way to get a login prompt from an already
> running debspawn container?
I am not familiar with
On Nov 18, Zack Weinberg wrote:
> Are you seriously claiming that that phenomenon is not a severity:critical
> bug?
I am seriously claming that whatever you are referring to, if true, is
such a contrived example that does not actually happen in real life
(or at least, it does not happen
On Nov 18, Zack Weinberg wrote:
> And, as it has proven to be a genuinely critical problem, it is also their
No, it has not.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Nov 10, Sam Hartman wrote:
> I'm sorry, but I think the only way in which that horse is dead is that
> no one has proposed patches to dpkg.
Indeed, because the sides of this argument are like three people (one of
them being the dpkg maintainer) versus everybody else.
Since some significant
On Nov 08, Simon Richter wrote:
> Yes, but the conversion needs to be performed by dpkg, because the usrmerge
Please kindly stop beating this long-dead horse.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Nov 08, Simon Richter wrote:
> Right now, it is sufficient to preseed debconf to disallow the usrmerge
> package messing with the filesystem tree outside dpkg. Managed installations
> usually have a ready-made method to do so.
This is not really relevant, since the conversion is mandatory.
I have been asked to remove from the usrmerge package the debconf
question which asks to confirm the conversion.
Does anybody REALLY believe that it should not be removed?
--
ciao,
Marco
signature.asc
Description: PGP signature
On Oct 18, Sean Whitton wrote:
Thank you: this is great work and, even if it requires maintaining
support for unmerged systems for yet another release, I fully agree with
the results.
> - Debian contributors who are interested in merged-/usr are invited to
> implement a straightforward
On Oct 05, John Paul Adrian Glaubitz wrote:
> Could anyone tell me what the proper gbp command is for creating the changelog
This works for me.
md:~ $ cat ~/bin/git-debtag
#!/bin/sh -e
VER="$(dpkg-parsechangelog --show-field Version)"
if [ -z "$VER" ]; then
echo "Could not parse the
On Sep 28, Noah Meyerhans wrote:
Should it be mentioned what the new recommended DHCP server for general
use will be?
> For what it's worth, my preference would be transition to
> systemd-networkd with bookworm.
I think that a good default would be systemd-networkd for servers and
On Sep 27, John Paul Adrian Glaubitz wrote:
> Not for me, though. Debian has always followed the philosophy to be a
> universal
> operating system, which also meant that we can't (immediately) use all the new
> technologies and features that other distributions or upstream projects
> develop.
On Sep 24, Marc Haber wrote:
> But maybe an alternative? I find the partitioning step one of the most
> error-prone and hard-to-use parts of non-trivial Debian installations.
And the preseeding syntax is as powerful as it is inconvenient.
I had not heard of growlight before yesterday, but from
On Aug 29, Colin Watson wrote:
> I can see the issue there. Adding another prompt that every Debian user
> will need to consider on upgrade to the next release is pretty
> undesirable, though - I actively try to avoid that in base-passwd
> changes. So maybe the policy violation, i.e. ending up
On Aug 26, Guillem Jover wrote:
> By my definition, these have never been working correctly, but
> semantics I guess.
It is not semantics. You keep saying that countless Debian and Ubuntu
systems are not working correctly, but since this obviously does not
reflect the experience of the owners
1 - 100 of 2878 matches
Mail list logo
