Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Jeremy Olexa wrote: Andrey Grozin wrote: It was discussed (don't have a reference to the thread at hand) that it would be useful to have a table which shows which functions die by themselves, and which not. Andrey I see this asked every X months and never quite figured out why, (this isn't personal against you, Andrey) [...] Take a look for yourself and you will see why there has never been a table or anything created. (it is trivial - and you have the source on your computer already) It shouldn't be necessary to grep the source, if these things would follow a simple logical rule, in accordance with the principle of least surprise. It would be handy to be able to say: all e* functions die, but do* and new* do not. But tommy's list shows that emake is an exception to the rule. I'm not aware of any other exceptions, but I can't be sure unless I go digging through the source. Which really should not be necessary, in my opinion. -- Ben de Groot Gentoo Linux developer (lxde, media, qt, desktop-misc) Gentoo Linux Release Engineering PR liaison __ yng...@gentoo.org http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
On Wed, 24 Dec 2008 00:19:06 -0600 Jeremy Olexa darks...@gentoo.org wrote: Take a look for yourself and you will see why there has never been a table or anything created. (it is trivial - and you have the source on your computer already) It's even trivialler than you think. If it's an external program, it can't die. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
2008/12/23 Doug Goldstein car...@gentoo.org: Looks like people have been truly over-zealous when removing die statements from ebuilds lately. I've added back to HAL an assortment of die statements. I hope this hasn't happened in too many other ebuilds. Maybe then someone should take a look at bug #233184 and close it. -- Regards, Daniel
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
On Monday 22 December 2008 11:40:32 pm Branko Badrljica wrote: Duncan wrote: Branko Badrljica bran...@avtomatika.com posted 494f1518.2020...@avtomatika.com, excerpted below, on Mon, 22 Dec 2008 05:18:32 +0100: Maybe I should have filed this as a bug, but don't have a clue to which package should I assign it, if any. FWIW, this would have been a perfect question for the gentoo-desktop list, but doesn't really belong on the -dev list. There's also the gentoo-user list, altho that one has very heavy volume so you might not wish to subscribe there. Well, regarding the actual error, i think it might interest someone here, also. Although I mentioned just baselayout and openrc, I did check ( end reemerged etc) hal also, and it indeed emerged _without_ /etc/init.d/hald. I tracked it down to root cause: Although I don't use it, I have compiled-in selinux support ( and selinux=0 as kernel start parameter). When I was makeconfiging my kernel, I saw also SMACK support, read info and thought what the heck, it can't hurt me, but I might want to play with it, so I compiled-in that, too. Then after some time I realised that I never got to actually used all that and changed my config file by cutting out that all that security stuff. And recompiled all my kernels accordingly. Around that time I saw people recommending using tmpfs for /var/tmp as this would speed-up emerges etc, so I did that. I didn't know that while I was on SMACK (pun intended) , machine would add extended attr to every file machine would write. ( It was SMACK64 in security domain ). After cleaning my system, even though those attributes were still on all files, everything was fine until I actually tried to copy something from that FS to some other FS. /bin/cp would realise that there are extra security attrs on a file and would try to duplicate them on a copy. And since new kernel was without SMACK support, it would fail. When emerging stuff with /var/tmp on tmpfs, /bin/cp seems to get rarely used in such way when copying stuff into /var/tmp or maybe it was because distfiles were without SMACK attrs- so most ebuilds would seemingly sucseed. Most errors seem tho have been made when ebuild needed some local data, usually in /etc that had SMACK64 attr. If /bin/cp was used to get that data, it would fail, but this would not stop the ebuild. It would usually finished its work just as if nothing happened. Once I unmounted /var/tmp, ebuild could finish normally. Also, after removing security attr from all files, ebuild has started working normally from tmpfs partition again. It is also interesting that on 2.6.27* kernel ebuild fails sometimes and when it fails, it does so silently most of the time. With newest 2.6.28-rc9 i couldn't emerge a thing... Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge... Very nice edge case and great work tracking down the cause.
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Branko Badrljica wrote: Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge... Well there isn't a single place to add die statements. The important thing is for ebuild developers to remember to add || die to all stuff that could potentially fail. If you find the cp in question that failed for you, the right place to file bugs is https://bugs.gentoo.org. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Petteri Räty wrote: Branko Badrljica wrote: Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge... Well there isn't a single place to add die statements. The important thing is for ebuild developers to remember to add || die to all stuff that could potentially fail. If you find the cp in question that failed for you, the right place to file bugs is https://bugs.gentoo.org. Regards, Petteri Looks like people have been truly over-zealous when removing die statements from ebuilds lately. I've added back to HAL an assortment of die statements. I hope this hasn't happened in too many other ebuilds.
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Doug Goldstein wrote: Petteri Räty wrote: Branko Badrljica wrote: Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge... Well there isn't a single place to add die statements. The important thing is for ebuild developers to remember to add || die to all stuff that could potentially fail. If you find the cp in question that failed for you, the right place to file bugs is https://bugs.gentoo.org. Regards, Petteri Looks like people have been truly over-zealous when removing die statements from ebuilds lately. I've added back to HAL an assortment of die statements. I hope this hasn't happened in too many other ebuilds. Who has been removing die statements? Is this a suggested way of action somewhere by someone? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Duncan wrote: Branko Badrljica bran...@avtomatika.com posted 494f1518.2020...@avtomatika.com, excerpted below, on Mon, 22 Dec 2008 05:18:32 +0100: Maybe I should have filed this as a bug, but don't have a clue to which package should I assign it, if any. FWIW, this would have been a perfect question for the gentoo-desktop list, but doesn't really belong on the -dev list. There's also the gentoo-user list, altho that one has very heavy volume so you might not wish to subscribe there. Well, regarding the actual error, i think it might interest someone here, also. Although I mentioned just baselayout and openrc, I did check ( end reemerged etc) hal also, and it indeed emerged _without_ /etc/init.d/hald. I tracked it down to root cause: Although I don't use it, I have compiled-in selinux support ( and selinux=0 as kernel start parameter). When I was makeconfiging my kernel, I saw also SMACK support, read info and thought what the heck, it can't hurt me, but I might want to play with it, so I compiled-in that, too. Then after some time I realised that I never got to actually used all that and changed my config file by cutting out that all that security stuff. And recompiled all my kernels accordingly. Around that time I saw people recommending using tmpfs for /var/tmp as this would speed-up emerges etc, so I did that. I didn't know that while I was on SMACK (pun intended) , machine would add extended attr to every file machine would write. ( It was SMACK64 in security domain ). After cleaning my system, even though those attributes were still on all files, everything was fine until I actually tried to copy something from that FS to some other FS. /bin/cp would realise that there are extra security attrs on a file and would try to duplicate them on a copy. And since new kernel was without SMACK support, it would fail. When emerging stuff with /var/tmp on tmpfs, /bin/cp seems to get rarely used in such way when copying stuff into /var/tmp or maybe it was because distfiles were without SMACK attrs- so most ebuilds would seemingly sucseed. Most errors seem tho have been made when ebuild needed some local data, usually in /etc that had SMACK64 attr. If /bin/cp was used to get that data, it would fail, but this would not stop the ebuild. It would usually finished its work just as if nothing happened. Once I unmounted /var/tmp, ebuild could finish normally. Also, after removing security attr from all files, ebuild has started working normally from tmpfs partition again. It is also interesting that on 2.6.27* kernel ebuild fails sometimes and when it fails, it does so silently most of the time. With newest 2.6.28-rc9 i couldn't emerge a thing... Since I might not be the only tinkerer on Gentoo to try stuff like that and since it took me a day to find this, maybe it wouldn't hurt to check for this kind of thing in portage ? At the very least failed cp should stop emerge...
[gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
Branko Badrljica bran...@avtomatika.com posted 494f1518.2020...@avtomatika.com, excerpted below, on Mon, 22 Dec 2008 05:18:32 +0100: Maybe I should have filed this as a bug, but don't have a clue to which package should I assign it, if any. FWIW, this would have been a perfect question for the gentoo-desktop list, but doesn't really belong on the -dev list. There's also the gentoo-user list, altho that one has very heavy volume so you might not wish to subscribe there. I know you didn't know where to post, so this is simply for future reference. Try to keep the -dev list for technical dev discussion, as every post the devs have to deal with here is time they can't be spending on fixing packages. =:^( I was forced to switch baselayout from stable 1.12.11* to 2.0.0, which triggered openrc install etc. I did all that etc , then after some time I noticed that system doesn't respond to PnP events. So I started looking around and have noticed that I have no /etc/init.d/hald and that hal daemon never gets called during boot. Then I tried to find alternate hald starting mechanism, but couldn't find any. I did emerge -pv system | grep hal and noticed that hal damon is not part of the system, but it is part of the world and it gets reemerged if I unmerge it, since 15-something packages depend on it throuh hal use flag. equery belongs /etc/init.d/hald [ Searching for file(s) /etc/init.d/hald in *... ] sys-apps/hal-0.5.11-r4 (/etc/init.d/hald) So did you actually remerge hal? What version? The above hal-0.5.11-r4 is the ~arch version, but -r1 appears to be the latest stable (except for arm and sh, on which 0.5.9.1-r3 is latest stable) and at least my archived binpkg -r1 has /etc/init.d/hald as well. Even my oldest archived hal-0.5.10 binpkg has that file. So if it's not being created when you remerge hal and you aren't running something terribly outdated, I'd say it's time to look up hal bugs, and to file one if necessary. (As above, please post anything further on the topic to the desktop list, which I read as well, to keep the dev list from getting too cluttered. Thanks.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
