Your Personal Letter Dated 27-01-2017

[Amadi Kate]

[image: Inline image 1]
___
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: tagging 847203

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 847203 + fixed-upstream
Bug #847203 [systemd] systemd: journalctl zsh completion fails with RC_QUOTES
Added tag(s) fixed-upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
847203: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847203
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#774430: systemd: service makes as not reloadable

[James Cowgill]

Hi,

On 26/01/17 21:49, Michael Biebl wrote:
> Am 26.01.2017 um 15:44 schrieb Michael Biebl:
>> Am 18.01.2017 um 14:31 schrieb James Cowgill:
> 
>>> After debugging a bit I found this commit which seems likely to be the
>>> cause. I haven't actually tested 215 with the patch though:
>>> https://github.com/systemd/systemd/commit/c2fa048c4a70c8386c6d8fe939e5ea9edecf1e98
>>
>> That looks very promising
>> Could you try that patch on top of v215 and test if it fixes the issue?
>> If so I'd cherry-pick that for the next stable upload.
> 
> Since I'm pretty sure this fixes the issue, I've pulled this patch into
> the jessie branch [1] so the fix can be made available in the next stabe
> release.

I have now tested that patch and it does fix the problem for me.

Thanks,
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Debian Bug Tracking System]

Your message dated Fri, 27 Jan 2017 15:16:57 +0100
with message-id <20170127141657.dzvo2skczyex6...@bongo.bofh.it>
and subject line Re: Bug#852811: udev: Doesn't start after upgrade powerpc
has caused the Debian Bug report #852811,
regarding udev: Doesn't start after upgrade powerpc
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.)


-- 
852811: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852811
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: udev
Version: 232-14
Severity: important

Dear Maintainer,

Maybe the problem is because / is a RAID0 ?

Setting up udev (232-14) ...
addgroup: The group `input' already exists as a system group. Exiting.
Job for systemd-udevd.service failed because the control process exited with 
error code.
See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript udev, action "restart" failed.
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor 
preset: enabled)
   Active: activating (start) since Fri 2017-01-27 14:50:00 CET; 16ms ago
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
 Main PID: 13630 ((md-udevd))
Tasks: 1
   CGroup: /system.slice/systemd-udevd.service
   ‣ 13630 [(md-udevd)]

Jan 27 14:50:00 fabian.marillat.net systemd[1]: Starting udev Kernel Device 
Manager...
dpkg: error processing package udev (--configure):
 subprocess installed post-installation script returned error exit status 1


$ systemctl status systemd-udevd.service
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-01-27 14:51:23 CET; 3min 
52s ago
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
  Process: 15711 ExecStart=/lib/systemd/systemd-udevd (code=exited, 
status=232/ADDRESS_FAMILIES)
 Main PID: 15711 (code=exited, status=232/ADDRESS_FAMILIES)

Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Main 
process exited, code=exited, status=232/ADDRESS_FAMILIES
Jan 27 14:51:23 fabian.marillat.net systemd[1]: Failed to start udev Kernel 
Device Manager.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Unit 
entered failed state.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Failed 
with result 'exit-code'.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Service 
has no hold-off time, scheduling restart.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: Stopped udev Kernel Device 
Manager.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Start 
request repeated too quickly.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: Failed to start udev Kernel 
Device Manager.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Unit 
entered failed state.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Failed 
with result 'exit-code'.




Christian

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc64)

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

Versions of packages udev depends on:
ii  adduser  3.115
ii  dpkg 1.18.19
ii  libacl1  2.2.52-3
ii  libblkid12.28.2-1
ii  libc62.24-9
ii  libgcc1  1:6.3.0-5
ii  libkmod2 23-2
ii  libselinux1  2.6-2
ii  libudev1 232-14
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3
ii  util-linux   2.28.2-1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  232-14

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:

P: /devices/breakpoint
E: DEVPATH=/devices/breakpoint
E: SUBSYSTEM=event_source

P: /devices/cpu
E: DEVPATH=/devices/cpu
E: SUBSYSTEM=event_source

P: /devices/pci:00/:00:0b.0
E: DEVPATH=/devices/pci:00/:00:0b.0
E: ID_MODEL_FROM_DATABASE=CPC945 PCIe Bridge
E: ID_PCI_CLASS_FROM_DATABASE=Bridge
E: ID_PCI_INTERFACE_FROM_DATABASE=Normal decode
E: ID_PCI_SUBCLASS_FROM_DATABASE=PCI bridge
E: ID_VENDOR_FROM_DATABASE=Apple Inc.
E: MODALIAS=pci:v106Bd005Bsvsdbc06sc04i00
E: OF_ALIAS_0=pci0
E: OF_COMPATIBLE_0=u4-pcie
E: OF_COMPATIBLE_N=1
E: OF_FULLNAME=/pci@0

Bug#852811: udev: Doesn't start after upgrade powerpc

[Christian Marillat]

Package: udev
Version: 232-14
Severity: important

Dear Maintainer,

Maybe the problem is because / is a RAID0 ?

Setting up udev (232-14) ...
addgroup: The group `input' already exists as a system group. Exiting.
Job for systemd-udevd.service failed because the control process exited with 
error code.
See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript udev, action "restart" failed.
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor 
preset: enabled)
   Active: activating (start) since Fri 2017-01-27 14:50:00 CET; 16ms ago
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
 Main PID: 13630 ((md-udevd))
