[arch-dev-public] Risky business: udev upgrade

Aaron Griffin

28 Aug 2008 28 Aug '08

2:22 a.m.

So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land. Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do. Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with. Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz An x86_64 build of trunk would be appreciated. Two things to note: a) rules have moved out of /etc, they are now located in /lib/udev/rules.d/ (eek!) b) The cdrom-rules.patch we had appears no longer applicable. Can anyone confirm this doesn't break anything. Cheers, I will be back in a few hours to play around some more, Aaron

Show replies by date

Allan McRae

28 Aug 28 Aug

3:22 a.m.

Aaron Griffin wrote:

...

So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land.

Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do.

Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with.

Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about

i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz <snip>

Briefly tested here. Boot-up went fine. My !pcspkr entry in the MODULES array of /etc/rc.conf was ignored. Also, I had no (wireless) internet. Didn't look into this too far but the iwl3945 module had loaded. I have need for internet today so I gave up there for the time being. Allan

Aaron Griffin

6:09 a.m.

On Wed, Aug 27, 2008 at 10:22 PM, Allan McRae wrote:

...

My !pcspkr entry in the MODULES array of /etc/rc.conf was ignored.

Looks like modprobe is still called directly in /lib/udev/rules.d/80-drivers.rules I will fix that. It should call load-modules. Fixing and re-uploading.

...

Also, I had no (wireless) internet. Didn't look into this too far but the iwl3945 module had loaded. I have need for internet today so I gave up there for the time being.

Odd... did you also upgrade the kernel or anything? Doesn't sound like a udev issue if the module is loaded. For the record, my internet has been flakey recently too, but I think that's related to me dropping ndiswrapper for ath5k. ndiswrapper seems to give me superior signal strength, but now that the atheros drivers are viable for this laptop, I think I'd rather use that... Anyway, I re-uploaded. Bumped the pkgrel, so the new i686 package is here: https://dev.archlinux.org/~aaron/udev-126-2-i686.pkg.tar.gz

Tobias Powalowski

6:49 a.m.

Am Donnerstag 28 August 2008 schrieb Aaron Griffin:

...

On Wed, Aug 27, 2008 at 10:22 PM, Allan McRae wrote:

...
My !pcspkr entry in the MODULES array of /etc/rc.conf was ignored.

Looks like modprobe is still called directly in /lib/udev/rules.d/80-drivers.rules I will fix that. It should call load-modules. Fixing and re-uploading.

...
Also, I had no (wireless) internet. Didn't look into this too far but the iwl3945 module had loaded. I have need for internet today so I gave up there for the time being.

Odd... did you also upgrade the kernel or anything? Doesn't sound like a udev issue if the module is loaded.

For the record, my internet has been flakey recently too, but I think that's related to me dropping ndiswrapper for ath5k. ndiswrapper seems to give me superior signal strength, but now that the atheros drivers are viable for this laptop, I think I'd rather use that...

Anyway, I re-uploaded. Bumped the pkgrel, so the new i686 package is here:

https://dev.archlinux.org/~aaron/udev-126-2-i686.pkg.tar.gz hey there, will look at your changes this weekend. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Aaron Griffin

6:27 a.m.

On Wed, Aug 27, 2008 at 10:22 PM, Allan McRae wrote:

...

My !pcspkr entry in the MODULES array of /etc/rc.conf was ignored.

Looks like modprobe is still called directly in /lib/udev/rules.d/80-drivers.rules I will fix that. It should call load-modules. Fixing and re-uploading.

...

Also, I had no (wireless) internet. Didn't look into this too far but the iwl3945 module had loaded. I have need for internet today so I gave up there for the time being.

Allan McRae

7:20 a.m.

Aaron Griffin wrote:

...

On Wed, Aug 27, 2008 at 10:22 PM, Allan McRae wrote:

...
My !pcspkr entry in the MODULES array of /etc/rc.conf was ignored.

Looks like modprobe is still called directly in /lib/udev/rules.d/80-drivers.rules I will fix that. It should call load-modules. Fixing and re-uploading.

Works fine now.

...

...
Also, I had no (wireless) internet. Didn't look into this too far but the iwl3945 module had loaded. I have need for internet today so I gave up there for the time being.

Odd... did you also upgrade the kernel or anything? Doesn't sound like a udev issue if the module is loaded.

I did not change anything else at the same time.

...

