if you are interested in another tester for Slackware 14.0, and you can point me towards some up-to-date instructions on how to acquire and compile R14.0, I'd be happy to give it a try and report on any issues I find.
I no longer have my web site running, where originally I had that documentation and build scripts. If you are interested then contact me directly off list. I don't want to offer my build scripts publicly. My build scripts are complex because I am one of the main testers for Trinity. I need flexibility with how I compile and test. That said, I would enjoy seeing somebody reduce the build scripts to a point that theoretically could become slackbuilds.org compatible. :-)
As a side note, would be nice if there was somebody using 13.1 or 13.37 who could compile Trinity with HAL support to ensure that part of Trinity still functions as expected. I've gone full 14.0 here on all systems because that reduces my own time and overhead. Probably likewise for you. That said, if there were simpler build scripts (like the KDE3 scripts in Slackware 12.2) and a basic wiki (we could add such a page to the Trinity wiki), then others running 13.1 or 13.37 could test and enjoy Trinity too. :-)
There are other Slackers who want to run Trinity (browse the LQ forum), but there are no wiki pages or build scripts to make that more accessible for Slackers. :-( Possibly if we work together we could make that happen?
Darrell
On Tue, Aug 6, 2013 at 12:36 (-0500), Darrell Anderson wrote:
if you are interested in another tester for Slackware 14.0, and you can point me towards some up-to-date instructions on how to acquire and compile R14.0, I'd be happy to give it a try and report on any issues I find.
I no longer have my web site running, where originally I had that documentation and build scripts. If you are interested then contact me directly off list. I don't want to offer my build scripts publicly. My build scripts are complex because I am one of the main testers for Trinity. I need flexibility with how I compile and test. That said, I would enjoy seeing somebody reduce the build scripts to a point that theoretically could become slackbuilds.org compatible. :-)
As a side note, would be nice if there was somebody using 13.1 or 13.37 who could compile Trinity with HAL support to ensure that part of Trinity still functions as expected. I've gone full 14.0 here on all systems because that reduces my own time and overhead. Probably likewise for you. That said, if there were simpler build scripts (like the KDE3 scripts in Slackware 12.2) and a basic wiki (we could add such a page to the Trinity wiki), then others running 13.1 or 13.37 could test and enjoy Trinity too. :-)
There are other Slackers who want to run Trinity (browse the LQ forum), but there are no wiki pages or build scripts to make that more accessible for Slackers. :-( Possibly if we work together we could make that happen?
Darrell:
I will contact you off-list.
All:
I wonder about the benefit of integrating and testing HAL, as opposed to dropping it like a rock. Are any major distros still using it? I realize that it is not nice to abandon people who have to stick with old distros, but given the (apparently) small amount of people actively working on Trinity (thanks to all of you!), I'd suggest the bang for the buck is not worth it.
For me, the only reason I'd be using an older distro at this point would be if I wanted KDE 3. (I realize other peoples' mileage varies, but...) And if TDE worked on the newer version of my distro, I'd be a happy camper.
Cheers.
Jim
Le 06/08/2013 23:28, Jim Diamond a écrit :
All:
I wonder about the benefit of integrating and testing HAL, as opposed to dropping it like a rock. Are any major distros still using it? I realize that it is not nice to abandon people who have to stick with old distros, but given the (apparently) small amount of people actively working on Trinity (thanks to all of you!), I'd suggest the bang for the buck is not worth it.
For me, the only reason I'd be using an older distro at this point would be if I wanted KDE 3. (I realize other peoples' mileage varies, but...) And if TDE worked on the newer version of my distro, I'd be a happy camper.
Cheers.
Jim
Hello, The 2 current supported versions of RedHat Enterprise Linux (5 and 6) are both provided with a working (and mandatory) HAL daemon, but do not support udisks, upower, and other recent stuff ..
So, TDE R14 can provide the mount/umount features with the small pmount utility, but what about the power options ?
We must not neglect this kind of distributions, because precisely they ship with old versions of KDE3 / early KDE4 /old Gnome2, so Trinity is a very serious alternative.
The meaning of the original question was more precisely: If I build -DWITH_UPOWER=NO -DWITH_UDISKS=NO -DWITH_UDISKS2=NO , what won't work in the end ?
If there is no alternative, I will have to build HAL support for these distributions in R14. So please do not drop it now :-)
Francois
Dne st 7. srpna 2013 François Andriot napsal(a):
Le 06/08/2013 23:28, Jim Diamond a écrit :
All:
I wonder about the benefit of integrating and testing HAL, as opposed to dropping it like a rock. Are any major distros still using it? I realize that it is not nice to abandon people who have to stick with old distros, but given the (apparently) small amount of people actively working on Trinity (thanks to all of you!), I'd suggest the bang for the buck is not worth it.
For me, the only reason I'd be using an older distro at this point would be if I wanted KDE 3. (I realize other peoples' mileage varies, but...) And if TDE worked on the newer version of my distro, I'd be a happy camper.
Cheers.
JimHello, The 2 current supported versions of RedHat Enterprise Linux (5 and 6) are both provided with a working (and mandatory) HAL daemon, but do not support udisks, upower, and other recent stuff ..
So, TDE R14 can provide the mount/umount features with the small pmount utility, but what about the power options ?
We must not neglect this kind of distributions, because precisely they ship with old versions of KDE3 / early KDE4 /old Gnome2, so Trinity is a very serious alternative.
The meaning of the original question was more precisely: If I build -DWITH_UPOWER=NO -DWITH_UDISKS=NO -DWITH_UDISKS2=NO , what won't work in the end ?
If there is no alternative, I will have to build HAL support for these distributions in R14. So please do not drop it now :-)
Francois
It would be a solution if tdehw library could use hal as a backend?
Slavek --
2013/8/7 François Andriot francois.andriot@free.fr
Le 06/08/2013 23:28, Jim Diamond a écrit :
All:
I wonder about the benefit of integrating and testing HAL, as opposed to dropping it like a rock. Are any major distros still using it? I realize that it is not nice to abandon people who have to stick with old distros, but given the (apparently) small amount of people actively working on Trinity (thanks to all of you!), I'd suggest the bang for the buck is not worth it.
For me, the only reason I'd be using an older distro at this point would be if I wanted KDE 3. (I realize other peoples' mileage varies, but...) And if TDE worked on the newer version of my distro, I'd be a happy camper.
Cheers.
JimHello, The 2 current supported versions of RedHat Enterprise Linux (5 and 6) are both provided with a working (and mandatory) HAL daemon, but do not support udisks, upower, and other recent stuff ..
So, TDE R14 can provide the mount/umount features with the small pmount utility, but what about the power options ?
We must not neglect this kind of distributions, because precisely they ship with old versions of KDE3 / early KDE4 /old Gnome2, so Trinity is a very serious alternative.
The meaning of the original question was more precisely: If I build -DWITH_UPOWER=NO -DWITH_UDISKS=NO -DWITH_UDISKS2=NO , what won't work in the end ?
-DWITH_UDISKS[2] are used only for eject drives, the eject command is used as a fallback implementation. So if your user have permissions to do that with eject(1) you will loose noting. I can't say a lot about -DWITH_UPOWER, but if you switch it off you'll loose a suspend/hibernate functionality at least. Also will be affected the brightness and cpu governor control functionality.
If there is no alternative, I will have to build HAL support for these distributions in R14. So please do not drop it now :-)
Francois
Le 07/08/2013 20:35, Fat-Zer a écrit :
Hello,
The 2 current supported versions of RedHat Enterprise Linux (5 and 6) are both provided with a working (and mandatory) HAL daemon, but do not support udisks, upower, and other recent stuff .. So, TDE R14 can provide the mount/umount features with the small pmount utility, but what about the power options ? We must not neglect this kind of distributions, because precisely they ship with old versions of KDE3 / early KDE4 /old Gnome2, so Trinity is a very serious alternative. The meaning of the original question was more precisely: If I build -DWITH_UPOWER=NO -DWITH_UDISKS=NO -DWITH_UDISKS2=NO , what won't work in the end ?-DWITH_UDISKS[2] are used only for eject drives, the eject command is used as a fallback implementation. So if your user have permissions to do that with eject(1) you will loose noting.
Thanks for your precisions, I think you talk about "optical drives" ejection ? You're right, I think that 99% of the time, the connected user can eject them with eject command ... What about the mount feature ? Can't udisks(2) be used for that purpose, instead of pmount ? We do not have a "-DWITH_PMOUNT" option yet, but distributions are more likely to provide udisks than pmount ...
I can't say a lot about -DWITH_UPOWER, but if you switch it off you'll loose a suspend/hibernate functionality at least. Also will be affected the brightness and cpu governor control functionality.
That's what I'm afraid of. From what you know, can Upower be built on any (old) distribution, or does it require recent kernel/libraries/etc .. ?
If there is no alternative, I will have to build HAL support for these distributions in R14. So please do not drop it now :-)
If I remember what was said before, -DWITH_HAL=ON is incompatible with -DWITH_TDEHWLIBRARY=ON . Does that mean that, if I build with HAL and without hwlibrary, I will automatically lose upower, udisks and pmount support too ? I guess I will also need to stick with kpowersave and knetworkmanager8, instead of tdepowersave and tdepowermanager.
Francois
2013/8/7 François Andriot francois.andriot@free.fr
Thanks for your precisions, I think you talk about "optical drives" ejection ?
First of all about optical drives, but udisks provides Eject method for general drive class. I'm not sure what effect it will take if it would be called for e.g usb-stick.
You're right, I think that 99% of the time, the connected user can eject them with eject command ... What about the mount feature ? Can't udisks(2) be used for that purpose, instead of pmount ? We do not have a "-DWITH_PMOUNT" option yet, but distributions are more likely to provide udisks than pmount ...
I've told about this in the first answer on the thread. For now it won't be introduced before 14.1 because it will require API changes.
That's what I'm afraid of. From what you know, can Upower be built on any (old) distribution, or does it require recent kernel/libraries/etc .. ?
sorry, dunno...
If I remember what was said before, -DWITH_HAL=ON is incompatible with -DWITH_TDEHWLIBRARY=ON . Does that mean that, if I build with HAL and without hwlibrary, I will automatically lose upower, udisks and pmount support too ? I guess I will also need to stick with kpowersave and knetworkmanager8, instead of tdepowersave and tdepowermanager.
yes, it's so, but I can say only for tdebase...
You're right, I think that 99% of the time, the connected user can eject them with eject command ... What about the mount feature ? Can't udisks(2) be used for that purpose, instead of pmount ? We do not have a "-DWITH_PMOUNT" option yet, but distributions are more likely to provide udisks than pmount ...
I've told about this in the first answer on the thread. For now it won't be introduced before 14.1 because it will require API changes.
Why would it require an API change? The entire point of the TDE HW library is to abstract low level calls; simple calls to the udisks/udisks2 mount/unmount commands can be easily added (with fallback to pmount if they do not succeed). See the eject routine for an example of how to do this properly with CMake conditionals and fallback support.
Tim
2013/8/8 Timothy Pearson kb9vqf@pearsoncomputing.net
You're right, I think that 99% of the time, the connected user can eject them with eject command ... What about the mount feature ? Can't udisks(2) be used for that purpose, instead of pmount ? We do not have a "-DWITH_PMOUNT" option yet, but distributions are more likely to provide udisks than pmount ...
I've told about this in the first answer on the thread. For now it won't be introduced before 14.1 because it will require API changes.
Why would it require an API change? The entire point of the TDE HW library is to abstract low level calls; simple calls to the udisks/udisks2 mount/unmount commands can be easily added (with fallback to pmount if they do not succeed). See the eject routine for an example of how to do this properly with CMake conditionals and fallback support.
Tim
TDEStorageManager::mountDevice() prototype is nailed to pmount. The same about it's usage in tdeioslaves/media.
On Wed, 07 Aug 2013 20:47:22 +0200 François Andriot francois.andriot@free.fr wrote:
Le 07/08/2013 20:35, Fat-Zer a écrit :
I can't say a lot about -DWITH_UPOWER, but if you switch it off you'll loose a suspend/hibernate functionality at least. Also will be affected the brightness and cpu governor control functionality.
That's what I'm afraid of. From what you know, can Upower be built on any (old) distribution, or does it require recent kernel/libraries/etc .. ?
The significant runtime dependencies apper to be glib, dbus, polkit, udev, libusb, pm-utils.
The oldest upower I was able to find information for is 0.9.2, from April 2010. It wants at least: glib 2.21.5 dbus-glib 0.76 polkit 0.91 udev 151 pm-utils 1.3.0
The most recent I was able to find was 0.9.21, which wants: glib 2.22 dbus-glib 0.100 polkit 0.110 udev 200 pm-utils 1.4.1 (or systemd 200)
I don't know what minimum version our hardware lib requires.
On Wednesday 07 of August 2013 19:54:16 François Andriot wrote:
Hello, The 2 current supported versions of RedHat Enterprise Linux (5 and 6) are both provided with a working (and mandatory) HAL daemon, but do not support udisks, upower, and other recent stuff ..
So, TDE R14 can provide the mount/umount features with the small pmount utility, but what about the power options ?
We must not neglect this kind of distributions, because precisely they ship with old versions of KDE3 / early KDE4 /old Gnome2, so Trinity is a very serious alternative.
The meaning of the original question was more precisely: If I build -DWITH_UPOWER=NO -DWITH_UDISKS=NO -DWITH_UDISKS2=NO , what won't work in the end ?
If there is no alternative, I will have to build HAL support for these distributions in R14. So please do not drop it now :-)
Francois
Hi all,
I tried to prepare tdehwlib HAL backend for power management. It currently supports suspend and hibernation. Is designed to transparently selects between upower and HAL.
How about a way of solution?
So far I have not examined whether it would be possible in a similar way to prepare HAL backend for removable drives.
Slavek --
-
Darrell Anderson -
E. Liddell -
Fat-Zer -
François Andriot -
Jim Diamond -
Slávek Banko -
Timothy Pearson