[SOLVED] [ANNOUNCE] eudev for Slackware 14.1 is available for testing purposes
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,750
Original Poster
Rep:
Quote:
Originally Posted by nobodino
I think you just gzipped the files twice: file.diff.gz.gz and file.tar.gz.gz
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.
Last edited by Didier Spaier; 05-22-2014 at 05:14 AM.
Reason: s/ftp/file transfer/ & (or is it an Apache setting ...) added
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,750
Original Poster
Rep:
Quote:
Originally Posted by ReaperX7
If those patches were for udev classic you shouldn't have to use them with eudev since its a newer version.
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.
Last edited by Didier Spaier; 05-21-2014 at 06:05 PM.
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:
Code:
kernel: <27>udevd[682]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
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.
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,750
Original Poster
Rep:
Quote:
Originally Posted by comet.berkeley
At start up this new message repeats in the /var/log/messages:
Code:
kernel: <27>udevd[682]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
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:
Code:
# pass all events to the HAL daemon
RUN+="socket:@/org/freedesktop/hal/udev_event"
but hald being not launched the daemon is nowhere to be found so the rule fails.
Quote:
As an experiment I tried to start hald but it seems to hang at startup.
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.
Last edited by Didier Spaier; 06-19-2014 at 10:38 PM.
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:
Code:
# pass all events to the HAL daemon
RUN+="socket:@/org/freedesktop/hal/udev_event"
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().
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?
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,750
Original Poster
Rep:
Quote:
Originally Posted by ReaperX7
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.
Last edited by Didier Spaier; 06-20-2014 at 02:50 AM.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.