#ubuntu-toolchain 2005-08-29
* infinity wakes up to the pleasant surprise of ppc64 buildds.
<infinity> elmo : Danke.
* infinity touches up .sbuildrc and restarts a buildd.
<infinity> Oh, well, that worked smashingly.
* infinity smacks himself, adds linux32 to the chroots and tries again.
<infinity> Much better.
<elmo> pls to be fixing live + di builds too
<elmo> I realise you're probably on it, I just don't want it to get forgotten
<elmo> as I think mdz would be unamused by a G5-only colony 4
<infinity> Heh.
<infinity> More interestingly, we don't have linux32 on warty.
<elmo> what's it linux32-ing in the chroot?
<elmo> can't it just linux32 the chroot call?
<infinity> That's the way build_env_cmnd works, it calls "exec linux32 dpkg-buildpackage" in the chroot.
<infinity> But I suppose we could just run buildd itself under linux32 in the base.
<infinity> Don't see why that wouldn't work.
<elmo> well, except then we can't exclude packages
<elmo> not sure if we need to or not
<infinity> I can't see why we'd want to.
<elmo> some things want to be built on a powerpc64?
<elmo> maybe they don't check and/or care
<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
<elmo> but I don't know if gcc -m64 works when uname returns ppc
<elmo> I know the debian kernel package breaks with sparc32
<elmo> dunno who's fault that is tho
<infinity> Well, the kernel tries to autoguess what target to build for by looking at uname.
<infinity> But that can be forced, as we do in our kernel builds.
<infinity> (Hence how we've been building ppc64 kernels just fine on ppc32 until now)
<elmo> ok
<elmo> well, I've got a b-at run pending anyway, so I guess we'll find out
<elmo> *mutter* die postgres die *mutter
<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.
<infinity> (or is that parisc/parisc64?... I can never remember)
<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.
<infinity> I suppose buildd's call to sbuild would be a safe bet.
<infinity> Alright, that should do it.
<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.
<infinity> Which may be more sane than a wishy-washy, I-might-forget-to-set-it config option.
<elmo> does linux32 work/exist on sparc?
<elmo> debian uses 'sparc32' from sparcutils instead
<infinity> It works on sparc just fine.
<infinity> sparc32 exists because it was the first kernel to implement personalities.
<elmo> ok
<infinity> linux32 is the genericisation of that.
<elmo> I reckon hardcode and depend on then
<infinity> <nod>.. That feels more right to me.
<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)
<elmo> argh
<elmo> you andreas jochens fan boy
<infinity> Heh.
<infinity> It's more just the thought that anything being autoconfigured in buildd/sbuild should be reasonably overridable, and the defaults should be sane.
<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".
<infinity> Oh, feh.  We should also promote linux32 to main.
<elmo> boggle
<elmo> god yes
<elmo> 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.
<infinity> Will mdz demand a MainInclusionReport for this, or do you want to just seed it?
<elmo> uh, I dunno, I suppose we should ask
<elmo> if I abuse my dak supah powahs, it makes it harder for me to shout at him rm-ing random files
<infinity> <nod>... 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.
<infinity> I don't suppose we have a hoary-cat yet? ;)
<lamont> jbailey: wth is springgraph/
<lamont> ?
<jbailey> It's a graphviz clone.
<jbailey> Why are3 you asking me? =)
<lamont> because you're Mr CDBS, ofcourse
<elmo> infinity: no, sorry, meh
<elmo> I really want that myself
<infinity> Lamont picked a fine time to kill his connection.
<infinity> Oh well, guess I'll manually roll these changes out for now, and lamont can clean up with a proper release later.
<infinity> (ps: did I mention how much I'd love hoary-cat?)
<infinity> Alright, buildds are all back up and happy.  live and d-i next.
<infinity> elmo : Thanks for this, by the way.  I'm fairly certain it was desperately needed.
<infinity> I'll do a mass give-back in a bit and see how many failures mysteriously clear up.
<infinity> There, live and DI are fixed up too.
<fabbione> morning
<fabbione> jbailey, doko, elmo: any chance to get binutils fixed asap?
<fabbione> (for sparc i mean)
<doko> morning fabbione
<doko> elmo: please install libgl1-mesa-dev and libglu1-mesa-dev on davis/breezy, the xlibmesa packages were not removed automatically
<fabbione> doko: yo
<fabbione> doko: i start to be under pressure with binutils
<fabbione> after seb uploaded all of gnome again, almost all of it is FTBFS due to that problem
<doko> fabbione: understood
<fabbione> thanks
<doko> elmo: do you have a pre-unstable version of the patch available, that we can apply for sparc (maybe hppa) only?
<fabbione> doko: afaik the patch is required for sparc and hppa.. 
<fabbione> and alpha..
<fabbione> but we don't have alpha so ENOCARE
<infinity> fabbione : Alright, do you want to know how to fix mesa for sparc?
<fabbione> infinity: nope...
<fabbione> or better..
<fabbione> yes i want to know
<fabbione> because i don't know how to
<infinity> Actually, I'm sure you can figure it out. :)
<infinity> Anyhow, three simple steps:
<infinity> 1: Build libdrm_1.0.3-2 (which just showed up in wanna-build)
<infinity> 2: preseed your chroot with reasonably recent libglu1-mesa-dev, libgl1-mesa-dev, mesa-common-dev.
<infinity> 3: build mesa_6.3.2-0ubuntu2
<infinity> 4: Never have to worry about build-dep loops again, cause the most recent mesa no longer has any.
<fabbione> 2) <- i don't have any recent libglu1-mesa-dev libgl1-mesa-dev, mesa-common-dev.
<fabbione> or are they arch: all???
<infinity> mesa-common-dev is arch:all, the others are arch:any, that's where the problem was.
<fabbione> infinity: i don't think i even have them anywhere...
<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.
<fabbione> libglu1-mesa_6.3.1.1-0ubuntu1_sparc.deb
<fabbione> this is the most recent one i have
<infinity> That looks recent to me.
<fabbione> hmmm
<fabbione> it might have built while i was sleeping 
<fabbione> and i missed it..
<infinity> Install that, plus the matching libgl1-mesa, plus the matching -dev packages, plus mesa-common-dev, ann in the same versions.
<infinity> s/ann/all/
<infinity> Once the new mesa has been built, you can clean them out of your chroot, and life resumes as normal.
<fabbione> infinity: well as soon as i build the new mesa i should be fine...
<infinity> Right, once you have the new mesa, you're fine.  But you need the old to build the new (hence the problem)
<infinity> And the old has exact version deps between arch:any and arch:all packages.
<fabbione> ok, but it seems i have the old ones...
<fabbione> AHH CRAP
<fabbione> ok
* fabbione understands now...
<infinity> Right. :)
<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.
<infinity> Just keep in mind that you need libdrm first, cause mesa build-deps on it.
<fabbione> yup...
<fabbione> doing it
<fabbione> -2 ?
<fabbione> yeah.. it's not in my local archive yet...
<fabbione> i need to wait for it
<infinity> Yeah, -2.
<infinity> -1 was a little bit broken.  Just a tad.
<fabbione> ehehe
<elmo> infinity/lamont: breezy-at is finally going, FYI
<infinity> elmo : Yay.  Does this mean I can bug you about hoary-cat again? ;)
<elmo> christing bananas
<elmo> adelie's going nuts trying to cope with all the logs
<elmo> (fails, I assume)
<infinity> I only have 178 -autotest failures in my INBOX so far.
<infinity> But if they're all backlogged, I guess I'll see more. :)
<elmo> well, it's sending to lamont
<elmo> probably over, like a piece of string, by way of alsaka or something
<infinity> <snicker>
<infinity> Yeah, mine all go to a host in a datacenter with multiple GigE carriers and a 100Mbit port on the box.
<infinity> So, I doubt I'm a bottleneck.
<infinity> Of course, then I access said mail via IMAP from my tin cans and string in Australia, but let's not split hairs.
<lamont-away> elmo: it's sending over a straw of 25kbps, which it shares with the upload/download queue for the buildd
<lamont-away> so it's not _quite_ string and tin-cans
<jbailey> lamont-away: Haven't you moved that under your desk at work yet? =)
<lamont-away> jbailey: there's another one under the desk, which gets _VERY_ annoyed at HP's proxies
<lamont-away> which are "transparent"
<lamont-away> and given bandwidth available at the site, I think elmo would be conflicted about whether I should set up shop there...
<elmo> buildd mail isn't going to hurt gluck
<lamont-away> it's more the  up/down loads of the buildd
<elmo> dude, I ran two buildds on a 2Mb connection
<elmo> your two debian buildds in fact :)
<lamont-away> ah, ok.  I'll like move it then
<lamont-away> infinity: you upload a buildable mesa yet? :-)
<lamont-away> ah, daniels uploaded... maybe ubuntu3 will build for me.
<infinity> lamont-away : Oh, you'll need to handhold it once.
<lamont-away> grrrrrr
<lamont-away> but only once?
<infinity> lamont-away : Make sure the latest libdrm is built first.
<lamont-away> oh, that part is fine.
<lamont-away> it was the circular build-dep on itself that was annoying me most
<infinity> lamont-away : Then pre-seed a chroot with reasonably recent libgl1-mesa-dev, libglu1-mesa-dev, mesa-common-dev, libgl1-mesa, libglu1-mesa.
<infinity> lamont-away : Then build the most recent mesa, and you'll never see this loop again (cause it's gone)
<lamont-away> woohoo!!!!
<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.
<lamont-away> thanks muchly
<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:
<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
<doko> heh, yes, libgcc2 is nice to have :-)
<elmo> lamont: if you jump through the required hoops, I could/would
<elmo> well, at least for new source packages
<elmo> are any of those from packages already in main?
<lamont-away> gcc-3.4-hppa64 is from gcc-3.4, libgcc2 comes from 3.4 or 4.0
<elmo> hmm, crap, the problem is germinate doesn't do hppa
<lamont-away> right
<elmo> how stable is hppa ATM?
<lamont-away> seems to be stable-ish
<lamont-away> buildd is running breezy
<lamont-away> hrm.. actually, hoary/breezy mix..
<lamont-away> most things pinned at hoary
<elmo> I'll try adding hppa to germinate temporarily, see how bad the damage is
<elmo> are you using onion on hppa?
<lamont-away> yes
<elmo> ok
<infinity> lamont-away : Have you merged the patches I sent you to your arch archives?
<lamont-away> since the beginning of time (hoary archive on people was built using ogre-model)
<elmo> btw, I dunno how useful it is, but neuro's done auto-dep-wait in w-b
<lamont-away> infinity: I just read them a couple minutes ago
<lamont-away> elmo: yeah, we probably want to merge that in
<fabbione> infinity: patch to do what?
<infinity> elmo : Yeah, I was going to look at it and merge it if it looked decent.
<lamont-away> more merge our changes forward to his base
<lamont-away> or something like that
<infinity> lamont-away : Merging w-b in general is on my TODO anyway.
<lamont-away> right
<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)
<elmo> uhm
<elmo> heck yes I mind
<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
<elmo> neuro managed to transition them?
<infinity> Yeah, I believe he did.
<lamont-away> elmo: ISTR something from him about how he'd, um, managed to wind up doing a mass-give-back of everything...
<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.
<infinity> Yeah, he gave back everything in building.  That was an oops.
<infinity> But he kept the entire failure history, that was the important bit for Debian.
<lamont-away> infinity: some days I actually reply with bug numbers...
<infinity> Not sure how much we care about that.
<lamont-away> but that tends to be packages that someone uploaded broken, and then didn'
<infinity> Rebuilding our DB's from scratch based  on the archive state wouldn't really hurt us much.
<lamont-away> t fix for a few days
<lamont-away> back in a few
<elmo> infinity: I don't care about breezy
<elmo> I care slightly more about << breezy
<infinity> Ahh, yeah.  I can see that.
<elmo> gar, germinate so slow
<infinity> Well, we can look into smooth upgrades when I find the round tuits required to exercise some WAB on infrastructure.
<elmo> ok, hppa's pulling in random crap
<elmo> Building        :  1123 (buildd+rothera: 1093, buildd+terranova: 9,
<elmo> uhh
<elmo> someone might want to check on rothera
<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.
<elmo> no
<elmo> 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..
<elmo> oh crap, I forgot to trash the w-b databases
<elmo> now they're full of d-w, d-w-r, f and f-r
<infinity> Hrm, perhaps we should have made sure the breezy-at chroots were fresh, clean, and ready to go before firing up the run.
<infinity> Should we start this experiment over again? :)
<elmo> yeah, sounds like a plan
<infinity> lamont-away : How away are you actually right now?
<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.
<infinity> elmo : Can you open the floodgates at the touch of a button after we clean stuff up and poke you?
<elmo> yeah
<elmo> I'm redoing the import process on rockhopper now
<elmo> so just yell whenever
<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.
* infinity allows himself to be dragged off to bed, then.
<lamont> not so away
<lamont> elmo/infinity: so we just need to nuke/rebuild the -autotest chroots?
<elmo> lamont: nuke might be a bit harsh, certainly check+sanitize tho
<lamont> yeah - but nuke is trivial.... :-)
<lamont> umount in a loop, build-chroot buildd breezy -autotest, fin.
<lamont> well, with a rm -rf after the umounts
* lamont undertakes the process
<elmo> thanks
<lamont> first 4 done, second 8 cleaning now
<lamont> (new math)
<lamont> elmo: breezy-autotest thinks it's a 'go' as far as buildd's are concerned
<elmo> lamont: cool, thanks
<lamont> Subject: Log for failed build of glibc_2.3.5-1ubuntu10 (dist=breezy-autotest)
<lamont> grumble
<elmo> is that a genuine failure/
<lamont> no... build-tree disappeared from under it.
<elmo> ah
<elmo> heh
<lamont> which could be me nuking it, or -1ubuntu11 got uploaded...
<lamont> probably the first
<elmo> hum?  it's b-at
<elmo> I nuked everything from under it, w-b.. the archive..
<lamont> elmo: what process do I need to follow for those debs to move to main?
<lamont> doh.  b-at --> almost certainly the former. :-)
<elmo> see MainInclusionQueue on the wiki
<lamont> cool
<elmo> I think.. grepping for MainInclusion should give you some hints
#ubuntu-toolchain 2005-08-30
<fabbione> morning 
<elmo> breeay-at is running again
#ubuntu-toolchain 2005-08-31
<lamont> ./autotools-2.sh: realpath: command not found
* lamont notes that just dropping realpath from the build-deps doesn't work for cdbs...
<jbailey> lamont: =(
<jbailey> lamont: I don't remember what we use it for.
<jbailey> Oh, for the testsuite.
<jbailey> Do you have to autobuild this?
<jbailey> DEB_BUILD_OPTIONS=nocheck debuild =)
<lamont> well, yes and no...
<lamont> what do I change in rules/Makefile.am/whatever to do the same thing?
* lamont bets it's the last line of debian/rules
<lamont> much better. :-)
<elmo> lamont-away: vernadsky has no buildd?
<lamont-away> ??
* lamont-away looks
<elmo> well, I noticed b-at uploads for i386 are only coming from two hosts
<elmo> so I assume vernadsky's buildd's down as I didn't see it building anything
<lamont> it was being confused.
<lamont> shouldbe running shortly
<elmo> coolio, tnx
<lamont> elmo: it's running now
<fabbione> morning guys
<lamont> g'night all
<fabbione> night lamont
<jbailey> lamont-away, fabbione: I'm doing a glibc upload soonish (This weekend or Monday).  Got things you need done for sparc/hppa?
<fabbione> jbailey: the ipv6 resolver and for some reasons apt-ftparchive sends out a bus error with new libc
<fabbione> so perhaps it's time for you to plug your sparc :)
<jbailey> Yup, the resolver is on my list to look at.
<jbailey> *bus error*?
<jbailey> Ugh.
<jbailey> Yeah, maybe.
<jbailey> I wonder if that's a gcc bug screwing with alignment.
<jbailey> I have trouble imagining it being a libc function.
<jbailey> davem's pretty careful about that,  but it's easy to imagine an enthusiastic optimisation written by a non-sparc person.
<lamont-away> jbailey: not that I know of
<elmo> lamont-away/infinity: rothera has 281 packages d-w on debhelper in b-at
<elmo> hmm, this breezy-autotest thing is not going well
<infinity> elmo : The debhelper dep-wait is orthoganal to the other issues breezy-at had.  We get it in breezy too, and it appears to be a bit of a goofy apt bug that then bites our auto-dep-wait script.
<infinity> elmo : I've not looked deeply into it (though I should sit down with mvo at some point) because it always fixes itself on the next cron.daily anyway.
<elmo> well.. except when they all get wedged with it, and there is no cron.daily ;)
<elmo> I mentioned ryan's auto-d-w work, right?
<infinity> Yeah, I'll look at it first thing next week.
<infinity> This is, in theory, a weekend. :)
<elmo> ok, cool
<elmo> yeah, sure
<infinity> Only fixing the current glaring bugs because they're, well, glaring.
<infinity> They were mocking me, even.
<infinity> Wait, there's no cron.daily for -autotest?
<infinity> How on earth do dep-waits work, then?
<elmo> no there is
<infinity> Oh, phew.
<elmo> but cron.daily doesn't run if there's nothing to do
<infinity> Right.  And nothing was being uploaded, cause I fucked up.
<infinity> Fixed.
<elmo> where as normal breezy's has humans always uploading, b-at is only powered by the buildds
<infinity> Ouch.  I think I broke wanna-build.
<infinity> Or... jackass...
<infinity> Can't create lock file /srv/buildd.no-name-yet.com/db/amd64/build-db-breezy.lock: Read-only file system
<elmo> yes
<elmo> I'm on myway to the DC now
<infinity> Ugh.  Good luck.
#ubuntu-toolchain 2005-09-01
<jbailey> lamont-away: Hey, do you still maintain bsdmainutils?
#ubuntu-toolchain 2005-09-03
* lamont-away grumbles at hppa/breezy's _GOT_ challenges..
<lamont-away> specifically, openexr is FTBFS, because configure trips over _GOT_ issues when checking for -lz.
<lamont-away> rebuilding zlib does not fix things
<fabbione> morning
<elmo> infinity/lamont: I'm going to have to export/import the w-b databases
<fabbione> elmo: something new coming up?
<fabbione> is there anything i need to do on the sparc buildd?
<elmo> no, it's just related to the jackass change of hw, and berkley db not liking being promoted ot 64-bit
<elmo> (see backscroll in #c)
<fabbione> ok :)
<fabbione> thanks
<lamont-away> elmo: ok
<lamont-away>  /usr/include/linux/socket.h:10: error: redefinition of 'struct sockaddr'
<lamont-away> feh
<lamont-away> jbailey_: if you're bored, could you look at an hppa chroot and see if you can figure out why openexr fails to build?
<lamont-away> (symptom is that conftest.c, linking against glibc, gets duplicate _G_O_T_ symbol
* lamont-away must run away for a while
#ubuntu-toolchain 2005-09-04
<fabbione> morning
<jbailey> doko, elmo: fabbiones was nudging me about the binutils update, and I think it might solve the GOT issue on HPPA (it looks very similar).  Do you want me to look at it later?
<doko> jbailey: sure, yes. elmo, could you place the patch somewhere? maybe we just apply it for sparc and hppa for breezy.
<elmo> eww
<elmo> the patch is on the mailing list
<elmo> I think conditionally applying patches, esp. on a per-arch basis is satanic
<jbailey> elmo: Yup, you said you were hacking on it last week - do you have a dpatch?  If not, I'll throw it together.
<jbailey> And we do that all the time in the toolchain.
<elmo> however, I can't justify working on it during the day, not if it doesn't affect a release arch, so you guys go ahead and do what you want for breezy
<elmo> jbailey: that doesn't make it right
<elmo> and FWIW binutils has never done it :P
<jbailey> =)
<fabbione> so guys.. how many chances i have to get fixed binutils?
<jbailey> fabbione: I'll extract the patch in a few hours.
<jbailey> fabbione: When are you passing out tonight?
<fabbione> jbailey: around 18:00 UTC
<jbailey> Ah, quite early then.
<jbailey> Well, hopefully by the time you wake up then.
<fabbione> jbailey: well yeah.. i will have dinner at that time.. and i would love to spend sometime with my wife :)
<jbailey> I understand. =)
<jbailey> We need to get more of us married off so that becomes normal. ;)
<fabbione> jbailey: ehehe
#ubuntu-toolchain 2006-09-01
<leoncamel_> hi, folks. how can I install gcc-3.2 into Ubuntu 5.10 ?
#ubuntu-toolchain 2007-08-27
<doko> arthur-: did you update the .orig.tar.gz?
<arthur-> doko: iirc yes, let me check
<arthur-> doko: looks like I forgot to re-upload... hold on
<doko> ok, and did you have the diffs to only build on the supported archs ready?
<arthur-> doko: I'm currently testing with fpmath.o on sparc before
<arthur-> but
<arthur-> ../../../src/libphobos/internal/fpmath.d:47: static assert  is false
<arthur-> make[3] : *** [internal/fpmath.o]  Error 1
<arthur-> doko: please try http://uploads.dunnewind.net/packages/gdc-4.1_0.24-4.1.2-15/gdc-4.1_0.24-4.1.2-15.dsc for the source package
<arthur-> should be ok
<arthur-> touch stamps/05-build-stamp
<arthur-> have to test it works now
<arthur-> (sid)arthur@sunny:~/gdc-4.1/gdc-4.1-0.24-4.1.2/debian/gdc-4.1$ ./test 
<arthur-> Bus error
<arthur-> doko: ok, I'm updating svn to set supported archs
<arthur-> doko: just sent you a mail
<arthur-> doko: does patches apply with this source package?
<doko> arthur-: have to check
<arthur-> ok
<doko> arthur-: patch applies
<arthur-> good, thanks
<doko> arthur-: could you subscribe to the package in launchpad?
<arthur-> doko: sure, done
<arthur-> doko: shall I join the ubuntu-toolchain team too?
<doko> arthur-: if you want to fix bugs =)
<arthur-> hum ok let's wait a few years then :-)
<doko> lamont: please build gcj-4.2 on hppa, appears to work for me
<lamont`> doko: in gutsy?
<doko> lamont: yes
<lamont`> rokc
<lamont`> rock, even
<doko> at least gjdoc and ecj do build,
<lamont`> doko: it's queued
<lamont`> devel/gcc-4.2_4.2.1-4ubuntu1: Needs-Build [important:out-of-date] 
<lamont`> base/linux-ubuntu-modules-2.6.22_2.6.22-10.24: Needs-Build [optional:out-of-date] 
<lamont`> devel/gcc-defaults_1.58ubuntu2: Needs-Build [optional:out-of-date] 
<lamont`> devel/gcj-4.2_4.2.1-4ubuntu1: Needs-Build [optional:out-of-date] 
<lamont`> that's what's not already taken that's ahead of gcj-4.2. :-(
<lamont`> gcc-4.2 is a 7 hour build
<doko> get faster machines :-)
<lamont`> 4-way j7000 in that case
<lamont`> 440MHz processors, though
<lamont`> it's that %&*(&^) test suite....
<doko> turn it off :)
#ubuntu-toolchain 2007-08-30
<arthur-> doko_: a new gdc svn snapshot should fix #439836, I'm testing it
<doko> arthur-: ok with me, maybe package it as svn-gdc-updates?
<arthur-> doko: what do you mean?
<doko> arthur-: instead of having a new .orig.tar.gz, put the updates in a dpatch file
<arthur-> damn too late :-)
<arthur-> I'm going to see how big is the diff
<arthur-> can't diff because of those @!# ends of line, have to get a new upstream tarball on sf.net
<arthur-> (sid)arthur@doko:~$ diff -Naur d d.new | wc -l
<arthur-> 86
<arthur-> doko: ok for me, I'm going to make a new patch
<arthur-> doko: is a version 0.24svn20070829-4.1.2 ok?
<doko> arthur-: as you like it
<arthur-> ok
<arthur-> d/.ChangeLog.swp  <<<  upstream author should quit vim with :wq, make diffs look nicer
<arthur-> doko: sent you a mail with a svn diff, please hold on before checking it in, have a to test build first
<arthur-> doko: don't check in at all, forgot to include changes list from the patch...
<arthur-> dpkg-deb: building package `gdc-4.1' in `../gdc-4.1_0.24svn20070829-4.1.2-15_powerpc.deb'.
<arthur-> doko: looks like the bug is fixed, no compiler ar assembler warning, but I can't check entirely since I don't know ppc asm at all =)
<arthur-> doko: re-sent you a mail with the updated diff, you'll find a signed source package here: http://uploads.dunnewind.net/packages/gdc-4.1_0.24svn20070829-4.1.2-15/gdc-4.1_0.24svn20070829-4.1.2-15.dsc
<arthur-> sleep time
* Starting logfile irclogs/ubuntu-toolchain.log
<lamont`> doko: 2.6.22.4 on an A500, current gutsy-stage0, no love.  Wanna send me the output of dpkg -l on your machine?
#ubuntu-toolchain 2007-08-31
<doko_> arthur-: D ping
<arthur-> doko: D pong
<doko> could you update the D packaging bits for 4.2 over the weekend (if you have time)
<arthur-> doko: I'm not sure I'll have, university begin on tuesday for me, I'll try
<doko> ok, never mind
<arthur-> :)
<arthur-> doko: can you upload gdc?
<doko> arthur-: gutsy?
<arthur-> doko: sid
<doko> please prepare a combined i386/powerpc upload
<arthur-> doko: *_multi.changes :-)
<doko> yes
<arthur-> ok
<arthur-> doko: build should take about 3 hours on my i386, please bear with me :-)
<arthur-> doko: is your sid schroot up-to-date ou powerpc?
<arthur-> s/ou/on/
<doko> should be recent, yes
<arthur-> ok :)
<arthur-> doko: built: http://paste.dunnewind.net/364
<arthur-> doko: please tell me where do you want me to put it when you are around
<doko> arthur-: well, adding the upstream changes as a patch was to avoid a new upstream version, but now you do have a new one ...
<arthur-> doko: I've asked you about the version and shown you this one, you answered "as you want"
<doko> hmm ... 
<arthur-> doko: which version number would you like?
<arthur-> doko: around?
#ubuntu-toolchain 2007-09-01
<arthur-> doko: http://people.dunnewind.net/arthur/doko/
<doko> arthur-: why did you build with -sa?
<arthur-> doko: I didn't, I've included it by hand
<doko> why?
<doko> arthur-: and please file a sync request
<arthur-> doko: don't really, sorry if it was a mistake
<doko> np, do it better the next time. you don't need to include the source again if it's already in the archive
<arthur-> ok :-)
<arthur-> doko: here is the sync request: https://bugs.launchpad.net/ubuntu/+source/gdc-4.1/+bug/136578
<arthur-> doko: my sponsor can ACK it if you have no time
<doko> arthur-: you need to mention that the ubuntu changes can be overwritten (if you have checked that)
<arthur-> "Previous merge don't bring any Ubuntu change to gdc-4.1."
<arthur-> doko: this was likely a "fakemerge" right? :-)
<arthur-> the -15ubuntu1 upload
<doko> yes
<arthur-> doko: shall I join the orig for an upload in experimental if the orig is in unstable?
<doko> no
<arthur-> ok, thanks
<doko> arthur-: you need to mention in the bug report, why the ubuntu changes can be dropped
<arthur-> wget -O /dev/stdout -q http://patches.ubuntu.com/g/gdc-4.1/gdc-4.1_0.23-4.1.2-15ubuntu2.patch | grep ^diff | grep -v changelog
<arthur-> diff -pruN 0.23-4.1.2-15/debian/control 0.23-4.1.2-15ubuntu2/debian/control
<arthur-> diff -pruN 0.23-4.1.2-15/debian/lib32gcj7-dev.overrides 0.23-4.1.2-15ubuntu2/debian/lib32gcj7-dev.overrides
<arthur-> diff -pruN 0.23-4.1.2-15/debian/README.Debian 0.23-4.1.2-15ubuntu2/debian/README.Debian
<arthur-> diff -pruN 0.23-4.1.2-15/debian/rules.parameters 0.23-4.1.2-15ubuntu2/debian/rules.parameters
<arthur-> doko: ok
<arthur-> doko: done, have to go.
<arthur-> doko: http://paste.dunnewind.net/367 don't think I forgot something
<arthur-> doko: I'm not sure at all of what I've dont with control.m4, have to test :-)
<arthur-> hum
<arthur-> forgot the gdc package in control.m4...
<arthur-> doko: http://paste.dunnewind.net/368
<doko> arthur-: look, but it's not against the current svn
<arthur-> Actualis  la rvision 2430.
<arthur-> damn
<arthur-> doko: http://paste.dunnewind.net/369
<doko> else ifeq ($(PKGSOURCE),gdc-4.1)
<doko> gcc-4.2-source (>= 4.2.2)
<arthur-> fixed
<doko> and the gcc-d-lang.dpatch is missing (please check that it applies in a gcc-4.2 build)
<doko> the other things look ok
<arthur-> ok
<arthur-> doko: http://paste.dunnewind.net/370 testing build right now
<doko> arthur-: please send it by email, something is wrong with the paste
<arthur-> doko: sure
<arthur-> doko: and hum, I'm sure you noticed that, but: http://packages.qa.debian.org/g/gcc-snapshot.html
<doko> shit happens
<arthur-> sent
<arthur-> doko: have you failed a script or something?
#ubuntu-toolchain 2007-09-02
<arthur-> doko: cc1: internal compiler error: no multiarch mapping for multilib (32)
<arthur-> doko: building gcc-4.1 on sparc
<arthur-> (gdc-4.1 0.24-4.1.2-17~exp)
<doko> arthur-: debian/rules2 : s/v9/v8/, or update the svn
<arthur-> ok, thanks
<arthur-> doko: D ping
<doko> ?
<arthur-> doko: can I upload something like this in experimental? http://people.dunnewind.net/arthur/doko/
<arthur-> (won't include orig tarball this time don't worry)
<arthur-> merge from Unstable package, just add a patch to fix build
<doko> hmm, I wouldn't use `+ in the release (that's something reserved for binNMUs), plus adding something differentiate your uploads to experimental: -16exp1
<arthur-> doko: ok, I build a -16exp1, I've found an amd64 so I prepare an upload for i386/amd64/powerpc/sparc
<arthur-> doko: can gdc be called (description) the "The GNU D compiler" since it uses gcc in middle-end and back-end ?
<doko> arthur-: hmm, is the FSF copyright holder?
<arthur-> doko: no
<arthur-> doko: david Friedman (gdc) and Walter Bright (dmd, digitalmars)
<doko> so maybe not
<arthur-> I perhaps should ask on the gcc ml
<doko> hmm, maybe not, use the name from the upstream project?
<arthur-> dmd? yes, gdc uses dmd in font-end
<doko> but who does hold the copyright? (I do not mean the authors)
<arthur->    Copyright (C) 2004 David Friedman
<arthur->    Copyright (c) 1999-2006 by Digital Mars
<doko> usually the FSF holds the copyright for GNU software, so I wouldn't name it "GNU D"
<arthur-> I wondered, moreover upstream gcc already recognize D, hold on
<arthur-> doko: http://people.dunnewind.net/arthur/doko/
<arthur-> doko: gcc/dwarf2.h:    DW_LANG_D = 0x0013,
<arthur-> doko: gdc builds fine with gcc-4.0, it would perhaps be useful to build a gdc-4.0 package
<doko> arthur-: NO! we want to KILL 4.0, not keep it
<arthur-> doko: ok  =)
<arthur-> doko: here will be my changes for -17 http://paste.dunnewind.net/373 (I'll also include them in 4.2 in 4.3 once I would have finish to test it)
<doko> arthur-: please send diffs by email
<arthur-> doko: just done about 1 sec ago :-)
<arthur-> doko: give --disable-proc-maps to libphobos configure should build fix at least on kfreebsd-{i386,amd64} , but how to give it explicitly to libphobos configure? il Makefile.def ?
<doko> it should be propageted from the toplevel configure
#ubuntu-toolchain 2011-09-01
<desrt> word.
<desrt> i found the oddest bug in what i believe to be the libc: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975
<desrt> i've done a lot of digging/investigating so far but i'd appreciate help from someone more familiar with these things
<desrt> since i'm sort of at a dead-end
 * desrt steps out for a moment
