--- Log opened Tue Oct 14 00:00:22 2008 02:04 < Ragnar|away> rxr: why update to 2.6.26.6 when 2.6.27 is out? o_o 04:32 < CIA-8> aldas * r30795 /trunk/package/network/iptables/iptables.desc: * updated iptables (1.4.1.1 -> 1.4.2) 04:33 < CIA-8> aldas * r30796 /trunk/package/filesystem/e2fsprogs/e2fsprogs.desc: * updated e2fsprogs (1.41.2 -> 1.41.3) and removed NOPARALLEL 07:50 -!- mpp [n=user@i53876EFD.versanet.de] has joined #t2 08:01 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has joined #t2 08:05 -!- dsoul [i=darksoul@insomniac.pl] has joined #t2 08:58 < rxr> Ragnar|away: because I wat for at least .1 to actually look at the "random junk" 09:14 < Ragnar|away> ah ok 09:23 -!- mpp_ [n=user@i538768A6.versanet.de] has joined #t2 09:25 -!- mpp [n=user@i53876EFD.versanet.de] has quit [Read error: 110 (Connection timed out)] 09:26 -!- tri [n=tri@p4FCF3DDD.dip0.t-ipconnect.de] has joined #t2 09:56 -!- Stealth [i=stealth@sourcemage/guru/stealth] has quit [Read error: 148 (No route to host)] 09:59 -!- Stealth [i=stealth@81.200.8.213] has joined #t2 10:21 -!- mpp_ is now known as mpp 10:21 < mpp> hey rxr 10:44 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has quit [Read error: 60 (Operation timed out)] 10:45 -!- Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: koan 10:45 -!- Netsplit over, joins: koan 10:47 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has joined #t2 10:53 -!- Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: hikenboot, mpp, CIA-8, dsoul 11:04 -!- Netsplit over, joins: mpp, dsoul, hikenboot 11:05 -!- CIA-60 [n=CIA@208.69.182.149] has joined #t2 11:05 -!- CIA-31 [n=CIA@208.69.182.149] has joined #t2 11:05 -!- CIA-60 [n=CIA@208.69.182.149] has left #t2 [] 12:02 < mpp> hey 12:02 < mpp> when i update the local svn tree 12:02 < mpp> what was the command for resceduling / updating new + updated packages ? 12:03 < mpp> for a build target 12:03 < rxr> ./scripts/Create-ErrList -cfg reference -newremove 12:05 < CIA-31> rene * r30797 /trunk/package/archiver/zip/zip.conf: 12:05 < CIA-31> "Harmuth, Florian" : 12:05 < CIA-31> * fixed zip to cross build by removing generally added AS= from makeopts 12:09 < mpp> thnx rxr 12:10 < CIA-31> rene * r30798 /trunk/package/archiver/zip/zip.desc: * updated zip (232 -> 30) 12:14 < CIA-31> rene * r30799 /trunk/package/xorg/xf86-video-radeonhd/xf86-video-radeonhd.desc: * updated xf86-video-radeonhd (1.2.1 -> 1.2.3) 13:49 -!- hwinkel [n=hwinkel@p54A74DB7.dip.t-dialin.net] has joined #t2 14:06 -!- operativo [n=dfiumice@82.51.41.58] has joined #t2 14:15 -!- operativo [n=dfiumice@82.51.41.58] has quit [Remote closed the connection] 14:39 < mpp> how can i remove updated packages from the build/.... tree ? 14:39 < mpp> e.g like linux26 which updated from .5 to .6 14:39 < mpp> besides removing + rebuilding the target ? 14:48 < rxr> you mean accumulated files like kernel images with unique names ? 14:50 < mpp> yes - 14:51 < mpp> if possibly for other packages too , like zip ... 14:52 < rxr> for one thing, if you want this behavior use another option of CreateErrList 14:52 < rxr> -newremove 14:53 < rxr> err 14:53 < rxr> -newdelete 14:53 < mpp> k 14:53 < rxr> (we should finally rename them, they even confuse me ...) 14:53 < mpp> :-) 14:53 < rxr> remove just removes the logfile delete does uninstall the package 14:53 < rxr> (in a bruth force rm way) 14:53 < mpp> thats's fine 14:53 < rxr> files that a package rebuild did not re-install usually should be in the olist in var/adm/olist 14:54 < rxr> (flist == file-list, olist == orphaned-list) 14:54 < mpp> confuze seems better than confuse :-) LOL 14:54 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has quit [Read error: 60 (Operation timed out)] 14:54 < mpp> sometimes 14:54 < mpp> ... 14:54 < rxr> but that does not yet work perfectly reliable, because some packages use timestamps or checksums and intentionally do not reinstall files 14:54 < rxr> (though that are package bugs, not t2 bugs, but non-the-less those Makefiles et al. should be patched for smoothest t2 meta-data interaction possible) 14:54 < mpp> okay so rebuilding the whole target with ccache enabled seems like a reasonable way 14:55 < rxr> hm? 14:55 < mpp> rm the build/target 14:55 < rxr> could could CreateErrList -newdelete to take out single new packages 14:55 < mpp> then rebuilt it 14:55 < rxr> well - you do not have to 14:56 < rxr> as I thought I pointed out above 14:56 < mpp> sure 14:56 < mpp> i am asking 14:56 < mpp> because people who do fresh svn co 14:56 < rxr> in addition to the "single package rebuilding above" (or orphaned file deletion) you can of course rebuild with ccache for the most accurate (but more cpu hungry) results 14:56 < mpp> stumble over some strange build issues from time to time 14:57 < mpp> as i guess you are building with long lasting co's 14:57 < mpp> like updating them all the time 14:57 < rxr> yes, indeed, I only rebuild partially 14:57 < mpp> that's what i think of some build issues now and then 14:58 < rxr> for example I think the latest binutils update caused dietlibc regressions only a full rebuild (that I also did in a second tree) catches 14:58 < mpp> hm.. 14:58 < rxr> as rule of thumb I completely wipe my reference builds every 2 weeks or so ... 14:58 < mpp> ah... that's what i was up to :-) 14:59 < mpp> cause sometimes i get *** off with your statement - everything builds fine here .... :-) 14:59 < mpp> no offence though !! 14:59 < mpp> now that i know ill be more carefull with the update/upgrade on my build host 14:59 < rxr> yeah - but there are really many variables 15:00 < rxr> e.g. I could not reproduce the zip cross build breakage even on a completely vanillaa tree 15:00 < mpp> hm... 15:00 < mpp> heisenbug... whatever keeps the tekkies on the line ... 15:01 < mpp> i just had some heavy core dumps on my new phenom x4 15:01 < mpp> i was relly suprised 15:01 < rxr> what core dumped ? 15:01 < mpp> glibc32 and linux26 as i did a rebuild with the new packages 15:01 < mpp> i'll have a look and see if i still have the /var/log/messages 15:02 < mpp> im suspecting the optimized amd64 15:02 < mpp> host .. 15:03 < mpp> is the ccache coherent concerning updated package versions. i think so as it uses hashes for the ccache files 15:03 < mpp> could be a collision in the hash.... longshot i know 15:04 < rxr> I know ccache had problems on gcc multilib builds which is why I just diabled ccache for gcc in multilib configs or si ... 15:04 < rxr> but aside from that I did not yet had problem 15:04 < rxr> s 15:04 < rxr> at least I notice none ... 15:18 < koan> hi rxr did you encounter my gcc problem too on your build? 15:22 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has joined #t2 15:23 < rxr> koan: no, only other issues with dietlibc probably due to the new binutils 15:24 < koan> hm can I disable 2-gcc temporarily or do I really need it? 15:26 < rxr> in theory 15:26 < rxr> but in practise when gcc does not build natively in a fresh bootstrap you probably will get more and other random errors 15:26 < rxr> have you tried to rebuild?, e.g. try if it's a timing / parallel make issue ? 15:26 < rxr> do you have anything in the syslog / dmeg regarding crash binaries etc.? 15:28 < koan> I'll retry and then look at syslog and dmesg 15:31 -!- hwinkel1 [n=hwinkel@p54A74DB7.dip.t-dialin.net] has joined #t2 15:32 -!- hwinkel [n=hwinkel@p54A74DB7.dip.t-dialin.net] has quit [Read error: 104 (Connection reset by peer)] 15:33 < koan> ok I see something 15:33 < koan> Oct 14 15:31:26 vostro kernel: [ 6448.270098] ld[10039]: segfault at 0 ip 00007f5d2f529ad2 sp 00007fff3811dfa8 error 4 in libc-2.6.1.so[7f5d2f4b2000+13b000] 15:34 < koan> and another one 4 seconds later 15:35 < koan> and a third and fourth one, always the same error 15:40 < koan> hm and in 2-gcc.err I see: 15:40 < koan> checking size of long long... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. 16:04 < rxr> aha! 16:08 < koan> rings a bell? :-) 16:16 < rxr> not that is happening here, but at least we know where it comes from 16:18 < koan> I temporarily disabled 2-gcc and the build process has been going fine for some ten packages now 16:18 < rxr> the question is where it comes from, mpp didn'd you say you have also amd64 optimized segfaults in your trunk build these days ? 16:18 < koan> if random errors pop up maybe I start from scratch but without processor optimalisations 16:19 < mpp> yes i do 16:19 < rxr> mpp: also on 2-gcc ? 16:19 < mpp> yes 16:19 < koan> I'm now building optimized for Athlon64 16:19 < rxr> ah, what did you optimiize for before ? 16:19 < mpp> afaikt on a generic 64bit host everything worked fine 16:19 < rxr> mpp: what where you optimizing for ? 16:20 < mpp> amd64 16:20 < mpp> athlon 64 16:20 < koan> ok 16:20 < rxr> unfortunatly I only have intel 64bit implementations for some time and optimize for core2 for years now :-((( 16:20 < mpp> i have a xeon host which works flawlessly 16:20 < mpp> with optimized for xeon 64bit 16:23 < rxr> on the other hand, do we still include the custom amd64 optimization from AMD 16:23 < rxr> maybe they are the culprit 16:23 < mpp> so what are you suggesting ? 16:23 < rxr> hm - no - apparently not enabled 16:23 < rxr> we should update glibc some days, anyway, maybe fixed upstream 16:24 < rxr> however, there was some major drawback and that's why I have not done so 16:24 < koan> what was the drawback? 16:24 < rxr> - I guess linuxthread related for embedded architecture 16:24 < rxr> glibc maintainers are extreme morons and highly uncopoperative ... 16:24 < rxr> they do not even care to apply useful embedded bits ... 16:24 < rxr> only high performance high end stuff ... 16:24 < rxr> that's their official statement ... 16:27 < koan> hm but is this a drawback for t2? aren't you using dietlibc for embedded architectures? 16:27 < rxr> nope, most often also glibc 16:28 < koan> ok 16:28 < rxr> embedded systems today are in the range of high end workstations from just yesterday 16:28 < koan> :-) 16:28 < rxr> glibc is one of our biggest headache ... 16:28 < rxr> and why folks even forked of eglibc 16:28 < koan> eglibc? never heard of it 16:28 < rxr> not to mention uclibc already is a "shrinked down glibc" fork ... 16:29 < rxr> eglibc fork "with all things considered" 16:29 < rxr> a glibc fork .... 16:29 < rxr> that is patches are considered on a technical basis, not daily feeling of Ullrich Drepper or Red Hat's business strategy 16:29 < koan> :-) 16:30 < rxr> http://osdir.com/ml/t2.devel/2007-06/msg00038.html 16:31 < koan> interesting 16:33 < mpp> hmm.... 16:34 < mpp> so what's the practical outcome of this ? 16:34 < mpp> use generic 64 for adm ? 16:34 < mpp> amd :-) 16:34 < rxr> mpp: yes, for now 16:34 < rxr> and of course review where it's coming from 16:34 < rxr> maybe it's also rather a gcc optimizer bug ... 16:34 < rxr> and also to work on updating glibc some day ... 16:34 < mpp> okay... 16:38 < rxr> some of us even mailed RMS about this issue of glibc maintainenace, but actually there was no outcome ... 16:38 < rxr> you might google for ullrich drepper and people unpleased with glibc maintenance and probable get quite some hits ... 16:38 < rxr> including the eglibc page :-( 16:39 < rxr> ulrich drepper even 16:47 < mpp> okay 16:48 < mpp> do the p4 xeon core2 build work well on an amd64 machine ? 16:48 < mpp> what optimization would you recommend for amd64 if any ? 16:57 < koan> rxr: there's a typo in http://t2-project.org/handbook/html/t2-book.html#t2.build-stages 16:57 < koan> "Normal build stages, all the selected packages are build." -> last "build" should be "built" 17:13 < rxr> thanks, changed in the book SVN 17:14 < rxr> we really have to regenerate the online view of it (HTML, PDF) 17:15 < koan> is the source DocBook? 17:18 < rxr> yes 17:18 < rxr> http://svn.exactcode.de/t2-handbook/trunk (IIRC) 17:20 < koan> When I have some time I'd like to proofread it, I'm a journalist, so I have an eye for spelling errors :-) 17:21 < rxr> you're welcome! 17:59 < koan> in the mean time, the build is going well here, except for glibc32: 17:59 < koan> configure: error: forced unwind support is required 18:15 < rxr> I would restart the build with optimization as suggestioned by mpp 18:16 < koan> will it have to rebuild all packages then? 18:17 < mpp> i say yes ! 18:19 < koan> I should have known better, "premature optimization is the root of all evil", as Donald Knuth says :-) 18:20 < mpp> it got me too 18:20 < mpp> i am reinstalling two of my machines as we speak 18:20 < mpp> i had all those nasty bugs you mentioned 18:20 < mpp> so it's time to reboot ! 18:21 < koan> how do I clean the t2 directory before a new build? 18:21 < rxr> ./scipts/Clenup - build 18:21 < rxr> err 18:21 < rxr> -build # without the space 18:21 < mpp> right 18:21 < mpp> or rm -rf build/* 18:21 < mpp> :-) 18:21 < rxr> rm -rf is not encouraged, if there is loopback stuff still mounted it can wipe the whole t2 tree due the loopback mounts 18:22 < mpp> ah. sorry 18:22 < rxr> Cleanup checks for that and umounts them first 18:22 < mpp> copy that ! 18:22 < rxr> no problem, just want to spread info for re-circulate .-) 18:22 < koan> :-) 18:22 < mpp> i had troubled myself with the rm -rf some times 18:23 < mpp> time to get wise finally ! 18:23 < mpp> :-) 18:25 < koan> okay, rebuilding... 19:01 -!- DuckFault [n=DuckFaul@rrcs-71-43-244-114.se.biz.rr.com] has joined #t2 19:18 -!- hwinkel1 [n=hwinkel@p54A74DB7.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)] 19:28 -!- LMJ [n=serwou@laf31-4-82-236-42-164.fbx.proxad.net] has joined #t2 19:46 -!- DuckFault [n=DuckFaul@rrcs-71-43-244-114.se.biz.rr.com] has quit [Remote closed the connection] 20:09 < rxr> http://www.apple.com/macbook/the-new-macbook/watch.html#large 20:19 < Ragnar|away> rxr: did you see my second question, about stripe size? 20:20 < rxr> nope 20:20 < rxr> -EDONTREMEBER 20:21 < rxr> ah build 20:21 < rxr> i use raid5 on our multi core builder 20:21 < rxr> did not tune it too special, ended up with ext3, reiser3 and xfs sucked on huge dirs rm -rf and svn up performance 20:21 < rxr> have to go now - we're late to get some fresh foot at this time in berlin - cu then 20:28 < Ragnar|away> ok take care 20:28 < mpp> bye ! 20:28 < Ragnar|away> ext3 ... interesting 20:31 -!- claudio_ch [n=claudio@217-162-160-47.dclient.hispeed.ch] has joined #t2 21:24 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has quit [Read error: 60 (Operation timed out)] 21:28 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has joined #t2 21:34 -!- DuckFault [n=DuckFaul@rrcs-71-43-244-114.se.biz.rr.com] has joined #t2 21:57 -!- mpp [n=user@i538768A6.versanet.de] has quit ["good night - good fight"] 22:25 -!- DuckFault [n=DuckFaul@rrcs-71-43-244-114.se.biz.rr.com] has quit [Remote closed the connection] 22:29 -!- DuckFault [n=DuckFaul@rrcs-71-43-244-114.se.biz.rr.com] has joined #t2 22:34 -!- gw [n=gw@2001:5c0:99fe:0:21b:63ff:fe01:f18d] has quit ["Leaving"] 23:12 -!- claudio_ch [n=claudio@217-162-160-47.dclient.hispeed.ch] has quit ["Client exiting"] 23:23 -!- tri [n=tri@p4FCF3DDD.dip0.t-ipconnect.de] has left #t2 [] --- Log closed Wed Oct 15 00:00:28 2008