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 ?
2008/12/23 Doug Goldstein : > > 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 Wed, 24 Dec 2008 00:19:06 -0600 Jeremy Olexa 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 ?
Andrey Grozin wrote: On Wed, 24 Dec 2008, Petteri R?ty wrote: Who has been removing die statements? Is this a suggested way of action somewhere by someone? As recently discussed on the list, econf dies by itself, and || die should better be removed after econf. The same is true for, e.g., eqmake4. 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) %% pwd /usr/lib/portage/bin %% grep -l die * ebuild.sh etc-update isolated-functions.sh misc-functions.sh repoman So, that means that none of these die: %% ls do* dobin*dodoc* dohard* doinitd* dolib.a* domo* dosed* doconfd* doenvd* dohtml* doins*dolib.so* donewins@ dosym* dodir*doexe* doinfo* dolib*doman* dosbin* or %% ls new* newbin*newdoc* newexe*newins*newlib.so* newsbin* newconfd* newenvd* newinitd* newlib.a* newman* etc. 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) Maybe this should be a question asked on the new dev quizies.."How do I tell if something dies on its own or not?" HTH, Jeremy
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
On Wed, 24 Dec 2008, Petteri R?ty wrote: Who has been removing die statements? Is this a suggested way of action somewhere by someone? As recently discussed on the list, econf dies by itself, and || die should better be removed after econf. The same is true for, e.g., eqmake4. 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
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 ?
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 ?
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 ?
On Monday 22 December 2008 11:40:32 pm Branko Badrljica wrote: > Duncan wrote: > > Branko Badrljica 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 ?
Duncan wrote: > Branko Badrljica 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...
