=== ubuntulog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === Topic for #ubuntu-toolchain: GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: hppa, sparc NPTL, i386 biarch, C++ ABI change: 33/55 library packages in the archives === Topic (#ubuntu-toolchain): set by doko at Thu May 19 00:40:28 2005 [12:29] ohh, jbailey does the glibc dance ;) === lamont__ heads out === BenM is now known as bout === bzzz is now known as BenM [02:40] doko: Yeah. =( [02:40] doko: Glibc is much happier with everything being old binutils or everything being new binutils, which worries me a bit, but everything seemed to check out with some readelf love. [03:08] Feh. module-init-tools needs a give back after the chroot is updated, too. [03:08] (ppc and amd64) [05:22] morning [05:26] jbailey: done [05:27] *2 [05:27] (glibc. module-init-tools) [05:28] Jun 15 18:51:05 buildd: breezy: total 963 packages to build. [05:28] woot! [05:30] hey lamont [05:30] morning fabbione [05:30] i guess hppa is catching up :) [05:30] gcc-snapshot ICE. kewl. :( [05:31] that number is from the local w-b, not the one on p.u.c [05:31] oh [05:32] jbailey: glibc is building now on sparc [05:32] on that one, the numbers are a bit closer... [05:32] 3551/2634/6185 for hppa, 3329/2889/6218 for sparc (installed, needs, total) [05:33] yup [05:33] and given that all of kde Depends: arts (ICE), you'll eventually get ahead again, big time.. -) [05:34] and libgtk2.0 install hangs :-( [05:34] life sucks these days [05:35] ah [05:37] but once the buildd catches up as best it can, then I can actually spend a little time making everything sync up nicely, and maybe even do some debugging [05:37] yeah [05:37] but frankly, if I can get the server install to work, along with the useful server packages, I'm happy. [05:37] when i will get the other buildd up, i can free some time from my sparc to do it [05:38] i need to move w-b on another machine [05:39] yeah - that's on my list of things to do this week as well. [05:39] 3) migrate w-b to another machine, so that both buildd's can share it. [05:39] i lost the first 2) [05:39] sadly, 2) is to create world pease [05:39] peace, even [05:39] (netsplit of death) [05:40] nah - didn't post #1 or #2 [05:40] ehehhe ok [05:40] but when I headed home tonight, there was a B180 doing a sarge install in a screen session [05:41] 1) is working ipsec configuration :-) [05:42] ehhe [05:42] now i need to understand why ppc is FTBFS on ppc64 kernels [05:42] apparently i am leaking a ppc64 somewhere [05:42] 893 Building, 589 Dep-Wait, 29 Failed, 2779 Installed, 952 Needs-Build, 860 Uploaded, Total 6102 [05:42] ouch [05:42] (ppc64) [05:43] well basically it FTBFS building the headers [05:44] it's ok if the buildd is running ppc kernels [05:44] those numbers are with a 3-day old mostly-current binary archive, and current as of 3.5 hours ago source [05:44] but not with ppc64 [05:44] heh not bad [05:44] so are any of the DC buildd's running ppc64, or just davis? [05:46] only davis [05:46] but the ppc64 kernel fixes the random segfaul/segkill problem [05:46] and trust me.. it's flying === doko [~doko___@dsl-082-082-201-214.arcor-ip.net] has joined #ubuntu-toolchain === BenM [~benm@c-24-128-49-153.hsd1.ma.comcast.net] has joined #ubuntu-toolchain === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-toolchain [05:58] ahhhh [05:58] it's getting the wrong defconf [06:02] hrm.. so how do I format a fat16 partitiion, I wonder [06:04] isn't there a vfat or fat utils? [06:14] there's mformat, but it wants details I don't want to generate.. :-) [06:14] and there's mkntfs, but I want FAT [06:17] AHHH FOUND IT!!! [06:17] make defconfig; \ [06:17] DIE! [06:17] nice [06:19] now... go figure why it prefers ppc64 over ppc [06:36] now.. patch to the kernel Makefile or usual tons of workarounds in debian/rules??? [06:42] I' [06:42] d be incinled to fix the makefile [06:42] i think the makefile is correct [06:42] it's the way we call it that's wrong [06:45] well, then fix debian/rules, of course. :-) [06:46] i am trying to think... [06:46] SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ [06:46] -e s/arm.*/arm/ -e s/sa110/arm/ \ [06:46] -e s/s390x/s390/ -e s/parisc64/parisc/ ) [06:46] this is where we fail [06:46] or better .. [06:46] where the kernel makefile fails [06:46] it uses uname -m to determine ARCH= via SUBARCH [06:47] ARCH ?= $(SUBARCH) [06:47] it looks to me that we should instead set ARCH properly [07:06] there.... [07:06] fixed === BenM is now known as bzzz [08:52] doko: i think gcc-4.0 is doomed on sparc [08:52] /usr/bin/ld: __libc_errno: TLS definition in /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a(errno.o) section .tbss mismatches non-TLS reference in [08:52] /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a(check_fds.o) [08:53] /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a: could not read symbols: Bad value [08:53] i have seen this already in 2 packages [08:59] which packages are these? [09:01] busybox-cvs and modules-init-tools [09:01] do you want the build logs? [09:01] but the error is exactly the same [09:10] works with 3.4 on sparc? [09:10] doko: dunno.. i will have to check [09:10] they are really fresh build logs [09:49] infinity, lamont: ping? [10:01] unpong [10:15] elmo: i fixed the ppc kernel build on ppc64 kernels.. you can upgrade anytime, but we might find other packages with the same problem [10:16] specially the ones that use uname -m to detect what they should do [10:20] fabbione : We could (should?) just linux32 ppc buildds, like we do with sparc buildds. [10:21] (But, I agree, packages using `uname -m` for anything are pretty broken) === smurflogbot [~SmurfLogB@netz.smurf.noris.de] has joined #ubuntu-toolchain [10:22] infinity: i don't think it even exists linux32/64 for ppc [10:22] smurflogbot ?? [10:22] fabbione: Error: "??" is not a valid command. [10:22] ubuntu-toolchan is already logged [10:22] amen [10:22] smurflogbot: !die [10:22] fabbione: Error: "!die" is not a valid command. [10:23] amen [10:23] speaking of which [10:23] i need to log #ubuntu-java === Seveas [~seveas@ksl403-uva-153.wireless.uva.nl] has joined #ubuntu-toolchain [11:12] fabbione : Well, if it doesn't it should. [11:12] fabbione : But apt-cache tells me it already does. [11:26] linux32 [11:26] -su: linux32: command not found [11:26] that's on davis breezy chroot [11:26] anyway.. foooooooooooooooood [11:26] smurflogbot: help [11:26] doko: (help [] [] ) -- This command gives a useful description of what does. is only necessary if the command is in more than one plugin. [11:27] smurflogbot: help help [11:27] doko: (help [] [] ) -- This command gives a useful description of what does. is only necessary if the command is in more than one plugin. [11:27] smurflogbot: help die [11:27] doko: Error: There is no command die. [11:27] smurflogbot: helpyourself kill [11:27] doko: Error: "helpyourself" is not a valid command. [11:36] smurflogbot : quit [11:36] infinity: Error: ":" is not a valid command. [11:37] smurflogbot: quit [11:37] infinity: Error: You don't have the owner capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. [11:37] Bah. [11:37] (If anyone's curious, the bot is one of these: http://supybot.sourceforge.net/docs/commands.html) === smurflogbot [~SmurfLogB@netz.smurf.noris.de] has joined #ubuntu-toolchain === smurflogbot [~SmurfLogB@netz.smurf.noris.de] has joined #ubuntu-toolchain === smurflogbot [~SmurfLogB@netz.smurf.noris.de] has joined #ubuntu-toolchain === smurflogbot [~SmurfLogB@netz.smurf.noris.de] has joined #ubuntu-toolchain [12:03] who has op in here? [12:03] and ban that bot? === warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === Topic for #ubuntu-toolchain: GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: hppa, sparc NPTL, i386 biarch, C++ ABI change: 33/55 library packages in the archives === Topic (#ubuntu-toolchain): set by doko at Thu May 19 00:40:28 2005 === #ubuntu-toolchain [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup === jbailey [~jbailey@CPE00501836c657-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === doko [~doko___@dsl-084-059-062-132.arcor-ip.net] has joined #ubuntu-toolchain [01:04] lamont, fabbione: thanks [01:34] Sparcv9 testsuite Errors: tst-align2, tst-getpid1, tst-timer, tst-mqueue1, tst-mqueue2, tst-mqueue4, tst-timer4, tst-timer5 === jbailey digs up a previous log for sparc. [01:35] At least two of those, I have a patch for from davem [01:37] BAH === jbailey cries to Fabio about getting sparc build logs put somewhere. [01:38] I have no basis for comparison here... =( [01:40] jbailey: they are all in the usual place.. and yes i know.. they should go to people, but i need to get elmo to do it [01:40] you can get the old logs in ~/logs [01:40] You can't just scp them into your homedir? =) [01:41] jbailey: it means duplicating the effort i already did to get them to people atm [01:41] My imap client doesn't like your imap server. Can I ask you to extract a previous glibc success log for me? [01:42] jbailey: ok wait. i will scp them on people.. even if you have ssh access to where logs are stored [01:42] Do I? [01:42] I thought I had to look in the imap server to get to them... [01:42] no [01:43] you can either ssh or look via imap [01:43] i have you an alternative :) [01:43] now i am compressing them... [01:43] and scping them to people :) === jbailey does a snoopy dance! [01:45] afk a sec [01:49] jbailey: since you can ssh .. i did stop the bzip2 :) [01:49] i think it's easier for you to run diffs there than having to download 4 * 43MB of files [01:49] =) [01:50] grep rather than diff, but yeah. =) [01:50] yeah [01:50] and the manual build is at 36MB [01:50] it seems that it is almost done [01:56] YEah, it's a good chunk of the way through the sparc64 testsuite that I added. [01:56] and that's fine for me :) [02:05] Old sparc testsuite errors: tst-mqueue1, tst-mqueue2, tst-mqueue4 [02:06] So we're gaining timer test failures. [02:07] jbailey: do these tests rely on some kind of timeouts? [02:07] because the machine has been pretty overloaded [02:07] I'll check. [02:07] so a test failure due to machine load is nothing i would be too worried about [02:18] sparc64 fails with: tst-regex2.. Weird. =) [02:19] jbailey: you are killing sparc! you bastard :P [02:19] Oh, I see. [02:20] segfaults on the timer tests. =( [02:20] Nope, only the first one. [02:20] Not, #4, and #5 [02:20] I don't see an error message, though. [02:21] No they did segfault. [02:21] It just didn't percolate the error up. [02:21] Didn't expect signal from child: got `Segmentation fault' [02:21] make[3] : *** [/home/sparcbuildd/glibc-2.3.5/build-tree/sparc-libc/rt/tst-timer5.out] Error 1 [02:21] It should look like: [02:21] make[3] : *** [/home/sparcbuildd/glibc-2.3.5/build-tree/sparc-libc/rt/tst-timer.out] Error 139 [02:21] For a segfault [02:21] weird weird weird. === svenl_ [~luther@AStrasbourg-251-1-73-215.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain [03:17] The former looks more readable... [03:17] (Where is this output, though?) [03:18] 139 is just "1 + 138 from child" [03:18] The textual version is much saner, despite being different. :) [03:19] infinity: I scan for the error codes. [03:19] infinity: "Error 1" is a simple testsuite failure, so I usually check the output. There's no obviously failure in the message, so it threw me. === bout is now known as BenM === lamont__ [~lamont@15.238.7.83] has joined #ubuntu-toolchain [04:35] lamont__: Did the last glibc do fine on hppa, btw? [04:37] libs/glibc_2.3.5-1ubuntu7: Dep-Wait by buildd+smallone [required:out-of-date] [04:38] HAven't got the new binutils yet? [04:38] devel/binutils_2.16.1-0ubuntu1: Dep-Wait by buildd+smallone [standard:out-of-date] [04:38] Dependencies: dpkg (>= 1.13.7) [04:38] base/dpkg_1.13.9: Needs-Build [required:out-of-date] [04:38] Joy.. So check you with again tomorrow sometime. =) [04:38] ==> archive issues... let me fix things [04:39] (issues in my mirror, that is) [04:39] Haven't you moved that thing to under your desk at work yet? =) [04:40] that's an in-progress thing [04:44] yesterday I configured the DMZ box for it [05:03] archive kicked around a bit, should actually build things now [05:04] jbailey: some quick packages ahead of it, then dpkg'll build [05:04] Cool. [05:05] I expect hppa should be happy now. [05:05] and I fixed the sources.lists so that my lazy archive management shouldn't hurt it much anymore [05:06] I was telling Fabio that I intend to have all of the glibc hacking for sparc and hppa finished by UVF. [05:06] (it was preferring the mirror that only has current hppa bits for source. :-( [05:06] that's a good goal [05:06] And whatever state it's in at that point, to basically keep it that way until Breezy+1 hacking starts. [05:07] So I have some function pointer stuff to do on hppa, and I think that's all I'll get in for you. [05:07] at least feature wise, sure [05:07] Bug fixes, sure. [05:07] no TLS, eh? === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [06:10] jbailey: i was looking that even if we get the toolchain in place before UVF, both hppa and sparc are gcc-4.0 doomed [06:10] a lot of stuff doesn't build with gcc-4.0 yet [06:10] Like what? [06:10] There really shouldn't be that much that's arch specific... [06:10] gclcvs in main :) [06:10] Is that in ~/logs ? [06:10] yes [06:11] there are a bunch of libs that don't build.. [06:11] i will need to check them again [06:11] universe is a mess [06:11] a lot of stuff doesn't build with gcc-4.0 [06:16] lamont__: i can i check buildd stats? [06:16] per buildd.. not globally [06:17] i am curious to see how much the new buildd is crunching :) [06:19] fabbione: Is that sparc-specific or all over the place? [06:19] (nothing urgent.. i will be back later) [06:20] jbailey: the point is that most of these packages haven't been rebuilt in universe after the gcc transition [06:20] so basically sparc is building them for the first time [06:20] with gcc-4.0 [06:20] and i guess hppa will hit the same problem [06:20] since it's building universe [06:20] i am pretty sure that if we do a real testbuild of i386 from scratch we will hit most of the same errors [06:21] and that's something we should really do asap [06:21] at least to check: main compiles out of main [06:21] universe.. well tought luck [06:21] Oh, I see. [06:21] I think we can be pretty certain of main. [06:21] There is very little there that doesn't get movement during a dev cycle. [06:21] jbailey: i wouldn't :) [06:22] warty -> hoary there was one package that was not updated :P [06:22] Right, one is not significant in the set of 800 or so. =) [06:22] http://people.ubuntu.com/~lamont/buildLogs/g/ghc6/ this is an example [06:23] libx11-6 conflicts with xlib-data? [06:23] fun [06:23] jbailey: that compiler or whatever it is.. it's a b-d for many packages [06:23] jbailey: probably it has been bootstrapped ok.. builded all the whatever [06:23] jbailey: but now.. it's not buildable anymore [06:23] because of gcc-4.0 [06:24] so that's one of the example of packages that will not be built on sparc/hppa [06:24] because they are not there yet [06:24] fabbione: only the packages, that were not compiled in the breezy cycle [06:24] and all the packages that b-d on it will follow [06:24] doko: right.. but that assume that you have all of hoary already there [06:24] doko: that's not exactly true on arch that are bootstrapping :) [06:25] doko: i know you hate me because of sparc.. i still love you a lot :P [06:25] anyway i need to fold the washing :) [06:25] i will be back later after dinner [06:26] fabbione: Setup a "Hoary" repo with gcc set to gcc-3.3. Build them and inherit like everyone else. =) [06:29] there are _LOTS_ of build failures - we're supposed to get breezy-autotest up and running RSN (elmo -nudge nudge), and then we'll have good build logs that people will actually look at [06:31] AWW MAN [06:31] binutils is just a fricking blackhole of unrobustness [06:31] elmo: H J Lu!! [06:32] jbailey: I'll be filing RC bugs on all of them once breezy-autotest is live, maybe sooner as time permits === lamont__ is tempted to just upload ...build1 versions of the borken ones, just to get them worked on... :-) [06:33] lamont__: In Debian or in Ubuntu? =) [06:33] Mind you, I guess UVF is soon, isn't it? [06:34] jbailey: WHAT? [06:36] err.. [06:37] daniels: will you upload an xlib-data, which doesn't conflict with libx11-6 ? [06:37] or should things be recompiled === daniels looks at doko. [06:37] ... you want me to remove the Conflicts? [06:38] no, just know, what needs to be done to get libs like kdelibs4c2 installed again [06:39] jbailey: ...build1 versions are ubuntu-specific [06:39] could you please explain the specific problem? [06:39] libx11-6 Conflicts xlibs-data << 6.8.2-25 [06:39] this is because, up until 6.8.2-25, xlibs-data contained files that are now in libx11-6 [06:39] i don't know what you want me to do other than this, nor do I even know what the actual problem is [06:40] The following packages will be REMOVED: [06:40] gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools [06:40] gnome-volume-manager hwdb-client kdelibs-bin kdelibs4c2 libdbus-qt-1-1c2 [06:40] libgksu1.2-0 libgksuui1.0-0 x-window-system-core xbase-clients xterm [06:40] The following packages will be upgraded: [06:40] libtext-iconv-perl x-dev x11proto-core-dev [06:40] 3 upgraded, 0 newly installed, 15 to remove and 2 not upgraded. [06:40] doko: *shrug* worked fine for me [06:40] trying to upgrade breezy [06:40] daniels: +/home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/libglu1-mesa-dev [06:40] +_6.2.1-5_hppa.deb (--unpack): [06:40] trying to overwrite `/usr/include/GL/glu.h', which is also in package [06:40] +x11proto-gl-dev [06:40] that'd be nice to fix... [06:40] doko: want to run the dependency resolver and see what's actually causing it? [06:41] lamont__: 6.2.1-5? wtf? [06:41] oh, -mesa- [06:41] yeah, I'll get that fixed up with a Conflicts and a mesa upload [06:41] tomorrow, though; it's 0241 [06:41] thanks [06:44] daniels: hmm, my current xlibs-data is 6.8.2-24, the -25 build did fail on i386 [06:44] hm, but succeeded on amd64 and powerpc. wtf? [06:45] via_xvmc.c:51:16: error: Xv.h: No such file or directory [06:45] via_xvmc.c:52:18: error: XvMC.h: No such file or directory [06:45] via_xvmc.c:188: error: 'XVMC_CHROMA_FORMAT_420' undeclared here (not in a function) [06:45] via_xvmc.c:194: error: 'XVMC_MPEG_2' undeclared here (not in a function) [06:45] via_xvmc.c:195: error: 'XVMC_OVERLAID_SURFACE' undeclared here (not in a function) [06:45] yes, but fails on ia64 as well [06:45] argh, the fucking via driver! [06:46] my recommendation for now is that ou don't dist-upgrade [06:46] DOKO [06:46] unless you actually want to remove all that stuff [06:46] ok [06:46] doko: dude, what's up with the blacklists [06:46] am I still blacklisting syncs? [06:47] elmo: hmm, I thougth we replaced them with dep-waits on the buildds? [06:47] that was for building of stuff [06:48] you never told me to do anything about the blacklists of the sync program [06:48] yes, to be able to enable the syncs [06:48] hmm, didn't we talk together with infinity? [06:48] sorry [06:49] so I can remove blacklists? [06:50] from my point of view, yes. all packages, which depend on not yet converted libs, are marked as b-d on the expected new libname [06:58] ok [07:50] elmo: ping? [07:51] fabbione: sup [07:52] hey elmo [07:52] elmo: jbailey and i were wondering if you had any time to think on how we can get sparc build logs on people... [07:53] elmo: last time i suggested that the mail2htmllog could perhaps run directly on people [07:53] elmo: In truth, I've been snivveling at Fabio... [07:54] His threats to beat me only got me excited, you see... [07:54] err. [07:54] NM [07:54] elmo: iirc correctly the problem was that the main machine that processes them can't be used [07:54] elmo: so perhaps the main machine could just send a copy to people that will do the log2html processing [07:54] elmo: and external buildd could send a copy there too [07:55] yeah, we can't have sanae receiving external mail. if this going to work, I think the way forward is: [07:55] our buildds mail sanae forward the mail to a log2html processor on another box, your buildds are also allowed to mail that other box [07:55] but I may just be repeating myself here [07:56] that's exactly what i suggested :) [07:56] i suggested people.. but it could be any other box [07:56] i don't think my .promailrc will ever care :) [07:56] or I could be repeating you.. either works ;) [07:57] elmo: i love when we say the same thing in 20 different ways :) it makes hot :P [07:57] hum, people's in danger of suffering from chinstrap disaease, if it's not already in the advanced stages [07:57] -ETOOMUCHCRAP? [07:58] right [07:59] anyway, fuck it. people's fine. if you can get the lamont/infinity hybrid to agree to do the work and choose a domain name, I'll set up our mail double-bounce madness to allow the mail into rookery [08:00] elmo: sure :) [08:01] elmo: i am going to hunt them down to death and set it up :) [08:01] heh [08:06] elmo: "choose a domain name"?? [08:06] lamont__: $domainname@ubuntu.com :) [08:06] lamont: or an LHS for @ubuntu.com [08:06] i was asking the same thing right now [08:06] which/whatever [08:06] elmo : What happened to buildd.u.c that we discussed a few days ago?> :) [08:06] infinity: go to bed, dude [08:06] daniels : You too, punk. [08:06] daniels: go to bed kid [08:07] yeah, I'm off to sleep now [08:07] and don't forget to change the diaper or i will tell mamma [08:08] infinity: it got stalled on the httpd2.1 thing [08:08] Alright. I'll read the backscroll on this convo tomorrow. [08:08] I'll rip it out in a sec [08:08] elmo : Right. [08:08] infinity: ok :) [08:08] elmo: we could just go with logs@buildd.u.c or some such, yes? [08:08] Which is sane. [08:08] lamont: sure [08:08] And easy to remember, since it's the same for Debian. :) [08:08] ehehe === infinity -> bed, for real.. Maybe. [08:09] infinity: night dude [08:09] elmo: that would also let me retire the rsync from sanae, which would be cool. [08:09] (have sanae still archive all the DC builds, but not make it push stuff out..) [08:10] elmo: do we want to then migrate the logfiles to live under http://buildd.ubuntu.com/ as well? [08:10] hmm speaking of which... it will require me to increase the max email size === fabbione goes and pokes with postfix here and there [08:11] lamont__ : That was my plan, and I was going to slap up a simple interface on it that didn't completely suck. [08:11] Yay, sleep-typing. [08:11] /usr/sbin/postconf -e message_size_limit=0 [08:12] infinity: I'm figuring that the initial dump is mv ~lamont/public_html/buildLogs /srv/buildd.ubuntu.com/buildLogs [08:12] and set things up to save there. Once there's a pretty interface to it, people can stop drilling down on their own. [08:12] or not. :-) [08:12] lamont__: does it also add it to the config files? [08:13] fabbione: that only edits the config file [08:13] ah ok :) [08:13] i still need to restart it... [08:13] suckage.. === fabbione files a wishlist bug ;P [08:14] fabbione: actually, the daemons regularly kill themselves off, so you don't _need_ to say reload [08:14] (and, in fact, reload just causes master to tell all the current children to exit upon finishing whatever they're doing)( [08:17] lamont__: what can i say... *point [08:17] it'll be +wontfix [08:19]