Tasks: 1
   CGroup: /system.slice/systemd-udevd.service
   ‣ 13630 [(md-udevd)]

Jan 27 14:50:00 fabian.marillat.net systemd[1]: Starting udev Kernel Device 
Manager...
dpkg: error processing package udev (--configure):
 subprocess installed post-installation script returned error exit status 1


$ systemctl status systemd-udevd.service
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-01-27 14:51:23 CET; 3min 
52s ago
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
  Process: 15711 ExecStart=/lib/systemd/systemd-udevd (code=exited, 
status=232/ADDRESS_FAMILIES)
 Main PID: 15711 (code=exited, status=232/ADDRESS_FAMILIES)

Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Main 
process exited, code=exited, status=232/ADDRESS_FAMILIES
Jan 27 14:51:23 fabian.marillat.net systemd[1]: Failed to start udev Kernel 
Device Manager.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Unit 
entered failed state.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Failed 
with result 'exit-code'.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Service 
has no hold-off time, scheduling restart.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: Stopped udev Kernel Device 
Manager.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Start 
request repeated too quickly.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: Failed to start udev Kernel 
Device Manager.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Unit 
entered failed state.
Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service: Failed 
with result 'exit-code'.




Christian

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc64)

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

Versions of packages udev depends on:
ii  adduser  3.115
ii  dpkg 1.18.19
ii  libacl1  2.2.52-3
ii  libblkid12.28.2-1
ii  libc62.24-9
ii  libgcc1  1:6.3.0-5
ii  libkmod2 23-2
ii  libselinux1  2.6-2
ii  libudev1 232-14
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3
ii  util-linux   2.28.2-1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  232-14

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:

P: /devices/breakpoint
E: DEVPATH=/devices/breakpoint
E: SUBSYSTEM=event_source

P: /devices/cpu
E: DEVPATH=/devices/cpu
E: SUBSYSTEM=event_source

P: /devices/pci:00/:00:0b.0
E: DEVPATH=/devices/pci:00/:00:0b.0
E: ID_MODEL_FROM_DATABASE=CPC945 PCIe Bridge
E: ID_PCI_CLASS_FROM_DATABASE=Bridge
E: ID_PCI_INTERFACE_FROM_DATABASE=Normal decode
E: ID_PCI_SUBCLASS_FROM_DATABASE=PCI bridge
E: ID_VENDOR_FROM_DATABASE=Apple Inc.
E: MODALIAS=pci:v106Bd005Bsvsdbc06sc04i00
E: OF_ALIAS_0=pci0
E: OF_COMPATIBLE_0=u4-pcie
E: OF_COMPATIBLE_N=1
E: OF_FULLNAME=/pci@0,f000
E: OF_NAME=pci
E: OF_TYPE=pci
E: PCI_CLASS=60400
E: PCI_ID=106B:005B
E: PCI_SLOT_NAME=:00:0b.0
E: PCI_SUBSYS_ID=:
E: SUBSYSTEM=pci
E: USEC_INITIALIZED=10724536

P: /devices/pci:00/:00:0b.0/:0a:00.0
E: DEVPATH=/devices/pci:00/:00:0b.0/:0a:00.0
E: ID_MODEL_FROM_DATABASE=NV43 [GeForce 6600]
E: ID_PCI_CLASS_FROM_DATABASE=Display controller
E: ID_PCI_INTERFACE_FROM_DATABASE=VGA controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller
E: ID_VENDOR_FROM_DATABASE=NVIDIA Corporation
E: MODALIAS=pci:v10DEd0141sv10DEsd0010bc03sc00i00
E: OF_COMPATIBLE_N=0
E: OF_FULLNAME=/pci@0,f000/NVDA,Parent@0
E: OF_NAME=NVDA,Parent
E: OF_TYPE=NVDA,GeForce
E: PCI_CLASS=3
E: PCI_ID=10DE:0141
E: PCI_SLOT_NAME=:0a:00.0
E: PCI_SUBSYS_ID=10DE:0010
E: SUBSYSTEM=pci
E: USEC_INITIALIZED=10730884

