Bug#822635: udev rules for USB device access effective at boot, but not on hotplug

2018-03-23 Thread Josh Triplett 
On Fri, Mar 23, 2018 at 05:17:11PM +0100, Michael Biebl wrote:
> On Mon, 22 Jan 2018 18:10:58 +0100 Michael Biebl 
> wrote:
> > Hi Josh!
> > 
> > On Wed, 21 Dec 2016 20:15:12 +0100 Michael Biebl  wrote:
> > > On Fri, 6 May 2016 18:12:27 -0500 Martin Pitt  wrote:
> > > > Control: tag -1 moreinfo
> > > > 
> > > > Hello Josh,
> > > > 
> > > > Josh Triplett [2016-04-25 13:48 -0700]:
> > > > > ~$ cat /etc/udev/rules.d/99-local-gnubby.rules
> > > > > SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0200", 
> > > > > TAG+="uaccess"
> > > > >
> > > > > If I boot with the device attached, this seems to take effect:
> > > > >
> > > > > However, if I unplug and replug the device, this rule no longer seems 
> > > > > to take
> > > > > effect:
> > > > 
> > > > The uaccess tag is evaluated in /lib/udev/rules.d/73-seat-late.rules,
> > > > thus 99-* is too late. Can you please move it to e. g.
> > > > 70-gnubby.rules? I'm fairly sure it will work then, but I'll keep the
> > > > bug open until you confirm, just in case.
> > > > 
> > > 
> > > The dump from Josh shows, that the uaccess udev property is properly
> > > set. So I don't think it's an udev rules ordering issue.
> > > 
> > > I think the problem rather is, that you are already logged in and the
> > > ACLs are only applied on login or when the session becomes active.
> > > 
> > > I assume if you log out and re-login after the hotplug, the ACL is
> > > properly applied?
> > 
> > Any updates on this bug report? Is there still something which needs to
> > be addressed on the systemd side? If so we need to further investigate
> > the issue.
> 
> Josh, any updates on this?

I'm not currently using the device, so I don't know the status of this
issue.

Regarding the mention of when the ACLs are applied, though, is that true
in general? I thought that if you hotplugged a device that the user is
supposed to have access to, they'd immediately get access to it.

___
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#875557: Info received (Bug#875557: systemd: service mark as enabled but not in reality)

2018-03-23 Thread Michael Biebl 
hm, the email address bounces here:

>
>The mail system
>
> : host mx.cblue.be[193.104.37.23] said: 550 Unrouteable
> address (in reply to RCPT TO command)
>
>
>
> Reporting-MTA: dns; dd17218.kasserver.com
> X-Postfix-Queue-ID: A90216801856
> X-Postfix-Sender: rfc822; bi...@debian.org
> Arrival-Date: Fri, 23 Mar 2018 17:12:34 +0100 (CET)
>
> Final-Recipient: rfc822; sth...@cblue.be
> Original-Recipient: rfc822;sth...@cblue.be
> Action: failed
> Status: 5.0.0
> Remote-MTA: dns; mx.cblue.be
> Diagnostic-Code: smtp; 550 Unrouteable address
>


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP 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#831414: marked as done (systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface)

2018-03-23 Thread Debian Bug Tracking System 
Your message dated Fri, 23 Mar 2018 17:24:02 +0100
with message-id 
and subject line Re: Bug#831414: systemd: learns IPv6 prefix from its own RAs 
and configures IP address on wrong interface
has caused the Debian Bug report #831414,
regarding systemd: learns IPv6 prefix from its own RAs and configures IP 
address on wrong interface
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
831414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831414
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 230-5pitti1
Severity: minor
Tags: ipv6

Hi,

I am filing this as severity minor because this bug is in a version
that is not officially in Debian. I am filing it nevertheless because
systemd with this IPv6 user space code active should not be in Debian.
If this were an official version, this would be an important bug, with
the potential for "serious" at maintainer discretion.

While following up Martin's requests for #815793 and #815884, I have
found new misbehsvior regarding IPv6.

Given a host that also acts as a router, with the following network
setup:

2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
   valid_lft forever preferred_lft forever
inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
   valid_lft 12650sec preferred_lft 12650sec
inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr 
noprefixroute dynamic
   valid_lft 86309sec preferred_lft 14309sec
