[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-apps/xwarppointer: xwarppointer-1.ebuild metadata.xml ChangeLog

2008-12-22 Thread Christian Faulhammer

Heath Caldwell (hncaldwell) hncaldw...@gentoo.org:
 src_install() {
   exeinto /usr/bin
   doexe xwarppointer
   dodoc README

 You can exchange the exeinto-doexe combination with dobin, and you
should die on it. 


Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode


Description: PGP signature

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

2008-12-22 Thread Branko Badrljica
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

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...