P: /devices/p

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Michael Biebl]

Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System:
>> Maybe the problem is because / is a RAID0 ?
>>
>> Setting up udev (232-14) ...
> No. This is the problem:
> 
>> addgroup: The group `input' already exists as a system group. Exiting.

I suspect this to be the problem:

Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service:
Main process exited, code=exited, status=232/ADDRESS_FAMILIES
...
Architecture: powerpc (ppc64)


> systemd (232-12) unstable; urgency=medium
> 
>   * Fix build if seccomp support is disabled
>   * Enable seccomp support on ppc64

seccomp is supposed to work on ppc64 [1], but maybe it's not.

Christian, could comment out
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

in systemd-udevd.service



[1]
https://packages.qa.debian.org/libs/libseccomp/news/20160210T235231Z.html
-- 
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#852811: udev: Doesn't start after upgrade powerpc

[Christian Marillat]

On 27 janv. 2017 15:16, m...@linux.it (Marco d'Itri) wrote:

> On Jan 27, Christian Marillat  wrote:
>
>> Maybe the problem is because / is a RAID0 ?
>> 
>> Setting up udev (232-14) ...
> No. This is the problem:
>
>> addgroup: The group `input' already exists as a system group. Exiting.

I see also this problem on my main machine (i386) but udev don't fail to
upgrade :

,
| Unpacking udev (232-14) over (232-14) ...
| Setting up udev (232-14) ...
| addgroup: The group `input' already exists as a system group. Exiting.
`

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Michael Biebl]

Am 27.01.2017 um 15:26 schrieb Michael Biebl:
> Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System:
>>> Maybe the problem is because / is a RAID0 ?
>>>
>>> Setting up udev (232-14) ...
>> No. This is the problem:
>>
>>> addgroup: The group `input' already exists as a system group. Exiting.
> 
> I suspect this to be the problem:
> 
> Jan 27 14:51:23 fabian.marillat.net systemd[1]: systemd-udevd.service:
> Main process exited, code=exited, status=232/ADDRESS_FAMILIES
> ...
> Architecture: powerpc (ppc64)
> 
> 
>> systemd (232-12) unstable; urgency=medium
>>
>>   * Fix build if seccomp support is disabled
>>   * Enable seccomp support on ppc64
> 
> seccomp is supposed to work on ppc64 [1], but maybe it's not.


The output of grep SECCOMP /boot/config-$(uname -r)
would be helpful as well.


-- 
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#852811: udev: Doesn't start after upgrade powerpc

[Felipe Sateler]

On Fri, 27 Jan 2017 15:16:57 +0100 m...@linux.it (Marco d'Itri) wrote:
> On Jan 27, Christian Marillat  wrote:
>
> > Maybe the problem is because / is a RAID0 ?
> >
> > Setting up udev (232-14) ...
> No. This is the problem:
>
> > addgroup: The group `input' already exists as a system group. Exiting.

That message should be innocuous. I think the real problem is this:

> Process: 15711 ExecStart=/lib/systemd/systemd-udevd (code=exited, 
> status=232/ADDRESS_FAMILIES)

It may be that seccomp is not working in powerpc?


Christian, does the problem go away if you remove the
RestrictAddressFamilies setting in systemd-udevd.service ?

Saludos


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Christian Marillat]

On 27 janv. 2017 15:29, Michael Biebl  wrote:

[...]

> The output of grep SECCOMP /boot/config-$(uname -r)
> would be helpful as well.