For the record, my internet has been flakey recently too, but I think that's related to me dropping ndiswrapper for ath5k. ndiswrapper seems to give me superior signal strength, but now that the atheros drivers are viable for this laptop, I think I'd rather use that...

Further investigation shows it is some kind of issue with gnome-network-manager as I couldn't even connect via ethernet that way. All is fine (at least for ethernet) if I don't use gnome-network-manager. I will do further investigation later tonight. Allan

James Rayner

10:24 a.m.

On Wed, Aug 27, 2008 at 7:22 PM, Aaron Griffin wrote:

...

So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land.

Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do.

Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with.

Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about

i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz An x86_64 build of trunk would be appreciated.

Here's -1, you havn't committed -2 http://dev.archlinux.org/~james/udev-126-1-x86_64.pkg.tar.gz Will look over it and test when I get a chance. James

Aaron Griffin

3:38 p.m.

On Thu, Aug 28, 2008 at 5:24 AM, James Rayner wrote:

...

On Wed, Aug 27, 2008 at 7:22 PM, Aaron Griffin wrote:

...
So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land.

Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do.

Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with.

Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about

i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz An x86_64 build of trunk would be appreciated.

Here's -1, you havn't committed -2 http://dev.archlinux.org/~james/udev-126-1-x86_64.pkg.tar.gz

Will look over it and test when I get a chance.

Doh... committed now

Aaron Griffin

29 Aug 29 Aug

9:15 p.m.

On Thu, Aug 28, 2008 at 10:38 AM, Aaron Griffin wrote:

...

On Thu, Aug 28, 2008 at 5:24 AM, James Rayner wrote:

...
On Wed, Aug 27, 2008 at 7:22 PM, Aaron Griffin wrote:

...
So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land.

Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do.

Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with.

Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about

i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz An x86_64 build of trunk would be appreciated.

Here's -1, you havn't committed -2 http://dev.archlinux.org/~james/udev-126-1-x86_64.pkg.tar.gz

Will look over it and test when I get a chance.

Doh... committed now

Just a bump here. I'd like to throw this in testing if someone else can verify I didn't make machines unbootable. When this hit's testing, it will require a rebuild of packages which contain udev rules (move from /etc/udev/rules.d/ to /lib/udev/rules.d/). When I move to testing, I will make a todo list for these packages

Eric Belanger

10:44 p.m.

On Fri, 29 Aug 2008, Aaron Griffin wrote:

...

On Thu, Aug 28, 2008 at 10:38 AM, Aaron Griffin wrote:

...
On Thu, Aug 28, 2008 at 5:24 AM, James Rayner wrote:

...
On Wed, Aug 27, 2008 at 7:22 PM, Aaron Griffin wrote:

...
So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land.

Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do.

Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with.

Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about

i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz An x86_64 build of trunk would be appreciated.

Here's -1, you havn't committed -2 http://dev.archlinux.org/~james/udev-126-1-x86_64.pkg.tar.gz

Will look over it and test when I get a chance.

Doh... committed now

Just a bump here. I'd like to throw this in testing if someone else can verify I didn't make machines unbootable. When this hit's testing, it will require a rebuild of packages which contain udev rules (move from /etc/udev/rules.d/ to /lib/udev/rules.d/). When I move to testing, I will make a todo list for these packages

I tried udev-126-2-i686.pkg.tar.gz. My machine still booted fine. The only problem that I noticed is that the /dev/sg0 device that it creates for my external USB DVD/CD-RW doesn't have the write permission for the optical group: $ ls -l /dev/sg0 crw-r----- 1 root optical 21, 0 2008-08-29 18:42 /dev/sg0 The permissions for sr0 are correct though: $ ls -l /dev/sr0 brw-rw---- 1 root optical 11, 0 2008-08-29 18:42 /dev/sr0 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Eric Belanger

11:19 p.m.

On Fri, 29 Aug 2008, Eric Belanger wrote:

...

On Fri, 29 Aug 2008, Aaron Griffin wrote:

...
On Thu, Aug 28, 2008 at 10:38 AM, Aaron Griffin wrote:

...
On Thu, Aug 28, 2008 at 5:24 AM, James Rayner wrote:

...
On Wed, Aug 27, 2008 at 7:22 PM, Aaron Griffin wrote:

...
So I've let udev stagnate for a while, mostly because I'm a fool and real life has given me a lack of time for anything serious in Arch-land.

Anyway, I've rebuilt udev 126 (we're on 119, eek!) and made what changes I thought ideal. I would love to stick with strictly vanilla rules, but some of them don't work properly for us, so we still have a tiny bit of patching to do.