inet6 2001:db8:0:3282::1d:250/128 scope global
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:3282::1d:100/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe82:2100/64 scope link
   valid_lft forever preferred_lft forever
3: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
link/ether c6:f4:98:dc:5e:21 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.254/24 brd 192.168.29.255 scope global br0
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:328d::1d:153/64 scope global
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:328d::1d:100/64 scope global
   valid_lft forever preferred_lft forever
inet6 fec0:0:0:::3/128 scope site
   valid_lft forever preferred_lft forever
inet6 fec0:0:0:::2/128 scope site
   valid_lft forever preferred_lft forever
inet6 fec0:0:0:::1/128 scope site
   valid_lft forever preferred_lft forever
inet6 fe80::c4f4:98ff:fedc:5e21/64 scope link
   valid_lft forever preferred_lft forever

On br0, there is a radvd, advertising a prefix on br0:
interface br0 {
AdvSendAdvert on;
MinRtrAdvInterval 600;
MaxRtrAdvInterval 1200;
prefix 2001:db8:0:328d::/64 {
DeprecatePrefix on;
};
RDNSS 2001:db8:0:328d::1d:153 {
AdvRDNSSLifetime 1200;
};
};

When the radvd is started, the local host seems to learn the prefix
from the locally running radvd and _configures_ _it_ _on_ _eth0_,
which is plain wrong:

2: eth0:  mtu 1500 qdisc pfifo_fast state UP gr
oup default qlen 1000
link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
   valid_lft forever preferred_lft forever
inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
   valid_lft 12530sec preferred_lft 12530sec
inet6 2001:db8:0:328d:5604:a6ff:fe82:2100/64 scope global mngtmpaddr 
noprefixroute dynamic
   valid_lft 86390sec preferred_lft 14390sec
inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr 
noprefixroute dynamic
   valid_lft 86189sec preferred_lft 14189sec
inet6 2001:db8:0:3282::1d:250/128 scope global
   valid_lft forever preferred_lft forever
inet6 2001:db8:0:3282::1d:100/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe82:2100/64 scope link
   valid_lft forever preferred_lft forever

It also learns a default route pointing to its own link local IP
address on br0:

[2/502]mh@fan:~$ ip -6 r
2001:db8:0:3282::1d:250 dev eth0  proto kernel  metric 256  pref medium
2001:db8:0:3282::/64 dev eth0  proto kernel  metric 256  pref medium
2001:db8:0:3282::/64 dev eth0  proto ra  metric 1024  pref medium
2001:db8:0:328d::/64 dev br0  proto kernel  metric 256  pref

Bug#875557: systemd: service mark as enabled but not in reality

2018-03-23 Thread Michael Biebl 
Control: tags -1 + moreinfo

On Tue, 12 Sep 2017 10:08:49 +0200 Michael Biebl  wrote:
> Am 12.09.2017 um 09:45 schrieb sthiry:
> > Package: systemd
> > Version: 232-25+deb9u1
> > Severity: normal
> > 
> > Hello,
> > 
> > I use multiple php-fpm process to run apache websites and I have to create 
> > one process by site, so I have a service file named php7-fpm@.service. It 
> > let me create service like this php7-fpm@mysite that 
> > I have to enable once it is created. So I notice that when I enable one 
> > service, the others are mark as enabled when I type "service php7-fpm* 
> > status", but they are not enabled. So you have to enable all
> > services.
> 
> Can you please include the full service file you are using and the
> output of the commands.

Would be great, if you can provide the requested information.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP 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

Processed: bug 868159 is forwarded to https://github.com/systemd/systemd/issues/8566

2018-03-23 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> forwarded 868159 https://github.com/systemd/systemd/issues/8566
Bug #868159 [systemd] systemd-setup-tmpfiles startup error when /srv is on 
read-only fs
Set Bug forwarded-to-address to 
'https://github.com/systemd/systemd/issues/8566'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
868159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868159
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Processed: Re: Bug#875557: systemd: service mark as enabled but not in reality

2018-03-23 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 + moreinfo
Bug #875557 [systemd] systemd: service mark as enabled but not in reality
Added tag(s) moreinfo.

-- 
875557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
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#863710: marked as done (journald's most recent entries)

