T2 IRC Log: 2008-10-14
This is the log as captured by an IRC bot in the channel. The statements are those of the individual people and might not neccessarily reflect the policy and legal rules as set forth by the T2 SDE Project.
--- 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
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