Now... I'm looking for a helping hand here. I've built the package the best I can, and installed it, but I have not rebooted. I am going to commit these changes to svn trunk, and upload a package for anyone to play with.

Please, if you have a little time, take a look at all of it - the rules, everything, give it a once over and see if we can eliminate any of the patching done to the stock rules. Some of it (i.e. the addition of some GROUP directives) needs to stay, but others I am unsure about

i686 package here: https://dev.archlinux.org/~aaron/udev-126-1-i686.pkg.tar.gz An x86_64 build of trunk would be appreciated.

Here's -1, you havn't committed -2 http://dev.archlinux.org/~james/udev-126-1-x86_64.pkg.tar.gz

Will look over it and test when I get a chance.

Doh... committed now

Just a bump here. I'd like to throw this in testing if someone else can verify I didn't make machines unbootable. When this hit's testing, it will require a rebuild of packages which contain udev rules (move from /etc/udev/rules.d/ to /lib/udev/rules.d/). When I move to testing, I will make a todo list for these packages

I tried udev-126-2-i686.pkg.tar.gz. My machine still booted fine. The only problem that I noticed is that the /dev/sg0 device that it creates for my external USB DVD/CD-RW doesn't have the write permission for the optical group: $ ls -l /dev/sg0 crw-r----- 1 root optical 21, 0 2008-08-29 18:42 /dev/sg0

The permissions for sr0 are correct though: $ ls -l /dev/sr0 brw-rw---- 1 root optical 11, 0 2008-08-29 18:42 /dev/sr0

Also, /etc/start_udev refers to /sbin/udevtrigger and /sbin/udevsettle. These binaries are missing in udev-126-2. If they were removed on purpose, then start_udev should be updated. And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location? BTW, udev 127 is out (or will be out soon). Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Aaron Griffin

11:45 p.m.

On Fri, Aug 29, 2008 at 6:19 PM, Eric Belanger wrote:

...

Also, /etc/start_udev refers to /sbin/udevtrigger and /sbin/udevsettle. These binaries are missing in udev-126-2. If they were removed on purpose, then start_udev should be updated.

start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine. Is everyone ok with removing it?

...

And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Whoopsy.

...

BTW, udev 127 is out (or will be out soon).

Rebuilding and committing then

Roman Kyrylych

30 Aug 30 Aug

8:35 a.m.

2008/8/30 Aaron Griffin :

...

On Fri, Aug 29, 2008 at 6:19 PM, Eric Belanger wrote:

...
Also, /etc/start_udev refers to /sbin/udevtrigger and /sbin/udevsettle. These binaries are missing in udev-126-2. If they were removed on purpose, then start_udev should be updated.

start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

I think yes. We cannot support old initscripts forever. -- Roman Kyrylych (Роман Кирилич)

Xavier

9:28 a.m.

On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...

start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331 This is just a safety against foolish people.

Aaron Griffin

10:19 p.m.

On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...

On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally. Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...

Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

Additionally, do we need the migrate-udev script anymore? I sincerely hope not. Any qualms with killing THAT off too?

Tobias Powalowski

10:23 p.m.

Am Sonntag 31 August 2008 schrieb Aaron Griffin:

...

On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

Additionally, do we need the migrate-udev script anymore? I sincerely hope not. Any qualms with killing THAT off too?

migrate udev creates device nodes which might be necessary, i wouldn't kill it. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Aaron Griffin

10:40 p.m.

On Sat, Aug 30, 2008 at 5:23 PM, Tobias Powalowski wrote:

...

Am Sonntag 31 August 2008 schrieb Aaron Griffin:

...
On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

Additionally, do we need the migrate-udev script anymore? I sincerely hope not. Any qualms with killing THAT off too?

migrate udev creates device nodes which might be necessary, i wouldn't kill it.

It creates device nodes that the installer also creates. It only appears useful if someone is installing improperly from an existing system or from an older ISO. And, hell, if we *really* want to make sure these devices exist, we should add checks to rc.sysinit to create them before starting udev, rather than relying on a script to do so.

Aaron Griffin

31 Aug 31 Aug

2:15 a.m.

On Sat, Aug 30, 2008 at 5:40 PM, Aaron Griffin wrote:

...

On Sat, Aug 30, 2008 at 5:23 PM, Tobias Powalowski wrote:

...
Am Sonntag 31 August 2008 schrieb Aaron Griffin:

...
On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

