Summary: | sys-fs/udev-149: stable request | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthias Schwarzott <zzam> |
Component: | New packages | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | artemkaa, axiator, tomka |
Priority: | High | Keywords: | STABLEREQ |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 273358 | ||
Bug Blocks: |
Description
Matthias Schwarzott
2010-01-31 21:40:33 UTC
@Archs: Please stable udev-149. It doesn't pass the testsuite on x86 successfully, but at least there is one error less than in the previous stable version (150 errors instead of 151 ;-). So that's no regression.... But the syntax of the rules has changed a bit and i had to adjust them manually.... net-misc/dahdi-2.2.0.2 places a rule with USER=asterisk value within dahdi.ruels, even when no user asterisk is avaiable. Furthermore it creates/overwrites xpp.rules with "BUS!=" and "SYSFS{}=" which are both deprecated syntaxes! -There's no stable version of that package at all! The stable media-libs/svgalib-1.9.25 creates 30-svgalib.rules with "NAME="%k"" which is also deprecated. The -r1 ~x86 version seems to be better in that regard, but there's no stablereq for it yet! The stable sys-cluster/vzctl-3.0.23-r2 creates 60-vzctl.rules with the same "NAME="%k"" problem. There's only a -9999 version otherwise, where i haven't looked into it. Probably there are even more of those packages that i simply haven't got installed........ (In reply to comment #2) > It doesn't pass the testsuite on x86 successfully, but at least there is one > error less than in the previous stable version (150 errors instead of 151 ;-). > So that's no regression.... > But the syntax of the rules has changed a bit and i had to adjust them > manually.... Matthias, is the deprecated use a real problem or is it just discouraged in this version? Otherwise we have to stabilise some more packages. (In reply to comment #2) > It doesn't pass the testsuite on x86 successfully, but at least there is one > error less than in the previous stable version (150 errors instead of 151 ;-). > So that's no regression.... well, maybe we must disable tests, as there seems no way to get them work with emerge > But the syntax of the rules has changed a bit and i had to adjust them > manually.... > > net-misc/dahdi-2.2.0.2 places a rule with USER=asterisk value within > dahdi.ruels, even when no user asterisk is avaiable. Furthermore it > creates/overwrites xpp.rules with "BUS!=" and "SYSFS{}=" which are both > deprecated syntaxes! -There's no stable version of that package at all! > > The stable media-libs/svgalib-1.9.25 creates 30-svgalib.rules with "NAME="%k"" > which is also deprecated. The -r1 ~x86 version seems to be better in that > regard, but there's no stablereq for it yet! > > The stable sys-cluster/vzctl-3.0.23-r2 creates 60-vzctl.rules with the same > "NAME="%k"" problem. There's only a -9999 version otherwise, where i haven't > looked into it. > > Probably there are even more of those packages that i simply haven't got > installed........ > All these issues are only warnings until now (udev-149 and also udev-151). So it will still should run as before, just be more verbose at udevd startup time. So these can be requested stable if ~arch is fixed, but does not need not to be fixed before updating to udev-149. A deprecation warning for using SYSFS{}= instead of ATTR{}= is also given for the following stable packages: sys-power/nut-2.4.1-r1 (/etc/udev/rules.d/70-nut-usbups.rules) dev-libs/openct-0.6.17 (/etc/udev/rules.d/70-openct.rules) x86 stable, thanks Thomas and Andreas Stable for HPPA. amd64/arm stable ppc64 done (In reply to comment #8) > amd64/arm stable > Udev-149 made my system unbootable (udevadm segfault during boot). Had to downgrade to udev-141. Now works fine. ia64/m68k/sparc stable ppc done s390 has version udev-164-r2 stable at the moment, and we have bug 399717 open for udev-171-r5 so removing from CC and closing the bug |