On Apr 20, Adrian Bunk wrote:
With embedded distributions a whole system of bootloader, kernel and
userspace easily fits on 16 MB flash, even when including bloated stuff
like glibc and systemd, with plenty of space left for the application
that should run on the device.
You can't do that with
On Apr 20, Josh Triplett wrote:
On a slightly related note, one of these days I'd love to figure out how
we could stop systematically installing /usr/share/lintian/overrides *in
binary packages*, and move them to some form of metadata that doesn't
get installed.
Yes please! This is why I almos
On Apr 19, Michael Stone wrote:
If the goal is a minimal container image, why use debian at all vs a
distribution optimized for that purpose? Running alpine without perl
is already a solved problem...
Because I want to use a real libc, for a start.
--
ciao,
Marco
signature.asc
Description:
On Apr 10, Helmut Grohne wrote:
how about libc6-dev stops depending on libcrypt-dev?
Sure.
material of course. Also libc6-dev would still "Recommends:
libcrypt-dev", but libcrypt-dev would no longer be build-essential.
What purpose would this Recommends solve?
Assuming "no" and "yes" as a
On Apr 02, Bill Allombert wrote:
Does that breaks the usual unix commands like 'who' ? If yes this is
who(1) specifically, yes.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 .
Maybe the coreutils maintainer is already working to backport this
simple patch in time for trixie, o
On Apr 03, Michael Stone wrote:
The issue isn't making a change, the issue is what change is the right
thing to do. IMO, dropping utmp without any kind of a transition or
deprecation period is the wrong thing to do. Hence this thread.
I think it's a bit late now to disagree with the plan imple
On Mar 15, "Roberto C. Sánchez" wrote:
This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU.
Indeed.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Mar 12, Hakan Bayındır wrote:
If we think that a shader is a firmware, any software running on the
second socket on a system is also a firmware, since the program is
running on a different CPU w.r.t. to Kernel.
This is not how Linux actually works.
--
ciao,
Marco
signature.asc
Descripti
On Mar 12, Hakan Bayındır wrote:
In first blush, I don’t think shaders should be considered firmware.
They are not used to enable the hardware,
I am not taking a position about shaders at this point, but I will note
that this has never been the definition of firmwares.
Firmwares are software
On Mar 09, Matthias Urlichs wrote:
> My "build me a Debian image" script has been doing that for two years now,
> simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
> onto /var/lib/dpkg (symlinking won't work).
How so? My /var/lib/dpkg has been a symlink for a very long t
I will just note that I have been a Debian Developer for almost 30 years,
and a few months after I started maintaining varnish and other related
packages I am still not sure if I did everything needed to receive one
and only one copy of new bug reports.
So I would welcome some rationalization in
On Feb 26, Soren Stoutner wrote:
> The purpose of this email is to propose that the expectation that
> emails should be wrapped at 80 characters when they are sent should be
> dropped.
I am opposed.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Feb 18, Charles Plessy wrote:
> Again, given the scale, Debian can not expect that the package
> maintainers are going to contact each upstream and send a patch. We are
> not paid for that.
We are not paid for anything at all, to be fair...
I think that we are expected to forward most bugs to
On Feb 14, Colin Watson wrote:
> But it doesn't. Santiago's using the data from the security tracker to
> determine whether CVEs are open.
And in the case of one of my own packages these CVEs have not yet been
fixed upstream, not even in an unreleased branch.
--
ciao,
Marco
signature.asc
De
On Feb 15, Stéphane Glondu wrote:
> On the other hand, insisting on using upstream VCS contents can lead to ugly
> hacks in Debian packaging, such as what you are describing. I must admit I
> usually use "official" tarballs to avoid these hacks (and maybe a little out
> of laziness).
In my own pa
On Feb 13, Vincent Danjean wrote:
> In addition, I do not see how snapshotting of full FS can be correctly
> supported, unless all other softwares are stopped while dpkg is running.
>
> What if a database records some transactions while dpkg is running. What
> would happen at rollback ?
Th
On Jan 24, Otto Kekäläinen wrote:
> I would be curious to hear why people are *not* adopting 'debian/latest'?
>
> Why does the majority of Debian packages still use 'master' or
> 'debian/master' branch as the main development branch?
Because it works fine and it is the most commonly used branch
On Jan 14, Simon Josefsson wrote:
> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like that.
Like the Kerberos patch for OpenSSH?
--
ciao,
On Jan 14, Simon Josefsson wrote:
> I don't think it is a good idea to use the powers that comes by being a
> package maintainer or distribution to force changes of how some piece of
> software is supposed to work by patching it without changing its name.
We have been doing this since Debian exis
On Jan 07, Julien Plissonneau Duquène wrote:
> You are free to join or discuss it here. That DEP has been online for some
> years now, it's not exactly happening in the hiding.
Nobody mentioned hiding anything, but it's still just a few people
chatting in a gitlab issue.
> > WTF? I say instead
On Jan 07, Raphael Hertzog wrote:
> This change basically adds the recommendation to use "upstreamvcs" as the
> name of the "git remote" to access the upstream repository and it also
Like many others, this looks like a gratuitous change for change's sake.
Countless packages have been using "upstr
On Dec 19, Henrik Ahlgren wrote:
> Take bind9 named(8) for example – it can chroot (with -t) but AFAIK
> Debian does not use it by default, and I think using the various
Because it makes managing it much harder, since /etc/bind/ then moves to
/var/.
Systemd directives like ProtectSystem, ReadOnl
On Dec 19, Frank Guthausen wrote:
> Is it reasonable to use this idea as "best practice" and implement it
> into Debian style administration recommendations? It works very well
No: the expected default for systemd-managed services is to use
/etc/$SERVICE/ .
--
ciao,
Marco
signature.asc
Descr
On Dec 16, Michael Tokarev wrote:
> What do you think about this aspect of postfix on debian?
I do not remember ever having any issues about this, and I have been
using Postfix since before it was called Postfix. But if Wietse says
that a chroot default is not worth it then I fully trust him.
On Dec 12, Jonathan Dowland wrote:
> The "Perl Problem" is a wider issue we should explore in much more depth.
We would first need to determine that there is an actual problem.
Perl is quite healthy as a language and has aged much better than many
other younger languages: e.g. there is no need t
On Nov 27, gregor herrmann wrote:
> As person B I don't want to go hunting for a tarball and place it in
> the right place, I want gbp to re-create it from the pristine-tar
> branch.
Who cares? gbp export-orig takes care of it, unless you need to actually
upload it to the archive.
--
ciao,
Mar
On Nov 27, Johannes Schauer Marin Rodrigues wrote:
> If the upstream tarball is in the archive, it's probably okay to retrieve one
> from there. It's not always trivial because now you need to have the right
> "deb-src" lines enabled in your apt sources.list but it's possible. But how do
It is t
On Nov 26, Jonathan Dowland wrote:
> On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:
> > Yes, as they don't enable pristine-tar
> Is pristine-tar still valuable these days?
Not really. The debian branches of all of my packages[1] are based off
the upstream git repository, which i
On Nov 24, Bastien Roucariès wrote:
> > > Do you think it is a good idea to set the testbed hostname to a FQDN ?
> > Please do. This has been a pain for the INN CI as well.
>
> Thanks marco
>
> How can we get some improvment on this side ?
Just set in the CI containers/guests an hostname which
On Nov 24, Sean Whitton wrote:
> This is interesting. One concern I have is speed -- isn't it always
> slower to have to unpack a tarball before the build instead of having a
> chroot under /srv/chroot that's always unpacked?
People who feel this is a problem can try my super fast fork of pbuild
On Nov 22, Julian Andres Klode wrote:
> That's correct due to some overlinking in the Rust toolchain,
> there needs to be some more crate splitting to make it smaller.
Do you have reasons to believe that this is going to happen in time for
the next release?
The size increase is not trivial. :-(
On Nov 21, Julian Andres Klode wrote:
> I've just finished more or less, adjusting the APT test suite
> to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> tomorrow. This ensures full compatibility between apt and
> gpgv-sq going forward.
OK, but why?
Did you make an analysis of how much
On Nov 12, Iustin Pop wrote:
> The question is why on a default install with grub, which doesn't need
> nor use the symlinks, are they still created. For most systems, they're
> superfluous.
>
> iustin, who also dislikes these and always needs to disable them
Agreed.
--
ciao,
Marco
signature
On Nov 08, Bastien Roucariès wrote:
> Does it seems a reasonable assumption to use a domain for an host even if it
> is localdomain or test ?
>
> Do you think it is a good idea to set the testbed hostname to a FQDN ?
Please do. This has been a pain for the INN CI as well.
--
ciao,
Marco
sig
On Oct 29, Dennis van Dok wrote:
> I think what I should do is update the release number and do another (source
> only) upload.
Correct: these uploads are supposed to be accepted because binary
uploads are still needed for passages in NEW (in that case: it's to
target experimental for the first
On Oct 28, Chris Hofstaedtler wrote:
> It also appears true that IBM has an interest in s390x, but today
I wonder if their interest could actually be just in Debian providing
a base for the Ubuntu port (which I understand used to be funded by
IBM).
And if this is still true now that IBM owns Re
On Oct 14, Charles Plessy wrote:
> The package names starts with r-cran. Upstream, they are tested against
> amd64 and Silicon only. If you look at the health of the packages and
> the team, it is not good. Well it is as good as many pieces of the free
> software ecocystem: crumbling under the
On Oct 06, Otto Kekäläinen wrote:
> Also some projects release tarballs with extra additions that are not
> in the same git, or they strip away directories/files that are in git,
I am sure that there are counterexamples, but usually they exclude
things that we want to rebuild anyway, like config
On Oct 05, Simon Josefsson wrote:
> I would like that 'apt install signify' install OpenBSD's signify (from
> the Debian 'signify-openbsd' package) and not the 2003 mail-related
> signify perl script from the Debian 'signify' source package.
Agreed: the current signify package is a niche tool mai
No objections to have this kind of capability, but I still strongly
believe that importing tar archives is highly suboptimal and directly
branching off the upstream git repository is an highly superior workflow
and should be used as much as possible.
This being said, I maintain some packages wh
On Sep 23, Lukas Märdian wrote:
> As described in the "Proposal" section and first answer of the FAQ, it's all
> about consistency.
>
> There seems to be a tendency for moving towards a hybrid stack, using
> sd-networkd and NetworkManager in different contexts/use-cases. But having
> fragmented
On Sep 23, Holger Levsen wrote:
> ifupdown2 is like ifupdown, just rewritten in python.
Yes, that's the problem: there was a consensus that it is not an
appropriate dependency for the base system.
ifupdown2 will still be around for anybody who wants to install it.
--
ciao,
Marco
signature.as
On Sep 20, Lukas Märdian wrote:
> PS: I know this proposal doesn't please everybody, but I think it's the most
Actually I cannot thing of your proposal having much support from
anybody else.
At this point I am starting to find annoying how hard you alone are
trying to push Netplan on Debian.
>
On Sep 04, Lukas Märdian wrote:
> With Netplan we could provide coherent network configuration across all
> variants of Debian (server, cloud, laptop, ...), while choosing the best
> underlying stack for the usecase (i.e. systemd-networkd on server/cloud
> and NetworkManager on desktop/laptop).
O
My position is that I am happy for Debian to have the option of netplan
but I do not think that it should be installed by default, because it is
an abstraction which adds complexity and that nobody asked for other
than its developers.
And this is an orthogonal issue with deciding if ifupdown is
On Sep 02, Daniel Gröber wrote:
> Based on publically available [information], my previous and recent
> interactions with upstream this happend more due to personal
> differences with upstream than for technical reasons and I hope to be
> able to rebuild that damaged bridge.
Based on my own perso
On Aug 23, Theodore Ts'o wrote:
> > salsa update_projects $NAMESPACE/$PROJECT \
> > --jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline
>
> OK, more stupid questions. What is "$NAMESPACE"?
Whatever you see after "salsa.debian.org/" in the URL.
> And I thought I saw somethin
On Aug 23, Theodore Ts'o wrote:
> 1) From a technical respective, what does Salsa CI buy me? Is it just
Maybe different and more Debian-specific tests than the one that you are
running elsewhere? They should all be documented here:
https://salsa.debian.org/salsa-ci-team/pipeline/ .
> 2) If I'
On Aug 22, Aurélien COUDERC wrote:
> I personally think it’s crazy / not a good use of my time to try and
> mix both upstream and packaging history in the same repo and try to
> make git dance around that when handling new upstream releases. The
> extents of the ongoing d-devel discussions on
On Aug 21, Otto Kekäläinen wrote:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?
Advertise widely and frequently that there is a pool of people which is
ha
On Aug 01, Luca Boccassi wrote:
> Emails are actually a barrier against collaboration, and actively
> hinder it by preventing new people from joining in. Please understand
No, email is the only inclusive collaboration platform.
I can use email while traveling and when the least possible connectiv
On Jul 28, Phil Wyett wrote:
> As DebConf24 starts I am going to put in another request for DDs with some
> spare time to review and possibly upload to Debian packages that have been
> submitted to Debian Mentors and have passed sanity checking/tests.
Can we have this become a regular message, ma
On Jul 11, Matthias Urlichs wrote:
> On 11.07.24 08:13, Marc Haber wrote:
> > Therefore, you could change
> > configuration while the Interfacce was up and then just say "ifdown ;
> > ifup" and be fine. No network configuration software up to today has
> > THAT feature.
> Shouldn't "systemctl rel
On Jul 10, Simon Richter wrote:
> It is supported *now*, but the roadmap is unclear -- that support could be
> discontinued at any moment, and it would not be the first time a feature
> Debian relied on was removed.
You have manufactured a non-existing issue and then decided to get
anxious about
On Jul 11, Vincent Bernat wrote:
> This is quite unfair. Cumulus tried very hard to make ifupdown2 a community
> projects, with notably a presentation at Debconf 14 and Debconf 16. One of
> its killer feature is the ability to go from the running state to the target
> state with one command (ifre
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.
It has all the disadvantages of switching to a new configuration format,
but then it limits you to the features
On Jul 09, Bjørn Mork wrote:
> Just tried to point out that automatic conversion will be hard. And
And I believe that nobody argued to do that.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Jul 09, Simon Richter wrote:
> For a server installation, I absolutely need the option to configure a
> static IP from d-i text mode interface or a preseed file, and this
> configuration to be taken over into the installed system.
I do not understand why you are explaining this as if it were s
On Jul 09, Martin-Éric Racine wrote:
> I just had a look at ifupdown-ng. The /etc/network/interface syntax
> is not a drop-in replacement for ifupdown. That's a big no-no. Those
> "use dhcp" have to go.
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or sys
On Jul 03, Alec Leamas wrote:
> 1. Is it possible to package such a solib in the non-free section?
Is it actually redistributable?
> 2. opencpn would have a weak Suggests: or Recommends: on this package. Would
> it mean it has to move to contrib?
Suggests, no. Recommends, yes. See policy 2.2.1.
On Jun 25, Guillem Jover wrote:
> I manage my chroots with schroot (but not via sbuild, for dog fooding
> purposes :), and use type=directory and union-type=overlay so that I
> get a fast and persistent base, independent of the underlying filesystem,
> with fresh instances per session. (You can a
On Jun 06, Johannes Schauer Marin Rodrigues wrote:
> A question that goes in a similar direction is whether every d/rules that
> needs
> it should have to do this:
>
> export DPKG_EXPORT_BUILDFLAGS=y
> include /usr/share/dpkg/buildflags.mk
>
> Or whether we should switch the default and requir
On Jun 06, Simon McVittie wrote:
> I believe the change Luca describes is increasing rlim_max (hard limit)
> but not rlim_cur (soft limit), and the code touched by that patch is
> looking at rlim_cur, so it should be unaffected anyway - unless some larger
> component is raising rlim_cur.
Somethin
On Jun 06, Luca Boccassi wrote:
> The last time this was tried some packages were still not ready, so it
> was patched out to let them be fixed. Enough time has passed now, and
> it's time to let any unknown leftover just break and be fixed. In all
> known cases, the buggy pattern was to manually
On May 28, Andreas Metzler wrote:
> I think it is bad choice to deliberately have different behavior for
> freshly installed and upgraded systems. Offering upgrades has always
> been one of the major selling points of Debian, and imho this
> implicitely includes that you do not get a worse or sec
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 distributions
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 mayb
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 w
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 becom
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 trace
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 no
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 v
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 gbp-import-
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 a
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 h
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 reall
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 signa
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 --exclude=/usr
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 ago.
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 sti
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
> common-{account,auth,password,session,session-noninter
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 sens
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 we
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 /e
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 thi
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
Description
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 th
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 mechanism
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 agre
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 the
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,
con
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
1 - 100 of 1776 matches
Mail list logo