Additionally, do we need the migrate-udev script anymore? I sincerely hope not. Any qualms with killing THAT off too?

migrate udev creates device nodes which might be necessary, i wouldn't kill it.

It creates device nodes that the installer also creates. It only appears useful if someone is installing improperly from an existing system or from an older ISO. And, hell, if we *really* want to make sure these devices exist, we should add checks to rc.sysinit to create them before starting udev, rather than relying on a script to do so.

Done http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=119b8df1fb12... Now migrate_udev is safe to remove. This patch makes more sense anyway, and covers all our bases without forcing the user to run a script if they screw up.

Tobias Powalowski

8:44 a.m.

Am Sonntag 31 August 2008 schrieb Aaron Griffin:

...

On Sat, Aug 30, 2008 at 5:40 PM, Aaron Griffin wrote:

...
On Sat, Aug 30, 2008 at 5:23 PM, Tobias Powalowski wrote:

...
Am Sonntag 31 August 2008 schrieb Aaron Griffin:

...
On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin

wrote:

...
...
...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

Additionally, do we need the migrate-udev script anymore? I sincerely hope not. Any qualms with killing THAT off too?

migrate udev creates device nodes which might be necessary, i wouldn't kill it.

It creates device nodes that the installer also creates. It only appears useful if someone is installing improperly from an existing system or from an older ISO. And, hell, if we *really* want to make sure these devices exist, we should add checks to rc.sysinit to create them before starting udev, rather than relying on a script to do so.

Done http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=119b8df1fb1 258231750309f01e747e72f382493

Now migrate_udev is safe to remove. This patch makes more sense anyway, and covers all our bases without forcing the user to run a script if they screw up. yes this patch is fine :) greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Eric Belanger

6 Sep 6 Sep

6:37 p.m.

On Sat, 30 Aug 2008, Aaron Griffin wrote:

...

On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

