=== Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain === infinity wakes up to the pleasant surprise of ppc64 buildds. [03:55] elmo : Danke. === infinity touches up .sbuildrc and restarts a buildd. [04:04] Oh, well, that worked smashingly. === infinity smacks himself, adds linux32 to the chroots and tries again. [04:07] Much better. [04:09] pls to be fixing live + di builds too [04:09] I realise you're probably on it, I just don't want it to get forgotten [04:09] as I think mdz would be unamused by a G5-only colony 4 [04:13] Heh. [04:13] More interestingly, we don't have linux32 on warty. [04:14] what's it linux32-ing in the chroot? [04:15] can't it just linux32 the chroot call? [04:15] That's the way build_env_cmnd works, it calls "exec linux32 dpkg-buildpackage" in the chroot. [04:15] But I suppose we could just run buildd itself under linux32 in the base. [04:15] Don't see why that wouldn't work. [04:16] well, except then we can't exclude packages [04:16] not sure if we need to or not [04:17] I can't see why we'd want to. [04:17] some things want to be built on a powerpc64? [04:17] maybe they don't check and/or care [04:17] linux32 only changes the behaviour of uname, not much else. Anything that wants/needs to build 64-bit binaries still can, it just needs to explicitly call gcc -m64 [04:17] but I don't know if gcc -m64 works when uname returns ppc [04:18] I know the debian kernel package breaks with sparc32 [04:18] dunno who's fault that is tho [04:18] Well, the kernel tries to autoguess what target to build for by looking at uname. [04:18] But that can be forced, as we do in our kernel builds. [04:19] (Hence how we've been building ppc64 kernels just fine on ppc32 until now) [04:19] ok [04:19] well, I've got a b-at run pending anyway, so I guess we'll find out [04:19] *mutter* die postgres die *mutter [04:19] So, yeah. If proper packaging assumes the machine will always return sparc/powerpc/hppa, and not sparc64/powerpc64/hppa64, then the whole buildd should be linux32'd anyway. [04:20] (or is that parisc/parisc64?... I can never remember) [04:20] Now, the only question is where it's best to implement that, so people can't shoot themselves in the feet by accidentally restarting without the linux32 call. [04:21] I suppose buildd's call to sbuild would be a safe bet. [04:39] Alright, that should do it. [04:40] Now the only remaining question is if I should just hardcode it for powerpc/sparc/hppa, and make the buildd package depend on linux32 on those arches. [04:40] Which may be more sane than a wishy-washy, I-might-forget-to-set-it config option. [04:41] does linux32 work/exist on sparc? [04:41] debian uses 'sparc32' from sparcutils instead [04:41] It works on sparc just fine. [04:41] sparc32 exists because it was the first kernel to implement personalities. [04:42] ok [04:42] linux32 is the genericisation of that. [04:42] I reckon hardcode and depend on then [04:43] .. That feels more right to me. [04:43] I can have a config option to let you override it, should you feel the strange desire (ie: call linux64 instead of linux32, to force an all-64-bit buildd) [04:43] argh [04:43] you andreas jochens fan boy [04:44] Heh. [04:44] It's more just the thought that anything being autoconfigured in buildd/sbuild should be reasonably overridable, and the defaults should be sane. [04:44] linux32 feels like the sane default, but who knows if we may want to throw up a buildd with the reverse config some day "just cause". [04:47] Oh, feh. We should also promote linux32 to main. [04:48] boggle [04:48] god yes [04:48] christ I missed the deadline for "get these things into main" AGAIN === infinity goes to clean up the code a bit, commit, then attack live/d-i. [04:51] Will mdz demand a MainInclusionReport for this, or do you want to just seed it? [04:51] uh, I dunno, I suppose we should ask [04:51] if I abuse my dak supah powahs, it makes it harder for me to shout at him rm-ing random files [04:51] ... No big deal if it doesn't get seeded, I guess, but I consider linux32 a necessary part of package development on 32/64 platforms. [04:55] I don't suppose we have a hoary-cat yet? ;) [05:05] jbailey: wth is springgraph/ [05:05] ? [05:05] It's a graphviz clone. [05:05] Why are3 you asking me? =) [05:05] because you're Mr CDBS, ofcourse [05:06] infinity: no, sorry, meh [05:06] I really want that myself [05:55] Lamont picked a fine time to kill his connection. [06:01] Oh well, guess I'll manually roll these changes out for now, and lamont can clean up with a proper release later. [06:01] (ps: did I mention how much I'd love hoary-cat?) [06:06] Alright, buildds are all back up and happy. live and d-i next. [06:07] elmo : Thanks for this, by the way. I'm fairly certain it was desperately needed. [06:07] I'll do a mass give-back in a bit and see how many failures mysteriously clear up. [06:51] There, live and DI are fixed up too. [07:09] morning [07:28] jbailey, doko, elmo: any chance to get binutils fixed asap? [07:29] (for sparc i mean) [07:50] morning fabbione [07:52] elmo: please install libgl1-mesa-dev and libglu1-mesa-dev on davis/breezy, the xlibmesa packages were not removed automatically [08:04] doko: yo [08:04] doko: i start to be under pressure with binutils [08:04] after seb uploaded all of gnome again, almost all of it is FTBFS due to that problem [08:06] fabbione: understood [08:06] thanks [08:07] elmo: do you have a pre-unstable version of the patch available, that we can apply for sparc (maybe hppa) only? [08:07] doko: afaik the patch is required for sparc and hppa.. [08:07] and alpha.. [08:07] but we don't have alpha so ENOCARE === chmj [n=chmj@196.36.161.235] has joined #ubuntu-toolchain === Seveas [n=seveas@ksl403-uva-132.wireless.uva.nl] has joined #ubuntu-toolchain === chmj [n=chmj@196.36.161.235] has joined #ubuntu-toolchain === chmj [n=chmj@196.36.161.235] has joined #ubuntu-toolchain [12:19] fabbione : Alright, do you want to know how to fix mesa for sparc? [12:19] infinity: nope... [12:19] or better.. [12:19] yes i want to know [12:19] because i don't know how to [12:20] Actually, I'm sure you can figure it out. :) [12:20] Anyhow, three simple steps: [12:20] 1: Build libdrm_1.0.3-2 (which just showed up in wanna-build) [12:20] 2: preseed your chroot with reasonably recent libglu1-mesa-dev, libgl1-mesa-dev, mesa-common-dev. [12:21] 3: build mesa_6.3.2-0ubuntu2 [12:21] 4: Never have to worry about build-dep loops again, cause the most recent mesa no longer has any. [12:21] 2) <- i don't have any recent libglu1-mesa-dev libgl1-mesa-dev, mesa-common-dev. [12:21] or are they arch: all??? [12:21] mesa-common-dev is arch:all, the others are arch:any, that's where the problem was. [12:22] infinity: i don't think i even have them anywhere... [12:22] If you haven't built mesa for a week or more, you shouldn't be hooped in the first place, since you can build against libgl1-xorg-dev and such. [12:22] libglu1-mesa_6.3.1.1-0ubuntu1_sparc.deb [12:23] this is the most recent one i have [12:23] That looks recent to me. [12:23] hmmm [12:23] it might have built while i was sleeping [12:23] and i missed it.. [12:23] Install that, plus the matching libgl1-mesa, plus the matching -dev packages, plus mesa-common-dev, ann in the same versions. [12:23] s/ann/all/ [12:23] Once the new mesa has been built, you can clean them out of your chroot, and life resumes as normal. [12:24] infinity: well as soon as i build the new mesa i should be fine... [12:24] Right, once you have the new mesa, you're fine. But you need the old to build the new (hence the problem) [12:24] And the old has exact version deps between arch:any and arch:all packages. [12:24] ok, but it seems i have the old ones... [12:24] AHH CRAP [12:24] ok === fabbione understands now... [12:25] Right. :) [12:25] If you don't have the old arch:all .deb lying around, you can --force-depends with a more recent version just long enough to get the new mesa built and you'll be fine. [12:25] Just keep in mind that you need libdrm first, cause mesa build-deps on it. [12:26] yup... [12:26] doing it [12:26] -2 ? [12:27] yeah.. it's not in my local archive yet... [12:27] i need to wait for it [12:27] Yeah, -2. [12:27] -1 was a little bit broken. Just a tad. [12:28] ehehe === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #ubuntu-toolchain === doko [n=doko@dsl-084-059-085-062.arcor-ip.net] has joined #ubuntu-toolchain === doko [n=doko@dsl-084-059-085-062.arcor-ip.net] has joined #ubuntu-toolchain === doko [n=doko@dsl-084-059-085-062.arcor-ip.net] has joined #ubuntu-toolchain === doko [n=doko@dsl-084-059-085-062.arcor-ip.net] has joined #ubuntu-toolchain === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain === doko [n=doko@dsl-084-059-085-062.arcor-ip.net] has joined #ubuntu-toolchain === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain [06:13] infinity/lamont: breezy-at is finally going, FYI [06:23] elmo : Yay. Does this mean I can bug you about hoary-cat again? ;) [06:27] christing bananas [06:27] adelie's going nuts trying to cope with all the logs [06:27] (fails, I assume) [06:28] I only have 178 -autotest failures in my INBOX so far. [06:28] But if they're all backlogged, I guess I'll see more. :) [06:29] well, it's sending to lamont [06:29] probably over, like a piece of string, by way of alsaka or something [06:29] [06:30] Yeah, mine all go to a host in a datacenter with multiple GigE carriers and a 100Mbit port on the box. [06:30] So, I doubt I'm a bottleneck. [06:30] Of course, then I access said mail via IMAP from my tin cans and string in Australia, but let's not split hairs. [06:38] elmo: it's sending over a straw of 25kbps, which it shares with the upload/download queue for the buildd [06:39] so it's not _quite_ string and tin-cans [06:39] lamont-away: Haven't you moved that under your desk at work yet? =) [06:39] jbailey: there's another one under the desk, which gets _VERY_ annoyed at HP's proxies [06:39] which are "transparent" [06:40] and given bandwidth available at the site, I think elmo would be conflicted about whether I should set up shop there... [06:43] buildd mail isn't going to hurt gluck [06:43] it's more the up/down loads of the buildd [06:44] dude, I ran two buildds on a 2Mb connection [06:44] your two debian buildds in fact :) [06:44] ah, ok. I'll like move it then [06:51] infinity: you upload a buildable mesa yet? :-) [06:52] ah, daniels uploaded... maybe ubuntu3 will build for me. [06:52] lamont-away : Oh, you'll need to handhold it once. [06:52] grrrrrr [06:52] but only once? [06:52] lamont-away : Make sure the latest libdrm is built first. [06:53] oh, that part is fine. [06:53] it was the circular build-dep on itself that was annoying me most [06:53] lamont-away : Then pre-seed a chroot with reasonably recent libgl1-mesa-dev, libglu1-mesa-dev, mesa-common-dev, libgl1-mesa, libglu1-mesa. [06:53] lamont-away : Then build the most recent mesa, and you'll never see this loop again (cause it's gone) [06:53] woohoo!!!! [06:54] lamont-away : Can't avoid the circular build-dep loop until you have the new one built, obviously. So, once you've done the preseed dance, you're fine from here on in. [06:55] thanks muchly [06:56] elmo: the only other real challenge hppa has so far is that the following packages are in universe, but need to be in main: [06:56] expect-tcl8.3-dev_5.43.0-2_hppa.deb expect-tcl8.3_5.43.0-2_hppa.deb expectk-tk8.3_5.43.0-2_hppa.deb gcc-3.4-hppa64_3.4.4-5ubuntu1_hppa.deb libgcc2_4.0.1-4ubuntu4_hppa.deb palo_1.9_hppa.deb [06:57] heh, yes, libgcc2 is nice to have :-) [06:58] lamont: if you jump through the required hoops, I could/would [06:59] well, at least for new source packages [06:59] are any of those from packages already in main? [06:59] gcc-3.4-hppa64 is from gcc-3.4, libgcc2 comes from 3.4 or 4.0 [06:59] hmm, crap, the problem is germinate doesn't do hppa [06:59] right [06:59] how stable is hppa ATM? [06:59] seems to be stable-ish [07:00] buildd is running breezy [07:00] hrm.. actually, hoary/breezy mix.. [07:00] most things pinned at hoary [07:00] I'll try adding hppa to germinate temporarily, see how bad the damage is [07:00] are you using onion on hppa? [07:01] yes [07:01] ok [07:01] lamont-away : Have you merged the patches I sent you to your arch archives? [07:01] since the beginning of time (hoary archive on people was built using ogre-model) [07:01] btw, I dunno how useful it is, but neuro's done auto-dep-wait in w-b [07:01] infinity: I just read them a couple minutes ago [07:01] elmo: yeah, we probably want to merge that in [07:01] infinity: patch to do what? [07:01] elmo : Yeah, I was going to look at it and merge it if it looked decent. [07:02] more merge our changes forward to his base [07:02] or something like that [07:02] lamont-away : Merging w-b in general is on my TODO anyway. [07:02] right [07:02] (The new faster DB access could be nice too, if elmo doesn't mind blowing away all the DBs in the process of upgrading) [07:02] uhm [07:02] heck yes I mind [07:03] infinity: I'll get those patches you sent merged in sometime soon, and look at switching the master/mirror status of the archives around, albeit probably thu/fri [07:03] neuro managed to transition them? [07:03] Yeah, I believe he did. [07:03] elmo: ISTR something from him about how he'd, um, managed to wind up doing a mass-give-back of everything... [07:03] OTOH, we have very little history in our DB worth caring about, since we don't tend to fail many/any packages with informative messages. [07:03] Yeah, he gave back everything in building. That was an oops. [07:04] But he kept the entire failure history, that was the important bit for Debian. [07:04] infinity: some days I actually reply with bug numbers... [07:04] Not sure how much we care about that. [07:04] but that tends to be packages that someone uploaded broken, and then didn' [07:04] Rebuilding our DB's from scratch based on the archive state wouldn't really hurt us much. [07:04] t fix for a few days [07:04] back in a few [07:04] infinity: I don't care about breezy [07:05] I care slightly more about << breezy [07:05] Ahh, yeah. I can see that. [07:05] gar, germinate so slow [07:05] Well, we can look into smooth upgrades when I find the round tuits required to exercise some WAB on infrastructure. [07:08] ok, hppa's pulling in random crap [07:09] Building : 1123 (buildd+rothera: 1093, buildd+terranova: 9, [07:10] uhh [07:10] someone might want to check on rothera [07:10] I'm going to assume that's the good ol' "oh god, my apt md5sums are buggered, I'm going to depwait the world on debhelper" bug. [07:10] no [07:10] E: The package eclipse-ecj needs to be reinstalled, but I can't find an archive for it. === infinity goes ot look. === infinity boggles at how rothera's breezy-at chroot can get away with not having libstdc++6 installed.. [07:14] oh crap, I forgot to trash the w-b databases [07:14] now they're full of d-w, d-w-r, f and f-r [07:16] Hrm, perhaps we should have made sure the breezy-at chroots were fresh, clean, and ready to go before firing up the run. [07:16] Should we start this experiment over again? :) [07:17] yeah, sounds like a plan [07:17] lamont-away : How away are you actually right now? [07:18] lamont-away : It's 3:17am for me, and I'm being dragged to bed. If you want to check/rebuild the -autotest chroots, that'd be cool. Otherwise, I should do it in the morning. [07:18] elmo : Can you open the floodgates at the touch of a button after we clean stuff up and poke you? [07:18] yeah [07:18] I'm redoing the import process on rockhopper now [07:19] so just yell whenever [07:19] Alright. Let's call this a mind-boggling oops, then, and I'll check the chroots in the morning and make sure it's all good. === infinity allows himself to be dragged off to bed, then. [07:41] not so away [07:42] elmo/infinity: so we just need to nuke/rebuild the -autotest chroots? [07:44] lamont: nuke might be a bit harsh, certainly check+sanitize tho [07:45] yeah - but nuke is trivial.... :-) [07:45] umount in a loop, build-chroot buildd breezy -autotest, fin. [07:46] well, with a rm -rf after the umounts === lamont undertakes the process [07:48] thanks [07:55] first 4 done, second 8 cleaning now [07:55] (new math) [08:07] elmo: breezy-autotest thinks it's a 'go' as far as buildd's are concerned [08:09] lamont: cool, thanks === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-toolchain [08:38] Subject: Log for failed build of glibc_2.3.5-1ubuntu10 (dist=breezy-autotest) [08:38] grumble [08:39] is that a genuine failure/ [08:40] no... build-tree disappeared from under it. [08:40] ah [08:40] heh [08:40] which could be me nuking it, or -1ubuntu11 got uploaded... [08:40] probably the first [08:40] hum? it's b-at [08:40] I nuked everything from under it, w-b.. the archive.. [08:40] elmo: what process do I need to follow for those debs to move to main? [08:41] doh. b-at --> almost certainly the former. :-) [08:41] see MainInclusionQueue on the wiki [08:41] cool [08:41] I think.. grepping for MainInclusion should give you some hints === doko [n=doko@dsl-084-059-092-216.arcor-ip.net] has joined #ubuntu-toolchain