If there are no blocking bugs, this version of sys-fs/udev should go stable.
Changing bug to udev-135-r4, as that has two more bugs fixed. dri permissions Bug #255841. and docs cleanup Bug #255955.
@Arch teams: Please stable udev-135-r4. It got first commited as udev-135-r3 on 2008/12/27. Then some small changes were done and it got bumped to udev-135-r4 for last bugfix on 2008/01/24. The changes to udev-135-r3 are: * Fix init-script in vserver (for openrc, so not stable relevant) Bug 253105 * No longer test /lib/librc.so as that may fail on multilib (also not stable relevant for now) Bug 252493 * Fix doc still using udevinfo command. Bug 255955 * Fix dri permission regression. Bug 255841
Stable for HPPA.
Stable on alpha.
we need newer sys-apps/hal and sys-fs/cryptsetup stable: # emerge -pv udev These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-fs/udev-135-r4 [124-r1] USE="(-selinux)" 0 kB [blocks B ] >=sys-fs/udev-125 (">=sys-fs/udev-125" is blocking sys-apps/hal-0.5.11-r1) [blocks B ] >=sys-fs/udev-126 (">=sys-fs/udev-126" is blocking sys-fs/cryptsetup-1.0.5-r1) Total: 1 package (1 upgrade), Size of downloads: 0 kB Conflict: 2 blocks (2 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('ebuild', '/', 'sys-fs/udev-135-r4', 'merge') pulled in by udev sys-fs/udev required by ('installed', '/', 'sys-fs/cryptsetup-1.0.5-r1', 'nomerge') virtual/dev-manager required by world (and 4 more) ('installed', '/', 'sys-apps/hal-0.5.11-r1', 'nomerge') pulled in by sys-apps/hal required by ('installed', '/', 'xfce-extra/thunar-volman-0.2.0', 'nomerge') sys-apps/hal required by ('installed', '/', 'media-gfx/gimp-2.4.6', 'nomerge') >=sys-apps/hal-0.5.7.1 required by ('installed', '/', 'xfce-extra/exo-0.3.4-r2', 'nomerge') (and 6 more)
alpha/hppa: please revert your stable keywording until those two deps are stabled, please, as this is breaking your current stable tree
(In reply to comment #6) > alpha/hppa: please revert your stable keywording until those two deps are > stabled, please, as this is breaking your current stable tree Both done.
*poke* 135 is working great on my thinkpad.
See dependency bug. udev cant go stable before setup-1.0.6-r2.
About Bug #266290: Either we backport the fixes, or we should directly head forward to stable udev-141.
maybe better to stable udev-141?
Perhaps it's best to close this one, and track something newer (141) ? I think bug 259253 is pretty dead.
(In reply to comment #12) > Perhaps it's best to close this one, and track something newer (141) ? Why creating a new bug and not just updating this one, the dependencies of this bug are still fine and must nevertheless be resolved? I changed it to now point to udev-141. Please add any new blockers if you have more of them. > I think bug 259253 is pretty dead. > No idea what they do, but they seem to refuse backporting the patch to get a stable version that can work with newer udev.
any news with 259253?
I guess we go forward now. Please look at bug 259253 first. Thanks all.
x86 stable
Hi there. On x86 I hit this message /etc/init.d/udev restart * The udev init-script is written for baselayout-2! * Please do not use it with baselayout-1!. sys-fs/udev-141 sys-apps/baselayout-1.12.11.1 What I should to do?
(In reply to comment #18) > Hi there. > On x86 I hit this message > > /etc/init.d/udev restart > * The udev init-script is written for baselayout-2! > * Please do not use it with baselayout-1!. > As this init-script tells you, it is not to be used if baselayout-1 is installed. So why do you want to restart udevd by hand? The ebuild already does it at update. And if you did change some rules, restarting udevd will not change anything. You need to trigger the relevant events to make the rules be reprocessed. Have a look at "udevadm trigger".
Hi, (In reply to comment #19) > (In reply to comment #18) > > Hi there. > > On x86 I hit this message > > > > /etc/init.d/udev restart > > * The udev init-script is written for baselayout-2! > > * Please do not use it with baselayout-1!. Me too. > > > As this init-script tells you, it is not to be used if baselayout-1 is > installed. Because I misread the message "restarting udevd now." Since I am really, really used to restarting things from /etc/init.d I now feel fearsome that my system won't boot the next time. > So why do you want to restart udevd by hand? The ebuild already does it at > update. > And if you did change some rules, restarting udevd will not change anything. > You need to trigger the relevant events to make the rules be reprocessed. > Have a look at "udevadm trigger". Thanks for the hint. Anyway I somehow feel that stabilizing a udev-ebuild which -in a way- depends on baselayout-2 is not a good move. (But then, what do I know about Gentoo development. ;-) Just my 2ct. Cheers, Stefan
(In reply to comment #20) > > Anyway I somehow feel that stabilizing a udev-ebuild which -in a way- depends > on baselayout-2 is not a good move. (But then, what do I know about Gentoo > development. ;-) Well, it does not depend on baselayout-2. udev generally depends on any baselayout version to be started at all (sounds logical). And udev does support all baselayout-versions around. It just contains different code-pathes for them. for baselayout-1 it uses so called rc-addons - small files executed by a shell: /lib/rcscripts/addons/udev-{start,stop}.sh for baselayout-2 it uses init-scripts /etc/init.d/{udev,udev-mount,udev-dev-tarball} So far udev is perfectly usable on baselayout-1. Nobody needs to directly run these init-scripts (behind the scenes both pathes above share code but that is not relevant here).
26 Jun 2009; Thomas Anderson <gentoofan23@gentoo.org> udev-141.ebuild: stable amd64, bug 254616
Please, read bug 275527. In udev-124-r2 there was more than 20 rules. Now i have only 8 with vmware's one. These eight rules replace all the previous 20? For example 40-video.rule is missing.
ppc stable
arm/ia64/m68k/s390/sh/sparc stable
ppc64 done
all arches done, closing
