6 Aug
2013
6 Aug
'13
5:36 p.m.
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
6 Aug
6 Aug
9:28 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
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
7 Aug
7 Aug
5:54 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
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
6:14 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
Dne st 7. srpna 2013 François Andriot napsal(a):
Le 06/08/2013 23:28, Jim Diamond a écrit :
It would be a solution if tdehw library could use hal as a backend?
Slavek
--
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
6:35 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
2013/8/7 François Andriot <francois.andriot(a)free.fr>
Le 06/08/2013 23:28, Jim Diamond a écrit :
All:
-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.
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
6:47 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
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
7:40 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
2013/8/7 François Andriot <francois.andriot(a)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...
8:42 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
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.
9:05 p.m.
New subject: [trinity-devel] about pmount and R14 new backends
2013/8/8 Timothy Pearson <kb9vqf(a)pearsoncomputing.net>
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.
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. 
8 Aug
8 Aug
1:42 a.m.
New subject: [trinity-devel] about pmount and R14 new backends
On Wed, 07 Aug 2013 20:47:22 +0200
François Andriot <francois.andriot(a)free.fr> wrote:
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.
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 .. ?
10 Aug
10 Aug
2:49 p.m.
New subject: tdehwlib HAL power management backend (was: [trinity-devel] about pmount and R14 new backends)
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
--
3914
days inactive
3918
days old
10 comments
7 participants
participants (7)
-
Darrell Anderson -
E. Liddell -
Fat-Zer -
François Andriot -
Jim Diamond -
Slávek Banko -
Timothy Pearson