I do ship a custom readme for qingy. At first, I was pointing people to the wiki article I had created. Then, I got somewhat uneasy about having to rely on a document that anyone can edit (qingy is a login manager so it's somewhat critical) even though I was receiving email notification everytime the article was edited. Therefore, I put the wiki info in a readme. In the case of udev, if you want to rely on the wiki, someone should watch the article edits carefully.

...

Additionally, do we need the migrate-udev script anymore? I sincerely hope not. Any qualms with killing THAT off too?

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Aaron Griffin

9:07 p.m.

On Sat, Sep 6, 2008 at 1:37 PM, Eric Belanger wrote:

...

On Sat, 30 Aug 2008, Aaron Griffin wrote:

...
On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

I do ship a custom readme for qingy. At first, I was pointing people to the wiki article I had created. Then, I got somewhat uneasy about having to rely on a document that anyone can edit (qingy is a login manager so it's somewhat critical) even though I was receiving email notification everytime the article was edited. Therefore, I put the wiki info in a readme. In the case of udev, if you want to rely on the wiki, someone should watch the article edits carefully.

Well, here's the point I keep trying to make - nothing in udev, besides a few rules, is arch-specific. The man pages are fully suitable for all commands. Personally, I don't see this document as critical at all. It's just a "oh, here's some more info" that seems to make more sense in a wiki page.

Eric Belanger

9:50 p.m.

On Sat, 6 Sep 2008, Aaron Griffin wrote:

...

On Sat, Sep 6, 2008 at 1:37 PM, Eric Belanger wrote:

...
On Sat, 30 Aug 2008, Aaron Griffin wrote:

...
On Sat, Aug 30, 2008 at 4:28 AM, Xavier wrote:

...
On Sat, Aug 30, 2008 at 1:45 AM, Aaron Griffin wrote:

...
start_udev is still there because people were jackasses and didn't update initscripts when they updated udev.... or something.. I can't remember the issue, but it was people being foolish and expecting their systems to boot fine.

Is everyone ok with removing it?

A suggestion was made 3 times to simply add a conflict line : http://bugs.archlinux.org/task/11112#comment31331

This is just a safety against foolish people.

Added locally.

Copied from arch-general (whoops, replied to the wrong list) regarding the readme file we ship with the udev package

...
Actually, I think we should remove this file. Reloading rules and all that is covered by the man pages and any arch specific documentation should be added to a wiki page so anyone can edit it.

Any issues with removing this? We don't ship custom readme's with any other packages that I know of.

I do ship a custom readme for qingy. At first, I was pointing people to the wiki article I had created. Then, I got somewhat uneasy about having to rely on a document that anyone can edit (qingy is a login manager so it's somewhat critical) even though I was receiving email notification everytime the article was edited. Therefore, I put the wiki info in a readme. In the case of udev, if you want to rely on the wiki, someone should watch the article edits carefully.

Well, here's the point I keep trying to make - nothing in udev, besides a few rules, is arch-specific. The man pages are fully suitable for all commands. Personally, I don't see this document as critical at all. It's just a "oh, here's some more info" that seems to make more sense in a wiki page.

I understand that part. BTW, I might even get rid of the readme in qingy as I believe I came up with it because qingy doesn't have man pages, only info pages that were previously removed from the package. As to the udev readme, I'm fine about removing it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Xavier

29 Aug 29 Aug

11:03 p.m.

On Fri, Aug 29, 2008 at 11:15 PM, Aaron Griffin wrote:

...

Just a bump here. I'd like to throw this in testing if someone else can verify I didn't make machines unbootable. When this hit's testing, it will require a rebuild of packages which contain udev rules (move from /etc/udev/rules.d/ to /lib/udev/rules.d/). When I move to testing, I will make a todo list for these packages

Well, I am not even sure this is a problem with udev or if I did something wrong, but the "auto-mount feature" of gnome apparently stopped working after this upgrade. But the system boot fines, the external usb disk is still properly detected is dmesg, the correct devices are created and with the proper permissions : brw-rw---- 1 root storage 8, 16 août 30 00:32 /dev/sdb brw-rw---- 1 root storage 8, 17 août 30 00:32 /dev/sdb1 And I can still mount it manually just fine. Just the automatic mount stopped working. So I have no idea what the problem is. Ahah, just as I finished writing this, I saw Eric reported exactly the same. So this is just a confirmation from my side.

Aaron Griffin

11:22 p.m.

On Fri, Aug 29, 2008 at 5:44 PM, Eric Belanger wrote:

...

I tried udev-126-2-i686.pkg.tar.gz. My machine still booted fine. The only problem that I noticed is that the /dev/sg0 device that it creates for my external USB DVD/CD-RW doesn't have the write permission for the optical group: $ ls -l /dev/sg0 crw-r----- 1 root optical 21, 0 2008-08-29 18:42 /dev/sg0

The permissions for sr0 are correct though: $ ls -l /dev/sr0 brw-rw---- 1 root optical 11, 0 2008-08-29 18:42 /dev/sr0

This should be easy to fix, just a matter of adding it to the patch On Fri, Aug 29, 2008 at 6:03 PM, Xavier wrote:

...

Well, I am not even sure this is a problem with udev or if I did something wrong, but the "auto-mount feature" of gnome apparently stopped working after this upgrade. But the system boot fines, the external usb disk is still properly detected is dmesg, the correct devices are created and with the proper permissions : brw-rw---- 1 root storage 8, 16 août 30 00:32 /dev/sdb brw-rw---- 1 root storage 8, 17 août 30 00:32 /dev/sdb1

And I can still mount it manually just fine. Just the automatic mount stopped working.

Hmm, the "storage" group seems a tad odd.... shouldn't it be "disk" ?

Tobias Powalowski

30 Aug 30 Aug

6:16 a.m.

...

On Fri, Aug 29, 2008 at 5:44 PM, Eric Belanger

wrote:

...
I tried udev-126-2-i686.pkg.tar.gz. My machine still booted fine. The only problem that I noticed is that the /dev/sg0 device that it creates for my external USB DVD/CD-RW doesn't have the write permission for the optical group: $ ls -l /dev/sg0 crw-r----- 1 root optical 21, 0 2008-08-29 18:42 /dev/sg0

The permissions for sr0 are correct though: $ ls -l /dev/sr0 brw-rw---- 1 root optical 11, 0 2008-08-29 18:42 /dev/sr0

This should be easy to fix, just a matter of adding it to the patch

On Fri, Aug 29, 2008 at 6:03 PM, Xavier wrote:

...
Well, I am not even sure this is a problem with udev or if I did something wrong, but the "auto-mount feature" of gnome apparently stopped working after this upgrade. But the system boot fines, the external usb disk is still properly detected is dmesg, the correct devices are created and with the proper permissions : brw-rw---- 1 root storage 8, 16 août 30 00:32 /dev/sdb brw-rw---- 1 root storage 8, 17 août 30 00:32 /dev/sdb1

And I can still mount it manually just fine. Just the automatic mount stopped working.

Hmm, the "storage" group seems a tad odd.... shouldn't it be "disk" ?

Am Samstag 30 August 2008 schrieb Aaron Griffin: the storage group was fro removable disks, example are portable usbdisks or something like that greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Xavier

9:23 a.m.

On Sat, Aug 30, 2008 at 1:03 AM, Xavier wrote:

...

Ahah, just as I finished writing this, I saw Eric reported exactly the same. So this is just a confirmation from my side.

The only thing in common with what Eric said is that the system booted fine and some problems happened after... Whatever, it was too late I guess..

Xavier

31 Aug 31 Aug

4:53 p.m.

On Sat, Aug 30, 2008 at 1:03 AM, Xavier wrote:

...

Well, I am not even sure this is a problem with udev or if I did something wrong, but the "auto-mount feature" of gnome apparently stopped working after this upgrade. But the system boot fines, the external usb disk is still properly detected is dmesg, the correct devices are created and with the proper permissions : brw-rw---- 1 root storage 8, 16 août 30 00:32 /dev/sdb brw-rw---- 1 root storage 8, 17 août 30 00:32 /dev/sdb1

And I can still mount it manually just fine. Just the automatic mount stopped working. So I have no idea what the problem is.

As I saw there : http://lists.freedesktop.org/archives/hal/2006-August/005777.html The event chain goes like this : kernel -> udev -> hal -> dbus -> g-v-m -> dbus -> hal -> kernel Since we are only changing udev, I thought the problem should be in udev->hal communication, and that hal needs to be updated somehow. But I have not found how to debug hal, to be sure hal is indeed the problem and that it does not see the udev event. I also checked if there were any hal git commits related to udev, and found a recent one : http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=f6af40c1e7ea54e69eb2d259... But I re-introduced the udevinfo symlink (ln -s /sbin/udevadm /usr/bin/udevinfo) and it did not help. I can reproduce this with the 126 version made by Aaron, the 127 version made by Tobias, and my own nearly vanilla 127 version (on this note, I don't know why Arch has to change so many things from vanilla).

Tobias Powalowski

5:03 p.m.

Am Sonntag 31 August 2008 schrieb Xavier:

...

On Sat, Aug 30, 2008 at 1:03 AM, Xavier wrote:

...
Well, I am not even sure this is a problem with udev or if I did something wrong, but the "auto-mount feature" of gnome apparently stopped working after this upgrade. But the system boot fines, the external usb disk is still properly detected is dmesg, the correct devices are created and with the proper permissions : brw-rw---- 1 root storage 8, 16 août 30 00:32 /dev/sdb brw-rw---- 1 root storage 8, 17 août 30 00:32 /dev/sdb1

And I can still mount it manually just fine. Just the automatic mount stopped working. So I have no idea what the problem is.

As I saw there : http://lists.freedesktop.org/archives/hal/2006-August/005777.html The event chain goes like this : kernel -> udev -> hal -> dbus -> g-v-m -> dbus -> hal -> kernel Since we are only changing udev, I thought the problem should be in udev->hal communication, and that hal needs to be updated somehow. But I have not found how to debug hal, to be sure hal is indeed the problem and that it does not see the udev event.

I also checked if there were any hal git commits related to udev, and found a recent one : http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=f6af40c1e7ea54e69eb2d25 9d91dd212065d5f6e But I re-introduced the udevinfo symlink (ln -s /sbin/udevadm /usr/bin/udevinfo) and it did not help.

I can reproduce this with the 126 version made by Aaron, the 127 version made by Tobias, and my own nearly vanilla 127 version (on this note, I don't know why Arch has to change so many things from vanilla). Hi we don't change much it's just the module loading that is changed to fit to arch module loading procedure, the rest is vanilla as udev ships.

greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Aaron Griffin

4 Sep 4 Sep

12:35 a.m.

Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing. Firstly: On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...

...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc Secondly, I want to remove the readme file from the udev package. Does anyone have a problem with this? At the very least I moved the install to /usr/share/udev/ but I don't think we need to ship a readme file for any of this - udev does have some comprehensive man pages. The rest should go in the wiki. Please take a look at trunk if you get a chance. I want to push this to testing tonight or tomorrow.

Thomas Bächler

8:05 a.m.

Aaron Griffin schrieb:

...

Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing.

I hope I can make the changes to load-modules.sh soon to make blacklisting work in a reasonable way. See http://bugs.archlinux.org/task/10972#comment32200

...

Firstly:

On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...
...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location? Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc

That depends on how you define "stock rules". Usually, the files in /etc/ are there for the user to be changed. However, our rules are not there to be changed, that's what the user creates his own rule files for. Now I don't see that we should make any difference between rules shipped upstream by udev and rules added by Arch. My opinion here is that /lib is for the distribution and the package manager and /etc is for the user. Therefore, Arch's rules should be in the same place as udev's upstream rules.

Aaron Griffin

3:51 p.m.

On Thu, Sep 4, 2008 at 3:05 AM, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...
Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing.

I hope I can make the changes to load-modules.sh soon to make blacklisting work in a reasonable way. See http://bugs.archlinux.org/task/10972#comment32200

...
Firstly:

On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...
...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc

That depends on how you define "stock rules". Usually, the files in /etc/ are there for the user to be changed. However, our rules are not there to be changed, that's what the user creates his own rule files for.

Now I don't see that we should make any difference between rules shipped upstream by udev and rules added by Arch. My opinion here is that /lib is for the distribution and the package manager and /etc is for the user. Therefore, Arch's rules should be in the same place as udev's upstream rules.

It's a decent point, but I think the *intent* of the udev devs is to put only their rules in /lib, and everyone else's goes to /etc.

Dusty Phillips

4:06 p.m.

2008/9/4 Aaron Griffin :

...

On Thu, Sep 4, 2008 at 3:05 AM, Thomas Bächler wrote:

...
Aaron Griffin schrieb:

...
Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing.

I hope I can make the changes to load-modules.sh soon to make blacklisting work in a reasonable way. See http://bugs.archlinux.org/task/10972#comment32200

...
Firstly:

On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...
...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc

That depends on how you define "stock rules". Usually, the files in /etc/ are there for the user to be changed. However, our rules are not there to be changed, that's what the user creates his own rule files for.

Now I don't see that we should make any difference between rules shipped upstream by udev and rules added by Arch. My opinion here is that /lib is for the distribution and the package manager and /etc is for the user. Therefore, Arch's rules should be in the same place as udev's upstream rules.

It's a decent point, but I think the *intent* of the udev devs is to put only their rules in /lib, and everyone else's goes to /etc.

You don't do much customization on behalf of the distro, but I think Archers like to know what few customizations have been done for them by the Arch developers (so they have the option to undo them even though hardly anybody actually does) I think it makes more sense to put the arch rules in /etc; what you're basically saying to the user then is "we have done this for you but you can change it". If you put it in /lib, you're saying "we have done this for you and we suggest you don't touch it". My $.02 (which is losing value as our CAD dollar continues to drop. *sigh*) Dusty

Aaron Griffin

6:25 p.m.

On Thu, Sep 4, 2008 at 11:06 AM, Dusty Phillips wrote:

...

2008/9/4 Aaron Griffin :

...
On Thu, Sep 4, 2008 at 3:05 AM, Thomas Bächler wrote:

...
Aaron Griffin schrieb:

...
Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing.

I hope I can make the changes to load-modules.sh soon to make blacklisting work in a reasonable way. See http://bugs.archlinux.org/task/10972#comment32200

...
Firstly:

On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...
...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc

That depends on how you define "stock rules". Usually, the files in /etc/ are there for the user to be changed. However, our rules are not there to be changed, that's what the user creates his own rule files for.

Now I don't see that we should make any difference between rules shipped upstream by udev and rules added by Arch. My opinion here is that /lib is for the distribution and the package manager and /etc is for the user. Therefore, Arch's rules should be in the same place as udev's upstream rules.

It's a decent point, but I think the *intent* of the udev devs is to put only their rules in /lib, and everyone else's goes to /etc.

You don't do much customization on behalf of the distro, but I think Archers like to know what few customizations have been done for them by the Arch developers (so they have the option to undo them even though hardly anybody actually does) I think it makes more sense to put the arch rules in /etc; what you're basically saying to the user then is "we have done this for you but you can change it". If you put it in /lib, you're saying "we have done this for you and we suggest you don't touch it".

My $.02 (which is losing value as our CAD dollar continues to drop. *sigh*)

I like this explaination a little better than "our rules are stock too", but I'm still undecided. I'd be interested in hearing some other opinions here... Dan, you usually have good input... opinion?

Dan McGee

6:45 p.m.

On Thu, Sep 4, 2008 at 1:25 PM, Aaron Griffin wrote:

...

I like this explaination a little better than "our rules are stock too", but I'm still undecided. I'd be interested in hearing some other opinions here... Dan, you usually have good input... opinion?

Without completely understanding udev as a whole, but understanding system customization, I can say this. If this file is meant to be modified by end users, it should definitely go in /etc. The current file there says this at the top, however: "do not edit this file, it will be overwritten on update". So what is the case here? If this comment is wrong, it should get killed. If this file is meant to be edited, it should certainly be in the package's backup array. Going back further on this thread, can anyone explain what this Arch-specific ruleset does that the upstream ruleset doesn't already do? It seems like their rules have gotten much more complete. -Dan

Aaron Griffin

6:58 p.m.

On Thu, Sep 4, 2008 at 1:45 PM, Dan McGee wrote:

...

On Thu, Sep 4, 2008 at 1:25 PM, Aaron Griffin wrote:

...
I like this explaination a little better than "our rules are stock too", but I'm still undecided. I'd be interested in hearing some other opinions here... Dan, you usually have good input... opinion?

Without completely understanding udev as a whole, but understanding system customization, I can say this. If this file is meant to be modified by end users, it should definitely go in /etc. The current file there says this at the top, however: "do not edit this file, it will be overwritten on update". So what is the case here? If this comment is wrong, it should get killed. If this file is meant to be edited, it should certainly be in the package's backup array.

...

Going back further on this thread, can anyone explain what this Arch-specific ruleset does that the upstream ruleset doesn't already do? It seems like their rules have gotten much more complete.

I didn't look through the custom rules too much. I looked at the patch that we apply, and most of it is to allow group access to certain devices that, for some reason, are not in the stock rules. i.e. some device has MODE="640" and we switch it to "660" and the like. As for the custom rules... I can run through those and figure out what we need. Can anyone that uses more complex devices (I just have usb mice, and an external harddrive) try the vanilla ruleset to see what we're missing?

Tobias Powalowski

5 p.m.

Am Donnerstag 04 September 2008 schrieb Thomas Bächler:

...

Aaron Griffin schrieb:

...
Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing.

I hope I can make the changes to load-modules.sh soon to make blacklisting work in a reasonable way. See http://bugs.archlinux.org/task/10972#comment32200

...
Firstly:

On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...
...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc

That depends on how you define "stock rules". Usually, the files in /etc/ are there for the user to be changed. However, our rules are not there to be changed, that's what the user creates his own rule files for.

Now I don't see that we should make any difference between rules shipped upstream by udev and rules added by Arch. My opinion here is that /lib is for the distribution and the package manager and /etc is for the user. Therefore, Arch's rules should be in the same place as udev's upstream rules. Hi I agree with Thomas here and if the user does want to change our default rules, copying our file to /etc will override it then. In short from my point the rules in the package should go to /lib instead to /etc.

greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Eric Belanger

6 Sep 6 Sep

6:41 p.m.

On Wed, 3 Sep 2008, Aaron Griffin wrote:

...

Some followups here. tpowa went ahead and handled a few of the changes I was discussing here, but there are a few more before I push this to testing.

Firstly:

On Sun, Aug 31, 2008 at 3:14 PM, Damjan Georgievski wrote:

...
...
And, 51-arch.rules is being installed in /etc/udev/rules.d. Shouldn't it go in the new location?

Probably not, the idea about rules in /lib/udev/ is that those are the stock rules as shipped with udev. And any distro or system rules would go to /etc/udev/rules.d/ (anything that's not stock).

There's some info here: http://lwn.net/Articles/293689/

So I've moved 81-arch.rules back to /etc. There should be no need to recompile applications, as those rules should still go to /etc

Secondly, I want to remove the readme file from the udev package. Does anyone have a problem with this? At the very least I moved the install to /usr/share/udev/ but I don't think we need to ship a readme file for any of this - udev does have some comprehensive man pages. The rest should go in the wiki.

Please take a look at trunk if you get a chance. I want to push this to testing tonight or tomorrow.

I just built the current trunk on i686. Everything works fine. The system boots fine and the permission problem for my external CD drive that I mentionned earlier are fixed. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5719

Age (days ago)

5728

Last active (days ago)

List overview

Download

36 comments

10 participants

participants (10)

Aaron Griffin
Allan McRae
Dan McGee
Dusty Phillips
Eric Belanger
James Rayner
Roman Kyrylych
Thomas Bächler
Tobias Powalowski
Xavier