Bug 352827 – stablereq: sys-fs/udev-164-r2

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andrew Brouwers 2011-01-26 13:55:33 UTC]

The stable version is getting a little stale again :)  I couldn't find any regression bugs that haven't been addressed, so it looks like a good candidate.

Reproducible: Always

[Comment 1 Matt Turner 2011-01-26 22:02:02 UTC]

Wrong box. :)

[Comment 2 Olivier Crete (RETIRED) 2011-04-12 05:35:26 UTC]

Any reason we don't get this version stable ? or any newer version for that matter ?

[Comment 3 Matthias Schwarzott 2011-04-12 13:07:26 UTC]

I suggest to go for stable udev-164-r2 after testing it, as that version is the first that will compile with linux-headers-2.6.38.

The installed files of udev-164 and udev-164-r1 should not differ (check?).
udev-164-r2 just modified noopenvz keyword in init-script and removed v4lv1 support.


*udev-164-r2 (19 Mar 2011)

  19 Mar 2011; Matthias Schwarzott <[e-mail]> +udev-164-r2.ebuild,
  +files/udev-164-remove-noopenvz.patch, +files/udev-164-remove-v4l1.patch:
  Enable udev inside OpenVZ containers, Bug #346885. Disable v4lv1, so that
  udev compiles with linux-headers-2.6.38, Bug #359407.

  06 Feb 2011; Mart Raudsepp <[e-mail]> udev-114.ebuild,
  udev-115-r1.ebuild:
  Drop to ~mips

*udev-164-r1 (12 Dec 2010)

  12 Dec 2010; Matthias Schwarzott <[e-mail]> +udev-164-r1.ebuild:
  Moved scripts from files to a tarball.

*udev-164 (30 Oct 2010)

  30 Oct 2010; Matthias Schwarzott <[e-mail]>
  +files/164/40-gentoo.rules, +files/164/90-network.rules,
  +files/164/shell-compat-KV.sh, +files/164/shell-compat-addon.sh,
  +files/164/udev.confd, +files/164/udev.initd,
  +files/164/udev-dev-tarball.initd, +files/164/udev-mount.initd,
  +files/164/udev-postmount.initd, +udev-164.ebuild,
  +files/164/udev-start.sh, +files/164/udev-stop.sh:
  Version bumped. Changed udev-postmount script to better check for ro
  filesystems and non bash shells. Bugs 342403, 326825. Remove /dev/loop if
  it is empty, Bug #338766.

[Comment 4 Andrew Brouwers 2011-05-02 17:31:55 UTC]

What about doing the latest 168 revision, which has a nice fix for the proper directory structure for udev ?

[Comment 5 Matthias Schwarzott 2011-05-09 05:13:08 UTC]

(In reply to comment #4)
> What about doing the latest 168 revision, which has a nice fix for the proper
> directory structure for udev ?

Please first stable udev-164-r2.

udev-168 first needs some improvements. Even support for proper directory structure is not yet done correctly. Then why stable this? we need then also a stable baselayout with support for /run.

[Comment 6 William Hubbs 2011-05-25 17:37:53 UTC]

Udev maintainers,

are we good to go with adding arch's here and getting this stable?

Thanks,

William

[Comment 7 Matthias Schwarzott 2011-05-29 18:48:49 UTC]

I think udev-164-r2 is ready for stable.

[Comment 8 Agostino Sarubbo 2011-05-30 12:55:22 UTC]

fails tests but works for me.

[Comment 9 Ian Delaney (RETIRED) 2011-05-30 15:07:22 UTC]

amd64:

was about to ditto Ago, but no.
this udev failed test, then found the silly system had somewhere somehow set python to 3.2!!!! eek.  Reset.

gentoo64 ~ # eselect python list
Available Python interpreters:
  [1]   python2.6
  [2]   python2.7 *

test set, emerged fine.

[Comment 10 Agostino Sarubbo 2011-05-30 21:53:53 UTC]

(In reply to comment #8)
> fails tests

submitted bug 369395

[Comment 11 Agostino Sarubbo 2011-05-31 11:19:59 UTC]

wait..checking better at startup i see:

After starting sshd [ok]
/etc/init.d/udev-postmount: line 28: /lib64/udev/move_tmp_persistent_rules.sh NO such file or directory.
And udev-postmount fails to start.

Checking in the dir there isn't this script...anyone can confirm this issue??

[Comment 12 Agostino Sarubbo 2011-05-31 13:56:59 UTC]

(In reply to comment #11)
> wait..checking better at startup i see:
> 
> After starting sshd [ok]
> /etc/init.d/udev-postmount: line 28: /lib64/udev/move_tmp_persistent_rules.sh
> NO such file or directory.
> And udev-postmount fails to start.
> 
> Checking in the dir there isn't this script...anyone can confirm this issue??

From other tests i can't reproduce this...probably was my bad with new config files( dispatch-conf )

[Comment 13 Tobias Klausmann (RETIRED) 2011-06-01 11:43:24 UTC]

Stable on alpha.

[Comment 14 Myckel Habets 2011-06-03 13:26:25 UTC]

Builds and runs fine on x86. Rdeps build fine. Please mark stable for x86.

[Comment 15 Ian Delaney (RETIRED) 2011-06-03 13:34:24 UTC]

amd64:

oddly,

/etc/init.d/udev-postmount: line 28: /lib64/udev/move_tmp_persistent_rules.sh: No such file or directory
 * ERROR: udev-postmount failed to start

I get this now.

[Comment 16 Matthias Schwarzott 2011-06-03 16:02:39 UTC]

(In reply to comment #15)
> amd64:
> 
> oddly,
> 
> /etc/init.d/udev-postmount: line 28: /lib64/udev/move_tmp_persistent_rules.sh:
> No such file or directory
>  * ERROR: udev-postmount failed to start
> 
very odd, /etc/init.d/udev-postmount does no longer call move_tmp_persistent_rules.sh, but this code was directly added into that init-script.

[Comment 17 Jeroen Roovers (RETIRED) 2011-06-05 18:24:21 UTC]

Stable for HPPA.

[Comment 18 Markos Chandras (RETIRED) 2011-06-08 17:28:18 UTC]

amd64 done. Thanks Agostino and Ian

[Comment 19 Markus Meier 2011-06-11 12:05:18 UTC]

arm stable

[Comment 20 Markus Meier 2011-06-14 19:23:29 UTC]

x86 stable, thanks Myckel

[Comment 21 Raúl Porcel (RETIRED) 2011-06-25 17:34:00 UTC]

ia64/m68k/sh/sparc stable

[Comment 22 Kacper Kowalik (Xarthisius) (RETIRED) 2011-07-09 17:22:59 UTC]

ppc/ppc64 stable

[Comment 23 Raúl Porcel (RETIRED) 2011-12-17 18:10:14 UTC]

s390 stable, closing