T2 IRC Log: 2008-11-10
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 Mon Nov 10 00:00:30 2008
00:03 -!- mpp [n=mpp@i53875FE8.versanet.de] has joined #t2
00:55 -!- mpp [n=mpp@i53875FE8.versanet.de] has quit [Remote closed the connection]
08:44 < rxr> mtr: how broken?
08:44 < rxr> mpp: how broken?
11:34 -!- gw [n=gw@2001:44b8:62:7f0:21b:63ff:fe01:f18d] has quit [Read error: 113 (No route to host)]
11:37 -!- gw [n=gw@2001:44b8:62:7f0:21b:63ff:fe01:f18d] has joined #t2
12:56 -!- mpp [n=mpp@i53875FE8.versanet.de] has joined #t2
12:57 < mpp> moinmoin
13:06 < koan> rxr: did you by any chance attend FOSDEM in Brussels one of the last years?
13:07 < mpp> hey koan
13:08 < koan> hi mpp
13:08 < mpp> im just doing a fresh checkout + build of rescue an 10-minimal
13:09 < mpp> see if things are back to normal
13:16 -!- nick21 [n=user21@202-176-88-55.static.asianet.co.th] has joined #t2
13:21 -!- michael-i [n=michael-@141.41.40.103] has joined #t2
13:23 < nick21> hello
13:24 < mpp> hey nick21
13:25 < rxr> koan: nope, I normally do not have any free time during the FOSDEM timeslots
13:26 < koan> rxr: a pity, otherwise I'd buy you a beer the next time :-)
13:27 -!- nick21 [n=user21@202-176-88-55.static.asianet.co.th] has quit ["leaving"]
13:27 < mpp> hey rxr
13:27 < mpp> ncurses is building fine now
13:28 < mpp> glibc with rescue target is building as we speak
13:28 < michael-i> Just wondering if anyone is actively building blackfin targets? I'm encountering errors when using the default embedded target: http://pastebin.ca/1250231
13:28 < michael-i> I'm building from svn trunk on 7.0rc2
13:30 < rxr> yes we do
13:32 < rxr> hm - strange linux-header patch does not apply
13:32 < michael-i> Could you recommend a known working configuration? Rescue CD?
13:32 < rxr> your setup should be find
13:32 < rxr> looks like some blackfin specificy is out-of-sync in trunk
13:32 < michael-i> ok
13:32 < rxr> though I just recently test-build a rather huge set on blackfin...
13:32 < mpp> target/rescue glibc built successfull - yeahh
13:33 < mpp> :-)
13:33 < rxr> mpp: i wire a Os/O2 translation to glibc
13:33 < rxr> the error is too strange to track in the glibc sources quickly
13:33 < mpp> -O2 Option did the trick
13:33 < rxr> ah - ok
13:33 < mpp> thats oky
13:33 < rxr> well - it builds if you sleect size now as well
13:33 < mpp> digging with google
13:33 < michael-i> rxr: let me know if I can provide more information, I'm glad to go diffing for it
13:33 < michael-i> s/diffing/digging
13:33 < rxr> just htat glibc is then falling back to speed O2 due the strange inlining issue
13:34 < mpp> it is a prob with glibc-2.7 that many are encoutering
13:34 < rxr> michael-i: just look at the patcht that fail to apply in your error-log
13:34 < rxr> should be possible to see quite quickly what's going wrong
13:34 < rxr> e.g. version mismatch old patch etc.
13:37 < rxr> hm - it build for me
13:37 < rxr> maybe it's a regression with changed/fixed architecture overlays recently
13:37 < rxr> I give a test build a try on my reference tester also to take a look
13:40 < mpp> http://www.google.de/url?sa=t&source=web&ct=res&cd=4&url=http%3A%2F%2Fwebui.sourcelabs.com%2Fapi%2FFilter_project%25253Aglibc%2FTag_software%25253Aglibc-2.7&ei=DCsYSbm0LIie1wbn6JTmCg&usg=AFQjCNHcUtEc33pZFtpvQbEu3QVOKCS1rQ&sig2=MR4rhE-tFi3G8ggMEz6XIw
13:40 < rxr> I guess you can savely remove the scsi patch in the blackfin dir
13:40 < rxr> I think with a typo in the older t2 scripts the patch was just not applied at all :-)
13:40 < mpp> as pointed out the -Os seems buggy regarding inline option
13:40 < michael-i> ok, rxr. thanks for the quick feedback on that
13:40 < mpp> felix von leitener had this issue already back in 2007
13:41 < rxr> yes, and the suse guy just said, build with default opts ...
13:41 < rxr> I google the thing for some minutes already
13:41 < mpp> it is specifix to x64 arch seems
13:41 < mpp> my rescue targets where all x64
13:41 < rxr> I think it always failed here with Os
13:42 < mpp> but it just occured since t2 update glibc -> 2.7
13:42 < mpp> on 2.6 everything went fine
13:42 < rxr> yes, it's a new glibc bug
13:42 < mpp> i build rescue regularly
13:42 < rxr> yes, it the past it just worked
13:42 < rxr> it's a Os regression with glibc-2.7
13:43 < mpp> i mean we can leave the Os witch and i'll apply a patch to my target
13:43 < rxr> which patch ?
13:43 < mpp> is this option -O2 also used for stage 5 building of glibc ?
13:43 < rxr> the optimization option is used for _everything_
13:44 < mpp> ahhh..
13:44 < mpp> thats somewhat bad ...
13:44 < rxr> in t2 trunk:HEAD I already workarounded glibc by translating Os to O2 in the glibc.conf
13:44 < rxr> what is bad ?
13:44 < mpp> afaikt the glibc was the one that always core- dumped in the conftest
13:45 < rxr> glibc was the one that "might" have had a amd64 optimization bug
13:45 < mpp> i mean -O2 is okay for speed ..
13:45 < mpp> id def had
13:45 < mpp> i did 2 consecutive builds now with my targets
13:45 < rxr> if would be great if you could check if the glibc-2.7 update fixed the "random/stray" segfaults with amd64 optimization
13:45 < mpp> no more dump from glibc
13:45 < rxr> with amd64 optimization?
13:45 < mpp> ill do so
13:45 < mpp> nope even without
13:46 < rxr> because generic and core2 did not had this issue on my side
13:46 < mpp> ill have host target rebuilt for amd64 and report back
13:48 < mpp> again thanx for the large effort rxr
13:48 < mpp> :-)
13:48 < rxr> you're welcome :-)
13:49 < rxr> hm - strange blackfind just builds here
13:52 < michael-i> rxr, after removing the scsi patch, I have a newly rejected patch to the kernel's fs/Makefile (http://pastebin.ca/1250242)
13:53 < michael-i> There is a different test for ramfs being performed which causes it to fail
13:55 < rxr> ah - ok - it's patching squashfs in
13:56 < rxr> hm - on the other hand so is it doing on my side
13:56 < michael-i> perhaps my default config has been messed up?
13:57 < rxr> the major difference is that I do not build embedded, but the generic target (that is as much as possible in default testting) maybe that makes a difference in some subtle detail
13:57 < michael-i> I'll give generic a try
13:57 < rxr> and I test if our mainline linux-header is new enough to have all blackfin bits, now
14:00 < michael-i> generic fails identically
14:00 < michael-i> I have to go for a bit...be back later
14:09 < rxr> strange thing
14:09 < rxr> really
14:42 -!- mpp_ [n=mpp@i53877AE1.versanet.de] has joined #t2
14:42 -!- mpp [n=mpp@i53875FE8.versanet.de] has quit [Read error: 110 (Connection timed out)]
14:42 -!- mpp_ is now known as mpp
14:51 < mpp> fyi http://pastebin.com/m265a01d2 always occurs on stage 2 gcc
15:19 < michael-i> back
15:20 < mpp> hey michael-i
15:32 < michael-i> I'm testing the same build using power pc as architecture out of curiosity and getting much further.
15:33 < rxr> michael-i: I removed the blackfind custom linux-header in trunk already
15:33 < rxr> michael-i: can you svn up and reset with blackfin
15:34 < michael-i> i saw the commit message. will do asap, rxr
15:38 < CIA-4> rene * r31198 /trunk/package/www/firefox/firefox.conf: * improved firefox to build with older, non-TLS/NPTL glibc's
15:38 < rxr> though still strange that you get different errors than I
15:40 < CIA-4> rene * r31199 /trunk/package/base/glibc/glibc.conf: * fixed glibc-2.7 to build with size optimization, by enforcing O2, for now
15:42 < CIA-4> rene * r31200 /trunk/package/base/glibc/x86_64-string.patch.disabled: * removed already disabled glibc/x86_64 string operation optimization patch
15:45 < CIA-4> rene * r31201 /trunk/architecture/blackfin/package/linux-header/:
15:46 < CIA-4> * removed blackfin specific linux-header overlay, all user-space
15:46 < CIA-4> required defines apparently exposed by the current mainline
15:46 < CIA-4> linux-header
15:59 < michael-i> rxr, with a fresh checkout of svn in a new directory everything's working (so far I'm to base/flex without any errors)
16:17 < mpp> hey rxr
16:18 < mpp> did some further build and confirm that gcc does segfault conftest all the time
16:18 < mpp> no matter what stage
16:18 < mpp> this has been from the beggining
16:18 < mpp> is it worth to track down this error ?
16:20 < rxr> in theory yes, but I'll not have the extra time for it
16:20 < rxr> it only happens with amd64 optimizations, right?
16:20 < rxr> generic and core2 do work ?
16:27 < michael-i> my blackfin build now made it to base/binutils: error-log + configure.rej (http://pastebin.ca/1250343)
16:27 < rxr> interesting
16:28 < michael-i> I should always be checking "this is a cross-compile" right?
16:28 < rxr> probably the same problem as the linux-header before, somehow patches are handled differents on my and your system
16:28 < michael-i> hmm
16:28 < rxr> yes, but it will not make a different for this error
16:28 < rxr> you are sure you are on trunk:HEAD ?
16:28 < michael-i> "At revision 31201"
16:29 < michael-i> but this is a quad-proc machine...perhaps somethings aren't resource safe?
16:29 < rxr> (our man regression tester is an 8way for a year now)
16:30 < rxr> s/man/main/
16:30 < michael-i> ok, so no ;)
16:31 < michael-i> should I update my t2-host system?
16:31 < rxr> no
16:31 < rxr> this should not have anything todo with the host environment
16:31 < rxr> and as you can reproduce it right now I rather like to see it fixed than hitting the next person giving it a try .-)
16:32 < michael-i> just let me know what you need, I'm here for another 90 minutes and am very willing to help
16:32 < rxr> the patch in question just applies here:
16:32 < rxr> Apply patch /mnt/builder/t2-trunk-cross/architecture/blackfin/package/binutils/texinfo-version.patch ...
16:32 < rxr> patching file configure
16:32 < rxr> Hunk #1 succeeded at 3679 (offset -2513 lines).
16:33 < rxr> hm - ok - maybe it's the host systems patch and mine is more relaxed than yours=
16:33 < rxr> ?
16:33 < rxr> which patch version do you have ?
16:34 < michael-i> 2.5.4
16:34 < rxr> hm - ok /me too
16:34 < rxr> mine -q patch ?
16:34 < rxr> patch 2.5.4 7.0-trunk
16:34 < michael-i> patch 2.5.4 7.0-stable
16:35 < rxr> admitedly the offset of -2513 lines is rather huge
16:35 < michael-i> a bit
16:35 < rxr> maybe a less fuzzy patch really is the case
16:35 < rxr> ok - I break my build by mangling my patch and then we md5sum the file that should get patched
16:36 < rxr> which stage was this binutils build? 0- 1- ?
16:36 < michael-i> 0? (== 16:06:39 =[0]=> Building base/binutils [2.17-bfin-r1613 8.0-trunk].)
16:37 < rxr> 0, yes
16:38 < rxr> ah - have to rebuild again, my auto-builder has "always clean failed source trees enabled" ...
16:44 < rxr> cd src.binutils.*
16:44 < rxr> binutils-2.17# md5sum configure
16:44 < rxr> cf9a54e3ac26fde457711cebad4dc17b configure
16:45 < michael-i> fc36abaa7be1095f24519b4b1c398db4 configure
16:45 < rxr> hm
16:46 < rxr> can you upload / send me your configure ?
16:46 < rxr> I want to try to apply the patch with my patch program
16:48 < michael-i> working on it, I'll send via e-mail if that's ok?
16:48 < rxr> yep
16:48 < rxr> I'll also upload my working log
16:48 < rxr> maybe attach your full log as well so we can both diff / scroll over it
16:49 < michael-i> which log exactly?
16:49 < rxr> your full 0-binutils
16:49 < rxr> more comfortable and bit exact via email than pulling it out of the pastebin
16:52 < michael-i> on their way
16:53 < rxr> btw. you could probably also remove the offending patch it's only important if you have an older texinfo or what it was
16:53 < rxr> but fixing this would be nice (tm)
16:54 < rxr> http://people.exactcode.de/~rene/blackfin-uclibc-0-binutils.log
16:54 < michael-i> the less workarounds needed for other people the better
16:55 < rxr> yep
16:55 < michael-i> you're using uclibc here and I'm not
16:56 < rxr> are you sure? I think blackfin will only build with uclibc
16:56 < rxr> can you force t2 in using something else for bfin ?
16:57 < michael-i> I'm just looking at both of our "gcc is /....." lines
16:57 < michael-i> mine says "default-8.0-trunk-generic-blackfin-bf533-cross" and yours is "blackfin-uclibc-cross-8.0-trunk-generic-blackfin-bf533-cross"
16:58 < rxr> ok - that is ust my config name - the libc is not stored in the uuid
16:58 < michael-i> always learning something new...
16:59 < mpp> hey rxr - i have an updated package for git 1.6.0.3 send to the mailing list it's tested - it has a few new deps - conf is filled up to build proper and docs / man /html are now on
16:59 < mpp> would be great if you could push it to svn
16:59 < mpp> thnx
17:02 < rxr> take a look in a second
17:02 < mpp> k
17:02 < rxr> michael-i: very strange when I diff the logs, your's and mine, the patches are applied in the same order etc. and then the final textinfo-version.patch is failing
17:03 < michael-i> rxr, can I add a flag to patch to give you better info?
17:03 < rxr> I rediff that patch - maybe that helps by not making the fuzz too big
17:03 < rxr> not really, not that I can think of something
17:06 < michael-i> i can test that before you commit it if you like
17:07 < rxr> I think I
17:07 < rxr> 'll just commit it in a sec, less fuzzy patch should not hurt :-)
17:07 < michael-i> gotcha
17:07 < rxr> really strange thing, in 15y of Unix hacking I never experienced something like this
17:08 < michael-i> well I'm glad it wasn't a dumb question then!
17:12 < rxr> it's in
17:12 < CIA-4> rene * r31202 /trunk/architecture/blackfin/package/binutils/texinfo-version.patch:
17:12 < CIA-4> * rediffed binutils/texinfo-version.patch, to not have a fuzz
17:12 < CIA-4> of -2513 lines, and hopefully apply more often
17:14 < michael-i> you're not going to like this: !> Hunk #1 FAILED at 3679
17:15 < rxr> pff, where the heck is this coming from?!?!?!?
17:16 < michael-i> i did: svn co; ./scripts/Clean; ./scripts/Build-Target. Is there something more to be done before retrying the build
17:16 < michael-i> err.. svn up actually
17:19 < michael-i> it looks like configure already has this patch applied
17:25 < michael-i> when I look at my configure, 3682 already reflects the updated regex, rxr
17:25 < CIA-4> rene * r31190 /trunk/package/base/pciutils/pciutils.desc: * updated pciutils (3.0.2 -> 3.0.3)
17:26 < CIA-4> rene * r31191 /trunk/package/graphic/poppler/poppler.desc: * updated poppler (0.10.0 -> 0.10.1)
17:26 < CIA-4> rene * r31196 /trunk/package/perl/perl-mp3-info/perl-mp3-info.desc: * updated perl-mp3-info (1.23 -> 1.24)
17:26 < CIA-4> rene * r31195 /trunk/package/perl/perl-anyevent/perl-anyevent.desc: * updated perl-anyevent (4.31 -> 4.32)
17:26 < CIA-4> rene * r31193 /trunk/package/perl/perl-date-time/perl-date-time.desc: * updated perl-date-time (0.4305 -> 0.4401)
17:26 < CIA-4> rene * r31194 /trunk/package/perl/perl-libwww/perl-libwww.desc: * updated perl-libwww (5.819 -> 5.820)
17:26 < rxr> michael-i: hm
17:26 < CIA-4> rene * r31192 /trunk/package/textproc/iso-codes/iso-codes.desc: * updated iso-codes (3.3 -> 3.4)
17:27 < CIA-4> rene * r31197 /trunk/package/develop/git/git.desc: * updated git (1.6.0.3 -> 1.6.0.4)
17:29 < rxr> mpp: svn diff of the git files would have been a dream :-)
17:30 < mpp> ahm. oky
17:30 < mpp> sorry
17:30 < rxr> but I'll still get it in ...
17:31 < mpp> noted for the feature
17:31 < mpp> :-)
17:34 < mpp> looks like svn.exactocode is on 31202
17:34 < mpp> but rxr pushed 31197
17:34 < mpp> ???
17:35 < mpp> am i missing something ...
17:36 < rxr> this CIA thing is lagging
17:37 < rxr> those commits are from the morning
17:38 < mpp> puhh...
17:43 < mpp> damnit xmlto dep for git slipped...
17:43 < mpp> needs to be in git.cache
17:43 < mpp> hold on the git package rxr
17:44 < mpp> i'll have to resync it with my local repo
17:44 < mpp> sorry
17:44 < mpp> ill provide an apropriate diff later on
17:46 < rxr> I could test build and add it
17:46 < rxr> had to kick some VM anyway ...
17:47 < mpp> im on it
17:47 < mpp> sorry for the mess
17:47 < mpp> im rebuilding the synced repo now
17:48 < rxr> hm - indeed
17:48 < mpp> if it's flawless i'll have it diffed and tared to the ml
17:48 < rxr> michael-i: I wiped my tarball and let svn repull the sources, now the patch does no longer apply
17:48 < michael-i> rxr, glad to hear it's not working...
17:49 < michael-i> I have to go in about 10 minutes, would you like any more info?
17:49 < rxr> ok - and it looks the "magicaly fixed binutils-bfin" package is on our mirror
17:49 < rxr> so we just wipe the patch and go
17:50 < michael-i> good deal
17:53 < rxr> mpp: var_append var ' ' 'doc, ...' is better
17:54 < rxr> though not too important for git, but for other packages targets could set other stuff you would voerwrite
17:54 < rxr> also overwriting makeinstopt probably breaks cross building as it at least also wips DESTDIR
17:54 < rxr> I fixed that and commit after a test build
17:54 < rxr> load average: 12.06, 6.14, 2.59
17:55 < mpp> but the docs will not get build otherwise
17:56 < mpp> e.g git help diff
17:56 < rxr> I mean this cleaned changes:
17:56 < rxr> +var_append makeopt ' ' 'all doc info'
17:56 < rxr> +var_append makeinstopt ' ' 'install-doc install-info install-html'
17:56 < mpp> fails on the origin .conf
17:56 < rxr> this should result in your intended behaviour without wiping pre-set variables
17:56 < mpp> i dont't get it probably
17:57 < rxr> you had makeopt="" there
17:57 < mpp> ah. okay
17:57 < rxr> this resets the whole makeopt, usually, especially during cross builds there is a whole lot already set in it
17:57 -!- michael-i [n=michael-@141.41.40.103] has quit []
17:57 < rxr> especially makeinstopt which carrie DESTDIR=$root
17:57 < mpp> so i guess you changed allready on your side :-)
17:58 < mpp> i was not aware of the difference
17:58 < rxr> yep, that's why I teach you advanced packaging topics to save my time/work in the future :-)
17:58 < mpp> the updated cache file is missing the xmlto as dep
17:58 < mpp> ill have to reread
17:59 < CIA-4> rene * r31203 /trunk/architecture/blackfin/package/binutils/texinfo-version.patch:
17:59 < CIA-4> * removed blackfin/.../binutils/texinfo-version.patch, the fixed configure
17:59 < CIA-4> already made it into the file on the t2 mirrors (?!?!?)
18:04 < rxr> hm - git breaks here:
18:04 < rxr> Can't locate Dpkg.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0/i686-t2-linux-gnu /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.1
18:04 < rxr> 0.0/i686-t2-linux-gnu /usr/lib/perl5/site_perl/5.10.0 /opt/lib/perl5/vendor_perl/5.10.0/i686-t2-linux-gnu /opt/lib/perl5/vendor_perl/5.
18:04 < rxr> 10.0 /opt/lib/perl5/vendor_perl .) at /usr/sbin/install-info line 8.
18:04 < rxr> BEGIN failed--compilation aborted at /usr/sbin/install-info line 8.
18:04 < rxr> Can't locate Dpkg.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0/i686-t2-linux-gnu /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.1
18:04 < rxr> 0.0/i686-t2-linux-gnu /usr/lib/perl5/site_perl/5.10.0 /opt/lib/perl5/vendor_perl/5.10.0/i686-t2-linux-gnu /opt/lib/perl5/vendor_perl/5.
18:04 < rxr> 10.0 /opt/lib/perl5/vendor_perl .) at /usr/sbin/install-info line 8.
18:04 < rxr> BEGIN failed--compilation aborted at /usr/sbin/install-info line 8.
18:04 < rxr> make[1]: *** [install-info] Error 2
18:06 < mpp> hm...
18:06 < mpp> i don't have this on my site
18:06 < mpp> i also posted an updated cache file
18:07 < mpp> it needs xslt asciidoc
18:07 < mpp> and xmlto
18:15 < CIA-4> rene * r31205 /trunk/package/base/strace/ (arch-0-avr32.patch strace.desc):
18:15 < CIA-4> Adam Stirk:
18:15 < CIA-4> * updated strace (4.5.17 -> 4.5.18)
18:17 < CIA-4> rene * r31206 /trunk/package/network/ddclient/ddclient.init:
18:17 < CIA-4> Adam Stirk:
18:17 < CIA-4> * added ddclient.init script
18:22 < CIA-4> rene * r31207 /trunk/package/multimedia/libsimage/ (5 files):
18:22 < CIA-4> Adam Stirk:
18:22 < CIA-4> * added libsimage (1.6.1) - The simage Library
18:26 < CIA-4> rene * r31208 /trunk/package/audio/libmpcdec/ (. libmpcdec.cache libmpcdec.desc):
18:26 < CIA-4> Adam Stirk:
18:26 < CIA-4> * added libmpcdec (v1.2.6) - Musepack is an audio compression format with a strong emphasis on high quality
18:29 < rxr> http://science.slashdot.org/science/08/11/09/1558241.shtml
18:52 < CIA-4> rene * r31209 /trunk/package/multimedia/libsimage/libsimage.desc: * marked libsimage to cross build
18:54 < mpp> http://www.theinquirer.net/gb/inquirer/news/2008/11/06/redhat-amd-migrate-vms-across
19:21 < rxr> hm - I do this for months, nothing new, probably KVM anyway
20:15 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has joined #t2
20:32 < tri> moin
20:39 < rxr> hi tri
20:39 < tri> hi
20:40 < tri> rxr: do you have ever build v4l-dvb?
20:40 < rxr> the kernel module ?
20:45 < tri> the source from linuxtv.org
20:46 < tri> how is the process - most of the stuff is already in the main kernel, right?
20:46 < rxr> I do not know what exactly you mean .-)
20:46 < rxr> all stuff I ever build lives in form of t2 packages :-)
20:46 < rxr> if it's not in t2 I did not build it, or it was useless :-)
20:52 < rxr> ok - gotta go - cu
20:56 < tri> :-)
20:56 < tri> cu
21:51 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has left #t2 []
22:06 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has joined #t2
22:08 -!- mqueiros [n=mqueiros@217.70.75.130] has joined #t2
22:42 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has left #t2 []
22:43 -!- mqueiros [n=mqueiros@217.70.75.130] has quit []
22:57 -!- mpp [n=mpp@i53877AE1.versanet.de] has quit ["ChatZilla 0.9.83 [Firefox 3.0.3/2008092510]"]
--- Log closed Tue Nov 11 00:00:36 2008
00:03 -!- mpp [n=mpp@i53875FE8.versanet.de] has joined #t2
00:55 -!- mpp [n=mpp@i53875FE8.versanet.de] has quit [Remote closed the connection]
08:44 < rxr> mtr: how broken?
08:44 < rxr> mpp: how broken?
11:34 -!- gw [n=gw@2001:44b8:62:7f0:21b:63ff:fe01:f18d] has quit [Read error: 113 (No route to host)]
11:37 -!- gw [n=gw@2001:44b8:62:7f0:21b:63ff:fe01:f18d] has joined #t2
12:56 -!- mpp [n=mpp@i53875FE8.versanet.de] has joined #t2
12:57 < mpp> moinmoin
13:06 < koan> rxr: did you by any chance attend FOSDEM in Brussels one of the last years?
13:07 < mpp> hey koan
13:08 < koan> hi mpp
13:08 < mpp> im just doing a fresh checkout + build of rescue an 10-minimal
13:09 < mpp> see if things are back to normal
13:16 -!- nick21 [n=user21@202-176-88-55.static.asianet.co.th] has joined #t2
13:21 -!- michael-i [n=michael-@141.41.40.103] has joined #t2
13:23 < nick21> hello
13:24 < mpp> hey nick21
13:25 < rxr> koan: nope, I normally do not have any free time during the FOSDEM timeslots
13:26 < koan> rxr: a pity, otherwise I'd buy you a beer the next time :-)
13:27 -!- nick21 [n=user21@202-176-88-55.static.asianet.co.th] has quit ["leaving"]
13:27 < mpp> hey rxr
13:27 < mpp> ncurses is building fine now
13:28 < mpp> glibc with rescue target is building as we speak
13:28 < michael-i> Just wondering if anyone is actively building blackfin targets? I'm encountering errors when using the default embedded target: http://pastebin.ca/1250231
13:28 < michael-i> I'm building from svn trunk on 7.0rc2
13:30 < rxr> yes we do
13:32 < rxr> hm - strange linux-header patch does not apply
13:32 < michael-i> Could you recommend a known working configuration? Rescue CD?
13:32 < rxr> your setup should be find
13:32 < rxr> looks like some blackfin specificy is out-of-sync in trunk
13:32 < michael-i> ok
13:32 < rxr> though I just recently test-build a rather huge set on blackfin...
13:32 < mpp> target/rescue glibc built successfull - yeahh
13:33 < mpp> :-)
13:33 < rxr> mpp: i wire a Os/O2 translation to glibc
13:33 < rxr> the error is too strange to track in the glibc sources quickly
13:33 < mpp> -O2 Option did the trick
13:33 < rxr> ah - ok
13:33 < mpp> thats oky
13:33 < rxr> well - it builds if you sleect size now as well
13:33 < mpp> digging with google
13:33 < michael-i> rxr: let me know if I can provide more information, I'm glad to go diffing for it
13:33 < michael-i> s/diffing/digging
13:33 < rxr> just htat glibc is then falling back to speed O2 due the strange inlining issue
13:34 < mpp> it is a prob with glibc-2.7 that many are encoutering
13:34 < rxr> michael-i: just look at the patcht that fail to apply in your error-log
13:34 < rxr> should be possible to see quite quickly what's going wrong
13:34 < rxr> e.g. version mismatch old patch etc.
13:37 < rxr> hm - it build for me
13:37 < rxr> maybe it's a regression with changed/fixed architecture overlays recently
13:37 < rxr> I give a test build a try on my reference tester also to take a look
13:40 < mpp> http://www.google.de/url?sa=t&source=web&ct=res&cd=4&url=http%3A%2F%2Fwebui.sourcelabs.com%2Fapi%2FFilter_project%25253Aglibc%2FTag_software%25253Aglibc-2.7&ei=DCsYSbm0LIie1wbn6JTmCg&usg=AFQjCNHcUtEc33pZFtpvQbEu3QVOKCS1rQ&sig2=MR4rhE-tFi3G8ggMEz6XIw
13:40 < rxr> I guess you can savely remove the scsi patch in the blackfin dir
13:40 < rxr> I think with a typo in the older t2 scripts the patch was just not applied at all :-)
13:40 < mpp> as pointed out the -Os seems buggy regarding inline option
13:40 < michael-i> ok, rxr. thanks for the quick feedback on that
13:40 < mpp> felix von leitener had this issue already back in 2007
13:41 < rxr> yes, and the suse guy just said, build with default opts ...
13:41 < rxr> I google the thing for some minutes already
13:41 < mpp> it is specifix to x64 arch seems
13:41 < mpp> my rescue targets where all x64
13:41 < rxr> I think it always failed here with Os
13:42 < mpp> but it just occured since t2 update glibc -> 2.7
13:42 < mpp> on 2.6 everything went fine
13:42 < rxr> yes, it's a new glibc bug
13:42 < mpp> i build rescue regularly
13:42 < rxr> yes, it the past it just worked
13:42 < rxr> it's a Os regression with glibc-2.7
13:43 < mpp> i mean we can leave the Os witch and i'll apply a patch to my target
13:43 < rxr> which patch ?
13:43 < mpp> is this option -O2 also used for stage 5 building of glibc ?
13:43 < rxr> the optimization option is used for _everything_
13:44 < mpp> ahhh..
13:44 < mpp> thats somewhat bad ...
13:44 < rxr> in t2 trunk:HEAD I already workarounded glibc by translating Os to O2 in the glibc.conf
13:44 < rxr> what is bad ?
13:44 < mpp> afaikt the glibc was the one that always core- dumped in the conftest
13:45 < rxr> glibc was the one that "might" have had a amd64 optimization bug
13:45 < mpp> i mean -O2 is okay for speed ..
13:45 < mpp> id def had
13:45 < mpp> i did 2 consecutive builds now with my targets
13:45 < rxr> if would be great if you could check if the glibc-2.7 update fixed the "random/stray" segfaults with amd64 optimization
13:45 < mpp> no more dump from glibc
13:45 < rxr> with amd64 optimization?
13:45 < mpp> ill do so
13:45 < mpp> nope even without
13:46 < rxr> because generic and core2 did not had this issue on my side
13:46 < mpp> ill have host target rebuilt for amd64 and report back
13:48 < mpp> again thanx for the large effort rxr
13:48 < mpp> :-)
13:48 < rxr> you're welcome :-)
13:49 < rxr> hm - strange blackfind just builds here
13:52 < michael-i> rxr, after removing the scsi patch, I have a newly rejected patch to the kernel's fs/Makefile (http://pastebin.ca/1250242)
13:53 < michael-i> There is a different test for ramfs being performed which causes it to fail
13:55 < rxr> ah - ok - it's patching squashfs in
13:56 < rxr> hm - on the other hand so is it doing on my side
13:56 < michael-i> perhaps my default config has been messed up?
13:57 < rxr> the major difference is that I do not build embedded, but the generic target (that is as much as possible in default testting) maybe that makes a difference in some subtle detail
13:57 < michael-i> I'll give generic a try
13:57 < rxr> and I test if our mainline linux-header is new enough to have all blackfin bits, now
14:00 < michael-i> generic fails identically
14:00 < michael-i> I have to go for a bit...be back later
14:09 < rxr> strange thing
14:09 < rxr> really
14:42 -!- mpp_ [n=mpp@i53877AE1.versanet.de] has joined #t2
14:42 -!- mpp [n=mpp@i53875FE8.versanet.de] has quit [Read error: 110 (Connection timed out)]
14:42 -!- mpp_ is now known as mpp
14:51 < mpp> fyi http://pastebin.com/m265a01d2 always occurs on stage 2 gcc
15:19 < michael-i> back
15:20 < mpp> hey michael-i
15:32 < michael-i> I'm testing the same build using power pc as architecture out of curiosity and getting much further.
15:33 < rxr> michael-i: I removed the blackfind custom linux-header in trunk already
15:33 < rxr> michael-i: can you svn up and reset with blackfin
15:34 < michael-i> i saw the commit message. will do asap, rxr
15:38 < CIA-4> rene * r31198 /trunk/package/www/firefox/firefox.conf: * improved firefox to build with older, non-TLS/NPTL glibc's
15:38 < rxr> though still strange that you get different errors than I
15:40 < CIA-4> rene * r31199 /trunk/package/base/glibc/glibc.conf: * fixed glibc-2.7 to build with size optimization, by enforcing O2, for now
15:42 < CIA-4> rene * r31200 /trunk/package/base/glibc/x86_64-string.patch.disabled: * removed already disabled glibc/x86_64 string operation optimization patch
15:45 < CIA-4> rene * r31201 /trunk/architecture/blackfin/package/linux-header/:
15:46 < CIA-4> * removed blackfin specific linux-header overlay, all user-space
15:46 < CIA-4> required defines apparently exposed by the current mainline
15:46 < CIA-4> linux-header
15:59 < michael-i> rxr, with a fresh checkout of svn in a new directory everything's working (so far I'm to base/flex without any errors)
16:17 < mpp> hey rxr
16:18 < mpp> did some further build and confirm that gcc does segfault conftest all the time
16:18 < mpp> no matter what stage
16:18 < mpp> this has been from the beggining
16:18 < mpp> is it worth to track down this error ?
16:20 < rxr> in theory yes, but I'll not have the extra time for it
16:20 < rxr> it only happens with amd64 optimizations, right?
16:20 < rxr> generic and core2 do work ?
16:27 < michael-i> my blackfin build now made it to base/binutils: error-log + configure.rej (http://pastebin.ca/1250343)
16:27 < rxr> interesting
16:28 < michael-i> I should always be checking "this is a cross-compile" right?
16:28 < rxr> probably the same problem as the linux-header before, somehow patches are handled differents on my and your system
16:28 < michael-i> hmm
16:28 < rxr> yes, but it will not make a different for this error
16:28 < rxr> you are sure you are on trunk:HEAD ?
16:28 < michael-i> "At revision 31201"
16:29 < michael-i> but this is a quad-proc machine...perhaps somethings aren't resource safe?
16:29 < rxr> (our man regression tester is an 8way for a year now)
16:30 < rxr> s/man/main/
16:30 < michael-i> ok, so no ;)
16:31 < michael-i> should I update my t2-host system?
16:31 < rxr> no
16:31 < rxr> this should not have anything todo with the host environment
16:31 < rxr> and as you can reproduce it right now I rather like to see it fixed than hitting the next person giving it a try .-)
16:32 < michael-i> just let me know what you need, I'm here for another 90 minutes and am very willing to help
16:32 < rxr> the patch in question just applies here:
16:32 < rxr> Apply patch /mnt/builder/t2-trunk-cross/architecture/blackfin/package/binutils/texinfo-version.patch ...
16:32 < rxr> patching file configure
16:32 < rxr> Hunk #1 succeeded at 3679 (offset -2513 lines).
16:33 < rxr> hm - ok - maybe it's the host systems patch and mine is more relaxed than yours=
16:33 < rxr> ?
16:33 < rxr> which patch version do you have ?
16:34 < michael-i> 2.5.4
16:34 < rxr> hm - ok /me too
16:34 < rxr> mine -q patch ?
16:34 < rxr> patch 2.5.4 7.0-trunk
16:34 < michael-i> patch 2.5.4 7.0-stable
16:35 < rxr> admitedly the offset of -2513 lines is rather huge
16:35 < michael-i> a bit
16:35 < rxr> maybe a less fuzzy patch really is the case
16:35 < rxr> ok - I break my build by mangling my patch and then we md5sum the file that should get patched
16:36 < rxr> which stage was this binutils build? 0- 1- ?
16:36 < michael-i> 0? (== 16:06:39 =[0]=> Building base/binutils [2.17-bfin-r1613 8.0-trunk].)
16:37 < rxr> 0, yes
16:38 < rxr> ah - have to rebuild again, my auto-builder has "always clean failed source trees enabled" ...
16:44 < rxr> cd src.binutils.*
16:44 < rxr> binutils-2.17# md5sum configure
16:44 < rxr> cf9a54e3ac26fde457711cebad4dc17b configure
16:45 < michael-i> fc36abaa7be1095f24519b4b1c398db4 configure
16:45 < rxr> hm
16:46 < rxr> can you upload / send me your configure ?
16:46 < rxr> I want to try to apply the patch with my patch program
16:48 < michael-i> working on it, I'll send via e-mail if that's ok?
16:48 < rxr> yep
16:48 < rxr> I'll also upload my working log
16:48 < rxr> maybe attach your full log as well so we can both diff / scroll over it
16:49 < michael-i> which log exactly?
16:49 < rxr> your full 0-binutils
16:49 < rxr> more comfortable and bit exact via email than pulling it out of the pastebin
16:52 < michael-i> on their way
16:53 < rxr> btw. you could probably also remove the offending patch it's only important if you have an older texinfo or what it was
16:53 < rxr> but fixing this would be nice (tm)
16:54 < rxr> http://people.exactcode.de/~rene/blackfin-uclibc-0-binutils.log
16:54 < michael-i> the less workarounds needed for other people the better
16:55 < rxr> yep
16:55 < michael-i> you're using uclibc here and I'm not
16:56 < rxr> are you sure? I think blackfin will only build with uclibc
16:56 < rxr> can you force t2 in using something else for bfin ?
16:57 < michael-i> I'm just looking at both of our "gcc is /....." lines
16:57 < michael-i> mine says "default-8.0-trunk-generic-blackfin-bf533-cross" and yours is "blackfin-uclibc-cross-8.0-trunk-generic-blackfin-bf533-cross"
16:58 < rxr> ok - that is ust my config name - the libc is not stored in the uuid
16:58 < michael-i> always learning something new...
16:59 < mpp> hey rxr - i have an updated package for git 1.6.0.3 send to the mailing list it's tested - it has a few new deps - conf is filled up to build proper and docs / man /html are now on
16:59 < mpp> would be great if you could push it to svn
16:59 < mpp> thnx
17:02 < rxr> take a look in a second
17:02 < mpp> k
17:02 < rxr> michael-i: very strange when I diff the logs, your's and mine, the patches are applied in the same order etc. and then the final textinfo-version.patch is failing
17:03 < michael-i> rxr, can I add a flag to patch to give you better info?
17:03 < rxr> I rediff that patch - maybe that helps by not making the fuzz too big
17:03 < rxr> not really, not that I can think of something
17:06 < michael-i> i can test that before you commit it if you like
17:07 < rxr> I think I
17:07 < rxr> 'll just commit it in a sec, less fuzzy patch should not hurt :-)
17:07 < michael-i> gotcha
17:07 < rxr> really strange thing, in 15y of Unix hacking I never experienced something like this
17:08 < michael-i> well I'm glad it wasn't a dumb question then!
17:12 < rxr> it's in
17:12 < CIA-4> rene * r31202 /trunk/architecture/blackfin/package/binutils/texinfo-version.patch:
17:12 < CIA-4> * rediffed binutils/texinfo-version.patch, to not have a fuzz
17:12 < CIA-4> of -2513 lines, and hopefully apply more often
17:14 < michael-i> you're not going to like this: !> Hunk #1 FAILED at 3679
17:15 < rxr> pff, where the heck is this coming from?!?!?!?
17:16 < michael-i> i did: svn co; ./scripts/Clean; ./scripts/Build-Target. Is there something more to be done before retrying the build
17:16 < michael-i> err.. svn up actually
17:19 < michael-i> it looks like configure already has this patch applied
17:25 < michael-i> when I look at my configure, 3682 already reflects the updated regex, rxr
17:25 < CIA-4> rene * r31190 /trunk/package/base/pciutils/pciutils.desc: * updated pciutils (3.0.2 -> 3.0.3)
17:26 < CIA-4> rene * r31191 /trunk/package/graphic/poppler/poppler.desc: * updated poppler (0.10.0 -> 0.10.1)
17:26 < CIA-4> rene * r31196 /trunk/package/perl/perl-mp3-info/perl-mp3-info.desc: * updated perl-mp3-info (1.23 -> 1.24)
17:26 < CIA-4> rene * r31195 /trunk/package/perl/perl-anyevent/perl-anyevent.desc: * updated perl-anyevent (4.31 -> 4.32)
17:26 < CIA-4> rene * r31193 /trunk/package/perl/perl-date-time/perl-date-time.desc: * updated perl-date-time (0.4305 -> 0.4401)
17:26 < CIA-4> rene * r31194 /trunk/package/perl/perl-libwww/perl-libwww.desc: * updated perl-libwww (5.819 -> 5.820)
17:26 < rxr> michael-i: hm
17:26 < CIA-4> rene * r31192 /trunk/package/textproc/iso-codes/iso-codes.desc: * updated iso-codes (3.3 -> 3.4)
17:27 < CIA-4> rene * r31197 /trunk/package/develop/git/git.desc: * updated git (1.6.0.3 -> 1.6.0.4)
17:29 < rxr> mpp: svn diff of the git files would have been a dream :-)
17:30 < mpp> ahm. oky
17:30 < mpp> sorry
17:30 < rxr> but I'll still get it in ...
17:31 < mpp> noted for the feature
17:31 < mpp> :-)
17:34 < mpp> looks like svn.exactocode is on 31202
17:34 < mpp> but rxr pushed 31197
17:34 < mpp> ???
17:35 < mpp> am i missing something ...
17:36 < rxr> this CIA thing is lagging
17:37 < rxr> those commits are from the morning
17:38 < mpp> puhh...
17:43 < mpp> damnit xmlto dep for git slipped...
17:43 < mpp> needs to be in git.cache
17:43 < mpp> hold on the git package rxr
17:44 < mpp> i'll have to resync it with my local repo
17:44 < mpp> sorry
17:44 < mpp> ill provide an apropriate diff later on
17:46 < rxr> I could test build and add it
17:46 < rxr> had to kick some VM anyway ...
17:47 < mpp> im on it
17:47 < mpp> sorry for the mess
17:47 < mpp> im rebuilding the synced repo now
17:48 < rxr> hm - indeed
17:48 < mpp> if it's flawless i'll have it diffed and tared to the ml
17:48 < rxr> michael-i: I wiped my tarball and let svn repull the sources, now the patch does no longer apply
17:48 < michael-i> rxr, glad to hear it's not working...
17:49 < michael-i> I have to go in about 10 minutes, would you like any more info?
17:49 < rxr> ok - and it looks the "magicaly fixed binutils-bfin" package is on our mirror
17:49 < rxr> so we just wipe the patch and go
17:50 < michael-i> good deal
17:53 < rxr> mpp: var_append var ' ' 'doc, ...' is better
17:54 < rxr> though not too important for git, but for other packages targets could set other stuff you would voerwrite
17:54 < rxr> also overwriting makeinstopt probably breaks cross building as it at least also wips DESTDIR
17:54 < rxr> I fixed that and commit after a test build
17:54 < rxr> load average: 12.06, 6.14, 2.59
17:55 < mpp> but the docs will not get build otherwise
17:56 < mpp> e.g git help diff
17:56 < rxr> I mean this cleaned changes:
17:56 < rxr> +var_append makeopt ' ' 'all doc info'
17:56 < rxr> +var_append makeinstopt ' ' 'install-doc install-info install-html'
17:56 < mpp> fails on the origin .conf
17:56 < rxr> this should result in your intended behaviour without wiping pre-set variables
17:56 < mpp> i dont't get it probably
17:57 < rxr> you had makeopt="" there
17:57 < mpp> ah. okay
17:57 < rxr> this resets the whole makeopt, usually, especially during cross builds there is a whole lot already set in it
17:57 -!- michael-i [n=michael-@141.41.40.103] has quit []
17:57 < rxr> especially makeinstopt which carrie DESTDIR=$root
17:57 < mpp> so i guess you changed allready on your side :-)
17:58 < mpp> i was not aware of the difference
17:58 < rxr> yep, that's why I teach you advanced packaging topics to save my time/work in the future :-)
17:58 < mpp> the updated cache file is missing the xmlto as dep
17:58 < mpp> ill have to reread
17:59 < CIA-4> rene * r31203 /trunk/architecture/blackfin/package/binutils/texinfo-version.patch:
17:59 < CIA-4> * removed blackfin/.../binutils/texinfo-version.patch, the fixed configure
17:59 < CIA-4> already made it into the file on the t2 mirrors (?!?!?)
18:04 < rxr> hm - git breaks here:
18:04 < rxr> Can't locate Dpkg.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0/i686-t2-linux-gnu /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.1
18:04 < rxr> 0.0/i686-t2-linux-gnu /usr/lib/perl5/site_perl/5.10.0 /opt/lib/perl5/vendor_perl/5.10.0/i686-t2-linux-gnu /opt/lib/perl5/vendor_perl/5.
18:04 < rxr> 10.0 /opt/lib/perl5/vendor_perl .) at /usr/sbin/install-info line 8.
18:04 < rxr> BEGIN failed--compilation aborted at /usr/sbin/install-info line 8.
18:04 < rxr> Can't locate Dpkg.pm in @INC (@INC contains: /usr/lib/perl5/5.10.0/i686-t2-linux-gnu /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.1
18:04 < rxr> 0.0/i686-t2-linux-gnu /usr/lib/perl5/site_perl/5.10.0 /opt/lib/perl5/vendor_perl/5.10.0/i686-t2-linux-gnu /opt/lib/perl5/vendor_perl/5.
18:04 < rxr> 10.0 /opt/lib/perl5/vendor_perl .) at /usr/sbin/install-info line 8.
18:04 < rxr> BEGIN failed--compilation aborted at /usr/sbin/install-info line 8.
18:04 < rxr> make[1]: *** [install-info] Error 2
18:06 < mpp> hm...
18:06 < mpp> i don't have this on my site
18:06 < mpp> i also posted an updated cache file
18:07 < mpp> it needs xslt asciidoc
18:07 < mpp> and xmlto
18:15 < CIA-4> rene * r31205 /trunk/package/base/strace/ (arch-0-avr32.patch strace.desc):
18:15 < CIA-4> Adam Stirk
18:15 < CIA-4> * updated strace (4.5.17 -> 4.5.18)
18:17 < CIA-4> rene * r31206 /trunk/package/network/ddclient/ddclient.init:
18:17 < CIA-4> Adam Stirk
18:17 < CIA-4> * added ddclient.init script
18:22 < CIA-4> rene * r31207 /trunk/package/multimedia/libsimage/ (5 files):
18:22 < CIA-4> Adam Stirk
18:22 < CIA-4> * added libsimage (1.6.1) - The simage Library
18:26 < CIA-4> rene * r31208 /trunk/package/audio/libmpcdec/ (. libmpcdec.cache libmpcdec.desc):
18:26 < CIA-4> Adam Stirk
18:26 < CIA-4> * added libmpcdec (v1.2.6) - Musepack is an audio compression format with a strong emphasis on high quality
18:29 < rxr> http://science.slashdot.org/science/08/11/09/1558241.shtml
18:52 < CIA-4> rene * r31209 /trunk/package/multimedia/libsimage/libsimage.desc: * marked libsimage to cross build
18:54 < mpp> http://www.theinquirer.net/gb/inquirer/news/2008/11/06/redhat-amd-migrate-vms-across
19:21 < rxr> hm - I do this for months, nothing new, probably KVM anyway
20:15 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has joined #t2
20:32 < tri> moin
20:39 < rxr> hi tri
20:39 < tri> hi
20:40 < tri> rxr: do you have ever build v4l-dvb?
20:40 < rxr> the kernel module ?
20:45 < tri> the source from linuxtv.org
20:46 < tri> how is the process - most of the stuff is already in the main kernel, right?
20:46 < rxr> I do not know what exactly you mean .-)
20:46 < rxr> all stuff I ever build lives in form of t2 packages :-)
20:46 < rxr> if it's not in t2 I did not build it, or it was useless :-)
20:52 < rxr> ok - gotta go - cu
20:56 < tri> :-)
20:56 < tri> cu
21:51 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has left #t2 []
22:06 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has joined #t2
22:08 -!- mqueiros [n=mqueiros@217.70.75.130] has joined #t2
22:42 -!- tri [n=tri@p4FCF3016.dip0.t-ipconnect.de] has left #t2 []
22:43 -!- mqueiros [n=mqueiros@217.70.75.130] has quit []
22:57 -!- mpp [n=mpp@i53877AE1.versanet.de] has quit ["ChatZilla 0.9.83 [Firefox 3.0.3/2008092510]"]
--- Log closed Tue Nov 11 00:00:36 2008