[03:55] <infinity> elmo : Danke.
[04:04] <infinity> Oh, well, that worked smashingly.
[04:07] <infinity> Much better.
[04:09] <elmo> pls to be fixing live + di builds too
[04:09] <elmo> I realise you're probably on it, I just don't want it to get forgotten
[04:09] <elmo> as I think mdz would be unamused by a G5-only colony 4
[04:13] <infinity> Heh.
[04:13] <infinity> More interestingly, we don't have linux32 on warty.
[04:14] <elmo> what's it linux32-ing in the chroot?
[04:15] <elmo> can't it just linux32 the chroot call?
[04:15] <infinity> That's the way build_env_cmnd works, it calls "exec linux32 dpkg-buildpackage" in the chroot.
[04:15] <infinity> But I suppose we could just run buildd itself under linux32 in the base.
[04:15] <infinity> Don't see why that wouldn't work.
[04:16] <elmo> well, except then we can't exclude packages
[04:16] <elmo> not sure if we need to or not
[04:17] <infinity> I can't see why we'd want to.
[04:17] <elmo> some things want to be built on a powerpc64?
[04:17] <elmo> maybe they don't check and/or care
[04:17] <infinity> 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] <elmo> but I don't know if gcc -m64 works when uname returns ppc
[04:18] <elmo> I know the debian kernel package breaks with sparc32
[04:18] <elmo> dunno who's fault that is tho
[04:18] <infinity> Well, the kernel tries to autoguess what target to build for by looking at uname.
[04:18] <infinity> But that can be forced, as we do in our kernel builds.
[04:19] <infinity> (Hence how we've been building ppc64 kernels just fine on ppc32 until now)
[04:19] <elmo> ok
[04:19] <elmo> well, I've got a b-at run pending anyway, so I guess we'll find out
[04:19] <elmo> *mutter* die postgres die *mutter
[04:19] <infinity> 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] <infinity> (or is that parisc/parisc64?... I can never remember)
[04:20] <infinity> 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] <infinity> I suppose buildd's call to sbuild would be a safe bet.
[04:39] <infinity> Alright, that should do it.
[04:40] <infinity> 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] <infinity> Which may be more sane than a wishy-washy, I-might-forget-to-set-it config option.
[04:41] <elmo> does linux32 work/exist on sparc?
[04:41] <elmo> debian uses 'sparc32' from sparcutils instead
[04:41] <infinity> It works on sparc just fine.
[04:41] <infinity> sparc32 exists because it was the first kernel to implement personalities.
[04:42] <elmo> ok
[04:42] <infinity> linux32 is the genericisation of that.
[04:42] <elmo> I reckon hardcode and depend on then
.. That feels more right to me.
[04:43] <infinity> 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] <elmo> argh
[04:43] <elmo> you andreas jochens fan boy
[04:44] <infinity> Heh.
[04:44] <infinity> 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] <infinity> 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] <infinity> Oh, feh.  We should also promote linux32 to main.
[04:48] <elmo> boggle
[04:48] <elmo> god yes
[04:48] <elmo> christ I missed the deadline for "get these things into main" AGAIN
[04:51] <infinity> Will mdz demand a MainInclusionReport for this, or do you want to just seed it?
[04:51] <elmo> uh, I dunno, I suppose we should ask
[04:51] <elmo> if I abuse my dak supah powahs, it makes it harder for me to shout at him rm-ing random files
... 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] <infinity> I don't suppose we have a hoary-cat yet? ;)
[05:05] <lamont> jbailey: wth is springgraph/
[05:05] <lamont> ?
[05:05] <jbailey> It's a graphviz clone.
[05:05] <jbailey> Why are3 you asking me? =)
[05:05] <lamont> because you're Mr CDBS, ofcourse
[05:06] <elmo> infinity: no, sorry, meh
[05:06] <elmo> I really want that myself
[05:55] <infinity> Lamont picked a fine time to kill his connection.
[06:01] <infinity> Oh well, guess I'll manually roll these changes out for now, and lamont can clean up with a proper release later.
[06:01] <infinity> (ps: did I mention how much I'd love hoary-cat?)
[06:06] <infinity> Alright, buildds are all back up and happy.  live and d-i next.
[06:07] <infinity> elmo : Thanks for this, by the way.  I'm fairly certain it was desperately needed.
[06:07] <infinity> I'll do a mass give-back in a bit and see how many failures mysteriously clear up.
[06:51] <infinity> There, live and DI are fixed up too.
[07:09] <fabbione> morning
[07:28] <fabbione> jbailey, doko, elmo: any chance to get binutils fixed asap?
[07:29] <fabbione> (for sparc i mean)
[07:50] <doko> morning fabbione
[07:52] <doko> elmo: please install libgl1-mesa-dev and libglu1-mesa-dev on davis/breezy, the xlibmesa packages were not removed automatically
[08:04] <fabbione> doko: yo
[08:04] <fabbione> doko: i start to be under pressure with binutils
[08:04] <fabbione> after seb uploaded all of gnome again, almost all of it is FTBFS due to that problem
[08:06] <doko> fabbione: understood
[08:06] <fabbione> thanks
[08:07] <doko> elmo: do you have a pre-unstable version of the patch available, that we can apply for sparc (maybe hppa) only?
[08:07] <fabbione> doko: afaik the patch is required for sparc and hppa.. 
[08:07] <fabbione> and alpha..
[08:07] <fabbione> but we don't have alpha so ENOCARE
[12:19] <infinity> fabbione : Alright, do you want to know how to fix mesa for sparc?
[12:19] <fabbione> infinity: nope...
[12:19] <fabbione> or better..
[12:19] <fabbione> yes i want to know
[12:19] <fabbione> because i don't know how to
[12:20] <infinity> Actually, I'm sure you can figure it out. :)
[12:20] <infinity> Anyhow, three simple steps:
[12:20] <infinity> 1: Build libdrm_1.0.3-2 (which just showed up in wanna-build)
[12:20] <infinity> 2: preseed your chroot with reasonably recent libglu1-mesa-dev, libgl1-mesa-dev, mesa-common-dev.
[12:21] <infinity> 3: build mesa_6.3.2-0ubuntu2
[12:21] <infinity> 4: Never have to worry about build-dep loops again, cause the most recent mesa no longer has any.
[12:21] <fabbione> 2) <- i don't have any recent libglu1-mesa-dev libgl1-mesa-dev, mesa-common-dev.
[12:21] <fabbione> or are they arch: all???
[12:21] <infinity> mesa-common-dev is arch:all, the others are arch:any, that's where the problem was.
[12:22] <fabbione> infinity: i don't think i even have them anywhere...
[12:22] <infinity> 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] <fabbione> libglu1-mesa_6.3.1.1-0ubuntu1_sparc.deb
[12:23] <fabbione> this is the most recent one i have
[12:23] <infinity> That looks recent to me.
[12:23] <fabbione> hmmm
[12:23] <fabbione> it might have built while i was sleeping 
[12:23] <fabbione> and i missed it..
[12:23] <infinity> Install that, plus the matching libgl1-mesa, plus the matching -dev packages, plus mesa-common-dev, ann in the same versions.
[12:23] <infinity> s/ann/all/
[12:23] <infinity> Once the new mesa has been built, you can clean them out of your chroot, and life resumes as normal.
[12:24] <fabbione> infinity: well as soon as i build the new mesa i should be fine...
[12:24] <infinity> Right, once you have the new mesa, you're fine.  But you need the old to build the new (hence the problem)
[12:24] <infinity> And the old has exact version deps between arch:any and arch:all packages.
[12:24] <fabbione> ok, but it seems i have the old ones...
[12:24] <fabbione> AHH CRAP
[12:24] <fabbione> ok
[12:25] <infinity> Right. :)
[12:25] <infinity> 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] <infinity> Just keep in mind that you need libdrm first, cause mesa build-deps on it.
[12:26] <fabbione> yup...
[12:26] <fabbione> doing it
[12:26] <fabbione> -2 ?
[12:27] <fabbione> yeah.. it's not in my local archive yet...
[12:27] <fabbione> i need to wait for it
[12:27] <infinity> Yeah, -2.
[12:27] <infinity> -1 was a little bit broken.  Just a tad.
[12:28] <fabbione> ehehe
[06:13] <elmo> infinity/lamont: breezy-at is finally going, FYI
[06:23] <infinity> elmo : Yay.  Does this mean I can bug you about hoary-cat again? ;)
[06:27] <elmo> christing bananas
[06:27] <elmo> adelie's going nuts trying to cope with all the logs
[06:27] <elmo> (fails, I assume)
[06:28] <infinity> I only have 178 -autotest failures in my INBOX so far.
[06:28] <infinity> But if they're all backlogged, I guess I'll see more. :)
[06:29] <elmo> well, it's sending to lamont
[06:29] <elmo> probably over, like a piece of string, by way of alsaka or something