2018-03-23 Thread Debian Bug Tracking System 
Your message dated Fri, 23 Mar 2018 17:03:19 +0100
with message-id <917a9097-0c17-577d-d435-f4154b9fc...@debian.org>
and subject line Re: Bug#863710: journald's most recent entries
has caused the Debian Bug report #863710,
regarding journald's most recent entries
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
863710: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863710
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 215-17+deb8u6
Severity: normal

Dear Maintainer,

I have tried to retrieve recent journal entries (with matching fields),
but the retrieved entries were not the most recent ones:

$ journalctl OBJECT_ID=50483 -n 15 | tail -n 1 | cut -c 1-15
May 29 23:05:13
$ journalctl OBJECT_ID=50483 -n 14 | tail -n 1 | cut -c 1-15
May 29 23:05:13
$ journalctl OBJECT_ID=50483 -n 13 | tail -n 1 | cut -c 1-15
May 30 03:04:57
$ journalctl OBJECT_ID=50483 -n 12 | tail -n 1 | cut -c 1-15
May 30 07:05:03
$ journalctl OBJECT_ID=50483 -n 11 | tail -n 1 | cut -c 1-15
May 30 07:05:03
$ journalctl OBJECT_ID=50483 -n 12 | tail -n 1 | cut -c 1-15
May 30 07:05:03
$ journalctl OBJECT_ID=50483 -n 13 | tail -n 1 | cut -c 1-15
May 30 03:04:57
$ journalctl OBJECT_ID=50483 -n 14 | tail -n 1 | cut -c 1-15
May 29 23:05:13
$ journalctl OBJECT_ID=50483 -n 15 | tail -n 1 | cut -c 1-15
May 29 23:05:13

Here is another example, a bit redacted (any  is identical to
another : the same few messages get inserted there roughly
every 4 hours):

$ journalctl OBJECT_ID=50482 -n 1
-- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:13 
MSK. --
May 30 07:03:49 mars mmdb[131728]: 
$ journalctl OBJECT_ID=50482 -n 2
-- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:14 
MSK. --
May 30 03:04:11 mars mmdb[131728]: 
May 30 03:04:11 mars mmsocks[946]: 
$ journalctl OBJECT_ID=50482 -n 3
-- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:22 
MSK. --
May 29 23:04:18 mars mmdb[131728]: 
May 29 23:04:19 mars mmsocks[946]: 
May 29 23:05:19 mars rtms4[35053]: 
$ journalctl OBJECT_ID=50482 -n 4
-- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:09:26 
MSK. --
May 29 19:06:03 mars mmdb[131728]: 
May 29 19:06:03 mars mmsocks[946]: 
May 29 19:07:03 mars rtms4[27816]: 
May 29 19:07:03 mars mmsocks[946]: 

Repeating the same commands led to same results, as in the first
example. After that, new messages were inserted, and it got shifted:

$ journalctl OBJECT_ID=50482 -n 1
-- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:20:31 
MSK. --
May 30 11:10:06 mars mmdb[131728]: 
$ journalctl OBJECT_ID=50482 -n 2
-- Logs begin at Sat 2017-05-27 15:00:01 MSK, end at Tue 2017-05-30 11:21:14 
MSK. --
May 30 07:03:49 mars mmdb[131728]: 
May 30 07:03:51 mars mmsocks[946]: 

It doesn't seem to happen with OBJECT_ID's where the messages are not as
repetitive. And it works fine if the `-n` option is not specified, or if
its argument is greater than the amount of messages for a given
OBJECT_ID.

Looks like a similar behaviour can be reproduced using systemd units and
shell scripts (just printing the same messages), with no custom fields
or programs, but I wasn't able to get a clean example (got a few
attempts mixed together the only time when it worked that way, and then
it got fixed on its own -- unlike the above examples).

The default /etc/systemd/journald.conf was used.


-- Package-specific info:

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u7
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u2
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u2
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u6
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u6
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.22-0+deb8u1
pn  libpam-systemd  

Versions of packages systemd

Bug#803524: journalctl too slow

2018-03-23 Thread Michael Biebl 
Control: tags -1 + moreinfo

On Sat, 31 Oct 2015 01:46:59 +0100 Christoph Egger
 wrote:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