,
| $ grep SECCOMP /boot/config-$(uname -r)
| CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
| CONFIG_SECCOMP_FILTER=y
| CONFIG_SECCOMP=y
`

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Christian Marillat]

On 27 janv. 2017 15:26, Michael Biebl  wrote:

> Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System:

[...]

> seccomp is supposed to work on ppc64 [1], but maybe it's not.
>
> Christian, could comment out
> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
>
> in systemd-udevd.service

Still the same :

,
| $ sudo dpkg --configure -a   
| Setting up udev (232-14) ...
| addgroup: The group `input' already exists as a system group. Exiting.
| Job for systemd-udevd.service failed because the control process exited with 
error code.
| See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
| invoke-rc.d: initscript udev, action "restart" failed.
| ● systemd-udevd.service - udev Kernel Device Manager
|Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor 
preset: enabled)
|Active: activating (start) since Fri 2017-01-27 15:38:52 CET; 14ms ago
|  Docs: man:systemd-udevd.service(8)
|man:udev(7)
|  Main PID: 2663 ((md-udevd))
| Tasks: 1
|CGroup: /system.slice/systemd-udevd.service
|‣ 2663 [(md-udevd)]
| 
| Jan 27 15:38:52 fabian.marillat.net systemd[1]: Starting udev Kernel Device 
Manager...
| Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: Main 
process exited, code=exited, status=228/SECCOMP
| Jan 27 15:38:52 fabian.marillat.net systemd[1]: Failed to start udev Kernel 
Device Manager.
| Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: Unit 
entered failed state.
| Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: Failed 
with result 'exit-code'.
| dpkg: error processing package udev (--configure):
|  subprocess installed post-installation script returned error exit status 1
| Errors were encountered while processing:
|  udev
`

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Michael Biebl]

Am 27.01.2017 um 15:40 schrieb Christian Marillat:
> On 27 janv. 2017 15:26, Michael Biebl  wrote:
> 
>> Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System:
> 
> [...]
> 
>> seccomp is supposed to work on ppc64 [1], but maybe it's not.
>>
>> Christian, could comment out
>> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
>>
>> in systemd-udevd.service
> 
> Still the same :

The error code is different.

> | Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: Main 
> process exited, code=exited, status=228/SECCOMP

IIRC MemoryDenyWriteExecute= uses seccomp as well.
Please comment that out as well and try again.

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

Processed: reopening 852811

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 852811
Bug #852811 {Done: m...@linux.it (Marco d'Itri)} [udev] udev: Doesn't start 
after upgrade powerpc
Bug reopened
Ignoring request to alter fixed versions of bug #852811 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
852811: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852811
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Felipe Sateler]

On 27 January 2017 at 11:44, Michael Biebl  wrote:
> Am 27.01.2017 um 15:40 schrieb Christian Marillat:
>> On 27 janv. 2017 15:26, Michael Biebl  wrote:
>>
>>> Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System:
>>
>> [...]
>>
>>> seccomp is supposed to work on ppc64 [1], but maybe it's not.
>>>
>>> Christian, could comment out
>>> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
>>>
>>> in systemd-udevd.service
>>
>> Still the same :
>
> The error code is different.
>
>> | Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: 
>> Main process exited, code=exited, status=228/SECCOMP
>
> IIRC MemoryDenyWriteExecute= uses seccomp as well.
> Please comment that out as well and try again.

RestrictRealtime also uses seccomp, so comment that out too.


-- 

Saludos,
Felipe Sateler


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Christian Marillat]

On 27 janv. 2017 15:44, Michael Biebl  wrote:

> Am 27.01.2017 um 15:40 schrieb Christian Marillat:
>> On 27 janv. 2017 15:26, Michael Biebl  wrote:

[...]

>> Still the same :
>
> The error code is different.
>
>> | Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: 
>> Main process exited, code=exited, status=228/SECCOMP
>
> IIRC MemoryDenyWriteExecute= uses seccomp as well.
> Please comment that out as well and try again.

Still fail :

,
| $ sudo dpkg --configure -a   
| Setting up udev (232-14) ...
| addgroup: The group `input' already exists as a system group. Exiting.
| Job for systemd-udevd.service failed because the control process exited with 
error code.
| See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
| invoke-rc.d: initscript udev, action "restart" failed.
| ● systemd-udevd.service - udev Kernel Device Manager
|Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor 
preset: enabled)
|Active: activating (start) since Fri 2017-01-27 15:50:11 CET; 14ms ago
|  Docs: man:systemd-udevd.service(8)
|man:udev(7)
|  Main PID: 3104 ((md-udevd))
| Tasks: 1
|CGroup: /system.slice/systemd-udevd.service
|‣ 3104 [(md-udevd)]
| 
| Jan 27 15:50:11 fabian.marillat.net systemd[1]: Starting udev Kernel Device 
Manager...
| Jan 27 15:50:11 fabian.marillat.net systemd[3104]: systemd-udevd.service: 
Failed at step SECCOMP spawning /lib/systemd/systemd-udevd: File exists
| dpkg: error processing package udev (--configure):
|  subprocess installed post-installation script returned error exit status 1
| Errors were encountered while processing:
|  udev
`

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Christian Marillat]

On 27 janv. 2017 15:48, Felipe Sateler  wrote:

> On 27 January 2017 at 11:44, Michael Biebl  wrote:
>> Am 27.01.2017 um 15:40 schrieb Christian Marillat:
>>> On 27 janv. 2017 15:26, Michael Biebl  wrote:

[...]

>>> | Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: 
>>> Main process exited, code=exited, status=228/SECCOMP
>>
>> IIRC MemoryDenyWriteExecute= uses seccomp as well.
>> Please comment that out as well and try again.
>
> RestrictRealtime also uses seccomp, so comment that out too.

Yes, well done. udev start now with theses lines commented :

#MemoryDenyWriteExecute=yes
#RestrictRealtime=yes
#RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Christian Marillat]

On 27 janv. 2017 15:48, Felipe Sateler  wrote:

> On 27 January 2017 at 11:44, Michael Biebl  wrote:
>> Am 27.01.2017 um 15:40 schrieb Christian Marillat:
>>> On 27 janv. 2017 15:26, Michael Biebl  wrote:

[...]

>>> | Jan 27 15:38:52 fabian.marillat.net systemd[1]: systemd-udevd.service: 
>>> Main process exited, code=exited, status=228/SECCOMP
>>
>> IIRC MemoryDenyWriteExecute= uses seccomp as well.
>> Please comment that out as well and try again.
>
> RestrictRealtime also uses seccomp, so comment that out too.

Yes, well done. udev start now with theses lines commented :

#MemoryDenyWriteExecute=yes
#RestrictRealtime=yes
#RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

But I see others problems after a reboot :

,
| [   13.107885] systemd[1]: Starting Login Service...
| [   13.110001] systemd[401]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   13.110110] systemd[1]: Started Run anacron jobs.
| [   13.111494] systemd[1]: Started RPC bind portmap service.
| [   13.111934] systemd[1]: systemd-logind.service: Main process exited, 
code=exited, status=232/ADDRESS_FAMILIES
| [   13.112767] systemd[1]: Failed to start Login Service.
| [   13.112989] systemd[1]: systemd-logind.service: Unit entered failed state.
| [   13.113045] systemd[1]: systemd-logind.service: Failed with result 
'exit-code'.
| [   13.117192] systemd[1]: systemd-logind.service: Service has no hold-off 
time, scheduling restart.
| [   13.117813] systemd[1]: Stopped Login Service.
| [   13.122902] systemd[404]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   13.129681] systemd[407]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   13.136223] systemd[409]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   13.142940] systemd[411]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   13.589471] u3msi: allocated virq 0x20 (hw 0x8) addr 0xfee0
| [   13.616962] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
| [   16.708158] tg3 0001:05:04.0 eth0: Link is up at 1000 Mbps, full duplex
| [   16.708175] tg3 0001:05:04.0 eth0: Flow control is on for TX and on for RX
| [   16.708201] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
| [   18.117322] systemd[1]: Starting Login Service...
| [   18.119113] systemd[558]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   18.119768] systemd[1]: systemd-logind.service: Main process exited, 
code=exited, status=232/ADDRESS_FAMILIES
| [   18.120546] systemd[1]: Failed to start Login Service.
| [   18.120618] systemd[1]: systemd-logind.service: Unit entered failed state.
| [   18.120697] systemd[1]: systemd-logind.service: Failed with result 
'exit-code'.
| [   18.125282] systemd[1]: systemd-logind.service: Service has no hold-off 
time, scheduling restart.
| [   18.125848] systemd[1]: Stopped Login Service.
| [   18.127799] systemd[1]: Starting Login Service...
| [   18.129733] systemd[560]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   18.130358] systemd[1]: systemd-logind.service: Main process exited, 
code=exited, status=232/ADDRESS_FAMILIES
| [   18.131147] systemd[1]: Failed to start Login Service.
| [   18.140238] systemd[562]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   18.150867] systemd[564]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   18.161554] systemd[566]: systemd-logind.service: Failed at step 
ADDRESS_FAMILIES spawning /lib/systemd/systemd-logind: File exists
| [   26.792016] systemd[1]: Time has been changed
| [   26.792271] systemd[1]: apt-daily.timer: Adding 1h 48min 11.146327s random 
time.
`

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Michael Biebl]

