Subject: bug#500: Package: usbmuxd calls systemd in its udev rules so it will never start in Devuan

From: Vernon Van Steenkist <[email-masked]>
Date: Tue, 28 Jul 2020 22:50:58 -0400

Package: usbmuxd
Version: 1.1.1~git20181007.f838cf6-1 i386

Beowulf usbmuxd is maintained by Debian. A Devuan usbmuxd package 
probably should be created because the Debian version references systemd 
in its udev rules so usbmuxd will never start under Devuan.

Debian usbmuxd /lib/udev/rules.d/39-usbmuxd.rules file contents

# systemd should receive all events relating to device
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", TAG+="systemd"

# Initialize iOS devices into "deactivated" USB configuration state and 
activate usbmuxd
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ACTION=="add", 
ENV{USBMUX_SUPPORTED}="1", ATTR{bConfigurationValue}="0", 
OWNER="usbmux", ENV{SYSTEMD_WANTS}="usbmuxd.service"

# Make sure properties don't get lost when bind action is called
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ACTION=="bind", 
ENV{USBMUX_SUPPORTED}="1", OWNER="usbmux", 
ENV{SYSTEMD_WANTS}="usbmuxd.service"

# Exit usbmuxd when the last device is removed
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ACTION=="remove", 
RUN+="/usr/sbin/usbmuxd -x"

Suggested /lib/udev/rules.d/85-usbmuxd.rules for a  new Devuan usbmuxd 
package.

# usbmuxd ("Apple Mobile Device" muxer listening on /var/run/usbmuxd)

# Forces iDevices to the last USB configuration and runs usbmuxd
ACTION=="add", SUBSYSTEM=="usb", OWNER="usbmux", ATTR{idVendor}=="05ac", 
ATTR{idProduct}=="12[9a][0-9a-f]", ENV{USBMUX_SUPPORTED}="1", 
ATTR{bConfigurationValue}!="$attr{bNumConfigurations}", 
ATTR{bConfigurationValue}="$attr{bNumConfigurations}", OWNER="usbmux", 
RUN+="/usr/sbin/usbmuxd -u -U usbmux"

# Exit usbmuxd when the last device is removed
ACTION=="remove", SUBSYSTEM=="usb", 
ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ENV{INTERFACE}=="255/*", 
RUN+="/usr/sbin/usbmuxd -x"

Please don't hesitate to contact me if you have any questions.

Thanks,
Vernon

---

From: Mark Hindley <[email-masked]>
Date: Wed, 29 Jul 2020 10:01:45 +0100

Vernon,

[Congratulations on submitting the 500th Devuan bug! ;)]

On Tue, Jul 28, 2020 at 10:50:58PM -0400, Vernon Van Steenkist wrote:
> Beowulf usbmuxd is maintained by Debian. A Devuan usbmuxd package probably
> should be created because the Debian version references systemd in its udev
> rules so usbmuxd will never start under Devuan.

Thanks for this.

[...]

> RUN+="/usr/sbin/usbmuxd -u -U usbmux"

I am certainly not an expert on udev rules.

Do you know if/how this can be made to sit alongside the existing systemd rules
without conflicting? i.e only use this rule if systemd is not installed
available?

If so, this patch should go to Debian as this bug will also be present on a
Debian system that is not running systemd as PID1.

Thanks

Mark

---

From: Mark Hindley <[email-masked]>
Date: Thu, 30 Jul 2020 10:22:11 +0100

Control: tags -1 debian
Control: forwarded -1 https://bugs.debian.org/966403

Vernon,

Thanks for this information which is very helpful.
 
> It appears that not having sysvinit support in usbmuxd.rules is not a bug
> but an intended feature.

I would phrase this another way: it is a conscious decision, but it is still a
bug. Non-systemd PID1 is still possible in Debian and so this behaviour will be
evident on such a system.

[…]