> File: /bin/journalctl
> 
> Hi!
> 
> `journalctl -u nsd.service` just takes 10 minutes (!) cpu time to
> scrol to the newest entries. I'd call that too much for something
> that's supposed to replace a `grep nsd /var/log/syslog`

Is this still reproducible with a recent version of systemd?

Is this with persistent journal enabled? If so,
- how big is /var/log/journal?
- does journalctl --verify report any errors?
- is the problem reproducible after removing existing journal files?

Fwiw, if you are interested in the newest journal entries, journalctl
now provides a -r switch, ie. it shows the newest entries first.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP 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

Processed: Re: journalctl too slow

2018-03-23 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 + moreinfo
Bug #803524 [systemd] journalctl too slow
Added tag(s) moreinfo.

-- 
803524: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803524
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
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#892585: systemd: can not create user.slice/user session, after upgrade systemd from 237-4 to 238-1/2

2018-03-23 Thread Michael Biebl 
On Wed, 21 Mar 2018 16:16:40 +0800 johnw  wrote:
> After upgrade systemd to 238-3, I still have this problem :(
> Any one?
> Help, please.

Does it work if you switch to a different display manager, like say
lightdm (which IIRC is the preferred one of xfce). Might be a problem
specific to slim, since I don't see any such issues myself here (using
GNOME/gdm).

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP 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#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]

2018-03-23 Thread James Cowgill 
On 23/03/18 14:25, Mathieu Malaterre wrote:
> Hi James,
> 
> On Fri, Mar 23, 2018 at 3:19 PM, James Cowgill  wrote:
>> Control: notforwarded -1
>>
>> Hi,
>>
>> On 22/03/18 14:28, Michael Biebl wrote:
>>> Am 22.03.2018 um 12:31 schrieb James Cowgill:
 I sent a patch upstream (see above).
>>>
>>> Thanks!
>>
>> Unfortunately I've had to ask for this to be reverted:
>> https://github.com/systemd/systemd/pull/8563
> 
> Are you saying that none of the unit tests failed after your changes ?
> that's kindda scary :(

No nothing failed.

James



signature.asc
Description: OpenPGP 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#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]

2018-03-23 Thread Mathieu Malaterre 
Hi James,

On Fri, Mar 23, 2018 at 3:19 PM, James Cowgill  wrote:
> Control: notforwarded -1
>
> Hi,
>
> On 22/03/18 14:28, Michael Biebl wrote:
>> Am 22.03.2018 um 12:31 schrieb James Cowgill:
>>> I sent a patch upstream (see above).
>>
>> Thanks!
>
> Unfortunately I've had to ask for this to be reverted:
> https://github.com/systemd/systemd/pull/8563

Are you saying that none of the unit tests failed after your changes ?
that's kindda scary :(

