Bug#879191: /usr/lib/modprobe.d/systemd.conf ignored, should be in /lib/modprobe.d

[Marco d'Itri]

On Oct 20, Michael Biebl  wrote:

> That path is read by kmod. Given that kmod supports
> /usr/lib/modules-load.d and /lib/modules-load.d/ it would imho make
> sense if it also supported /usr/lib/modprobe.d besides /lib/modprobe.d
I would rather have this patch be submitted upstream.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: urgency of a fix before stretch

[Marco d'Itri]

On Jun 03, Norbert Preining  wrote:

> >As one of the systemd maintainers I am explicitly and publicly 
> >requesting that you do not introduce this unwanted change.
> Then how are you planning to deal with this serious bug after years of 
> inactivity?
I think that I have already expressed clearly my position.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: urgency of a fix before stretch

[Marco d'Itri]

On Jun 02, Norbert Preining  wrote:

> I am planning to upload an NMU fixing this issue to DELAY3 and hope that
> release managers allow this fix into stretch.
You cannot do a NMU just because the maintainers of a package disagree 
with you.

As one of the systemd maintainers I am explicitly and publicly 
requesting that you do not introduce this unwanted change.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#862067: udev: U2F support. Outdated uaccess udev rules.

[Marco d'Itri]

On May 09, Michael Biebl  wrote:

> Do you think this bug report is important enough to be fixed in stretch,
> i.e. warrants another upload of src:systemd?
Either in 9.0 or it should be queued for the next point release.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#862067: udev: U2F support. Outdated uaccess udev rules.

[Marco d'Itri]

On May 08, Michael Biebl  wrote:

> Maintaining those udev rules in src:systemd as a downstream patch is not
> something I plan to continue. It was probably a mistake to add them in
> the first place.
Clearly it is too late to add a new binary package for Debian 9, so 
I think that we should accept such a patch once and decide a better 
approach post-stretch.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#855798: udev: MemoryDenyWriteExecute=yes should not be applied to udev plugins

[Marco d'Itri]

On Feb 21, Mike Manning  wrote:

> Some executables outside of systemd are no longer run as plugins after 
> an upgrade from Debian 8 to Debian 9 RC2, even though they should be 
Do you have a list? I would like to better understand the impact of this 
regression: we need to find the appropriate tradeoff between security 
and compatibility.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#827704: udev is not portable and mandates kernel features

[Marco d'Itri]

On Jun 20, Pierre Ynard  wrote:

> Please improve the portability of udev and reduce or eliminate the above
> list of required non-essential features.
No: maintaining such a patch kit would take a huge amount of our time 
for a very small benefit.

> As a last resort, please make this apparent lack of portability more
> understandable for users. The information in the README is a very good
> start already, I appreciate it, but please complete it to document
> what requires the features in the above list and foremost why they
I am not sure about what I should add: if you are, please feel free to 
send a patch to the upstream maintainers.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#825394: Bug#824931: similar to bug #824931

[Marco d'Itri]

On Jun 06, Marc Lehmann  wrote:

> The maintainer already said that this is the correct behaviour, so this
No, I did not: I explained that I wanted to better understand your setup 
to determine what the default semantics should be.
In the case of #824931 the problem is that it is login and not telnetd 
which creates the new user session, so the telnet daemon is left in the 
inetd cgroup and killed along with it.

While I still think that this would be the most generally useful 
semantics for other inetd-started daemons, I can see how it could 
surprise telnet/rsh users.

Since I am not sure if there is a simple solution that could be 
implemented in the telnetd package, at this point I am considering to 
set KillMode=process as the default for openbsd-inetd.

OTOH, I am not sure that this use (corner) case of telnet/rsh users is 
more important than the others, even if the current default is 
a regression for them, so I am still undecided...

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#824491: udev: impossible to disable predictable network interface names

[Marco d'Itri]

On May 16, "Steinar H. Gunderson"  wrote:

> >>   Error: argument "enx001e06303327.20" is wrong: "name" too long
> > That sounds like a bug on its own
> Yes. Although perhaps it's a kernel limitation?
It is (IFNAMSIZ).

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#824025: udev: Please split rule for MAC-based name of USB network interface out of 73-special-net-names.rules

[Marco d'Itri]

On May 11, Raphael Hertzog  wrote:

> I would really prefer if that rule could be split into its own file
> so that it can be disabled in the same way with a single symlink instead
> of having to maintain a forked version of 73-special-net-names.rules.
Well, this would mean us maintaining a forked version of 
73-special-net-names.rules instead...

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#821948: udev: Please plit uaccess config file

[Marco d'Itri]

On Apr 21, asu  wrote:

> >: > /etc/udev/rules.d/70-uaccess.rules
> >
> Good but i want to set only on sound device to follow users from group
> audio.
Then you can write your own rules in that file. We will not change the 
defaults.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#815321: resolved unconditionally uses google name servers - again

[Marco d'Itri]

On Feb 20, Marc Haber  wrote:

> DNS=fec0:0:0:::1
> DNS=fec0:0:0:::2
I think that the problem is that you did not configure any IPv4 name 
servers. Since it is a valid configuration, and not even implausible  
nowadays, this should be fixed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#812928: udev: cdrom_id terminated by signal BUS

[Marco d'Itri]

Control: reassign -1 src:linux
Control: found -1 4.3.0-1
Control: retitle -1 getauxval(AT_RANDOM) broken on sparc64

On Jan 27, Anatoly Pugachev  wrote:

> Program terminated with signal SIGUSR1, User defined signal 1.
> #0  0x0101b9b8 in initialize_srand () at src/basic/random-util.c:107
> 107 x ^= *(unsigned*) auxv;
> (gdb) bt
Looks like getauxval(AT_RANDOM) returns garbage on sparc64:

x = 0;
auxv = (void*) getauxval(AT_RANDOM);
if (auxv)
x ^= *(unsigned*) auxv;

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#811345: setupcon not run

[Marco d'Itri]

On Jan 23, Samuel Thibault  wrote:

> Should udev or systemd perhaps provide some hook to configure a
> just-created VT?
Maybe a rule like this one?

ACTION=="add", KERNEL=="tty[1-9]|tty[1-9][0-9]", RUN+="..."

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#810886: udev: Boggus interface name for 3G/LTE modem

[Marco d'Itri]

On Jan 13, Laurent Bigonville  wrote:

> On my new lenovo laptop, the interface name for the 3G/LTE modem seems
> boggus: enx
It really reports ff:ff:ff:ff:ff:ff as its own MAC address, so...

> cdc_ncm 2-4:1.0 usb0: register 'cdc_ncm' at usb-:00:14.0-4, CDC NCM, 
> ff:ff:ff:ff:ff:ff
> cdc_ncm 2-4:1.0 enx: renamed from usb0
Is this a firmware bug or does it need to be configured by some 
userspace tool?

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#809556: socket API filtering broken on x86

[Marco d'Itri]

FYI.

- Forwarded message from Marco d'Itri <m...@linux.it> -

From: Marco d'Itri <m...@linux.it>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: Bug#809556: socket API filtering broken on x86

Package: libseccomp2
Version: 2.2.3-2
Severity: grave
Tags: patch

Please merge the add-x86-32bit-socket-calls.patch patch from the Ubuntu 
package, which is required to handle the new socket-related system calls 
of recent kernels.

Without this patch systemd-nspawn is broken on x86, and I have tested 
that it works again with a patched libseccomp2.

For details:
https://github.com/systemd/systemd/issues/2177

After a quick look I think that all the patches of the current Ubuntu 
package should be imported wholesale since they fix issues on other 
architectures.

Please let me know if you need a NMU.

-- 
ciao,
Marco


- End forwarded message -

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#808997: Processed: Re: Missing /usr path in modules-load.d(5)

[Marco d'Itri]

On Dec 26, Michael Biebl  wrote:

> I actually think we should move files to /usr/lib/modules-load.d and
> make that the preferred location (that's what other distros use that
> have done the usr-merge).
Agreed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#801626: udev: out-of-memory/page-fault when encountering broken ms-dos partition table

[Marco d'Itri]

On Oct 12, Dieter  wrote:

> Sadly i can't. I have not yet found a system or live-cd that would not run
> into the described out-of-memory situation.
> (i tried debian-stable live, gparted live, arch-stable live)
GRML does not use systemd yet, so it may work.

> I thought i might be able to mask the partitions using the following rule:
> cat /etc/udev/rules.d/00_hide_partitions
> KERNEL=="sdc*", ENV{UDISKS_IGNORE}="1"
> KERNEL=="sdd*", ENV{UDISKS_IGNORE}="1"
I doubt that the problem is udisks, try instead:

cat << 'END' >> /etc/udev/rules.d/10-test.rules
KERNEL=="sd[cd]*", GOTO="systemd_end"
END

If this works then you can try raising 10 step by step until you can 
reproduce the issue (have a look at the existing rules to guess some 
interesting values).

-- 
ciao,
Marco


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#800572: [Pkg-alsa-devel] Bug#800572: CONFIG_UEVENT_HELPER=n kernel confuses alsactl restore

[Marco d'Itri]

Control: reassign -1 alsa-utils

On Oct 01, Elimar Riesebieter  wrote:

> As alsas' udev rules are installed by udev package.
This is not about the udev rules but wrong assumptions in alsactl.

-- 
ciao,
Marco


pgp7efjzDFeIE.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#800315: Processed: Re: Bug#800315: gets stuck at boot time with "switching to bochsdrmfb from simple"

[Marco d'Itri]

On Sep 28, Harald Dunkel  wrote:

> I wonder why this report has been set to resolved?
Because if loading a driver breaks your system then this is a kernel 
bug, not a udev or systemd bug.

-- 
ciao,
Marco


pgp8g7NjUG9XG.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices

[Marco d'Itri]

On Aug 08, brian m. carlson sand...@crustytoothpaste.net wrote:

 Previously, my WiMAX device was named something like wmx0.  Now, it
 appears it's been renamed to enxMAC Address.  First of all, the name
 has changed from what it used to be, and now I have to check that it's
 not broken anything.  There wasn't supposed to be a naming change for
 people with the persistent-net rules in place.
Indeed: what was the content of your 70-persistent-net.rules file?
I suspect that persistent naming just never worked for you for this 
interface.

 Secondly, this is not an Ethernet device, so en is not correct (it
 should be ww).  The device is on the USB bus (using the driver
 i2400m-usb).
I do not think that such a distinction is relevant here.

 For an example why this matters, think firewall rules: while I might
 legitimately want to SSH into my laptop over Ethernet or WiFi (e.g. from
 my phone when I'm in the other room), there's no reason I would want
 arbitrary people on the Internet (WiMAX) to SSH in.  Of course, I have
 appropriate security measures in place, but I'd still want to firewall
 incoming WiMAX connections, and using an appropriate naming scheme makes
 that possible.
You can still manually set any persistent name you like.

-- 
ciao,
Marco


pgpeKhdJb_WfP.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: usrmerge package

[Marco d'Itri]

On Aug 04, Josh Triplett j...@joshtriplett.org wrote:

 You might also try adding Important: yes to it and testing the effect
 of that in package managers (with a ping to the apt and dpkg folks to
 confirm the semantics).  As far as I know, that acts like Essential:
 yes in providing warnings about removing the package, except that
There is already some magic code in prerm which prevents removing the 
package in unsafe conditions.

 For similar reasons, while I'd like to see packages start to rely on
 this, for now I think it'd be appropriate to ping the lintian folks
 about adding usrmerge to their list of packages that nothing else may
 depend on.
I am not sure about this, we can always get back to this later if it 
will become a problem.

 Have you started the process of getting a Policy proposal together about
 handling everything-in-/usr (optional symlinks, etc), to point new
 packages at and to base Lintian warnings on?
I have been not dealt with the policy process in the last 15 years, so 
I hope that somebody who is more familiar with it will work on this. :-)
Also, we need a release goal proposal for everything-in-usr support.

 Consider adding a link somewhere to the BTS usertag for usrmerge bugs.
It is in README.Debian.

-- 
ciao,
Marco


pgplFEkv8tz4V.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Proposal: enable stateless persistant network interface names

[Marco d'Itri]

On Jun 26, Thomas Goirand z...@debian.org wrote:

  Actually it requires us to keep maintaining the 
  Revert-udev-network-device-renaming patch as long as there will be 
  systems with a 70-persistent-net.rules file renaming eth* to eth*.
 The other solution would be to upstream that patch (maybe as a kernel
 option if that is relevant).
This cannot happen since the patch actually reverts an upstream change.

  I believe that firmware-based device names work well enough in practice 
  since RHEL 7 uses them by default: I tend to trust a market-based 
  approach to maintenability more than anecdote from a very selected 
  population like the debian-devel@ subscribers.
 Oh, how nice is that... So our opinions don't count, and Red Hat is just
 always right!
Opinions do not make a statistic, indeed.
And you have not been paying attention, because right here I have 
expressed many times disagreement with some Red Hat decisions.

 All from redhat. /me not surprised...
Yes, at this point it is not a surprise that they produce good 
documentation and we do not.

 So your proposal is: if the default is unusable (like above), then the
 poor user has to find a way to fix that... I'm not convince that this is
 what we want. I'd very much prefer a usable default.
Me too, but there is none that we can use.

-- 
ciao,
Marco


pgp3TVDcZqnNG.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Proposal v2: enable stateless persistant network interface names

[Marco d'Itri]

On Jun 25, Martin Pitt mp...@debian.org wrote:

 Unlike /dev nodes, network interfaces can't have aliases as far as I
 know. Am I missing anything?
No. As is usual with udev, the people who do not understand how it works 
are always ready to propose solutions.

-- 
ciao,
Marco


pgpN9EvRdglqy.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[Marco d'Itri]

On Jun 24, A Mennucc mennu...@debian.org wrote:

 systemd is logging a lot of error messages as in the attached log
 
 I also attach the output of strace -p 1
 
 Someone wrote on the Internet that this may happen when the system
 runs out of memory. This was my case. In the log you may see
Can you clarify what you are complaining about exactly?

-- 
ciao,
Marco


pgpsUVso1wgHi.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#760923: tentative patch

[Marco d'Itri]

On Jun 23, Martin Pitt mp...@debian.org wrote:

 This sounds confusing -- systemd has never changed the behaviour of
 halt; sysvinit misimplemented halt, so the change is between
 changing init systems, not upgrading any particular version.
I think that either we can update the release notes for jessie or there 
is no point in clarifying this since most Debian systems (and almost 
all jessie systems) already use systemd and show this behaviour.

-- 
ciao,
Marco


pgpVMGTvjY22h.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#760923: tentative patch

[Marco d'Itri]

On Jun 23, Vincent McIntyre vincent.mcint...@csiro.au wrote:

 +systemd (221-1) UNRELEASED; urgency=medium
This has not changed in 221: even if we really want to document this in 
NEWS.Debian then the message must not be displayed to everybody who has 
already installed a version of systemd which has this behaviour.

-- 
ciao,
Marco


pgp7K6tA2M838.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Proposal: enable stateless persistant network interface names

[Marco d'Itri]

On May 08, Martin Pitt mp...@debian.org wrote:

 I propose to retire [mac], i. e. drop
 /lib/udev/rules.d/75-persistent-net-generator.rules and enable
 [ifnames] by default.
I see a large enough consensus about switching by default to ifnames, 
and I believe that the few people who want MAC-based names for USB 
interfaces can easily set NamePolicy=mac or write a custom rule.

I am not sure that we really need to retire 75-persistent-net-generator 
right now: the annoying part to maintain is the kernel patch which we 
will need anyway for at least a couple of releases, and once we make it 
use em* or eno* instead of eth* then it should be robust.
It is trivial to make it opt-in by setting something like net.ifnames=0 
(or even a different and specific value), and we can revisit this 
decision when we will be closer to the release.

 So we can only let time and replacing/reinstalling machines take care
 of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
 maintenance from us (it's just like the admin had manually set their
 own rules).
Actually it requires us to keep maintaining the 
Revert-udev-network-device-renaming patch as long as there will be 
systems with a 70-persistent-net.rules file renaming eth* to eth*.


I believe that firmware-based device names work well enough in practice 
since RHEL 7 uses them by default: I tend to trust a market-based 
approach to maintenability more than anecdote from a very selected 
population like the debian-devel@ subscribers.
This is the relevant documentation, which I strongly recommend everybody 
interested in this issue to read:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html

Maybe biosdevname would be nice to have, but:
- somebody needs to actually maintain it in Debian
- by default it only works on Dell systems
- it is not loved by the udev/systemd upstream maintainers
- it does not seem to me to provide any benefit over the firmware-based 
  names since in practice both would use by default an interface index 
  in the common case

So I do not think that we need to care about it.

An obvious downside is longer names for devices which do not provide 
ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does 
not (wlp2s0), but the Ethernet port does (eno1).
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on 
my Allwinner-based ARM computer), which means that interfaces will get 
a mac-based name like enx028909xx.
But if somebody cares about the aesthetic value of network interface 
names then they can probably write a custom udev rule to rename them,
or keep using 75-persistent-net-generator if we can keep it around.

(I believe that it would be a good idea for the ARM porters to have 
a look at which values are exported by their network drivers, because 
probably nobody else is going to work on this any time soon.)

FWIW, I did a quick survey of my hardware:
- HP G8: OK
- HP G8 + add-on Intel card: OK (but obviously no index)
- HP G8 + FlexFabric: OK
- HP Gen9 + FlexFabric: stupid but will work (the SMBIOS indexes start 
  from 49 instead of 1!)
- Cisco UCS: OK
- IBM BladeCenter + Emulex CNA: very broken (only eth0 has an index!
  I only checked biosdevname but it should not matter)
- IBM Flex + Emulex CNA: broken like the BladeCenter
- Some Intel-based Supermicro: OK

(If any of the HP people here can find out who is responsible to fix 
the Gen9 BIOS then I can have my HP account manager make a business case 
for it. Submitting a support case would be time consuming for me and 
unnecessarily cruel for the support people...)

-- 
ciao,
Marco


pgpqeby3JgoLK.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#783692: systemd: systemctl output is unreadable on light background

[Marco d'Itri]

On Apr 29, Juergen Stuber juer...@jstuber.net wrote:

 I use a light gray background, so green becomes completely unreadable.
I checked the attached image and I can read it well on a business 
matte LCD.
Maybe the settings for your screen should be tuned?
Are your eyesight and colors perception OK?

-- 
ciao,
Marco


pgpN49DVlUp2R.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#783321: systemd opens file in /var/run and not in /run

[Marco d'Itri]

On Apr 26, Michael Biebl bi...@debian.org wrote:

 My concern is, that /var/run might *not* be a symlink to /run.
I am not sure, but then I would rather have these systems break in 
a more visible than subtle way.

 It's hard to quantify, how common that is. Probably not that much, but
 still. I've seen setup's over the years where users had a separate tmpfs
 for /var/run for example.
If this is really a concern then we can easily add a check in systemd's 
preinst.

-- 
ciao,
Marco


pgpgGIxf9Prcn.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#783321: systemd opens file in /var/run and not in /run

[Marco d'Itri]

On Apr 26, Michael Biebl bi...@debian.org wrote:

 The problem with /var/run/dbus/system_bus_socket is, that it's
 hard-coded in so many locations (as you can see on codesearch), one
 could even consider it ABI, that I'm worried that we might break quite a
 lot of stuff by changing it.
I can't see why: the /var/run/ symlink is not going away any time soon 
so compatibility will be preserved.

-- 
ciao,
Marco


pgpqZVXDZXLNd.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: Please do not default to using Google nameservers

[Marco d'Itri]

On Apr 07, martin f krafft madd...@debian.org wrote:

 is your position unchanged?
Yes, since the arguments against this configuration that have been 
presented so far can be summarized in OMG Google!!!1!.

So far the current default looks like a reliable and secure one, and
as the package maintainer I do not believe that removing the feature
of a last resort fail-safe preconfigured DNS resolver would be 
no default would improve the quality of Debian.

If you feel the need to further pursue this then please explain in 
detail the threat model that you are trying to address and how the 
current default configuration would be worse than other default 
configurations.

-- 
ciao,
Marco


pgpPMySQbL0jE.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#761658: Please do not default to using Google nameservers

[Marco d'Itri]

On Apr 07, Christoph Anton Mitterer cales...@scientia.net wrote:

 Actually it's not, many networks block access to external resolvers
 since the proper ones are given via DHCP.
I do not believe this to be true.

 As it was pointed out here before, protocols like DHCP are the proper
 and reliable way to auto-configure the DNS resolvers.
I totally agree with this statement, and indeed systemd-resolved 
defaults to use DHCP-provided resolvers if available.

 Starting from privacy issues / data leakage (if you google for the
 topic, it apparently seems to be even an open secret, that google
 collects the queries people make against their nameservers), mass
Let me point you to the helpful official page which shows that Google 
does not store personally identifiable information:
https://developers.google.com/speed/public-dns/privacy .
This level of privacy is much better than the one provided by the 
resolvers of many large ISPs.

 surveillance issues (since data goes at least to the US) or even worse
I have already explained to you that this is not true.

 for people in dictatorial regimes where using 8.8.8.8 may not be liked
 by some governmental forces.
Can you point to documented cases of people being troubled by oppressive 
regimes for their choice of DNS resolvers?

 Could you please elaborate how you feel that the new fallback improves
 the quality, when like 99,99% of the systems are anyway already
 configured via DHCP or other ways and there never had been a need for a
 hidden hardcoded default.
It makes the other 0.01% (?) systems work.

 Could you elaborate on what you plan to do if Google should decide to
 terminate that service (will there then be an update for all
 stable/oldstable/etc?), which wouldn't be such a big surprise, given the
 number of other services they recently shut down?
Then they would not be worse than with no default configuration.

 Could you further elaborate on how this affects the systems of people in
 regions where access to the google name servers is blocked?
Then they would not be worse than with no default configuration.

 See above and previous mails from myself and other complainants, it's
 probably mostly the privacy and surveillance issues, especially since
These privacy and surveillance issues are substantially fictional.

-- 
ciao,
Marco


pgpK856_AUQCZ.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: Please do not default to using Google nameservers

[Marco d'Itri]

On Apr 07, martin f krafft madd...@debian.org wrote:

 admin's help is not acceptable. We may work hard to configure our
 services to provide sensible defaults, but the tendency is still not
 to turn them on by default.
I am not really sure of what this means.

 Our MTAs don't have default mail relays.
At least because there is no such service available.

 We don't enable AVAHI nor do we install cups-browsed to make things
 work out of the box.
Don't we? Then we probably should do it on desktop systems, since 
autoconfiguration greatly improves the user experience.

 We change upstream software to ensure as much
 as possible that we don't leak data. We file bug reports against
DNS queries intrinsecally leak data.

Also, your arguments about Debian having no defaults look a bit empty 
when looking at your original bug report in which you suggest OpenNIC as 
an acceptable default.

 So no, no concrete threat model. But I hope I was able to argue that
Cool, everything is still OK then.

-- 
ciao,
Marco


pgpf0rppbRqYI.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#742802: Bug#771523: systemd: Add build dependency for libmicrohttpd-dev

[Marco d'Itri]

On Mar 30, Martin Pitt mp...@debian.org wrote:

 IMHO, systemd should just ship what you need for booting a minimal
 system, and shouldn't have big dependencies. We currently cripple some
 features (networkd, due to dropping iptables-dev) or not ship them at
 all (importd, journald-remote) as they pull in too many dependencies,
 which isn't satisfying either.
I agree.

 Hence the idea of systemd-extras -- everything which brings in large
 dependencies and isn't needed for booting every system can go there.
 systemd would Recommends: systemd-extras, but admins of embedded
 machines etc. could remove/not install it.
A single -extras package is not a good solution unless we believe that 
all these features are non-relevant corner cases that only a significant 
minority of users care about.
I do not believe that this will be true for the networkd firewall 
features, for a start.
So as long as one of the features will be reasonably popular, which 
I expect that will happen at least for the networkd firewall features, 
then most people will just install both packages.

I am not opposed to a systemd/systemd-full split *if* we have a clear 
idea of the use cases of both packages but I see no benefit in just 
creating a second package for everything that contains everything that 
has extra dependencies.

-- 
ciao,
Marco


pgp6xEpPDqA7y.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#618862: systemd: ignores keyscript in crypttab

[Marco d'Itri]

On Mar 30, Brainslug brains...@freakmail.de wrote:

 Any progress on this? I would think this needs to be fixed before jessie
 can be released, otherwise a lot of systems out there will break?
While both we and the upstream maintainers believe that continuing to 
support this feature is a good idea, so far acceptable patches have not 
been contributed.
I doubt that such patches will magically appear in a few days, so it 
looks like that jessie will not support keyscripts.

I should add some code to preinst to abort the installation if the
keyscript directive is used in crypttab.

-- 
ciao,
Marco


pgpZolVNFnpI3.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#765577: (no subject)

[Marco d'Itri]

On Mar 18, Faidon Liambotis parav...@debian.org wrote:

 Well, the root cause IMO is that 75-persistent-net-generator.rules is
 inherently susceptible to races. It's my understanding that it's valid
 for events to be triggered multiple times -- there are multiple places
 in d-i that udevadm trigger is called, including start-udev (as
 shipped by udev-udeb) which would trigger another set of add events
 beyond the original hotplug one.
I do not think that this is valid in the sense that the kernel could 
generate multiple add events, but removing all misuses of udevadm 
trigger requires some work and may not even be possible at this time.

I see that we have independently devised the same fix, I am attaching 
a test case and a more refined version of your patch.

-- 
ciao,
Marco
#!/bin/sh -e

rm -f /etc/udev/rules.d/70-persistent-net.rules

rmmod e1000e || true
modprobe e1000e
sleep 1

rm -f /etc/udev/rules.d/70-persistent-net.rules

iteration=0

while : ; do
  iteration=$((iteration + 1))
  if ! echo add  /sys/class/net/eth0/uevent; then
echo Failed at iteration $iteration!
exit
  fi
  # do not send too many events to udev because they will all be queued
  # and eventually processed
  if [ $iteration -eq 2500 ]; then
echo Aborting at iteration $iteration!
exit
  fi
done

--- /lib/udev/write_net_rules.orig	2015-03-30 05:18:43.228147201 +0200
+++ /lib/udev/write_net_rules	2015-03-30 06:00:39.181085432 +0200
@@ -117,6 +117,18 @@
 basename=${INTERFACE%%[0-9]*}
 match=$match, KERNEL==\$basename*\
 
+# build a regular expression that matches the new rule that we want to write
+new_rule_pattern=$(echo ^SUBSYSTEM==\net\, ACTION==\add\$match | sed -re 's/([\?\*])/\\\1/g')
+
+# Double check if the new rule has already been written. This happens if
+# multiple add events are generated before the script returns and udevd
+# renames the interfaces. See #765577 for details.
+if egrep -q $new_rule_pattern \
+$RO_RULES_FILE $([ -e $RULES_FILE ]  echo $RULES_FILE); then
+  unlock_rules_file
+  exit 0
+fi
+
 if [ $INTERFACE_NAME ]; then
 	# external tools may request a custom name
 	COMMENT=$COMMENT (custom name provided by external tool)


pgp0CXb73md6m.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: Please do not default to using Google nameservers

[Marco d'Itri]

On Mar 29, Christoph Anton Mitterer cales...@scientia.net wrote:

 And AFAIU the problem of data/privacy leakage isn't just made up, is it?
So far, it is. If you still want to argue about this (which I something
that I strongly recommend against!), then you should explain in detail 
the threat model that you are trying to address and how the current 
configuration would be worse than other configurations.

 $ geoiplookup 8.8.8.8
 GeoIP Country Edition: US, United States
traceroutes from multiple non-US locations may surprise you.

 Or are there already Code of Conflict cases running against me now or
 Marco because he used the word lunacy on someone else's work o.O
I argue that alternative DNS roots are firmly in the camp of net.kooks, 
and there is more than enough history to support this.
Were you around at the time of the newdom mailing list? Fun times...
Be careful of who you choose to associate with, because you will be 
judged by your peers for it.

  Marco told you specifically, how you can configure this explicitly.
 Uhm? I just accidentally stumbled over this bug and I don't think he has
 told me anything in specific.
I did, in my reply. Short summary: have a resolv.conf file or use DHCP.

 IMO, OpenNIC or anything else would have the same issues than Google:
Then maybe you should work in the IETF to establish either:
- well know IP addresses which will provide recursive DNS service (this 
  may even work now that we have DNSSEC)
- a best practice of running a caching resolver on every end user system 
  (I highly doubt that this would be considered a good idea)

-- 
ciao,
Marco


pgptDtQdpMvym.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#767593: timedatectl: does not notice corrupted zoneinfo files

[Marco d'Itri]

Control: tag -1 upstream help

On Nov 01, David Schmitt da...@dasz.at wrote:

 Given that zoneinfo files have an obvious magic number and the garbage file
 hadn't one, it'd be really great if timedatectl could do basic sanity checks
 before loading the file and creating an invalid configuration.
This is a worthwhile enhancement, but the Debian systemd maintainers 
cannot allocate resources to work on this.
I recommend that you submit a patch to the upstream maintainers 
upstream.

-- 
ciao,
Marco


pgpNqnfjFrgtB.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#764303: systemd: improve handling of some settings from /etc/default/tmpfs

[Marco d'Itri]

Control: tag -1 help

On Oct 07, Bob Bib bob...@ukr.net wrote:

 According to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674755#63
 it's controlled only by systemd postinst;
 I've looked at that, and it seems that only RAMTMP is taken into account:
This could be solved by creating a file like
/etc/systemd/system/tmp.mount.d/rcS-transition.conf containing an 
Options directive.

While I believe that this is a worthwhile enhancement to improve wheezy 
to jessie ugprades I do not think that the Debian systemd maintainers
will find time to work on it.
I think that we would be happy to merge a patch implementing this if 
somebody could provide it in time for jessie.

-- 
ciao,
Marco


pgp3uhSTBPaYP.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#770526: more useful error messages

[Marco d'Itri]

Control: tag -1 upstream help

On Nov 22, Norbert Preining prein...@logic.at wrote:

 coming back to the original bug report, I have two wishlist items:
 * a way to force systemd to start a service regardless of tests
I am not sure that this is a good idea, or even possible at all.
But anyway it would be upstream material.

 * more decent error messages, in this case it was
   Error: File exists
   which is a tautology in any case and carries no meaning if not 
   accompanied with *which* file is the problem.
This is a worthwhile enhancement, but the Debian systemd maintainers
cannot allocate resources to work on this.
I recommend that you submit a patch to the upstream maintainers.

-- 
ciao,
Marco


pgpqYf9d0Liae.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#742802: Bug#771523: systemd: Add build dependency for libmicrohttpd-dev

[Marco d'Itri]

Control: forcemerge 742802 771523

On Nov 30, Michael Biebl bi...@debian.org wrote:

 This would also mean a library dependency on libmicrohttpd unless we
 split the package. Both things I'm not particular keen about.

 We'd first have to evaluate anyway, how mature this feature is, before
 enabling it.
Post-jessie we need to either:
- build systemd-journal-gatewayd but artificially remove the dependency
  from the systemd package
- split systemd-journal-gatewayd to a separate package
- have the systemd package depend on libmicrohttpd
- decide that we do not want to support systemd-journal-gatewayd

#1 is a very simple change but will seriously confuse the users who do 
not RTFM.

#2 needs some testing but should not cause a significant long term 
maintenance burden on us. The patch in #742802 needs some minor changes 
(remove postrm and README.Debian) but it looks simple enough.

I do not like #3 at all and the other maintainers concour, or we would
have already done this.

At this time I see no obvious justifications for #4, but still it would 
help if the people interested in enabling this feature could document 
how it is used in practice.

-- 
ciao,
Marco

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#738787: systemd: Can't get complete status of xinetd when using systemd

[Marco d'Itri]

Control: tag -1 wontfix
Control: close -1

On Feb 12, Salvo Tomaselli tipos...@tiscali.it wrote:

 This functionality is gone with systemd. Is there a way of getting it back?
It well established that the upstream maintainers have no plans of 
supporting non-standard actions for units, hence I am closing this bug.

This one of xinetd is a debugging feature, so I believe that documenting 
the semantics of SIGUSR1 in the man page is all that is needed to 
support it in the package.

-- 
ciao,
Marco


pgpt9NMgeaHNA.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#771523: systemd: Add build dependency for libmicrohttpd-dev

[Marco d'Itri]

On Mar 29, Michael Biebl bi...@debian.org wrote:

 I'm not a huge fan of micro packages and splitting everything up. Where
 would you draw the line.
Uncommon dependencies for not widely used/useful features.
I think that a libdw dependency is justifiable because it provides stack 
traces which may be invaluable for debugging a crash, but so far 
http-based forwarding of logs does not appear to be very popular.
Is it enabled at all in RHEL7? This could be a good benchmark.

 pitti was suggesting a systemd-extras package, but I'm not a huge fan of
 this idea either since it's unclear what would go into this package and
 what not and it complicates things if we have to move stuff around.
Me neither.

 For the time being, I'd say, we should simply be very conservative about
 what features we enable, which means not enabled the remote journal
 features for now.
It would surely be beneficial if the users arguing for support of this 
feature could document its popularity.

-- 
ciao,
Marco


pgpuEYDNVx6Aa.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#770633: systemd: Suggestion for a method to handle multiple providers of the same service

[Marco d'Itri]

Control: tag -1 moreinfo

On Nov 22, Andrei POPESCU andreimpope...@gmail.com wrote:

 Here's what I came up with, as possible addition to systemd.unit(5)
A new unit file configuration directive would have to be accepted 
upstream.

Didier suggested a different solution which can be implemented with no 
changes to the package, did you test it?

-- 
ciao,
Marco


pgpiD_Vd2J0Uo.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#780705: udev: floating net device number on devices with ro rootfs

[Marco d'Itri]

On Mar 24, vic...@gmail.com vic...@gmail.com wrote:

 AFAIK, this patch depends on only udev and udev doesn't depend on systemd,
systemd was not mentioned in my reply.

 at least for now. It's true most of the embedded Linux systems that have
 udev
  on it might have already switched to systemd, but I see there is a problem
 in udev and it can be fixed with a few additional care. That's all. Thank
There is no such thing as a free patch: every change requires an 
unpredictable amount of work and there are already many workarounds for 
this very unusual corner case.

-- 
ciao,
Marco


pgpVPmfq71JkX.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#780705: udev: floating net device number on devices with ro rootfs

[Marco d'Itri]

On Mar 19, Michael Biebl bi...@debian.org wrote:

 Not writing duplicated entries in 70-persistent-net.rules should
 indeed be the case. I'll let Marco, who wrote the code, review the
 patch. He should be more familiar with it.
I do not really want to think about the possibile interactions of this 
change with other code at time time in the release process.
I suspect that this use case would be served much better by a stable 
interfaces naming scheme different from the one managed by 
70-persistent-net.rules.

-- 
ciao,
Marco


pgpVUldnxCvK7.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: LXC breakage and workarounds when upgrading VMs to jessie

[Marco d'Itri]

On Nov 24, Tomas Pospisek tpo_...@sourcepole.ch wrote:

 My first proposed text for the release-notes is below. Please let me
 know if you prefer me to submit a proper patch against a SVN checkout of
 ddp.
Please also clarify that LXC containers *can* use systemd with no 
troubles if correctly configured.

-- 
ciao,
Marco


pgpPp_jtfEhcv.pgp
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: missing technical policy for systemd

[Marco d'Itri]

On Nov 01, Bill Allombert ballo...@debian.org wrote:

 Is there alternative documents describing the interfaces for packages to
 interoperate with systemd, and transition documents available for packagers 
 and
 users that need to adapt to the new system ?
Partially.

I have been working on https://etherpad.fr/p/systemd-best-practices but 
it is unfinished and not everything on this page is an opinion of the 
systemd maintainers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#766050: systemd: Please look at a read-only implementation of debug-shell.service

[Marco d'Itri]

On Oct 20, Richard Hartmann richih.mailingl...@gmail.com wrote:

 similar to zack's #766039, I would like to ask if it's possible to
 always enable a read-only version of debug-shell.service.
debug-shell.service pretty much just starts a shell.
To enable it by default we would need to use a wrapper which asks the 
root password with minimal interactions with the rest of the system, 
ideally by just checking it against /etc/shadow (hence no PAM, no NSS, 
etc).
Are you interested in working on such a program?

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#763197: closed by m...@linux.it (Marco d'Itri) (Re: Bug#763197: systemd: upgrade to systemd 215 broke boot with personal kernel)

[Marco d'Itri]

On Oct 06, Michael Biebl bi...@debian.org wrote:

 Would probably be a good idea. Do you know a reliable way to test that
 for a running kernel (and the other requirements listed in README.gz)?
Like I did for the old udev package, checking /proc/kallsyms.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#762343: systemd: timesyncd should run in VMware

[Marco d'Itri]

On Sep 20, Christian Hofstaedtler z...@debian.org wrote:

 timesyncd carries a setting of ConditionVirtualization=no, which is
 wrong for VMware virtualization guests, as the standard way of doing
 timesync in VMware guests is to run a timesync service in the guest
 (in a classic environment, ntpd).
And at least until RHEL 6, this is true for KVM as well.
The only full virtualization system that I know has a slaved guest clock
by default is Xen.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: Please do not default to using Google nameservers

[Marco d'Itri]

On Sep 15, martin f krafft madd...@debian.org wrote:

 I would like to propose that we either provide no default fallback,
 or chose to support OpenNIC that way.
If there has to be a default and if it has to be different from the 
current one, then I am violently opposed to even consider associating
Debian with that OpenNIC lunacy.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761257: systemd: disrupts hugepages support

[Marco d'Itri]

On Sep 12, Cyril Soldani devmusi...@legiasoft.com wrote:

 1) systemd *not* messing with the existing hugepages setup;
This will not happen: it would be too much complex and anyway the new 
standard location is /dev/hugepages/ .

 2) being warned when installing systemd-sysv that systemd handles
hugepages differently (especially when I have hugepages entries in my
fstab).
But I think that we can add a preinst check, can you provide a simple 
shell test case that checks for this condition?

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#760947: systemd: Does not start consoles configured in /etc/inittab

[Marco d'Itri]

On Sep 09, Samuel Thibault sthiba...@debian.org wrote:

 On a wheezy system, I had a serial console configured in /etc/inittab,
 used as a secondary work terminal (i.e. no console=ttyS0 on the kernel
 command line). After an upgrade to Jessie, logind doesn't start a getty
 on ttyS0.
No wonder, since systemd does not support /etc/inittab

Can you think of a way to 100% reliably parse inittab and convert these 
directives to a proper systemd configuration?

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#747073: [cups-daemon] Doesn't work with systemd

[Marco d'Itri]

reassign 747073 cups-daemon
thanks

On May 06, Didier 'OdyX' Raboud o...@debian.org wrote:

 Given that I don't think it's CUPS's responsibility to check for ipv6
 availability, I'm hereby reassigning this bug to systemd.
Sure it is: the CUPS maintainer script is explicitly instructing systemd 
to open an IPv6 socket and systemd tries to do it.

 systemd maintainers: I think Listen*=[::1]:$port stanzas shouldn't make
 the .socket-file loading fail if the ipv6 module is not loaded. It should
 certainly spit out a warning though.
There is no magic we do not care if it does not work address family:
if a unit is configured to open a socket but this fails then the unit 
must fail.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#756903: systemd: Boot hangs if filesystems unavailable

[Marco d'Itri]

On Aug 04, Cameron Norman camerontnor...@gmail.com wrote:

 With mountall/Upstart, there is a nobootwait option supported. I believe the
 behavior is similar to nofail, except that mountall will emit the filesystem
 event before finishing mounting the filesystem as well as not GAF about
 success/failure. Do you know if systemd supports this? To implement this in
 systemd I believe you would make the generator for mount units from fstab
 not add Before=local-fs.target or Before=remote-fs.target if the nobootwait
 option is used. This solves the problem that systemd does not know which
 filesystems are essential or not.
Such an option would not be the default, and if you can change your 
configuration to use it then you can more easily fix your fstab as well.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Best packaging practices document

[Marco d'Itri]

https://etherpad.fr/p/systemd-best-practices

Please contribute.

-- 
ciao,
Marco


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers