Is there a way to compile kdebase without hal support? It's not supported anymore in gentoo and I don't want to mess with my system trying to install it.
On Sep 7, 2011, at 14:37, L0ner sh4dou sh4dou@gmail.com wrote:
Is there a way to compile kdebase without hal support? It's not supported anymore in gentoo and I don't want to mess with my system trying to install it.
IIRC -DWITH_HAL=OFF check CMakeLists.txt or something.
-- Off the top of my head comes these responses. Grain of salt needed. Thank Apple for the top posting. later, Robert Xu
2011/9/7 Robert Xu robxu9@gmail.com:
On Sep 7, 2011, at 14:37, L0ner sh4dou sh4dou@gmail.com wrote:
Is there a way to compile kdebase without hal support? It's not supported anymore in gentoo and I don't want to mess with my system trying to install it.
IIRC -DWITH_HAL=OFF check CMakeLists.txt or something.
-- Off the top of my head comes these responses. Grain of salt needed. Thank Apple for the top posting. later, Robert Xu
Already tried that. No success. And in the CMakeLists.txt WITH_HAL is set to OFF. It throws at me this:
-- checking for one of the modules 'hal' CMake Error at cmake/modules/TDEMacros.cmake:20 (message): #################################################
hal is required, but was not found on your system
################################################# Call Stack (most recent call first): ConfigureChecks.cmake:42 (tde_message_fatal) CMakeLists.txt:125 (include)
Dne st 7. září 2011 L0ner sh4dou napsal(a):
Already tried that. No success. And in the CMakeLists.txt WITH_HAL is set to OFF. It throws at me this:
-- checking for one of the modules 'hal' CMake Error at cmake/modules/TDEMacros.cmake:20 (message): #################################################
hal is required, but was not found on your system
################################################# Call Stack (most recent call first): ConfigureChecks.cmake:42 (tde_message_fatal) CMakeLists.txt:125 (include)
HAL is meanwhile required dependency. See roadmap: http://www.trinitydesktop.org/wiki/bin/view/Developers/RoadMap
Slavek --
2011/9/7 Slávek Banko slavek.banko@axis.cz:
Dne st 7. září 2011 L0ner sh4dou napsal(a):
Already tried that. No success. And in the CMakeLists.txt WITH_HAL is set to OFF. It throws at me this:
-- checking for one of the modules 'hal' CMake Error at cmake/modules/TDEMacros.cmake:20 (message): #################################################
hal is required, but was not found on your system
################################################# Call Stack (most recent call first): ConfigureChecks.cmake:42 (tde_message_fatal) CMakeLists.txt:125 (include)
HAL is meanwhile required dependency. See roadmap: http://www.trinitydesktop.org/wiki/bin/view/Developers/RoadMap
Slavek
So, no trinity for me on Gentoo until hal dependency has been removed. Maybe I will try to install hal later.
Le Wed, 7 Sep 2011 21:06:53 +0200, Slávek Banko slavek.banko@axis.cz a écrit :
Dne st 7. září 2011 L0ner sh4dou napsal(a):
Already tried that. No success. And in the CMakeLists.txt WITH_HAL is set to OFF. It throws at me this:
-- checking for one of the modules 'hal' CMake Error at cmake/modules/TDEMacros.cmake:20 (message): #################################################
hal is required, but was not found on your system
################################################# Call Stack (most recent call first): ConfigureChecks.cmake:42 (tde_message_fatal) CMakeLists.txt:125 (include)
HAL is meanwhile required dependency. See roadmap: http://www.trinitydesktop.org/wiki/bin/view/Developers/RoadMap
KDE3 hadn't HAL as a mandatory dependency, at least for KDE 3.5.4 which was part of the HAL-less (and 2.4 kernel) Slackware 11.0. Was it the CMake conversion which turned HAL into a mandatory dependency ?
Slavek
Le Wed, 7 Sep 2011 21:06:53 +0200, Slávek Banko slavek.banko@axis.cz a écrit :
Dne st 7. záÅà 2011 L0ner sh4dou napsal(a):
Already tried that. No success. And in the CMakeLists.txt WITH_HAL is set to OFF. It throws at me this:
-- checking for one of the modules 'hal' CMake Error at cmake/modules/TDEMacros.cmake:20 (message): #################################################
hal is required, but was not found on your system
################################################# Call Stack (most recent call first): ConfigureChecks.cmake:42 (tde_message_fatal) CMakeLists.txt:125 (include)
HAL is meanwhile required dependency. See roadmap: http://www.trinitydesktop.org/wiki/bin/view/Developers/RoadMap
KDE3 hadn't HAL as a mandatory dependency, at least for KDE 3.5.4 which was part of the HAL-less (and 2.4 kernel) Slackware 11.0. Was it the CMake conversion which turned HAL into a mandatory dependency ?
As far as I can tell, yes. ksmserver relies on HAL at the moment, and the appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
Tim
On Wednesday 07 September 2011 22:38:07 Timothy Pearson wrote:
[...]
As far as I can tell, yes. ksmserver relies on HAL at the moment, and the appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
On Gentoo HAL cannot be installed with newer versions of udev.
Tim
2011/9/7 Serghei Amelian serghei@thel.ro:
On Wednesday 07 September 2011 22:38:07 Timothy Pearson wrote:
[...]
As far as I can tell, yes. ksmserver relies on HAL at the moment, and the appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
On Gentoo HAL cannot be installed with newer versions of udev.
Tim
-- Serghei
Yep. It's masked and I can imagine it will be hell getting it working... and I'm not really up to reinstalling my gentoo if I mess badly trying to install hal.
2011/9/7 Serghei Amelian serghei@thel.ro:
On Wednesday 07 September 2011 22:38:07 Timothy Pearson wrote:
[...]
As far as I can tell, yes. ksmserver relies on HAL at the moment, and the appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
On Gentoo HAL cannot be installed with newer versions of udev.
Tim
-- Serghei
Yep. It's masked and I can imagine it will be hell getting it working... and I'm not really up to reinstalling my gentoo if I mess badly trying to install hal.
OK. I should mention that HAL's replacements (DeviceKit and its pieces) are more limited than HAL. This impacts Trinity, as one of its design goals is to expose as much useful information to the user as possible. Currently we strongly recommend to use HAL when possible, as there is no direct replacement for it under Linux at this time.
Tim
2011/9/7 Serghei Amelian serghei@thel.ro:
On Wednesday 07 September 2011 22:38:07 Timothy Pearson wrote:
[...]
As far as I can tell, yes. ksmserver relies on HAL at the moment, and the appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
On Gentoo HAL cannot be installed with newer versions of udev.
Tim
-- Serghei
Yep. It's masked and I can imagine it will be hell getting it working... and I'm not really up to reinstalling my gentoo if I mess badly trying to install hal.
OK. I should mention that HAL's replacements (DeviceKit and its pieces) are more limited than HAL. This impacts Trinity, as one of its design goals is to expose as much useful information to the user as possible. Currently we strongly recommend to use HAL when possible, as there is no direct replacement for it under Linux at this time.
Tim
Can you try this patch against kdebase to see if it enables compilation without HAL support?
Thanks!
Tim
BTW Serghei, I decided to handle this one so you don't need to waste your time on it. I'm learning CMake slowly, bit by little bit... ;-)
On Thursday 08 September 2011 01:24:51 Timothy Pearson wrote:
OK. I should mention that HAL's replacements (DeviceKit and its pieces) are more limited than HAL. This impacts Trinity, as one of its design goals is to expose as much useful information to the user as possible. Currently we strongly recommend to use HAL when possible, as there is no direct replacement for it under Linux at this time.
This can potentially bar you from inclusion of Trinity in distributions.
On Thursday 08 September 2011 01:24:51 Timothy Pearson wrote:
OK. I should mention that HAL's replacements (DeviceKit and its pieces) are more limited than HAL. This impacts Trinity, as one of its design goals is to expose as much useful information to the user as possible. Currently we strongly recommend to use HAL when possible, as there is no direct replacement for it under Linux at this time.
This can potentially bar you from inclusion of Trinity in distributions.
"Strongly recommend", not "require". ;-)
See my message a couple of minutes ago with a possible patch to allow HAL support to be disabled.
Believe me, if there was a stable and full featured replacement for HAL I would migrate to it immediately. When DeviceKit is, for example, balking at adding backlight control to the power saving module (!?!??) I get rather concerned about the entire HAL "replacement".
Tim
2011/9/7 Timothy Pearson kb9vqf@pearsoncomputing.net:
On Thursday 08 September 2011 01:24:51 Timothy Pearson wrote:
OK. I should mention that HAL's replacements (DeviceKit and its pieces) are more limited than HAL. This impacts Trinity, as one of its design goals is to expose as much useful information to the user as possible. Currently we strongly recommend to use HAL when possible, as there is no direct replacement for it under Linux at this time.
This can potentially bar you from inclusion of Trinity in distributions.
"Strongly recommend", not "require". ;-)
See my message a couple of minutes ago with a possible patch to allow HAL support to be disabled.
Believe me, if there was a stable and full featured replacement for HAL I would migrate to it immediately. When DeviceKit is, for example, balking at adding backlight control to the power saving module (!?!??) I get rather concerned about the entire HAL "replacement".
Can't you get the info You need from other sources? I mean sysfs, DBUS and so on?
Can you try this patch against kdebase to see if it enables compilation without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Can you try this patch against kdebase to see if it enables compilation
>without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Can you try this patch against kdebase to see if it enables compilation
>without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Pull the latest kdelibs and recompile/reinstall--there were updates a week or so ago that added data structures and methods that kdebase now relies on.
Tim
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
Can you try this patch against kdebase to see if it enables compilation
>without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Pull the latest kdelibs and recompile/reinstall--there were updates a week or so ago that added data structures and methods that kdebase now relies on.
Tim
Is there something else I should rebuild/reinstall? http://paste.pocoo.org/show/472086/
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
Can you try this patch against kdebase to see if it enables compilation
>without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Pull the latest kdelibs and recompile/reinstall--there were updates a week or so ago that added data structures and methods that kdebase now relies on.
Tim
Is there something else I should rebuild/reinstall? http://paste.pocoo.org/show/472086/
Yes, Pull the latest source from out GIT repository with:
git clone http://scm.trinitydesktop.org/scm/git/tde
and rebuild/reinstall Qt3 from the sources in the main/dependencies/qt3 folder.
Tim
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
Can you try this patch against kdebase to see if it enables compilation
>without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Pull the latest kdelibs and recompile/reinstall--there were updates a week or so ago that added data structures and methods that kdebase now relies on.
Tim
Is there something else I should rebuild/reinstall? http://paste.pocoo.org/show/472086/
Yes, Pull the latest source from out GIT repository with:
git clone http://scm.trinitydesktop.org/scm/git/tde
and rebuild/reinstall Qt3 from the sources in the main/dependencies/qt3 folder.
Tim
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
On Thursday 08 September 2011 14:59:42 L0ner sh4dou wrote:
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
I wonder why it is so. KDE 3.5.10 builds well without hal (although the mediamanager cannot detect the removable drives unless patched).
On Thursday 08 September 2011 14:59:42 L0ner sh4dou wrote:
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
I wonder why it is so. KDE 3.5.10 builds well without hal (although the mediamanager cannot detect the removable drives unless patched).
Your patch is distro specific. Also, this is not KDE 3.5.10, this is TDE 3.5.13 development, and little problems like this are to be expected when dealing with the development branch.
Tim
On Thursday 08 September 2011 20:11:23 Timothy Pearson wrote:
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
I wonder why it is so. KDE 3.5.10 builds well without hal (although the mediamanager cannot detect the removable drives unless patched).
Your patch is distro specific.
Why do you think so?!!
Also, this is not KDE 3.5.10, this is TDE 3.5.13 development, and little problems like this are to be expected when dealing with the development branch.
On Thursday 08 September 2011 20:11:23 Timothy Pearson wrote:
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
I wonder why it is so. KDE 3.5.10 builds well without hal (although the mediamanager cannot detect the removable drives unless patched).
Your patch is distro specific.
Why do you think so?!!
Can you post a link? One of the members of the development team here had looked at it and mentioned it was distro-specific.
Tim
On Thursday 08 September 2011 20:58:22 Timothy Pearson wrote:
Can you post a link? One of the members of the development team here had looked at it and mentioned it was distro-specific.
So you did not see the patch and claim it is distro-specific. Is having a /media folder also distro-specific?
On Thursday 08 September 2011 20:58:22 Timothy Pearson wrote:
Can you post a link? One of the members of the development team here had looked at it and mentioned it was distro-specific.
So you did not see the patch and claim it is distro-specific. Is having a /media folder also distro-specific?
Where is the link? No, having a media folder is not distro specific.
If I was wrong here I apologize. I don't have time to examine each and every patch that exists outside of this mailing list, so I do have to trust other people to look at some of them--this is the nature of a large project such as Trinity.
Tim
On Thursday 08 September 2011 21:14:18 Timothy Pearson wrote:
So you did not see the patch and claim it is distro-specific. Is having a /media folder also distro-specific?
Where is the link? No, having a media folder is not distro specific.
If I was wrong here I apologize. I don't have time to examine each and every patch that exists outside of this mailing list, so I do have to trust other people to look at some of them--this is the nature of a large project such as Trinity.
Here is it.
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
>Can you try this patch against kdebase to see if it enables > compilation >without HAL support?
cmake configured just fine. Right now I'm compiling and it goes just fine.
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Pull the latest kdelibs and recompile/reinstall--there were updates a week or so ago that added data structures and methods that kdebase now relies on.
Tim
Is there something else I should rebuild/reinstall? http://paste.pocoo.org/show/472086/
Yes, Pull the latest source from out GIT repository with:
git clone http://scm.trinitydesktop.org/scm/git/tde
and rebuild/reinstall Qt3 from the sources in the main/dependencies/qt3 folder.
Tim
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
It sure looks like you didn't apply the entire patch I sent earlier. No matter, I committed it to SVN last night already. :-)
Pull kdebase from SVN again and recompile. It should work; if it does not then please post the build failure.
Thanks!
Tim
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
> >>Can you try this patch against kdebase to see if it enables >> compilation > >without HAL support? > > cmake configured just fine. Right now I'm compiling and it goes just > fine. >
Don't know if it's related, or it is something else (more probable from looking at the errors): http://paste.pocoo.org/show/472071/
Pull the latest kdelibs and recompile/reinstall--there were updates a week or so ago that added data structures and methods that kdebase now relies on.
Tim
Is there something else I should rebuild/reinstall? http://paste.pocoo.org/show/472086/
Yes, Pull the latest source from out GIT repository with:
git clone http://scm.trinitydesktop.org/scm/git/tde
and rebuild/reinstall Qt3 from the sources in the main/dependencies/qt3 folder.
Tim
Pulled, recompiled, reinstalled everything. kdebase does not compile: http://paste.pocoo.org/show/472328/ seems like it misses hal.
It sure looks like you didn't apply the entire patch I sent earlier. No matter, I committed it to SVN last night already. :-)
Pull kdebase from SVN again and recompile. It should work; if it does not then please post the build failure.
Thanks!
Probable. Anyway I pulled kdebase from svn and compilation went just fine.
<snip>
Can't you get the info You need from other sources? I mean sysfs, DBUS and so on?
Yes, but it's a pain. Additionally, as those interfaces change we would have to maintain the TDE connections to them, which would sap time and energy away from other tasks.
I have not yet decided on a course of action, but probably nothing will be done as far as replacing HAL until either someone sponsors the work or does it themselves.
Tim
2011/9/8 Timothy Pearson kb9vqf@pearsoncomputing.net:
<snip> > > Can't you get the info You need from other sources? I mean sysfs, DBUS > and so on?
Yes, but it's a pain. Additionally, as those interfaces change we would have to maintain the TDE connections to them, which would sap time and energy away from other tasks.
I have not yet decided on a course of action, but probably nothing will be done as far as replacing HAL until either someone sponsors the work or does it themselves.
Tim
Well, it seems lately that every developer in linux community is trying to make something new that actually is crap compared to what were used previously and everyone starts using it because it's "new". Just look at gnome3, hal and thing like that. It seems to me that with every upgrade and new feture every OS sucks more and more -_-
On Thursday 08 September 2011 02:27:33 Timothy Pearson wrote:
Can't you get the info You need from other sources? I mean sysfs, DBUS and so on?
Yes, but it's a pain. Additionally, as those interfaces change we would have to maintain the TDE connections to them, which would sap time and energy away from other tasks.
I have not yet decided on a course of action, but probably nothing will be done as far as replacing HAL until either someone sponsors the work or does it themselves.
I am currently writing from kdebase3 where hal has been disabled.
Only the following packages need hal as of now and I placed them in a separate repository:
kima knetworkmanager-kde3 kpowersave
All other stuff can be built without hal, otherwise the inclusion of KDE3 in the upcoming openSUSE release would be impossible.
On Thursday 08 September 2011 02:27:33 Timothy Pearson wrote:
Can't you get the info You need from other sources? I mean sysfs, DBUS and so on?
Yes, but it's a pain. Additionally, as those interfaces change we would have to maintain the TDE connections to them, which would sap time and energy away from other tasks.
I have not yet decided on a course of action, but probably nothing will be done as far as replacing HAL until either someone sponsors the work or does it themselves.
I am currently writing from kdebase3 where hal has been disabled.
Only the following packages need hal as of now and I placed them in a separate repository:
kima knetworkmanager-kde3 kpowersave
For Trinity, add kdebase and I end up with the same list, which is good. :-)
Just as a reminder, I do have specifications out for the new libraries that Trinity should include when we do move away from HAL, in case anyone feels inspired to work on them: http://www.trinitydesktop.org/wiki/bin/view/Developers/TUComputerAPI http://www.trinitydesktop.org/wiki/bin/view/Developers/KPowerAPI
A properly engineered base will prevent many problems down the line, and allow Trinity applications to easily access and control the computer's devices and power management state. Feedback on the proposed libraries is also welcome.
Tim
On Thursday 08 September 2011 03:43:08 Timothy Pearson wrote:
Can't you get the info You need from other sources? I mean sysfs, DBUS and so on?
Yes, but it's a pain. Additionally, as those interfaces change we would have to maintain the TDE connections to them, which would sap time and energy away from other tasks.
I have not yet decided on a course of action, but probably nothing will be done as far as replacing HAL until either someone sponsors the work or does it themselves.
I am currently writing from kdebase3 where hal has been disabled.
Only the following packages need hal as of now and I placed them in a separate repository:
kima knetworkmanager-kde3 kpowersave
For Trinity, add kdebase and I end up with the same list, which is good. :-)
The most diappointing one here is the knetworkmanager client. In theory it should not reqire hal? and should only communicate with the NM backend.
Le Wed, 7 Sep 2011 17:27:33 -0500, "Timothy Pearson" kb9vqf@pearsoncomputing.net a écrit :
<snip> > > Can't you get the info You need from other sources? I mean sysfs, > DBUS and so on?
Yes, but it's a pain. Additionally, as those interfaces change we would have to maintain the TDE connections to them, which would sap time and energy away from other tasks.
Why not reuse the work of KDE developers and use KDE4's Solid library ? It already supports both HAL and u* backends, doesn't seem to depend on other parts of kdelibs4 and the license is compatible.
I have not yet decided on a course of action, but probably nothing will be done as far as replacing HAL until either someone sponsors the work or does it themselves.
Tim
If you want old ebuilds that allow you to have a fully functional Gentoo with HAL, I can provide them. I'm using them as I type but of course I keep my overlay around.
Tiago
On Wed, Sep 7, 2011 at 9:00 PM, L0ner sh4dou sh4dou@gmail.com wrote:
2011/9/7 Serghei Amelian serghei@thel.ro:
On Wednesday 07 September 2011 22:38:07 Timothy Pearson wrote:
[...]
As far as I can tell, yes. ksmserver relies on HAL at the moment, and
the
appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
On Gentoo HAL cannot be installed with newer versions of udev.
Tim
-- Serghei
Yep. It's masked and I can imagine it will be hell getting it working... and I'm not really up to reinstalling my gentoo if I mess badly trying to install hal.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Wednesday 07 September 2011 22:38:07 Timothy Pearson wrote:
[...]
As far as I can tell, yes. ksmserver relies on HAL at the moment, and the appropriate #ifdef logic has not yet been added to the code to disable HAL.
HAL is simply a small background process that should not affect anything else on your system. Why doesn't it work on Gentoo?
On Gentoo HAL cannot be installed with newer versions of udev.
You're back! :-)
Good to know regarding Gentoo. Can you try to implement the remaining logic in CMake for a HAL-less ksmserver?
Thanks!
Tim
-
/dev/ammo42 -
Ilya Chernykh -
Katheryne Draven -
L0ner sh4dou -
Robert Xu -
Serghei Amelian -
Slávek Banko -
Tiago Marques -
Timothy Pearson