[gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Duncan]

Branko Badrljica <brankob@avtomatika.com> posted
494F1518.2020109@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

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Branko Badrljica]

Duncan wrote:
> Branko Badrljica <brankob@avtomatika.com> posted
> 494F1518.2020109@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...

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Robert R. Russell]

On Monday 22 December 2008 11:40:32 pm Branko Badrljica wrote:
> Duncan wrote:
> > Branko Badrljica <brankob@avtomatika.com> posted
> > 494F1518.2020109@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 ?

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Doug Goldstein]

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 ?

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Andrey Grozin]

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 ?

[Jeremy Olexa]

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 ?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

On Wed, 24 Dec 2008 00:19:06 -0600
Jeremy Olexa <darkside@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Daniel Pielmeier]

2008/12/23 Doug Goldstein <cardoe@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

[gentoo-dev] List of ebuild functions that die/do not die

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

As it seems like noone else is doing something about it, i have started a list with some entries[1].
Please send me more functions and their place and error reports directly to me (via mail or irc).

[1]: http://dev.gentoo.org/~tommy/ebuild-functions.txt


-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-dev] List of ebuild functions that die/do not die

[Nirbheek Chauhan]

On Wed, Dec 24, 2008 at 8:27 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> As it seems like noone else is doing something about it, i have started a list with some entries[1].
> Please send me more functions and their place and error reports directly to me (via mail or irc).

I thought that the rules for determination were pretty straightforward:

commands that die:
everything that is implemented as a function (ebuild.sh, eclasses, etc)

commands that don't die:
every external application (do*, cp, etc)


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] List of ebuild functions that die/do not die

[Doug Goldstein]

Nirbheek Chauhan wrote:
> On Wed, Dec 24, 2008 at 8:27 PM, Thomas Sachau <tommy@gentoo.org> wrote:
>   
>> As it seems like noone else is doing something about it, i have started a list with some entries[1].
>> Please send me more functions and their place and error reports directly to me (via mail or irc).
>>     
>
> I thought that the rules for determination were pretty straightforward:
>
> commands that die:
> everything that is implemented as a function (ebuild.sh, eclasses, etc)
>
> commands that don't die:
> every external application (do*, cp, etc)
>
>
>   
Technically the rule is that eclasses shouldn't die. At least that's the 
latest version of the rules that I remember.

Re: [gentoo-dev] List of ebuild functions that die/do not die

[Nirbheek Chauhan]

On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
> Nirbheek Chauhan wrote:
[snip]
>> commands that die:
>> everything that is implemented as a function (ebuild.sh, eclasses, etc)
[snip]
>
> Technically the rule is that eclasses shouldn't die. At least that's the
> latest version of the rules that I remember.
>

eclasses shouldn't die or functions inside eclasses shouldn't die? I
meant the latter:

s/(ebuild.sh/(inside ebuild.sh/

-- 
~Nirbheek Chauhan

[gentoo-dev] Re: List of ebuild functions that die/do not die

[Steve Long]

Nirbheek Chauhan wrote:

> On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
>> Nirbheek Chauhan wrote:
> [snip]
>>> commands that die:
>>> everything that is implemented as a function (ebuild.sh, eclasses, etc)
> [snip]
>>
>> Technically the rule is that eclasses shouldn't die. At least that's the
>> latest version of the rules that I remember.
>>
> 
> eclasses shouldn't die or functions inside eclasses shouldn't die? I
> meant the latter:
> 
> s/(ebuild.sh/(inside ebuild.sh/
> 
The only technical reason not to allow an --or-die (or the equivalent)
switch for everything is the issues with subshell die, for which I sent
some script to test but didn't hear back about, but more cogently that old
GNU heads think xargs is necessary as GNU find didn't implement -exec
correctly (according to POSIX) until a couple of years ago.

In BASH, one would use the equivalent loop (which will cope with any
filename):
while read -rd '' f; do foo --or-die "$f"; done < <(find .. -print0)

I usually show newbs this:
while read -rd ''; do arr+=("$REPLY"); done < <(find .. -print0)
..since it shows a bit more about read and gives the other usual
requirement.

This is compatible with the old broken GNU find as well as BSD, but -print0
is not required by POSIX.

I'm sure I've used that in a function somewhere amongst one of the patches I
filed with someone or the other. TBH a professional BASH scripter would
sneer (I can think of several) at needing to wrap it in a function: it's
like not knowing how to read a file line-by-line in POSIX sh.

Put it this way: if you actually need the filenames, or some other
information elsewhere in the script[1], chances are that the loop has more
meat to it.

I suppose you could pass directories and params for a find command/API
function, eg:
findE --or-die foo dirA/b dirC/d ! \( -type -l -o -name '*~' \)
..or the like, showing --or-die first for consistency but it could of course
come anywhere.

[1] /msg greybot faq disappear

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Ben de Groot]

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
______________________________________________________

yngwin@gentoo.org
http://ben.liveforge.org/
irc://chat.freenode.net/#gentoo-media
irc://irc.oftc.net/#lxde
______________________________________________________

[gentoo-dev] Re: Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Steve Long]

Ben de Groot wrote:
> 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.
>>>
>> 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)
That's more an argument for putting the table on the web than continuing
without adequate documentation. If it's going to change, automate it using
the script you posted (assuming it's watertight.)
> 
> It shouldn't be necessary to grep the source
Agreed.