Time for a new thread.
I have been beating myself up hard today troubleshooting some of the TDEHW quirks I have been reporting.
I believe we have two separate problems.
One is the "eject -T dvd" command stops working as soon as a disk is inserted. From what I gather online, this is a known bug and there is a patch. I haven't looked for the patch or tested.
I verified the "eject -T" problem exists in Xfce 4.10 and KDE 4.8.5 too. Thus, "eject -T" is broken one way or another.
The second problem is permissions. As root I tested Safely Remove with USB flash drives and Eject with an optical disk. The icons disappear for both, and the optical disk physically ejects. Although after the disk ejects the "eject -T dvd" command stops working until after I use the drive eject button. Then the "eject -T" command works.
I can't figure out what the permissions problem might be. I don't see any special suid permissions on any of the TDE bin files or the eject command. Could the TDEHW code cause this behavior?
Could pmount be causing this behavior? I never have used pmount before so I am a complete noob.
Darrell
The second problem is permissions. As root I tested Safely Remove with USB flash drives and Eject with an optical disk. The icons disappear for both, and the optical disk physically ejects. Although after the disk ejects the "eject -T dvd" command stops working until after I use the drive eject button. Then the "eject -T" command works.
I can't figure out what the permissions problem might be. I don't see any special suid permissions on any of the TDE bin files or the eject command. Could the TDEHW code cause this behavior?
Could pmount be causing this behavior? I never have used pmount before so I am a complete noob.
Group assignments for my normal user account:
disk lp wheel floppy audio video cdrom plugdev power scanner users
Darrell
I have been beating myself up hard today troubleshooting some of the TDEHW quirks I have been reporting.
I believe we have two separate problems.
One is the "eject -T dvd" command stops working as soon as a disk is inserted. From what I gather online, this is a known bug and there is a patch. I haven't looked for the patch or tested.
I verified the "eject -T" problem exists in Xfce 4.10 and KDE 4.8.5 too. Thus, "eject -T" is broken one way or another.
The second problem is permissions. As root I tested Safely Remove with USB flash drives and Eject with an optical disk. The icons disappear for both, and the optical disk physically ejects. Although after the disk ejects the "eject -T dvd" command stops working until after I use the drive eject button. Then the "eject -T" command works.
I can't figure out what the permissions problem might be. I don't see any special suid permissions on any of the TDE bin files or the eject command. Could the TDEHW code cause this behavior?
Could pmount be causing this behavior? I never have used pmount before so I am a complete noob.
I found a patch that resolves the "eject -T" problem:
https://bugs.launchpad.net/ubuntu/+source/eject/+bug/91873
The patch works.
There remains a permissions problem. As normal user, from the command line, kdeeject fails but sudo kdeeject succeeds. With the former the icons won't disappear and with the latter they do.
Darrell
I have been beating myself up hard today troubleshooting some of the TDEHW quirks I have been reporting.
I believe we have two separate problems.
One is the "eject -T dvd" command stops working as soon as a disk is inserted. From what I gather online, this is a known bug and there is a patch. I haven't looked for the patch or tested.
I verified the "eject -T" problem exists in Xfce 4.10 and KDE 4.8.5 too. Thus, "eject -T" is broken one way or another.
The second problem is permissions. As root I tested Safely Remove with USB flash drives and Eject with an optical disk. The icons disappear for both, and the optical disk physically ejects. Although after the disk ejects the "eject -T dvd" command stops working until after I use the drive eject button. Then the "eject -T" command works.
I can't figure out what the permissions problem might be. I don't see any special suid permissions on any of the TDE bin files or the eject command. Could the TDEHW code cause this behavior?
Could pmount be causing this behavior? I never have used pmount before so I am a complete noob.
I found a patch that resolves the "eject -T" problem:
https://bugs.launchpad.net/ubuntu/+source/eject/+bug/91873
The patch works.
There remains a permissions problem. As normal user, from the command line, kdeeject fails but sudo kdeeject succeeds. With the former the icons won't disappear and with the latter they do.
Darrell
This should be a system configuration problem. From this thread: http://ubuntu.5.n6.nabble.com/eject-not-working-unless-I-m-root-td4550555.ht...
"Your user should be in the group "cdrom" in order to eject stuff."
I suspect that your user also needs to be in a group for removable media to be able to eject USB drives.
Tim
This should be a system configuration problem. From this thread: http://ubuntu.5.n6.nabble.com/eject-not-working-unless-I-m-root-td4550555.ht...
"Your user should be in the group "cdrom" in order to eject stuff."
I suspect that your user also needs to be in a group for removable media to be able to eject USB drives.
From a previous post:
Group assignments for my normal user account:
disk lp wheel floppy audio video cdrom plugdev power scanner users
No problems as non-root in Xfce 4.10 and KDE 4.8.5. I never had problems before and group assignments are the same.
pmount, pumount, pmount-hal are installed 750 suid.
Darrell
This should be a system configuration problem. From this thread: http://ubuntu.5.n6.nabble.com/eject-not-working-unless-I-m-root-td4550555.ht...
"Your user should be in the group "cdrom" in order to eject stuff."
I suspect that your user also needs to be in a group for removable media to be able to eject USB drives.
From a previous post:
Group assignments for my normal user account:
disk lp wheel floppy audio video cdrom plugdev power scanner users
No problems as non-root in Xfce 4.10 and KDE 4.8.5. I never had problems before and group assignments are the same.
pmount, pumount, pmount-hal are installed 750 suid.
Darrell
Ah, OK. Could be another eject bug then.
I wonder if I need to add rudimentary eject hooks for udisks2 to the TDEHW library due to the plurality of bugs and problems in the HAL-less eject command, though this would not be for some time into the future as I have more pressing matters to deal with.
Tim
Ah, OK. Could be another eject bug then.
I wonder if I need to add rudimentary eject hooks for udisks2 to the TDEHW library due to the plurality of bugs and problems in the HAL-less eject command, though this would not be for some time into the future as I have more pressing matters to deal with.
Yes, Slackware 14 is using udisks/udisks2.
I'll look around the web to learn whether there are any HAL-less complaints about eject.
Were we going to add Serghei's udisks patches from OpenSuse 3.5.10?
Just to check, do you do anything special with pmount or /etc/pmount.allow? (I'm trying to learn more about pmount.)
Darrell
Ah, OK. Could be another eject bug then.
I wonder if I need to add rudimentary eject hooks for udisks2 to the TDEHW library due to the plurality of bugs and problems in the HAL-less eject command, though this would not be for some time into the future as I have more pressing matters to deal with.
Yes, Slackware 14 is using udisks/udisks2.
I'll look around the web to learn whether there are any HAL-less complaints about eject.
Were we going to add Serghei's udisks patches from OpenSuse 3.5.10?
It's not high on my priority list right now as Serghei has mentioned that it still needs some work.
Just to check, do you do anything special with pmount or /etc/pmount.allow? (I'm trying to learn more about pmount.)
Nope.
Tim
I wonder if I need to add rudimentary eject hooks for udisks2 to the TDEHW library due to the plurality of bugs and problems in the HAL-less eject command, though this would not be for some time into the future as I have more pressing matters to deal with.
For your TDEHW to do list:
I rebuilt pmount with --enable-hal=no. No difference.
In case eject had some HAL dependencies, I installed hal and started the HAL daemon. No difference.
I rebuilt eject with a slew of patches from Arch. At least one of the patches makes a big difference with ejecting CDs/DVDs.
The only trick I have found thus far to remove the USB icons from the desktop as non-root is to set /usr/bin/eject setuid.
I notice some functions in halbackend.cpp regarding privileges. Perhaps something similar is needed for TDEHW?
Darrell
On Mon, 3 Sep 2012 17:12:00 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I wonder if I need to add rudimentary eject hooks for udisks2 to the TDEHW library due to the plurality of bugs and problems in the HAL-less eject command, though this would not be for some time into the future as I have more pressing matters to deal with.
For your TDEHW to do list:
I rebuilt pmount with --enable-hal=no. No difference.
In case eject had some HAL dependencies, I installed hal and started the HAL daemon. No difference.
I rebuilt eject with a slew of patches from Arch. At least one of the patches makes a big difference with ejecting CDs/DVDs.
eject has no dependencies to speak of--I have neither HAL nor udisks on my system, and eject works just fine, with or without -T. I suspect your problem is the same as the one described in this bug report: https://bugs.gentoo.org/show_bug.cgi?id=261880
The patch attached to the report originated with SuSE and has presumably circulated in some format to most other distros, but has never been merged by upstream. (Actually, I'm not sure that eject still *has* a viable upstream. I can't find any evidence of recent activity on the project's Sourceforge page.) So: eject bug, not a problem for most distros, and not TDEHW's fault.
On Mon, Sep 3, 2012 at 6:41 PM, Darrell Anderson humanreadable@yahoo.comwrote:
Time for a new thread.
I have been beating myself up hard today troubleshooting some of the TDEHW quirks I have been reporting.
I believe we have two separate problems.
One is the "eject -T dvd" command stops working as soon as a disk is inserted. From what I gather online, this is a known bug and there is a patch. I haven't looked for the patch or tested.
I verified the "eject -T" problem exists in Xfce 4.10 and KDE 4.8.5 too. Thus, "eject -T" is broken one way or another.
The second problem is permissions. As root I tested Safely Remove with USB flash drives and Eject with an optical disk. The icons disappear for both, and the optical disk physically ejects. Although after the disk ejects the "eject -T dvd" command stops working until after I use the drive eject button. Then the "eject -T" command works.
I can't figure out what the permissions problem might be. I don't see any special suid permissions on any of the TDE bin files or the eject command. Could the TDEHW code cause this behavior?
Could pmount be causing this behavior? I never have used pmount before so I am a complete noob.
Is there any validation process in place before releases? It seems to me that even tough it is important to have functionality like this working perfectly, current hardware is moving away from optical drives and this may not be tested extensively before a release.
Thoughts?
Best regards, Tiago
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Is there any validation process in place before releases? It seems to me that even tough it is important to have functionality like this working perfectly, current hardware is moving away from optical drives and this may not be tested extensively before a release.
To my knowledge we have no validation or quality assurance plan before a release. I have raised the topic several times (check the archives). Once upon a time I started a wiki article to create a basic testing check list.
http://www.trinitydesktop.org/wiki/bin/view/Developers/PackageBuildQA
David has raised such topics too. Mostly, because of the small number of people involved, the discussions fizzle rapidly. :(
With that said, recently we tested TDEHWLIB in depth. A summary of issues I found are available in bug report 850, Comment 4.
http://bugs.trinitydesktop.org/show_bug.cgi?id=850
Please add to the bug report should you perform any testing.
I can get TDEHW to work quite well but only when I set /usr/bin/eject suid. I haven't figured out why that is needed or why HAL based systems do not need that. So yes, more work is needed before announcing TDEHW in any official manner, but I believe the new hardware layer is more advanced that most non GIT users would know.
Darrell
-
Darrell Anderson -
E. Liddell -
Tiago Marques -
Timothy Pearson