Am 27.01.2017 um 15:54 schrieb Christian Marillat:
> #MemoryDenyWriteExecute=yes
> #RestrictRealtime=yes
> #RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
> 
> But I see others problems after a reboot :

There are quite a few services which use seccomp features to restrict
the service. systemd-udevd is just one of them. So if seccomp is broken,
the output you get is expected.

Christian, I think it's best if you approach the ppc64 porters about
this. We need their input regarding seccomp support on that architecture.



-- 
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Christian Marillat]

On 27 janv. 2017 16:21, Michael Biebl  wrote:

> Am 27.01.2017 um 15:54 schrieb Christian Marillat:
>> #MemoryDenyWriteExecute=yes
>> #RestrictRealtime=yes
>> #RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
>> 
>> But I see others problems after a reboot :
>
> There are quite a few services which use seccomp features to restrict
> the service. systemd-udevd is just one of them. So if seccomp is broken,
> the output you get is expected.
>
> Christian, I think it's best if you approach the ppc64 porters about
> this. We need their input regarding seccomp support on that architecture.

Well the kernel is a ppc64 but the architecture is powerpc and this
architecture isn't a release architecture...

powerpc is still supported by Debian ?

Christian


___
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#852811: marked as done (udev: Doesn't start after upgrade powerpc)