> It turns out that enabling MemoryDenyWriteExecute on MIPS causes any
> applications which use threads to fail because the MIPS toolchain
> (still) does not implement PT_GNU_STACK. So this bug is going to require
> some extra toolchain support (at least glibc and one of gcc/binutils but
> I can't remember which) to fix.

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

Processed: Re: Bug#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]

2018-03-23 Thread Debian Bug Tracking System 
Processing control commands:

> notforwarded -1
Bug #893605 [src:systemd] warning: #warning "Consider adding the right mmap() 
syscall definitions here!" [-Wcpp]
Unset Bug forwarded-to-address

-- 
893605: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893605
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
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#893605: warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]

2018-03-23 Thread James Cowgill 
Control: notforwarded -1

Hi,

On 22/03/18 14:28, Michael Biebl wrote:
> Am 22.03.2018 um 12:31 schrieb James Cowgill:
>> I sent a patch upstream (see above).
> 
> Thanks!

Unfortunately I've had to ask for this to be reverted:
https://github.com/systemd/systemd/pull/8563

It turns out that enabling MemoryDenyWriteExecute on MIPS causes any
applications which use threads to fail because the MIPS toolchain
(still) does not implement PT_GNU_STACK. So this bug is going to require
some extra toolchain support (at least glibc and one of gcc/binutils but
I can't remember which) to fix.

James



signature.asc
Description: OpenPGP 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

Processed: Bug #892794 in systemd marked as pending

2018-03-23 Thread Debian Bug Tracking System 
Processing control commands:

> tag -1 pending
Bug #892794 [systemd] systemd-networkd fails to configure IPv6 without MTU from 
RA
Bug #892651 [systemd] networkd: no IPv6 default route after point release
Added tag(s) pending.
Added tag(s) pending.

-- 
892651: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892651
892794: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892794
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
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#893866: stretch-pu: package systemd/232-25+deb9u3

2018-03-23 Thread Michael Biebl 
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

we already briefly discussed this via IRC on #debian-release.

The last stable upload of systemd introduced a rather nasty regression
in networkd, which broke IPv6 support for lots of users.

KiBi was so kind to dig out the relevant upstream commit which fixes
this and got confirmation from the bug reporter(s) that with this patch
applied, networkd behaves properly. I thus would like to get this
update into stable as quickly as possible.

Here's the changelog, debdiff is attached:

systemd (232-25+deb9u3) stretch; urgency=medium

  [ Cyril Brulebois ]
  * networkd-ndisc: Handle missing mtu gracefully.
The previous upload made networkd respect the MTU field in IPv6 RA but
unfortunately broke setups where there's no such field. (Closes: #892794)

 -- Michael Biebl   Fri, 23 Mar 2018 13:55:43 +0100


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index e7b7ff1..1117655 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+systemd (232-25+deb9u3) stretch; urgency=medium
+
+  [ Cyril Brulebois ]
+  * networkd-ndisc: Handle missing mtu gracefully.
+The previous upload made networkd respect the MTU field in IPv6 RA but
+unfortunately broke setups where there's no such field. (Closes: #892794)
+
+ -- Michael Biebl   Fri, 23 Mar 2018 13:55:43 +0100
+
 systemd (232-25+deb9u2) stretch; urgency=medium
 
   * networkd: Handle MTU field in IPv6 RA (Closes: #878162)
diff --git 
a/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch 
b/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch
new file mode 100644
index 000..59d6808
--- /dev/null
+++ b/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch
@@ -0,0 +1,28 @@
+From: =?utf-8?q?J=C3=B6rg_Thalheim?= 
+Date: Mon, 19 Dec 2016 15:34:07 +0100
+Subject: networkd-ndisc: handle missing mtu gracefully (#4913)
+
+At least bird's implementation of router advertisement does not
+set MTU option by default (instead it supplies an option to the user).
+In this case just leave MTU as it is.
+
+(cherry picked from commit 29b5ad083a6925efec8e188013d1298742e0baaa)
+---
+ src/network/networkd-ndisc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/network/networkd-ndisc.c b/src/network/networkd-ndisc.c
+index 9cfdf01..d3fa56b 100644
+--- a/src/network/networkd-ndisc.c
 b/src/network/networkd-ndisc.c
+@@ -117,7 +117,9 @@ static void ndisc_router_process_default(Link *link, 
sd_ndisc_router *rt) {
+ }
+ 
+ r = sd_ndisc_router_get_mtu(rt, );
+-if (r < 0) {
++if (r == -ENODATA)
++mtu = 0;
++else if (r < 0) {
+ log_link_warning_errno(link, r, "Failed to get default router 
MTU from RA: %m");
+ return;
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 3f93454..2866963 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -78,6 +78,7 @@ networkd-handle-MTU-field-in-IPv6-RA-4719.patch
 shared-Add-a-linker-script-so-that-all-functions-are-tagg.patch
 resolved-fix-loop-on-packets-with-pseudo-dns-types.patch
 machinectl-don-t-output-No-machines.-with-no-legend-optio.patch
+networkd-ndisc-handle-missing-mtu-gracefully-4913.patch
 debian/Use-Debian-specific-config-files.patch
 debian/don-t-try-to-start-autovt-units-when-not-running-wit.patch
 debian/Make-logind-hostnamed-localed-timedated-D-Bus-activa.patch
___
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#883569: libpam-systemd: Prefer systemd-sysv over systemd-shim

2018-03-23 Thread Martin Pitt 
Hello Michael,

Michael Biebl [2018-03-19  6:44 +0100]:
> So, what are we going to do now then?

"Nothing" I supppose. I don't think it's actually broken right now, it just
feels a little odd to prefer SysV in the dependencies. But with systemd being
installed by default, I suppose it's okay.

Martin


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