[06:30] <infinity> Yeah, mine all go to a host in a datacenter with multiple GigE carriers and a 100Mbit port on the box.
[06:30] <infinity> So, I doubt I'm a bottleneck.
[06:30] <infinity> 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] <lamont-away> elmo: it's sending over a straw of 25kbps, which it shares with the upload/download queue for the buildd
[06:39] <lamont-away> so it's not _quite_ string and tin-cans
[06:39] <jbailey> lamont-away: Haven't you moved that under your desk at work yet? =)
[06:39] <lamont-away> jbailey: there's another one under the desk, which gets _VERY_ annoyed at HP's proxies
[06:39] <lamont-away> which are "transparent"
[06:40] <lamont-away> and given bandwidth available at the site, I think elmo would be conflicted about whether I should set up shop there...
[06:43] <elmo> buildd mail isn't going to hurt gluck
[06:43] <lamont-away> it's more the  up/down loads of the buildd
[06:44] <elmo> dude, I ran two buildds on a 2Mb connection
[06:44] <elmo> your two debian buildds in fact :)
[06:44] <lamont-away> ah, ok.  I'll like move it then
[06:51] <lamont-away> infinity: you upload a buildable mesa yet? :-)
[06:52] <lamont-away> ah, daniels uploaded... maybe ubuntu3 will build for me.
[06:52] <infinity> lamont-away : Oh, you'll need to handhold it once.
[06:52] <lamont-away> grrrrrr
[06:52] <lamont-away> but only once?
[06:52] <infinity> lamont-away : Make sure the latest libdrm is built first.
[06:53] <lamont-away> oh, that part is fine.
[06:53] <lamont-away> it was the circular build-dep on itself that was annoying me most
[06:53] <infinity> 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] <infinity> lamont-away : Then build the most recent mesa, and you'll never see this loop again (cause it's gone)
[06:53] <lamont-away> woohoo!!!!
[06:54] <infinity> 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] <lamont-away> thanks muchly
[06:56] <lamont-away> 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] <lamont-away> 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] <doko> heh, yes, libgcc2 is nice to have :-)
[06:58] <elmo> lamont: if you jump through the required hoops, I could/would
[06:59] <elmo> well, at least for new source packages
[06:59] <elmo> are any of those from packages already in main?
[06:59] <lamont-away> gcc-3.4-hppa64 is from gcc-3.4, libgcc2 comes from 3.4 or 4.0
[06:59] <elmo> hmm, crap, the problem is germinate doesn't do hppa
[06:59] <lamont-away> right
[06:59] <elmo> how stable is hppa ATM?
[06:59] <lamont-away> seems to be stable-ish
[07:00] <lamont-away> buildd is running breezy
[07:00] <lamont-away> hrm.. actually, hoary/breezy mix..
[07:00] <lamont-away> most things pinned at hoary
[07:00] <elmo> I'll try adding hppa to germinate temporarily, see how bad the damage is
[07:00] <elmo> are you using onion on hppa?
[07:01] <lamont-away> yes
[07:01] <elmo> ok
[07:01] <infinity> lamont-away : Have you merged the patches I sent you to your arch archives?
[07:01] <lamont-away> since the beginning of time (hoary archive on people was built using ogre-model)
[07:01] <elmo> btw, I dunno how useful it is, but neuro's done auto-dep-wait in w-b
[07:01] <lamont-away> infinity: I just read them a couple minutes ago
[07:01] <lamont-away> elmo: yeah, we probably want to merge that in
[07:01] <fabbione> infinity: patch to do what?
[07:01] <infinity> elmo : Yeah, I was going to look at it and merge it if it looked decent.
[07:02] <lamont-away> more merge our changes forward to his base
[07:02] <lamont-away> or something like that
[07:02] <infinity> lamont-away : Merging w-b in general is on my TODO anyway.
[07:02] <lamont-away> right
[07:02] <infinity> (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] <elmo> uhm
[07:02] <elmo> heck yes I mind
[07:03] <lamont-away> 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] <elmo> neuro managed to transition them?
[07:03] <infinity> Yeah, I believe he did.
[07:03] <lamont-away> elmo: ISTR something from him about how he'd, um, managed to wind up doing a mass-give-back of everything...
[07:03] <infinity> 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] <infinity> Yeah, he gave back everything in building.  That was an oops.
[07:04] <infinity> But he kept the entire failure history, that was the important bit for Debian.
[07:04] <lamont-away> infinity: some days I actually reply with bug numbers...
[07:04] <infinity> Not sure how much we care about that.
[07:04] <lamont-away> but that tends to be packages that someone uploaded broken, and then didn'
[07:04] <infinity> Rebuilding our DB's from scratch based  on the archive state wouldn't really hurt us much.
[07:04] <lamont-away> t fix for a few days
[07:04] <lamont-away> back in a few
[07:04] <elmo> infinity: I don't care about breezy
[07:05] <elmo> I care slightly more about << breezy
[07:05] <infinity> Ahh, yeah.  I can see that.
[07:05] <elmo> gar, germinate so slow
[07:05] <infinity> Well, we can look into smooth upgrades when I find the round tuits required to exercise some WAB on infrastructure.
[07:08] <elmo> ok, hppa's pulling in random crap
[07:09] <elmo> Building        :  1123 (buildd+rothera: 1093, buildd+terranova: 9,
[07:10] <elmo> uhh
[07:10] <elmo> someone might want to check on rothera
[07:10] <infinity> 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] <elmo> no
[07:10] <elmo> E: The package eclipse-ecj needs to be reinstalled, but I can't find an archive for it.
[07:14] <elmo> oh crap, I forgot to trash the w-b databases
[07:14] <elmo> now they're full of d-w, d-w-r, f and f-r
[07:16] <infinity> 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] <infinity> Should we start this experiment over again? :)
[07:17] <elmo> yeah, sounds like a plan
[07:17] <infinity> lamont-away : How away are you actually right now?
[07:18] <infinity> 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] <infinity> elmo : Can you open the floodgates at the touch of a button after we clean stuff up and poke you?
[07:18] <elmo> yeah
[07:18] <elmo> I'm redoing the import process on rockhopper now
[07:19] <elmo> so just yell whenever
[07:19] <infinity> 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.
[07:41] <lamont> not so away
[07:42] <lamont> elmo/infinity: so we just need to nuke/rebuild the -autotest chroots?
[07:44] <elmo> lamont: nuke might be a bit harsh, certainly check+sanitize tho
[07:45] <lamont> yeah - but nuke is trivial.... :-)
[07:45] <lamont> umount in a loop, build-chroot buildd breezy -autotest, fin.
[07:46] <lamont> well, with a rm -rf after the umounts
[07:48] <elmo> thanks
[07:55] <lamont> first 4 done, second 8 cleaning now
[07:55] <lamont> (new math)
[08:07] <lamont> elmo: breezy-autotest thinks it's a 'go' as far as buildd's are concerned
[08:09] <elmo> lamont: cool, thanks
[08:38] <lamont> Subject: Log for failed build of glibc_2.3.5-1ubuntu10 (dist=breezy-autotest)
[08:38] <lamont> grumble
[08:39] <elmo> is that a genuine failure/
[08:40] <lamont> no... build-tree disappeared from under it.
[08:40] <elmo> ah
[08:40] <elmo> heh
[08:40] <lamont> which could be me nuking it, or -1ubuntu11 got uploaded...
[08:40] <lamont> probably the first
[08:40] <elmo> hum?  it's b-at
[08:40] <elmo> I nuked everything from under it, w-b.. the archive..
[08:40] <lamont> elmo: what process do I need to follow for those debs to move to main?
[08:41] <lamont> doh.  b-at --> almost certainly the former. :-)
[08:41] <elmo> see MainInclusionQueue on the wiki
[08:41] <lamont> cool
[08:41] <elmo> I think.. grepping for MainInclusion should give you some hints