[Michael Biebl]

Am 27.01.2017 um 16:30 schrieb Christian Marillat:
> On 27 janv. 2017 16:21, Michael Biebl  wrote:
> 

>> Christian, I think it's best if you approach the ppc64 porters about
>> this. We need their input regarding seccomp support on that architecture.
> 
> Well the kernel is a ppc64 but the architecture is powerpc and this
> architecture isn't a release architecture...
> 
> powerpc is still supported by Debian ?
> 

powerpc and ppc64 are not release architectures.


-- 
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

systemd 232-14 MIGRATED to testing

[Debian testing watch]

FYI: The status of the systemd source package
in Debian's testing distribution has changed.

  Previous version: 232-8
  Current version:  232-14

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
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#852461: systemd: Creating scopes with systemd-run unreliable

[Michael Gebetsroither]

On 2017-01-24 20:20, Michael Biebl wrote:
Hi Michael,

>> The creation of scopes with systemd-run --scope is unreliable.
>> It seems to depend on system "load" or some other factors affected
>> by system "load".
>> On production systems we've seen an error rate of up to 20%.
> 
>> % for i in `seq 50`; do (systemd-run --scope -- sleep 5 2>&1 ) & done 2>&1 
>> |grep -ni failed
> 
> 
> You mean you see this problem under high load? What kind of load?

We are seeing this problem especially under high load, but for the commands 
above and the output
this was on a test-system without any load on it (4 cores kvm).

> Could it be that you are running into D-Bus timeouts?

doesn't seem like it, see below.

> Do you get any error messages in the journal?

no

> Can you reproduce the issue with v232 from stretch or tell us how we can
> reproduce the issue?
>
> Even my small PI (running raspbian + systemd 215-17+deb8u6) seems to
> handle your for loop without a hitch even if under load.

thx for trying so hard to reproduce the issue!
And sorry for wasting your time and not just sending some debug logs :/

# strace log of an unsuccessful systemd-run run

The error sent from systemd back to systemd-run seems to be:
"Unit run-24908.scope already exists."

A working run prints the scope with pid of the child process, not the pid of 
the caller.

