Well,

• as you could have noticed, these patches are already included in the udev package for Slackware 14.1,
• so you could have asked that question for udev/Slackware vs udev/LFS,
• but this thread's topic is not to compare Slackware with LFS,
• other than that, just look at the patches and make you own opinion.

I think you just gzipped the files twice: file.diff.gz.gz and file.tar.gz.gz

If those patches were for udev classic you shouldn't have to use them with eudev since its a newer version.

No, I didn't.

But maybe you used Firefox (or a similar browser) to download the files, and it does that:

• Using the command lftp -c "mirror http://slint.fr/misc/eudev" I get for instance 60-cdrom_id.rules.diff.gz with the good size (397 bytes).
• But when I download the same file with Firefox I get a file with a size of 520 bytes that is actually re-gzipped.

More accurately after a little research, it does so when the configuration preference network.http.accept-encoding has the default value "gzip, deflate" (see here). But If I unset it (deleting the value in about:config) the file is downloaded as-is.

It can be the expected behavior by Firefox developers (or is it an Apache setting? After all I'm not sure about that), still it looks like a bug to my eyes

PS Not sure that I understand the §14.3 Accept-Enconding of the HTTP/1.1 specification, but if for a an (X)HTML page is is customary to serve gzipped content that will be inflated by the client (as that saves bandwidth), deflating or inflating all kinds of gzipped content is unwise IMHO.

PPS I won't advise you to change that default setting though as that makes some websites (e.g. google.com) unreadable. Better use a specialized file transfer client to download the files.

Oh, and thanks again for the report: it allowed me to discover this (from my point of view) weirdness.

2 members found this post helpful.

[duplicate post]

That's wrong. For instance in eudev as in udev, 60-cdrom-id.rules only makes one symlink /dev/cdrom => /dev/sr0, but not the useful other ones like /dev/dvd => /dev/sr0, hence the need for the patch 60-cdrom_id.rules.diff.

Your statement seems to imply that the purpose of patches 60-cdrom_id.rules.diff and rule_generator.diff was to fix bugs present in udev-182 (but not in eudev-1.6), but this is not the case.

I just upgraded the build material to udev-1.7 here.

eudev-1.7 is based on systemd/udev-213.

The changes 1.6 => 1.7 are listed there.

If you didn't install eudev-1.6, upgrade udev-182 => eudev-1.7 like this:

1 members found this post helpful.

Excellent work Didier. It may not be official by Patrick, but eudev is a suitable replacement for udev. Works good sir and thank ye' kindly.

It seems to work well. All my devices seem to be there in /dev.

I keep a copy of the old /dev/MAKEDEV script around just in case udev fails.

There is one quirk though with eudev.

Hald from Slackware 13.37 is installed and turned off. (chmod -x /etc/rc.hald )

At start up this new message repeats in the /var/log/messages:
As an experiment I tried to start hald but it seems to hang at startup.

Hald is not really needed on this machine but would like to make it work on another machine in order to watch Amazon streaming videos.

That's pretty normal as the package hal-0.5.14 shipped in Slackware 13.37 installs the file /lib/udev/rules.d/90-hal.rules that contains:but hald being not launched the daemon is nowhere to be found so the rule fails.

Did you rebuild the package for Slackware 14.1 or did you try to use as is the package for 13.37? In the latter case I'd have been surprised that it work. In fact I just don't know if HAL can work on Slackware 14.1, at least without some big changes.

I actually installed Hal-0.5.14 from the original package from Slackware 13.37.

The /etc/rc.d/rc.M script still starts up rc.hald if it is executable.

It does work and I am able to watch videos from Amazon using udev-182.
-----------------------------------------------------------------------

Old udev-182 code has a function in libudev-monitor.c called udev_monitor_new_from_socket() which apparently handles the 90-hal.rules "socket:" rule.

This apparently opens a socket with hald and feeds it everything.

New eudev-1.7, being built from the new systemd, does not have the old udev_monitor_new_from_socket() code...

So to make hald work with eudev, either hald needs to be patched to use a newer method (kernel netlink?) or eudev needs to be patched to use the older udev_monitor_new_from_socket().

Or some another possibility?

1 members found this post helpful.

So hald hangs at startup when ueudev-1.7 is installed but not when udev-182 is installed, right?

Then I'll inform eudev's developers, please let me know if you prefer to do it yourself. Anyhow, thanks for the report and for digging in the code.

There should be a patch for the makefile somewhere in this forum for building HAL on modern systems. It's one of my posts too and it's the SlackBuild. Maybe a rebuild may help?

Do you mean that building HAL on Slackware 14.1 fails? (I ask because I didn't try yet myself) If that's the case and you know of a patch to correct that, please provide a pointer.

Nonetheless, I'm afraid that's a different issue as comet.berkeley can run HAL against udev-182 (included in recent Slackware versions) but not against eudev-1.7.

Found it!

http://www.linuxquestions.org/questi...435/page2.html

Took a while to sift out, but here it is. Ponce had a small patch for it, so I added it in. Yeah, I'm not sure if I'll help with eudev but you never know.