> I tested the above usbmuxd.rules file on my non-systemd Devuan and my
> systemd Ubuntu 18.04 machine (I don't have any pure Debian machines) and the
> above usbmuxd.rules worked on both machines (started usbmuxd when I
> connected my iphone). Therefore, it is unclear to me why Debian removed
> sysvinit usbmuxd.rules support in the next release of Debian
> (usbmuxd_1.1.0-2+b2_i386.deb).  I find the CHANGELOG cryptic and I can't
> make heads or tails of it.

I agree, it isn't really mentioned at all.
 
> So, Debian removing sysvinit support from Debian package usbmuxd which
> supported both systemd and sysvinit is not a bug but a feature.

A conscious decision, but still a bug on some Debian systems.

> Actually, I already (accidentally :) ) sent a bug report to Debian regarding
> this a few days ago. However, based on the Debian usbmuxd package history of
> purposefully removing sysvinit support from a usbmuxd.package that supported
> both systemd and sysvinit, it appears that Debian is willfully moving away
> from supporting sysvinit. Therefore I don't expect a response from Debian.
> 
> How would you like me to proceed?

I agree that the current actions of some Debian maintainers in actively removing
non-systemd functionality is very unhelpful. My personal opinion is that by
accepting such actions unchallenged we risk them increasing on a 'nobody noticed
or complained so nobody cares' basis. If the current trickle increases
substantially, Devuan's limited person-power could easily be overstretched.

So I think that a bug that can be demonstrated on a non-systemd PID1 Debian
system shold be fixed in Debian.  I accept that maybe easier said than done: I
have a number of Debian bugs open that are being ignored and I realise how
frustrating it is.

My suggestion is to retitle your Debian bug #966403 to mention non-systemd PID1
rather than Devuan and add a patch (and patch tag) to reintroduce legacy udev
support. And then be persistent until you get a response.

How do you feel about that?

Best wishes

Mark

---

From: Vernon Van Steenkist <[email-masked]>
Date: Thu, 30 Jul 2020 22:25:51 -0400

Mark,

On 7/30/20 5:22 AM, Mark Hindley wrote:
[...|
> substantially, Devuan's limited person-power could easily be overstretched.

Agree. Especially considering Devuan's limited person-power. However, 
these Devuan Beowulf systemd dependency issues are accumulating as well 
- NetworkManager, PulseAudio to name a few. A quick grep -li systemd 
/lib/udev/rules.d/* indicates there may be others.

I think it would be helpful to have some central place where all Devuan 
systemd dependencies and their workarounds are stored. Currently, the 
workarounds are scattered around different posts in the Devuan forum 
making them non-trivial to find. Initially, I though it would be a good 
idea to create a new Devuan forum category to hold these Devuan systemd 
dependency workaround.

However, today I found out that there is a friends of devuan wiki and I 
now think that may be a better place. I don't know the relationship 
between friends of devuan and the main devuan project and why I could 
find no link to this wiki on the devuan.org web site. Is there a risk 
that the friends of devuan could become the fiends of devuan :) ?

What do you think?

> How do you feel about that?

I agree and have changed the title and added additional clarification.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966403

I am all new to this and don't know the best way to pester Debian 
developers. Any thoughts are appreciated.

Thanks for all your responses.

Vernon

---

From: [email-masked]
Date: Thu, 30 Jul 2020 22:37:57 -0500

On 2020-07-30 21:25, Vernon Van Steenkist wrote:
> 
> However, today I found out that there is a friends of devuan wiki and
> I now think that may be a better place. I don't know the relationship

All the links to the FoD wiki have been removed because a wiki requires 
hands on and no one has stepped up to do that consistently.  Several 
years ago someone was going to set up a new media wiki format. That 
never happened. Then more recently there was another offer to set up a 
different wiki format but again, nothing materialized.  Sadly, until we 
have a reliable, long-term wiki-whisperer to tend it, I don't see a wiki 
being a viable option.

golinux