> 24908 socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> 24908 setsockopt(3, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
> 24908 setsockopt(3, SOL_SOCKET, 0x22 /* SO_??? */, [0], 4) = 0
> 24908 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
> 24908 setsockopt(3, SOL_SOCKET, 0x21 /* SO_??? */, [8388608], 4) = 0
> 24908 getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
> 24908 setsockopt(3, SOL_SOCKET, 0x20 /* SO_??? */, [8388608], 4) = 0
> 24908 connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, 22) = > 0
> 24908 getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
> 24908 fstat(3, {st_dev=makedev(0, 7), st_ino=8642755, st_mode=S_IFSOCK|0777, 
> st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, 
> st_atime=0, st_mtime=0, st_ctime=0}) = 0
> 24908 getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
> 24908 getsockname(3, {sa_family=AF_LOCAL, sun_path=@"37a95"}, [8]) = 0
> 24908 geteuid() = 0
> 24908 sendmsg(3, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL ", 15}, 
> {"30", 2}, {"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}], msg_controllen=0, 
> msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 45
> 24908 getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
> 24908 recvmsg(3, 0x7ffe1836b9d0, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) 
> = -1 EAGAIN (Resource temporarily unavailable)
> 24908 ppoll([{fd=3, events=POLLIN}], 1, {24, 999718000}, NULL, 8) = 1 
> ([{fd=3, revents=POLLIN}], left {24, 999061963})
> 24908 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"OK 
> 68040979bb0143a29a072e055d9fa717\r\nAGREE_UNIX_FD\r\n", 256}], 
> msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET, 
> cmsg_type=SCM_CREDENTIALS{pid=1, uid=0, gid=0}}, msg_flags=MSG_CMSG_CLOEXEC}, 
> MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 52
> 24908 sendmsg(3, {msg_name(0)=NULL, 
> msg_iov(2)=[{"l\1\0\1p\0\0\0\1\0\0\0\266\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\3\1s\0\22\0\0\0StartTransientUnit\0\0\0\0\0\0\2\1s\0
>  
> \0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\20ssa(sv)a(sa(sv))\0\0\0",
>  200}, 
> {"\17\0\0\0run-24908.scope\0\4\0\0\0fail\0\0\0\0@\0\0\0\0\0\0\0\v\0\0\0Description\0\1s\0\0\f\0\0\0/bin/sleep
>  5\0\0\0\0\4\0\0\0PIDs\0\2au\0\0\0\0\4\0\0\0La\0\0\0\0\0\0\0\0\0\0", 112}], 
> msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 312
> 24908 recvmsg(3, 0x7ffe1836bad0, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) 
> = -1 EAGAIN (Resource temporarily unavailable)
> 24908 ppoll([{fd=3, events=POLLIN}], 1, {24, 5}, NULL, 8) = 1 
> ([{fd=3, revents=POLLIN}], left {24, 999721214})
> 24908 recvmsg(3, {msg_name(0)=NULL, 
> msg_iov(1)=[{"l\4\1\1K\0\0\0\1\0\0\0p\0\0\0\1\1o\0\31\0\0\0", 24}], 
> msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET, 
> cmsg_type=SCM_CREDENTIALS{pid=1, uid=0, gid=0}}, msg_flags=MSG_CMSG_CLOEXEC}, 
> MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
> 24908 recvmsg(3, {msg_name(0)=NULL, 
> msg_iov(1)=[{"/org/freedesktop/systemd1\0\0\0\0\0\0\0\2\1s\0 
> \0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\7\0\0\0UnitNew\0\10\1g\0\2so\0\17\0\0\0run-24918.scope\0002\0\0\0/org/freedesktop/systemd1/unit/run_2d24918_2escope\0",
>  179}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET, 
> cmsg_type=SCM_CREDENTIALS{pid=1, uid=0, gid=0}}, msg_flags=MSG_CMSG_CLOEXEC}, 
> MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 179
> 24908 recvmsg(3, {msg_name(0)=NULL, 
> msg_iov(1)=[{"l\4\1\1D\0\0\0\2\0\0\0q\0\0\0\1\1o\0\31\0\0\0", 24}], 
> msg_controllen=32, 

Bug#852461: systemd: Creating scopes with systemd-run unreliable

[Michael Biebl]

Am 27. Januar 2017 18:56:31 MEZ schrieb Michael Gebetsroither 
:
>On 2017-01-24 20:20, Michael Biebl wrote:
>Hi Michael,
>
>>> The creation of scopes with systemd-run --scope is unreliable.
>>> It seems to depend on system "load" or some other factors affected
>>> by system "load".
>>> On production systems we've seen an error rate of up to 20%.
>> 
>>> % for i in `seq 50`; do (systemd-run --scope -- sleep 5 2>&1 ) &
>done 2>&1 |grep -ni failed
>> 
>> 
>> You mean you see this problem under high load? What kind of load?
>
>We are seeing this problem especially under high load, but for the
>commands above and the output
>this was on a test-system without any load on it (4 cores kvm).
>
>> Could it be that you are running into D-Bus timeouts?
>
>doesn't seem like it, see below.
>
>> Do you get any error messages in the journal?
>
>no
>
>> Can you reproduce the issue with v232 from stretch or tell us how we
>can
>> reproduce the issue?
>>
>> Even my small PI (running raspbian + systemd 215-17+deb8u6) seems to
>> handle your for loop without a hitch even if under load.
>
>thx for trying so hard to reproduce the issue!
>And sorry for wasting your time and not just sending some debug logs :/
>
># strace log of an unsuccessful systemd-run run
>
>The error sent from systemd back to systemd-run seems to be:
>"Unit run-24908.scope already exists."


Could you check if you have many scope units in /run which could slow down 
systemd

___
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#852461: systemd: Creating scopes with systemd-run unreliable

[Michael Gebetsroither]

On 2017-01-27 20:50, Michael Biebl wrote:

>> The error sent from systemd back to systemd-run seems to be:
>> "Unit run-24908.scope already exists."
> 
> 
> Could you check if you have many scope units in /run which could slow down 
> systemd

# find /run/systemd/system/ -type f -iname '*.scope' |wc -l
1440

All scope files containing only: '# Transient stub'

The directory below containing:

# cat /run/systemd/system/run-1654.scope.d/50-Slice.conf
[Scope]
Slice=.slice

# cat /run/systemd/system/run-1654.scope.d/50-Description.conf
[Unit]
Description=.sh

gebi

___
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#824532: [Pkg-auth-maintainers] Bug#848327: RFS: libu2f-host/1.1.3-1

[Nicolas Braud-Santoni]

Hi,

On Sun, Dec 25, 2016 at 03:29:39PM +0100, Luca Capello wrote:
> 
> sorry for the late reply, the package was rejected:
> 
>   
> 

Sorry for the even-more-late reply, I was ill the last few months  :(

I built a new version of the package
that has updated copyright metadata.


> However, can you first push your changes to the Git repository on
> Alioth?  I find awkward not to use it for Debian work...

It is in the rfs-848327 branch on alioth.


> > This updates brings:
> > - - a fix for #846358, so that rules for the right udev version are 
> > installed;
> > - - as per #846359 and #824532, this creates a new binary package,
> >   libu2f-common, containing the udev rules;
> > - - the new upstream version brings udev rules for additional devices.
> 
> Sorry, I still do not see the reasoning behing such a move:
> 
>   

Well, that one is simple:

- #846358 is a bug, pure and simple, and this fixes it.

- Before this upload, the udev rules were shipped in the libu2f-host0
  binary package, which is again wrong.  There are two options, then

  1. keeping the udev rules in the libu2f-host *source* package
  2. moving the udev rules to another source package


I am strongly in favor of 1, if only because upstream actually maintains
that list in this package.  The alternative involves
  - repackaging libu2f-host to get rid of this
(and patching the build/install scripts),
  - adding the udev rules to some other package,
likely as a Debian patch,
  - and keeping the udev rules up-to-date in that other package,
manually, forever.

Moreover, in the case where the other source package is udev,
this adds a lot of synchronisation overhead in maintaining libu2f-host
because I can't just push the udev rules in udev's packaging repo
and upload a new version of the package ...


> Mickael or Martin (both Bcc:ed), can you elaborate a bit more, please?
> Yes, I have read the full bug and I fully agree with Robert and Simon
> (both Bcc:ed), moreover:
>
> [...]
> 
> 2) U2F devices are becoming more and more frequent and they are
>considered by at least Google (who, to be fair, co-developed the
>standard) to be the more secure 2FA mechanism:
> 
>  
> 
>  

I'm not sure I see the point there.


> 3) some of them are even more than that (e.g. the YubiKey 4 which also
>contains an OpenPGP smartcard), which justify the fact that udev
>rules do not belong to any U2F-specific package:
> 
>  

If the name of the binary package is the only issue, it /could/ be
renamed udev-rules-for-crypto-hipsterdingen (or likely some better
name, but it is late and I'm tired).


All in all, I do not understand what are you precise objections
to that solution.

- Is the name of the libu2f-common binary package the issue?
  If so, I will happily take better suggestions, but I would
  have rather not spent so much time on a bikeshed.

- Is it that the udev rules live in the libu2f-host source package?
  Then, I would suggest taking up the issue with upstream:  the better
  solution would likely be to have a separate repository containing
  udev rules for crypto tokens.
  Also, I do not see why this would be a blocker for this upload:
  it doesn't create the issue (the udev rules already existed in the
  source package) and provides the first part in fixing it (splitting
  off the udev rules in a separate binary package).


Best,

  nicoo


___
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#852461: systemd: Creating scopes with systemd-run unreliable

[Michael Biebl]

Am 27. Januar 2017 21:16:52 MEZ schrieb Michael Gebetsroither 
:
>On 2017-01-27 20:50, Michael Biebl wrote:
>
>>> The error sent from systemd back to systemd-run seems to be:
>>> "Unit run-24908.scope already exists."
>> 
>> 
>> Could you check if you have many scope units in /run which could slow
>down systemd
>
># find /run/systemd/system/ -type f -iname '*.scope' |wc -l
>1440

Does the problem go away if you clean up stale scope units? 

___
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#824532: Bug#848327: [Pkg-auth-maintainers] Bug#848327: RFS: libu2f-host/1.1.3-1

[Andreas Gnau]

On 25/12/16 15:29, Luca Capello wrote:

On Fri, 16 Dec 2016 11:58:51 +0100, Nicolas Braud-Santoni wrote:

This updates brings:
- - a fix for #846358, so that rules for the right udev version are installed;
- - as per #846359 and #824532, this creates a new binary package,
  libu2f-common, containing the udev rules;
- - the new upstream version brings udev rules for additional devices.


Sorry, I still do not see the reasoning behing such a move:

  

Mickael or Martin (both Bcc:ed), can you elaborate a bit more, please?
Yes, I have read the full bug and I fully agree with Robert and Simon
(both Bcc:ed), moreover:

FYI, IMHO this is a udev upstream bug.


I would like to point to /lib/udev/rules.d/70-debian-uaccess.rules
Thus, we do already ship an outdated version of those udev-rules in the 
udev package. Obviously, we do not need two.


It has been tried to bring those rules upstream:
https://github.com/systemd/systemd/issues/102


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