>=udev-172 is now a dep of systemd-9999, we'd appreciate a version bump then.
Created attachment 280105 [details, diff] udev-172.ebuild.patch These are the changes I did to get udev-172 installed on my systems. Please note that the action_modeswitch code was removed from this version in favour of sys-apps/usb_modeswitch. What I'm not sure about is how to make the ebuild check for the in-kernel media-presence polling being available. This change of relying on in-kernel media-presence polling also requires at least udisks-1.0.3 to work reliably with this version of udev.
I'd wait for at least one more release. If you look at the git, you'll see "udevd: fix (recently) broken static node permission setting" commit, if you'll search for the source on Arch Linux mailing list, you'll learn that due to this bug, another release is planned shortly.
Hi all, I have been looking at this for the last day or so, and I have a new ebuild almost ready. Also there will be some updates to the startup scripts, so I am working on that. Due to the information in comment #2, I also think we should wait for 173. Mgorny, what do you think?
(In reply to comment #3) > I have been looking at this for the last day or so, and I have > a new ebuild almost ready. Also there will be some updates to the > startup scripts, so I am working on that. > > Due to the information in comment #2, I also think we should wait for > 173. Mgorny, what do you think? I don't mind. Just needed a bug to track the dep :P.
Oh, on semi-related note: 40-gentoo.rules and 90-network.rules are getting installed with executable permissions. Not that it hurts anything, but somebody should check if that not anything more than a cosmetic ebuild bug. As a side note: in the wake of xorg-devel discussion, an interesting change has just landed ("do not allow kernel properties to be set by udev rules"). Doesn't seem as if it would affect us, but stranger things happened. On the other hand, udev-acl change will affect those strange people willing to use systemd on Gentoo...(nothing personal, I'm just being cautious about it)
(In reply to comment #5) > On the other hand, udev-acl change will affect those strange people willing to > use systemd on Gentoo...(nothing personal, I'm just being cautious about it) -9999 worksforme, and systemd now requires >=udev-172.
OK, significantly later than I expected, but 173 has just been released.
It will be in the tree in the next few days; there are going to be some changes in how udev is started in this version that I need to work out.
Since udev-16x my Logitech MX 5500 kit are not working unless I move the mouse and press a key until udev it's fully started. The bluetooth donge, mouse and keyboard are properly recognized by kernel, but they simply does not comunicate with computer (either console or X server) if I forgot to use them until udev start. I found this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589388 So I modified /lib64/udev/rules.d/97-bluetooth-hid2hci.rules: # Logitech devices (hidraw) KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[35e]", \ RUN+="hid2hci --method=logitech-hid --devpath=%p" KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[4abc]|c71[34bc]", \ RUN+="hid2hci --method=logitech-hid --devpath=%p" # Logitech devices #KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71[34bc]", \ # RUN+="hid2hci --method=logitech-hid --devpath=%p" It's kinda "mokey see, monkey do" :) but I couldn't make MX 5500 Revolution kit working via hiddev, only vid hidraw, no mather I changer ATTRS to match my lsusb. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 003: ID 046d:0b06 Logitech, Inc. Bus 001 Device 004: ID 1e7d:38a4 ROCCAT Bus 001 Device 005: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 002 Device 003: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader) Bus 002 Device 004: ID 1a40:0101 TERMINUS TECHNOLOGY INC. USB-2.0 4-Port HUB Bus 001 Device 006: ID 046d:c71b Logitech, Inc. Bus 001 Device 007: ID 046d:c71c Logitech, Inc. Relevant dmesg: [ 2.194843] usb 1-1.1: Product: Logitech BT Mini-Receiver [ 2.194846] usb 1-1.1: Manufacturer: Logitech .... [ 3.513085] usb 2-1.4: new high speed USB device number 4 using ehci_hcd [ 3.598393] usb 2-1.4: New USB device found, idVendor=1a40, idProduct=0101 [ 3.598397] usb 2-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 3.598401] usb 2-1.4: Product: USB 2.0 Hub [ 3.598698] hub 2-1.4:1.0: USB hub found [ 3.598767] hub 2-1.4:1.0: 4 ports detected [ 3.661887] usb 1-1.1.2: new full speed USB device number 6 using ehci_hcd [ 3.753806] usb 1-1.1.2: New USB device found, idVendor=046d, idProduct=c71b [ 3.753810] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3.753814] usb 1-1.1.2: Product: Logitech BT Mini-Receiver [ 3.753817] usb 1-1.1.2: Manufacturer: Logitech [ 3.753819] usb 1-1.1.2: SerialNumber: 000761E1E6C4 [ 3.827521] usb 1-1.1.3: new full speed USB device number 7 using ehci_hcd [ 3.919196] usb 1-1.1.3: New USB device found, idVendor=046d, idProduct=c71c [ 3.919198] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3.919199] usb 1-1.1.3: Product: Logitech BT Mini-Receiver [ 3.919201] usb 1-1.1.3: Manufacturer: Logitech [ 3.919202] usb 1-1.1.3: SerialNumber: 000761E1E6C4 ... (this is a Logitech Webcam 3500).. not related, but, who know ? [ 4.090909] uvcvideo: Found UVC 1.00 device <unnamed> (046d:09a4) [ 4.121736] input: UVC Camera (046d:09a4) as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input3 [ 4.121795] usbcore: registered new interface driver uvcvideo [ 4.121797] USB Video Class driver (v1.1.0) ..... [ 4.130353] generic-usb 0003:1E7D:38A4.0001: input,hidraw0: USB HID v1.10 Device [HOLTEK ROCCAT Kave Headset] on usb-0000:00:1a.0-1.5/input0 [ 4.133262] input: Logitech Logitech BT Mini-Receiver as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/input/input5 [ 4.133412] generic-usb 0003:046D:C71B.0002: input,hidraw1: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1a.0-1.1.2/input0 [ 4.139818] input: Logitech Logitech BT Mini-Receiver as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/input/input6 [ 4.140214] generic-usb 0003:046D:C71C.0003: input,hiddev0,hidraw2: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1a.0-1.1.3/input0 [ 4.140253] usbcore: registered new interface driver usbhid [ 4.140255] usbhid: USB HID core driver Thank you!
(In reply to comment #9) > Since udev-16x my Logitech MX 5500 kit are not working unless I move the mouse > and press a key until udev it's fully started. > The bluetooth donge, mouse and keyboard are properly recognized by kernel, but > they simply does not comunicate with computer (either console or X server) if I > forgot to use them until udev start. Please do not hijack bugs. this is a completely separate issue and should be handled by another bug report. I would advise waiting until 173 is in the tree and seeing if this is still an issue.
(In reply to comment #10) > > Please do not hijack bugs. this is a completely separate issue and should be > handled by another bug report. I would advise waiting until 173 is in the tree > and seeing if this is still an issue. Probably won't change a thing anyway - bluetooth rules/tools are in bluez now.
Two notes for the >=udev-172 bump: Due to the change to in-kernel media-presence polling for removeable media when >=kernel-2.6.38 is in use we should consider adding an elog message telling the user to add something like "block.events_dfl_poll_msecs=1000" to his kernel command line in grub/lilo or else users won't be able to eject CDs/DVDs throught the eject button of their drives once these media were accessed. See http://lwn.net/Articles/423619/ for reference. Another issue I see on boot is that udevadm trigger --type=failed -v command from /etc/init.d/udev-postmount prints a warning about "--type=failed" being deprecated and that it will be removed in furure udev versions.
As for the first thing, if it's unset (set to 0), udev rule sets it to 2000.
...yuck, yet again brown paper. There's a commit in the git that fixes a mistake in the rules, which caused bluetooth input devices not being marked as such and not being detected by xserver.
(In reply to comment #13) > As for the first thing, if it's unset (set to 0), udev rule sets it to 2000. The problem is that the default for each removeable block device is -1. The meaning of -1 is to apply default system settings but the kernel's default is 0. From my experience on three different machines, all with udev-173, I can confirm that udev doesn't set this value on any removeable block device. You either have to set it via kernel commandline during bootup or manually through user intervention on each removeable block device.
(In reply to comment #14) > ...yuck, yet again brown paper. > There's a commit in the git that fixes a mistake in the rules, which caused > bluetooth input devices not being marked as such and not being detected by > xserver. Yes, I saw this in git as well. Should we wait now for udev 174 or go ahead with 173? This bug sounds like it might be significant.
(In reply to comment #16) > > Yes, I saw this in git as well. Should we wait now for udev 174 or go ahead > with 173? This bug sounds like it might be significant. Just add the patch from the git, I think. We've already waited for a few releases and the changes in next version will be even more significant, with input_id and a couple other turned into internal commands. Otherwise, to much could go wrong on the same time.
Ping. Maybe just add the ebuild masked/unkeyworded?
I was offline due to an internet outage for 1/2 of the weekend and today, so I should be able to get 173 into the tree soon, hopefully in the next couple of days.
Just a quick update. I have found that there is a significant amount of code in the udev ebuilds and our startup scripts which needs to be updated before I put udev-173 in the tree. I am working on this with the other members of the team, and we will get the new udev into the tree asap.
Any progress on this?
Currently, the udev startup scripts are being reworked, so that they will take advantage of openrc's start/stop functions and we may be able to not have a udev-mount startup script any longer. Once all of that is done this will be released.
Just a little note: udev git seems to be back online and there's a couple commits that sound quite unpleasant to people that don't want systemd, i.e. http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=fe9e1a0d4e324bde74a1bf85117ab57176092a26 Probably unrelated: 'udevadm trigger --type=failed -v' has been removed.
Just came back from Kernel Summit and seems it will be harder and harder to have a system without systemd. Thing is it stopped playing alone as init and started to fix real problems in a way other developers like. Soon it will get structured logging and daemons will use it. From what I've heard connman, bluez, ofono, avahi and others will likely drop their own cruft to do capabilities, daemon, etc and just rely on systemd. So Gentoo or other distros willing to have different init will have to patch them, or keep a fork. Moreover, I've heard from people that Ubuntu itself may move to systemd after their LTS next year. From a Gentoo PoV there is no reason to keep with openrc other than NIH syndrome. Yeah, Gentoo/kFreeBSD is another story.
(In reply to comment #24) > From what I've heard connman, bluez, ofono, avahi and others will likely drop > their own cruft to do capabilities, daemon, etc and just rely on systemd. So > Gentoo or other distros willing to have different init will have to patch them, > or keep a fork. AFAIR OpenRC init scripts can background services as well.
not trying to bash anyone, but pointing that openrc does background of services is either not understanding the services problems or subestimating these problems. There are at least few dozen reasons why openrc fails and systemd succeeds. From embedded to enterprise use cases. From speed to correctness to safety to accounting to logging to manageability. I could explain these all in details, but I suggest people interested to read Leannart's extensive series of blog posts about the topic. Moreover, OpenRC is not buying us anything. Actually it's adding burden and will add more and more as times went buy. As in this bug about udev. Very soon GNOME3 will rely on it. Some cloud services will recommend it. Etc. Keeping OpenRC will do no good. Okay, you may tag me as biased as I wrote systemd's initial patch for Gentoo and I'm indeed a strong supporter. But I really fail to see why it's good to keep openrc. If there is anything missing from openrc in systemd let us know and we'll fix it or point the correct way to solve it.
(In reply to comment #26) > There are at least few dozen reasons why openrc fails and systemd succeeds. > From embedded to enterprise use cases. From speed to correctness to safety to > accounting to logging to manageability. I could explain these all in details, > but I suggest people interested to read Leannart's extensive series of blog > posts about the topic. The main problem with systemd is that it developers fail to see much further than the tip of their noses. systemd could be good. Or could be even better, if its developers actually discussed with someone and tried to create a really portable, common configuration structures. In other words, if the files intended for systemd could be reused by some init system in *BSD and other non-Linuxes rather than forcing them to diverge or hack around systemd specifics. > Very soon GNOME3 will rely on it. Some cloud services will recommend it. Etc. > Keeping OpenRC will do no good. And you're saying that all Gentoo users are supposed to use GNOME3? Or some cloud services for whom I see no relationship to the topic at all? Keeping OpenRC means choice. Rather than dumping a dozen of users saying 'sorry, we don't support BSD anymore because Linux-specific package was hard to portably maintain'. > Okay, you may tag me as biased as I wrote systemd's initial patch for Gentoo > and I'm indeed a strong supporter. But I really fail to see why it's good to > keep openrc. If there is anything missing from openrc in systemd let us know > and we'll fix it or point the correct way to solve it. How about using /usr/share sanely rather than dumping random stuff into /usr/lib?
no offense, but please discuss this on gentoo-dev ml.
(In reply to comment #27) > (In reply to comment #26) > > There are at least few dozen reasons why openrc fails and systemd succeeds. > > From embedded to enterprise use cases. From speed to correctness to safety to > > accounting to logging to manageability. I could explain these all in details, > > but I suggest people interested to read Leannart's extensive series of blog > > posts about the topic. > > The main problem with systemd is that it developers fail to see much further > than the tip of their noses. systemd could be good. Or could be even better, if > its developers actually discussed with someone and tried to create a really > portable, common configuration structures. > > In other words, if the files intended for systemd could be reused by some init > system in *BSD and other non-Linuxes rather than forcing them to diverge or > hack around systemd specifics. BSD are free to port systemd. It is opensource. But nobody did anything to make it happen. Linux developers are collaborating to solver userspace problems. BSD doesn't seem to care about it. > > Very soon GNOME3 will rely on it. Some cloud services will recommend it. Etc. > > Keeping OpenRC will do no good. > > And you're saying that all Gentoo users are supposed to use GNOME3? Or some > cloud services for whom I see no relationship to the topic at all? I'm an Enlightenment developer, thus this is far from being true. However I'll do systemd user session support and I'd expect it to be usable by default in Gentoo. > Keeping OpenRC means choice. Rather than dumping a dozen of users saying > 'sorry, we don't support BSD anymore because Linux-specific package was hard to > portably maintain'. Likely you can use your openrc effort to port systemd to BSD and help the overall BSD community? Also bear in mind that systemd's services files are extremely simple "ini-like" syntax. You can make openrc parse it and ignore whatever systemd's does not support, like cgroups, few capabilities and so on. If you're willing to leave BSD in the dark ages, it's VERY simple. Even the socket activation is simple to do. > > Okay, you may tag me as biased as I wrote systemd's initial patch for Gentoo > > and I'm indeed a strong supporter. But I really fail to see why it's good to > > keep openrc. If there is anything missing from openrc in systemd let us know > > and we'll fix it or point the correct way to solve it. > > How about using /usr/share sanely rather than dumping random stuff into > /usr/lib? Mail systemd, but AFAIK there is nothing in /usr. All systemd files goes into one of 3 classes of directories: - /var/run/systemd: highest priority, temporary files - /etc/systemd: medium priority, static files (ie: sysadmin settings) - /lib/systemd: lowest priority, read-only system provided files. Sysadmins are supposed to edit /etc or /var/run. /lib matches other system daemons like udev.
(In reply to comment #28) > no offense, but please discuss this on gentoo-dev ml. sorry, I'm not subscribed. Would be glad if people willing to discuss it there CC my email: barbieri@gmail.com
Udev 174 is now in the tree, but it is p.masked until we have a default solution for the issue of separate /usr and /var partitions, as documented here. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken We are working on having a default minimal initramfs in the tree, and as soon as we have that this version will be unmasked.
Thank you!
*** Bug 398595 has been marked as a duplicate of this bug. ***
OK, this is slowly geting riddiculous. http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=b618e9957b2bd8a4484368620b71ca16fef0c9e6 """ remove udev-acl Udev-acl will be part of a future ConsoleKit release. On systemd systems, advanced ConsoleKit and udev-acl functionality are natively provided by systemd. """ Wouldn't be that big deal, if not that even if such change in consolekit is planned, it's not in the official repo yet. Shall it land today, it's still done a bit backwards, IMHO.
...also a minor note about 181 ebuild: while --with-{pci,usb}-ids-path=<value> is still valid, as both helpers have become builtin commands, "$(use_enable hwdb)" became redundant.
182 is now in ~arch so I'm closing this one off
