On 06/04/2012 10:00 PM, David C. Rankin wrote:
Calvin,
What's the fix?
Does hal need to be updated and the udev dependency removed to work with systemd-tools?
The error on startx was:
/opt/trinity/bin/konqueror: error while loading shared libraries: libudev.so.0: cannot open share object file: No such file or directory <snip>
tde-config: error while loading shared libraries: libudev.so.0: cannot open share object file: No such file or directory <snip>
/opt/trinity/bin/kdetcompmgr: error while loading shared libraries: libudev.so.0: cannot open share object file: No such file or directory <snip>
/opt/trinity/bin/ksplash: error while loading shared libraries: libudev.so.0: cannot open share object file: No such file or directory <snip>
/opt/trinity/bin/tdeinit: error while loading shared libraries: libudev.so.0: cannot open share object file: No such file or directory <snip>
/opt/trinity/bin/tdeinit_phase1: error while loading shared libraries: libudev.so.0: cannot open share object file: No such file or directory
Pretty clear what the problem was. I looked at the build scripts and nothing has a -DWITH_'UDEV'=ON type cmake setting available. So it looks like this will have to be fixed with a tde dependency -- but how?
On 06/04/2012 10:23 PM, David C. Rankin wrote:
On 06/04/2012 10:00 PM, David C. Rankin wrote:
Calvin,
What's the fix?
I'll give aur: hal 0.5.14-9 a try :)
No-Go
Calvin -- somebody, you, pawel, or somebody else smart on building hal needs to update it again. I see that 0.5.14-9 was released yesterday, but it still has a udev dependency. With the update yesterday - udev was removed due to its merge upstream with systemd-tools. A work around is to create a symlink in /usr/lib for libudev.so.0 (there was a soname bump to .1 with the systemd-tools update)
TDE starts without hal rebuild with the symlink, but that is not a fix. Let me know if one of you guys can do this. I haven't ever messed with the guts of hal, so I would be reinventing the wheel.
Calvin -- somebody, you, pawel, or somebody else smart on building hal needs to update it again. I see that 0.5.14-9 was released yesterday, but it still has a udev dependency. With the update yesterday - udev was removed due to its merge upstream with systemd-tools. A work around is to create a symlink in /usr/lib for libudev.so.0 (there was a soname bump to .1 with the systemd-tools update)
TDE starts without hal rebuild with the symlink, but that is not a fix. Let me know if one of you guys can do this. I haven't ever messed with the guts of hal, so I would be reinventing the wheel.
Did you try building with the new Trinity hardware devices support?
Darrell
On 06/04/2012 10:43 PM, David C. Rankin wrote:
I'll give aur: hal 0.5.14-9 a try :)
No-Go
Calvin -- somebody, you, pawel, or somebody else smart on building hal needs to update it again. I see that 0.5.14-9 was released yesterday, but it still has a udev dependency. With the update yesterday - udev was removed due to its merge upstream with systemd-tools. A work around is to create a symlink in /usr/lib for libudev.so.0 (there was a soname bump to .1 with the systemd-tools update)
TDE starts without hal rebuild with the symlink, but that is not a fix. Let me know if one of you guys can do this. I haven't ever messed with the guts of hal, so I would be reinventing the wheel.
I guess this will work -- since systemd-tools 'provides=("udev=$pkgver")' this should work fine. I'll dump everything regarding hal and start again to get the soname issues resolved.
If there is a shared library error you might need to rebuild tde against the new version. There has been a flurry of activity around the Hal package over the last few days so hopefully its getting resolved.
Calvin On Jun 5, 2012 12:04 AM, "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 06/04/2012 10:43 PM, David C. Rankin wrote:
I'll give aur: hal 0.5.14-9 a try :)
No-Go
Calvin -- somebody, you, pawel, or somebody else smart on building hal
needs
to update it again. I see that 0.5.14-9 was released yesterday, but it
still has
a udev dependency. With the update yesterday - udev was removed due to
its merge
upstream with systemd-tools. A work around is to create a symlink in
/usr/lib
for libudev.so.0 (there was a soname bump to .1 with the systemd-tools
update)
TDE starts without hal rebuild with the symlink, but that is not a
fix. Let me
know if one of you guys can do this. I haven't ever messed with the guts
of hal,
so I would be reinventing the wheel.
I guess this will work -- since systemd-tools 'provides=("udev=$pkgver")' this should work fine. I'll dump everything regarding hal and start again to get the soname issues resolved.
-- David C. Rankin, J.D.,P.E.
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
On 06/05/2012 08:10 AM, Calvin Morrison wrote:
If there is a shared library error you might need to rebuild tde against the new version. There has been a flurry of activity around the Hal package over the last few days so hopefully its getting resolved.
Calvin
Yes,
I see the new aur package. If you are talking with Pawel, pass along that 'systemd-tools' needs to be made a dependence of hal since systemd-tools is now what "provides" the udev dependency. Leaving the pkgbuild with just 'udev' as a dependency will not flag systemd-tools as required if it is not already installed before building hal...
On 5 June 2012 09:40, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 06/05/2012 08:10 AM, Calvin Morrison wrote:
If there is a shared library error you might need to rebuild tde against the new version. There has been a flurry of activity around the Hal package over the last few days so hopefully its getting resolved.
Calvin
Yes,
I see the new aur package. If you are talking with Pawel, pass along that 'systemd-tools' needs to be made a dependence of hal since systemd-tools is now what "provides" the udev dependency. Leaving the pkgbuild with just 'udev' as a dependency will not flag systemd-tools as required if it is not already installed before building hal...
-- David C. Rankin, J.D.,P.E.
Unfortunately Pawel has stopped in his efforts to build Trinity on Arch Linux. Currently there is a maintainer for hal though, who seems to be updating it.
I'll let them know
Calvin
On 06/05/2012 10:10 AM, Calvin Morrison wrote:
Unfortunately Pawel has stopped in his efforts to build Trinity on Arch Linux. Currently there is a maintainer for hal though, who seems to be updating it.
I'll let them know
Calvin
Calvin,
That's a bummer. Don't forget, you can download all the tde pkgbuild files at:
http://nirvana.3111skyline.com/dl/dt/tde/src/tde-pkgbuild-src.tar.gz
There may be a patch or two to back out, but otherwise, that is what I'm building on. See the Readme:
http://nirvana.3111skyline.com/dl/dt/tde/src/README-building.txt
it has the links to the automated build scripts. I'll update everything once we get the gcc 4.7 kwrite bug solved. That is really the only thing holding up having complete R14-dev packages for Arch.
On 5 June 2012 14:34, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 06/05/2012 10:10 AM, Calvin Morrison wrote:
Unfortunately Pawel has stopped in his efforts to build Trinity on Arch Linux. Currently there is a maintainer for hal though, who seems to be updating it.
I'll let them know
Calvin
Calvin,
That's a bummer. Don't forget, you can download all the tde pkgbuild files at:
http://nirvana.3111skyline.com/dl/dt/tde/src/tde-pkgbuild-src.tar.gz
There may be a patch or two to back out, but otherwise, that is what I'm building on. See the Readme:
http://nirvana.3111skyline.com/dl/dt/tde/src/README-building.txt
it has the links to the automated build scripts. I'll update everything once we get the gcc 4.7 kwrite bug solved. That is really the only thing holding up having complete R14-dev packages for Arch.
I'll say it again - you should really stick those up in our packaging repository so that they are available in any scenario (you get hit by a clown car, etc), but thank you I will look at those packages so I can get a system up and running
Calvin
On 06/05/2012 01:40 PM, Calvin Morrison wrote:
I'll say it again - you should really stick those up in our packaging repository so that they are available in any scenario (you get hit by a clown car, etc), but thank you I will look at those packages so I can get a system up and running
Calvin
I have to learn git first :)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin