| Summary: | HAL 0.5.7.1 and KDE 3.5.4 media devices not work [SOLUTION] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fabio Erculiani <lxnay> |
| Component: | [OLD] KDE | Assignee: | Project Gentopia <gentopia> |
| Status: | VERIFIED UPSTREAM | ||
| Severity: | major | CC: | decibels.2862, kde |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Have a look at /usr/portage/sys-apps/hal/files/hal-0.5.7-ignored-volumes.patch It is probably the cause of your problems. yes, it is... That should be considered a bug anyway since the hal-dbus policy says that if the user is in plugdev group, he can mount/umount volumes (using pmount?). *** Bug 146913 has been marked as a duplicate of this bug. *** sorry for double posting but this morning bugzilla had some problems. The solution proposed is incorrect and whatever statement this "K. Ottens" guy wants to make is also incorrect. The issue stems from the fact that some items were removed in 0.5.7. The "tweak" or better yet hack you're doing is incorrect and is really only causing a rescan because of removed functionality in HAL. The replacement functionality is suppose to be providered by a mounter or the DE. However no DE (Gnome or KDE) provide this and no mounter does. HAL PolicyKit will provide this but it is no where near ready to being packaged and it only supports 0.5.8 and higher. 0.5.7 was just a broken release entirely. Either I'm going to have a long day of generating a LOT of patches and fixes for 0.5.7 or we're going to back to 0.5.5.1. I'll have to decide. This bug also affects KDE-3.5.2. I haven't seen my CDROM/DVD in media:/ for a long time. The hack proposed by Fabio makes it work again. Now waiting for an officially sanctioned fix. Or is it safe to revert back to hald 0.5.5.1-r3? You can't use HAL 0.5.5.1 with KDE 3.5.4... KDE HAL management won't work at all. (In reply to comment #5) > The solution proposed is incorrect and whatever statement this "K. Ottens" guy > wants to make is also incorrect. Actually, "this K. Ottens guy" is right, and it is you who has no clue what you are talking about. I just spent the last couple of days poking around my system, trying to debug why it's not auto-detecting when I insert my USB drive anymore, only to find out that some idiot has disabled a crucial bit of HAL functionality in the ebuild! I was just about to post a bug report about this, when to my dismay I find that you have known about this breakage for 2 months now, yet you haven't lifted a finger to correct it (commenting out a single line in the ebuild fixes it). Fact #1: With the default storage-methods.fdi, HAL detects and generates events for USB drives just fine. Fact #2: Your changes to this file completely break detection and handling of USB drives. Conclusion: You broke the HAL package. The rest is irrelevant mumbo-jumbo. I _completely_ agree with Ivan. Complaints? Come, become developers and get everything done your way (often after 1 am....). Just for you to notice, my 20storage-methods.fdi looks exactly as the unpatched one ( true in the last line), and my HAL works like a charm (automounting both cd and usb drives) with kde-3.5.5. (that's unlikely to be less patched than your obsolete 3.5.4) That ugly fix maybe can help your system but it could also break lots of "other" systems. I would call it a workaround for broken machines, but if HAL is now done "that way" there's a reason. Please remember that gentoo should work not only on your machine. Matteo, you don't have understood the point. It's not HAL nor KDE that does not work. Everything works but, just try to change the .fdi file as stated in my #1, restart hald, relogin into your KDE and see media:/. If you have any _non_removable_ partition, it will show up. Without that change (that you call "hack", but I don't understand why a policy could be a hack...), you won't see any of those. So, if you followed me, without that "hack" you cannot VIEW nor MOUNT any physical HD partition !!!! Understood now? If you don't have time to keep up the work on gentoo, just leave, no? I shouldered don't leave this bug opened for two months... because yes, it's a bug. Is that INVALID? No, I don't think so. Uhm if your non removable partitions are in fstab, this was a bug that has been fixed as of 3.5.5 in KDE upstream. no, KDE 3.5.5 is still affected. Well, if we have to be precise, it is fixed in *our* and almost every other KDE 3.5.5.. not vanilla, I admit. But the patch is there for us. And yes, I can see my non-removable partitions (the one I have) just fine. It does not work with LVM logical volumes, but that's a restriction of HAL afaics. no it's not KDE nor GNOME nor anything else, the problem is in HAL. Anyway, I get the same behavior with KDE 3.5.5. (In reply to comment #11) > If you don't have time to keep up the work on gentoo, just leave, no? I > shouldered don't leave this bug opened for two months... because yes, it's a > bug. Is that INVALID? No, I don't think so. Please, next time refrain from doing such comments against our fellow developers. If you don't like the way things are done, you can always use your own overlay. BTW, it works like a charm in here. we are here to fix things in gentoo, and not fork stuff in other overlays. it's a shame to not fix this directly in gentoo, anyway... (In reply to comment #17) > we are here to fix things in gentoo, and not fork stuff in other overlays. We're here to fix things that do not work as they should, not to take it on devs. man, this bug had 2 months... Could I be a little bit upset perhaps? ;) Oh, good gods.... is media:/ supposed to shows non-removable partitions? I mean, do you need to use media:/ to mount fixed partitions??? Is plugdev group supposed to mount every fixed hd/partition in a system? (and, if them are public, why not mount them at startup?) I was believing that "plugdev" was a self-explanatory name..... "plug devices". I don't think that it includes fixed partitions, am I wrong? ok, you could be right for the "plugdev" name. But ya know, people want things that just work, and if you setup a system with the right /etc/pmount.allow entries, the right HAL policy, you would be able to provide to your erm... clients (in my case) a fully working point and mount. pmount can mount everything if certain criterias are met (man pmount?). I only disagree with the fact that media:/ (but even GNOME is affected since that's a HAL setup) does not show not removable devices anymore. Really curious why you're screwing around with pmount settings and what not. This bug was essentially left as was by me because I have most of my users on Gentoo w/ KDE at the office and I don't do anything special other then "emerge kde" with the dbus and hal USE flags enabled. And I have all my users in the plugdev group and it just works. Ivan and Fabio, all of my employees stick a CD in the drive and it works. A USB drive? It works. So don't bother me with your "you have no idea what you're talking about" crap. Provide some code show the exact failures, don't just ramble on about how we're broken. If you're relying on /media or as you're calling it media:// from KDE to mount fixed partitions, then you're just PLAIN WRONG. http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT in fact, I am not talking about removable devices at all :P So let me get this correct Fabio, your distro has an issue and just because you're packaging Gentoo it's got to be our fault? Then the complaint you have is that media (removable) devices aren't working but the devices you are trying to work are fixed devices which are defined in /etc/fstab? And you and Ivan want ME to get a clue? (In reply to comment #25) > Then the complaint you have is that media (removable) devices aren't working > but the devices you are trying to work are fixed devices which are defined in > /etc/fstab? > > And you and Ivan want ME to get a clue? Please don't mix the issues. My comment was *specifically* about REMOVABLE USB DRIVES not showing up when plugged in. When I commented out your "ignore-devices" patch and rebuilt HAL, they started showing up properly. I didn't change anything else. Why or how this worked, I don't care. Fact is, the upstream fdi file worked great for my removable USB drive, and your patch broke it somehow. In fact, I just removed temporarily my overlaid HAL ebuild, and reverted to yours just to check, and the removable devices disappeared again! So, that nails it for me, the HAL ebuild is broken. What more "clue" do you need? I'm telling you what the REALITY is on my machine, and I tell you the exact steps that fixed the issue (commenting out a single "epatch" line), yet you ask me to provide exact source lines of the error and what not... yeah, right. The solution is obvious to even the most clueless, yet you refuse to do it for two months: just comment out that patch if there is no urgent need for it, until whatever is causing this problem is fixed. I never complained about fixed (non-removable) drives, nor do I care if they are displayed in media:/ or not. Ivan: Show some code. Show some proof. Other then your rants you've got nothing. I've got 20 installs that say otherwise. As well as numerous other devs that also say otherwise. Otherwise, go use another distro. I only complain about how non-removable devices are now managed. That's it. Why not show them and let manage the policy by pmount and pmount.allow file ? Cause you don't need a media:// to use them, you just need to use fstab (eventually you can also use ~/.kde/autostart if you want to mount them as user). The mounting/showing of fixed partitions is not supposed for plugdev group (just think at swap or boot partitions, or private ones in multiusers environments, etc.etc.) With this in mind, media:// works flawlessy, showing only the mounted fixed partitions and not the unmounted ones. To Ivan: sorry, removable drives are working 100% for anyone,even Fabio.If you encountered this issue just on one system (or more systems with the same config files) it can be an issue in config files or a permission issue. (that's true anytime 99,9% of the users have something working flawlessy and one/two get issues, this means the issue is not in the source or ebuild). Please use forum for these kind of issues.(yes, I think forum should be a little "barrier" to give us more time to concentrate on real ebuilds/sources issues). Why in nearly 2007 do I still need to poke with fstab to see my partitions? It would be a shame, others distros do that by default. Just show them up, and let the administrator decide to give to their users the use permissions. And why not proposing upstream a patch to pmount to query if a partition is mountable and in case, show that up just like Diego P. told me? No admin may want users to be allowed to mount partitions like swap or boot, and you need to modify fstab to make them "root-only". Other than that, if it's not changed, even removable drives still need fstab lines to be handled fine. What's the issue with adding a line to a file you already need to fill? Also please say which distro is "doin that by default" whitout using fstab, I'm curious to poke. quote: No admin may want users to be allowed to mount partitions like swap or boot --- who said that? An admin can use /etc/pmount.allow to manage mount permissions and even the plugdev group which pmount relies on. (In reply to comment #27) > Ivan: Show some code. Show some proof. Other then your rants you've got > nothing. I've got 20 installs that say otherwise. As well as numerous other > devs that also say otherwise. That is among the most idiotic responses I ever heard. Are you seriously saying that you have never encountered a bug that only shows up in some particular configurations? If it works for 20 people then it must work for EVERYBODY without fail? I have shown you the proof: rebuilding the HAL ebuild with and without one of your patches produced radically different results, without changing the rest of the system. A removable USB drive, that is not in /etc/fstab (nor has ever been), simply stops being detected with your ebuild. So, you are pushing a purely cosmetic patch that removes fixed drives from GUI managers, even though it creates serious problems with removable drives for some users, e.g. me. If I knew the exact source line causing the error, do you think I would even bother with you? I would have sent a patch to the upstream developers directly. But as things stand, the upstream code works perfectly, it is your changes that break things, so I am here. If your patch is so good and problem-free, don't you think it would have been incorporated by upstream already? It's not in their latest git tree. > Otherwise, go use another distro. Great attitude... whenever you are wrong just shoot the messenger and close your eyes. Why should I? Why don't you go away and be a packager of another distro, if you are unable to deal with simple bug reports? Anyway, truth is, that's exactly what I have been contemplating this last week (not only because of this, but also other bugs in Gentoo lately). I will probably investigate alternative distros when I again have a bigger chunk of free time. It would certainly be better than wasting it on problems caused by stubborn and incompetent packagers, when the upstream software works just fine. So keep your little half-assed patches and good riddance. (In reply to comment #29) > To Ivan: sorry, removable drives are working 100% for anyone,even Fabio.If you > encountered this issue just on one system (or more systems with the same > config files) it can be an issue in config files or a permission issue. > (that's true anytime 99,9% of the users have something working flawlessy > and one/two get issues, this means the issue is not in the source or ebuild). > Please use forum for these kind of issues.(yes, I think forum should be a > little "barrier" to give us more time to concentrate on real ebuilds/sources > issues). Well, I did spend two days digging around the system, and I managed to distill the issue into a simple 100% reproducible test case (reproducible on my machine, that is): Comment out this line "epatch "${FILESDIR}"/${PN}-0.5.7-ignored-volumes.patch" and rebuild, everything works fine. Uncomment it again and rebuild, things break. Simple as that, no permissions or anything else is being changed between these rebuilds of hal-0.5.7.1-r1.ebuild. But did anybody even bother looking at this? Did anybody ask for some additional info from my machine that might be useful in debugging? All I got is some arrogant attitudes claiming that the bug simply does not exist, and that I must be hallucinating. I'm sure you can imagine how that might be a tad irritating. Keeping your heads in the sand is a good way to allienate users... and without users, what would be the point of Gentoo? Clearly I couldn't careless about supporting you. Know why? Your attitude. We've lost enough time with this. Move along. (In reply to comment #35) > Clearly I couldn't careless about supporting you. Know why? Your attitude. Your decision to not support *anyone* was made over two months ago. I had nothing to do with it. Bye. Oh, I'll continue with my bug submission march :P Closing. |
Since I've upgraded to KDE 3.5.4, the media devices handling didn't work completely. I was only able to see removable media under media:/ kioslave. Yesterday I was talking with Kevin Ottens about that and I've found, thanks to his help, that's a sort of policy misconfiguration in: /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi code: <!-- Here follow volumes we specifically want to ignore - it is the --> <!-- responsibility of software higher in the stack (e.g. gnome-vfs) --> <!-- amd mount programs (e.g. Mount() on HAL) to respect volume.ignore --> <merge key="volume.ignore" type="bool">false</merge> <match key="@block.storage_device:storage.hotpluggable" bool="false"> <match key="@block.storage_device:storage.removable" bool="false"> <merge key="volume.ignore" type="bool">true</merge> I have changed the last line above from "true" to "false". Restarted hald and kded, and magically the partitions show up. K. Ottens replied with: "I'd say it's a bug because of a wild patch applied without thinking about the consequences. ;-) For reference latest unpatched hal from fd.o repository doesn't have this rule... it really looks your distro devels made something wrong while patching this file." It worked with KDE <=3.5.3 because of a bug in it, but this bug has been fixed in KDE 3.5.4.