#ubuntu-toolchain 2005-10-31
<doko> infinity: when will the new gcc-defaults available on the buildd's?
<infinity> When it's installible?
<infinity> (hint: depending on compilers newer than what we have isn't helpful)
<doko> infinity: hint: we don't have any mechanism to avoid that
<infinity> Sure we do.  Make it build-dep on all the same packages/versions that it will eventually depend on. :)
<infinity> Then it'll be FTBFS until they're available.
<infinity> (Yes, it's ugly, but it would work)
<infinity> Anyhow, the alternate solution is for you to merge gcc-4.0_4.0.2-3. :)
<doko> I'm not supposed to merge things, if no merge is needed :-P
<doko> infinity: ^^^
<infinity> Well, then you better upload a new gcc-defaults_1.29ubuntu1 that drops that compiler dependencies again for now.
<infinity> s/that/the/
<doko> well, then I do prefer a gcc-4.0_4.0.2-3build1
<elmo> err, what?
<elmo> for fuck's sake, will you guys chill out
<elmo> the sync stuff is running full time, catching up with the backlog, and I'm running around trying to get ready to fly tomorrow
<elmo> the world's not going to end if we don't sync a new gcc in the next 24 hours
<doko> elmo: no it doesn't end, just that the new gcc-defaults is already built, and gcc depending on gcc-4.0 (>= 4.0.2)
<elmo> so nothing's building?
<doko> that was the question: what happens, if the buildd's are updated to the new gcc and g++. currently nothing should build which uses gij/gcj/gfortran/gobjc
<infinity> The buildds can't be updated, since gcc is uninstallable. :)
<infinity> elmo : Anyhow, this has nothing to do with syncs, unless gcc-4.0 is meant to be synced (looks to me like it shold be merged..)
<infinity> Oh, unless doko requested a sync-with-overwrite.
* infinity shrugs.
<infinity> Whatever's going on, you'll get your new GCC when you get it.
<lamont-away>   g77: Depends: cpp (>= 4:4.0.2-1) but 4:4.0.1-3 is to be installed
* lamont-away grumbles
<lamont> Oct 26 07:57:11 buildd: Starting build (dist=dapper) of:
<lamont> Oct 26 07:57:11 buildd: gcc-3.3_1:3.3.6-10 gcc-3.4_3.4.4-9 gcc-4.0_4.0.2-3 dash_0.5.2-8 nessus-core_2.2.5-2
* lamont crys
<lamont> cries, even
<lamont> gcc-3.3:                04:24:26 (1 entry, sigma 00:00:00)
<lamont> gcc-3.4:                11:34:22 (2 entries, sigma 00:44:39)
<lamont> gcc-4.0:                06:49:38 (2 entries, sigma 00:49:37)
<lamont> not much in the way of hppa uploads for the next 20 hours or so
* lamont disables ccache for builds of gcc-{3.3,3.4,4.0,snapshot} just because it's not gonna do anything anyway
<doko> why does gcc-3.4 takes so long?
<doko> lamont: and disable it for gcc-4.1 and gcc-snapshot as well ...
<lamont> 3.4 is just lucky or something... could be the expect bug
<lamont> s/expect/"expect"/.
<lamont> doko: that's true on all architectures, yes?
* lamont needs an hppa/mips patch to ld -r so that it doesn't merge sections (or emits long branch stubs if it merges)
<lamont> well, ok... I don't need or care about mips, but it has the same issue. :-)
<lamont> doko: remind me to hurt you if your next gcc-3.3 upload still uses expect instead of expect-tcl8.3 on hppa, k? :-)
<doko> lamont: well, it should be on all archs
<lamont> ok - I'll change the default gcc-opt config then
<doko> lamont: I think I did fix it ...
<lamont> expect (>= 5.38.0) [!hurd-i386] , 
<lamont> gcc-3.3_1\:3.3.6-10
<doko> ahh, no. will do it. the debian expect maintainer seems to be mia
<lamont> well, it's not properly an expect bug... iz kernel bug (I think)
<lamont> but the name sticks
<lamont> doko: I think 3.4's long time may be related to logwatch not exiting
<lamont> or maybe that's the "expect bug" again.
<lamont> hi elmo
#ubuntu-toolchain 2005-11-01
<infinity> lamont : logwatch not exiting "Just Happens" sometimes, and I really have no idea.  I've seen it on m68k, and I've seen it on the DC buildds a few times.
<infinity> lamont : As for the expect bug, while it may be a kernel issue on hppa that makes things worse, expect and tcl8.4 don't play well in general, so doko's right, all arches should just be using expect-tcl8.3
#ubuntu-toolchain 2005-11-02
<lamont> doko: gcc-3.4's long build times are because sometimes I don't notice logwatch.sh :-(
<infinity> Okay, watching GCC testsuite output with -j2 is rather... confusing.
<fabbione> infinity: ehhe
<lamont> hehe
<fabbione> lamont, infinity: if you speak french: http://66.103.220.197/sourde.mpg
#ubuntu-toolchain 2006-10-30
<fabbione> doko: i get the same error on gcc/pcc with  WITHOUT_LANG=biarch debuild -uc -us -b
<doko> fabbione: don't have a G4 to check ...
<fabbione> doko: ok.
<fabbione> doko: i am about to start the rebootstrap on sparc. do you want to receive the build logs or not?
<doko> fabbione: just the failed ones please
<fabbione> doko: i can't filter from here
<fabbione> i will need to forward it manually
<doko> fabbione: we should get these filter scripts from lucas (the guy who did make the cluster build)
<fabbione> doko: sbuild doesn't filter.. it just sends
<infinity> It's trivial to filter is with procmail.
<infinity> Given the uniform subject lines.
<Keybuk> do we have a toolchain for feisty yet?
<fabbione> no
<fabbione> it should be by the end of the week
<infinity> We have several, and some of them almost work, we don't have one in the archive yet.
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: glibc: ppc busted if kernel != .19 and headers != .19 | gcc: sparc busted (under testing) | hppa: bootstrapping needed (test in progress)
<jbailey> doko: g'day!
<doko> jbailey: good morning!
<jbailey> doko: I put the binutils stuff in bzr based on the current packaging.  One patch merged upstream (i386/amd64 biarch).
<jbailey> Build of glibc shows no regressions.
<jbailey> (ppc)
<jbailey> and ppc64.
<jbailey> I have the .orig.tar.gz in my homedir on chinstrap if you're interested.
<jbailey> glibc correctly detects the hashing stuff and enables it.
<doko> jbailey: ok, will have a look
<fabbione> jbailey: hashing is detected fine on sparc too
<jbailey> fabbione: Luvly.
<jbailey> I have a feeling i'mgoing to need to dust off my G4 for some build tests.
<jbailey> the ppc64 glibc has no significant errors.
<jbailey> the ppc32 one does.  I suspect it's all compat bugs, though.
<jbailey> I still want to look over the i486 one.
<jbailey> i686 and amd64 looked fine.
<jbailey> I'd be surprised if ia64 were anything other than fine, but I should build that too.
<jbailey> fabbione: I haven't committed my patch stuff yet.
<jbailey> I'll try to get it done by end of today, I think I was too aggressive in my pruning and want to review it again.
<fabbione> jbailey: what patch? glibc or binutils?
<jbailey> glibc.
<jbailey> binutils is probably final subject to a review from doko.
<fabbione> jbailey: this binutils can build hppa right?
<jbailey> fabbione: Right.  glibc itself is missing a patch, but the binutils is fine.
<fabbione> jbailey: ok. i am going trough a bootstrap sequence.. i will stop before glibc and wait for you
<jbailey> fabbione: on hppa?
<fabbione> yes
<jbailey> I nudged adam a bit about the hppa kernel last night.  Dunno if he found time for it or not.
<fabbione> i am building a kernel from git now. just to get the headers and get to binutils -> glibc -> gcc
<fabbione> i am pretty sure the kernel does build
<fabbione> but it might not run.. tough
<jbailey> <fabbione> jbailey: binutils looks ok on sparc.. builded glibc on top and gcc on top of glibc... no errors up till now
<jbailey> <fabbione> it would have fallen apart a while ago
<jbailey>  anyway i am off for a bit
<jbailey> <jbailey> up until now, like you just got an error, or like no errors so far? =)
<jbailey> <fabbione> time to enjoy wife :)
<jbailey> doko: ^^ 
<jbailey> We were in -kernel, instead of -toolchain, sorry.
<fabbione> he is in kernel too
* fabbione bounces
<jbailey> *lol*
<fabbione> ok i am off now
<fabbione> jbailey: libc6-dev in dapper Depends: linux-kernel-headers
<fabbione> and linux-libc-dev doesn't provide it afaict
<fabbione> so once we build hppa kernel, we can't build glibc
<fabbione> i guess we will need to force that one in
<fabbione> actually no
<fabbione> binutils doesn't need new linux-libc-dev to build
<fabbione> but glibc does..
<fabbione> just postponing the issue..
<doko> fabbione: did see it, nice.
<fabbione> doko: gcc build seems to going fine now on sparc
<fabbione> even on Niagara
<fabbione> doko: once gcc is done i will rebuild glibc and open the gates for testing
<fabbione> NOTE that i will not be using the rebuilt debs
<fabbione> we are only going to test pkg foo built on edgy+feisty toolchain
<fabbione> and not feisty rebuilt on feisty
<fabbione> that will happen automatically while we import stuff
<fabbione> jbailey: i need the glibc patch for hppa somewhere.. even offbandwith so i can test build and test
<doko> fabbione, jbailey: for long double 64->128 change: we'll need to rebuild all packages (at least on powerpc and sparc) which uses long double to be safe; it's not that easy to detect thoese packages easily
<fabbione> doko: well i will try to rebuild all of main BEFORE we open the gate
<doko> not sure, if we want to open the gates for libraries and binary-indep stuff first, then for other packages
<fabbione> do you expect just plain FTBFS or runtime errors?
<fabbione> we can't really filter manually.. it would be hell of a work to let one package at a time in
<doko> fabbione: runtime: libc and libstdc++ dohave support for both 64 and 128 bit long double, but other libraries don't have it.
<fabbione> oh christ
<fabbione> doko: we do have a local mirror on people.. what about a nice apt-get source $allofmain and a lot of grep magic?
<fabbione> that would help me to prioritize pkgs that use that 128bit thingy
<fabbione> and test them
<doko> fabbione: you would have to unpack tarballs inside packages, scan for typedefs and defines, and probably still miss some
<fabbione> doko: well that's doable.. 
<fabbione> missing some can happen
<fabbione> but we can still catch a few for testing-?=
<doko> yes, probably
<fabbione> doko: well want to start a script now so i can actually get to test by tomorrow or something?
<doko> yes, probably write one tonight. but you can start testing as well
<jbailey> doko: I think in general it would be nice to go through and look at any package that hasn't changed ina release and rebuilt it for good measure anyway.
<fabbione> doko: i can't start testing without rebuilding first
<fabbione> jbailey: statically i haven't see ONE release in which all packages in main have been the same
<fabbione> only one _all.deb in one release IIRC
<jbailey> doko: awake?
#ubuntu-toolchain 2006-10-31
<fabbione> morning guys
<fabbione> buildd@sunfire:~/build$ sbuild -d feisty --comp=main gcc-4.1_4.1.1-18ubuntu1
<fabbione> *** glibc detected *** ./pthread5.exe: corrupted double-linked list: 0x71700490 ***
<fabbione> doko ^^^otherwise it builds fine
<doko> fabbione: you did not run the testsuite in parallel, did you?
<fabbione> doko: i just builded the package as you did it.. 
<fabbione> dpkg-build...
<fabbione> so if it's set to run in parallel then yes
<fabbione> ld.so.1 (pid 7864): Privileged operation (code 10) at 401bc127   
<fabbione> ld.so.1 (pid 9413): Protection id trap (code 7) at 400016a3                     
<fabbione> ld.so.1(9618): unaligned access to 0x00010ae6 at ip=0x4010ce0b                  
<fabbione> ld.so.1(10034): unaligned access to 0x00013736 at ip=0x4010b6ff                 
<fabbione> ld.so.1(10718): unaligned access to 0x00010b06 at ip=0x4010ce0b                 
<fabbione> MEH
<fabbione> this can't be good
<doko> which package?
<fabbione> glibc-2.5 (hppa)
<fabbione> anyway.. let's talk about sparc and 128 bits
<fabbione> i just finished the second build of glibc-2.5 with newer gcc
<fabbione> ls still works :)
<fabbione> i am going to open the gates once i have the chroots ready
<fabbione> gates are open
<fabbione> libc6_2.5-0ubuntu1_hppa.deb
<fabbione> whooopa
<fabbione> ok we are getting tons of non fatal unalligned access with 2.5
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: gcc: sparc (under testing) | hppa: bootstrapping needed (test in progress)
<fabbione> we have the fix for ppc kernel
<cjwatson> argh, Ben's udeb changes are crack
<fabbione> cjwatson: i told him.. he was going to talk to you at UDS
<cjwatson> I've mailed him
<cjwatson> I don't care about the storage stuff, but the filesystem changes will break things
<cjwatson> newed, anyway
<fabbione> nah pointless again :)
<fabbione> it's still broken on ppc and sparc
<fabbione> it seems that the changes got lost somehow
<cjwatson> perhaps pointless, but harmless. :)
<cjwatson> and I don't like excess stuff stuck in new
<jbailey> doko: Around?
<doko> jbailey, fabbione, cjwatson, lamont: ping
<doko> jbailey: yes :)
<fabbione> doko: pongish
<jbailey> =)
<fabbione> i need 2 minutes break.. absolutely.. brb
<cjwatson> doko: yes?
<doko> about the ABI change on powerpc and sparc: long double changing from 64bit to 128bit
<doko> glibc and libstdc++ are the only libs having both support for 64 and 128 long doubles
<doko> how should we handle other libraries using long double datatypes in their interfaces?
<doko> - rename the library packages
<fabbione> re
<doko> - do nothing (minor ABI breakagae on some archs), and rebuild the archive
<fabbione> doko: do you have a list of packages affected?
<doko> http://people.ubuntu.com/~doko/ldbl/  (these are all packages with a long[ _] *double string in their header files
<fabbione> eh
<cjwatson> I don't see that in http://gcc.gnu.org/gcc-4.2/changes.html
<cjwatson> is this an undocumented ABI change or something?
<cjwatson> oww, that's a lot of packages in main
<fabbione> hold on.. those are headers.. what about stuff that B-D on those headers?
<doko> fabbione: right, that's the next step ...
<jbailey> doko: I'm confused.  The ldbl change is supposed to be ABI-neutral, no rebuild needed.
<jbailey> doko: I thought we'd shown that the old symbols got provided?
<doko> cjwatson: 4.2 is not yet released; these are backports from the fc 4.1 branch
<cjwatson> if it's supposed to be ABI-neutral, and isn't, then that seems like a bug, and can we unbackport those changes? :P
<doko> jbailey: yes for libc and libstdc++; but what about rebuilding a library libfoo and packages depinding on that library?
<doko> depending even
<jbailey> cjwatson: It's usually better to suck it up and follow upstream to be safe.
<fabbione> this is going to be another clusterfuck.. i feel  it
<jbailey> doko: Yeah, dunno.  I haven't followed all the header magic in that.  I don't know if there was some sort of compat macros or whatever that twiddled it transparently.
<cjwatson> jbailey: if renaming lots of libraries is involved, I'd rather have some time to consider that rather than being forced to do it immediately
<cjwatson> jbailey: especially if it might be a bug that gets fixed so we have to unrename everything later!
<doko> jbailey: what does header magic solve for libraries which don't support both?
<fabbione> cjwatson: it really depends on how soon you want to open feisty
<fabbione> if there is really an ABI breakage we better deal with it before
<fabbione> rather than later and collecting pieces with tons of uploads
<cjwatson> isn't this a specs file thing?
<cjwatson> -mlong-double-128
<cjwatson> fabbione: I would like to have it open before UDS
<fabbione> cjwatson: toolchain is not ready yet.. it's likely we can make it for UDS, but for example ppc is now stalling on elmo to install a new kernel on buildd and he is not around today.
<jbailey> doko: Magic headers in the type definition, is what I'm thinking.
<doko> see http://gcc.gnu.org/PR25864 for the detauls
<doko> can't type anymore
<fabbione> doko: could you before ? ;)
<cjwatson> how practical is it likely to be to provide _Q_ functions in other affected libraries?
<cjwatson> I'm not happy with a flag-day renaming of a bunch of libraries in main and all the upgrade pain that entails for the sake of two architectures, really
<cjwatson> _Q_> or whatever the compatibility symbols are called
<fabbione> cjwatson: what scares me is that we might trip in runtime errors during upgrades if we change ABI without renaming packages
<fabbione> or een using upgrader itself that's written in python and python is one of those affected pkgs
<cjwatson> if it's possible to provide compatibility symbols for both ABIs, that would solve that problem
<doko> fabbione: there are not many extensions actually using long double
<fabbione> cjwatson: right.. assuming we can
<cjwatson> if it's doable in libc ...
<fabbione> doko: can you write me a test case that will trip in that problem?
<doko> cjwatson: what would that solve? having a "long double foo (long double)" function in libfoo, we would need to have these symbols in libfoo
<cjwatson> EPARSE
<fabbione> and i guess massive patching is not an option for the sake of 2 arches
<cjwatson> library renaming that Debian isn't going to do for ages yet (given the etch freeze) counts as "massive patching"
<cjwatson> I'd actually be happier with a bunch of library patches ...
<fabbione> cjwatson: hmmm massive code patching is more dangerous IMHO
<fabbione> hi mdz
<mdz> morning
* ..[topic/#ubuntu-toolchain:fabbione] : STATUS: gcc: sparc (under testing) | hppa: bootstrapping needed (test in progress) | ppc needs fixed kernel on buildd (elmo informed)
<cjwatson> doko: glibc clearly has code that uses the old-style long double type somehow
<doko> cjwatson: "some arches" = sparc, sparc64, powerpc, powerpc64, s390, s390x, alpha
<jbailey> cjwatson: glibc handles it by not actually using the real function names.
<cjwatson> doko: i.e. powerpc and sparc from our point of view
<jbailey> cjwatson: When you call open, it gets mapped to _open@GLIBC_2.4
<fabbione> doko: for us is still sparc and ppc only
<doko> cjwatson: no, it provides functions handling both the old and new data types
<cjwatson> doko: yes, that's what I said
<jbailey> cjwatson: They change symbol version for the new ABI.
<cjwatson> jbailey: right, I know that, but the new glibc still builds the old _open@GLIBC_2.4 code with the current gcc
<jbailey> Right.  I'm guessing that they still have a compat type sitting around that they use.  I don't know off hand.
<cjwatson> yep, and if that compatibility type can be / is exported, it would not be that hard to make other libraries support both old and new ABIs
<fabbione> ok.. is there any way i can have a test case?
<fabbione> doko: ^^
<fabbione> i have almost done rebuild edgy on top of feisty toolchain on sparc
<fabbione> and i can test
<fabbione> but i want test cases
<fabbione> that should tell us if we need to do something fancy or not
<cjwatson> also assuming that it's possible to call the GLIBC_2.4 code directly
<cjwatson> (or do exceedingly cunning linker tricks to make that happen automatically for some objects)
<fabbione> ROFL
<cjwatson> fabbione: one of my concerns is that we have no established mechanism for ABI changes in perl and python
<infinity> Speaking of ABI changes...
<cjwatson> fabbione: I don't particularly want to establish one in a hurry (or at all, if we can get away with it)
<fabbione> cjwatson: that's why i need a test case :)
<fabbione> cjwatson:  i can test with old and new stuff
<infinity> jbailey: Is glibc/hppa still going to give us a broken ABI, and should I whip up a clever script to find every package that's not changed since dapper, so I can make sure they get rebuilt? :)
<fabbione> infinity: hppa will be rebuilt in full.. no matter :)
<fabbione> infinity: we lost an entire release
<infinity> fabbione: Yes, hence the "find things that haven't changed since dapper".
<infinity> fabbione: We still ship packages that haven't changed since warty, you know.
<fabbione> i don't think there is something left :)
<fabbione> infinity: probably because nobody uses them ...
<infinity> Some just don't need updates. :)
<fabbione> exactly :)
<cjwatson> $ ./suite-diff.py ubuntu/dists/warty/main/binary-i386/Packages.gz ubuntu/dists/edgy/main/binary-i386/Packages.gz eq | wc -l
<cjwatson> 28
<infinity> I maintain one that hasn't changed since dapper. *shrug*
<cjwatson> $ ./suite-diff.py ubuntu/dists/warty/universe/binary-i386/Packages.gz ubuntu/dists/edgy/universe/binary-i386/Packages.gz eq | wc -l
<cjwatson> 806
<infinity> cjwatson: I see I'm not the first person to want this statistic. :)
<infinity> Anyohw, 28/806 is very workable.  Cool.
<jbailey> infinity: Totally changed thread ABI.
<cjwatson> I use suite-diff more for ge, gt, le, lt comparisons, but eq is occasionally handy and was trivial to implement
<infinity> And main's all I care about initially anyway.
<cjwatson> infinity: one sec and I'll give you dapper->edgy figures
<infinity> jbailey: Right, so after bootstrapping the toolchain, I'll want to rebuild everything in {Build-,}Essential, and then move up the chain.  Fun.
<infinity> cjwatson: Oh, that was warty.  I wasn't paying attention.
<jbailey> infinity: It's an interesting experiment to see how ugly a bootstrap is these days.
<cjwatson> infinity: counting by source package:
<cjwatson> main: 478
<cjwatson> restricted: 1
<cjwatson> universe: 3885
<cjwatson> multiverse: 258
<infinity> jbailey: Shouldn't be too bad, and for all that I complain about them, the hppa buildds are still pretty quick.
<cjwatson> feel free to go "dear god" now
<infinity> cjwatson: Those figures sound more correct anyway. :)
<infinity> edgy's short cycle didn't help there.
<infinity> We might get those numbers down just with the initial round of merge/sync madness.
<infinity> But, whatever.  Worst case, I just do a mess of rebuild uploads.  Serves a dual purpose of fixing hppa, and getting the rest of the arches built against a modern toolchain.
<infinity> hppa's simple, just time-consuming.
<infinity> This long double thing sounds far more icky.
<fabbione> infinity: hppa is a pain at the moment.. second round of glibc build will fail but we have our super-Jeff on it
<infinity> Oh, it's not self-hosting yet?  Fun.
<fabbione> infinity: and you really want to take the debs i did build to get to gcc B-D
<fabbione> infinity: yes.. it's a header issue that shows up only at the second rebuild
<infinity> fabbione: Yeah, I'll use your bootstrap stuff, thanks.  It'll be several rebuilds before I get to the final archive debs anyway, so I don't mind the taint.
<fabbione> infinity: i know, they are just useful.. it's building gcc for feisty now.. that will come handy too
* infinity hopes no one quotes him out of context as saying "I don't mind the taint".
<fabbione> doko: ok.. so what is your suggestion on how to handle this ABI breakage+
<fabbione> ?
<infinity> I suspect I won't fully open hppa until I get back from UDS and have my 6750 powered on anyway.
<infinity> But the primary arches should, ideally, be opened in the next two or three days, if we can at all manage.
<fabbione> infinity: or we can play with it together.. i have console on mine
<fabbione> and your has also remote power capabilities.. that's even better
<fabbione> ok should we do a summary before my wife will kill me?
<infinity> fabbione: Well, I'll have a console on mine as soon as I've visited a Frys in SF and bought a USB->Serial dongle. :)
<fabbione> (i was supposed to be out of the office 2 hours ago)
<fabbione> i think i386/amd64 are fine.. at least so it seems
<infinity> fabbione: And yeah, the DC ones have remote power that I can mangle from anywhere, which is rather handy in light of the hppa kernel's... Oddities.
<fabbione> infinity: i am not running .19 kernel.. only dapper kernels
<fabbione> ppc needs a new kernel. the patch is in pitti/elmo hands
<doko> fabbione: last time we had an arch specific ABI change on sparc in unstable, we didn't do anything
<fabbione> sparc/ppc have the ABI issue
<fabbione> ia64 looks good
<fabbione> hppa whatever...
<cjwatson> doko: powerpc is first-class and released; IIRC last time sparc wasn't
<fabbione> sparc is released now and first-class on enterprise servers
<infinity> doko: Is this the sort of ABI breakage that will royally mess up upgrades (ie: postinst scripts dying and the like)?  If so, "just ignoring it" isn't going to cut it.
* fabbione hides a bit
<cjwatson> if it stands a decent chance of not breaking during upgrades (and that sounds plausible; do upgrades really require serious floating-point code?), then ignoring it is an option I'd certainly consider
<infinity> Yeah, that's the point I was driving at.
<infinity> Unlike Debian, we don't really pretend to support partial upgrades.
<fabbione> cjwatson: i can test scenario too
<cjwatson> thought I'd emphasise it the other way round. :-)
<infinity> So, I'm cool with "once your upgrade has settled, you'll be okay"... If the upgrade can go smoothly.
<fabbione> but i need a couple of more days to get there
<fabbione> otherwise somebody needs to ship me another T2000 and i could run 64 buildd
<cjwatson> infinity: and if we can figure out how to do compatibility code for this, we could do that just for libraries that break during upgrade, if any
<infinity> fabbione: You have enough toys.. Share with the class. :P
<fabbione> infinity: ehhe
<infinity> cjwatson: Fair point.
<fabbione> cjwatson: that's even scarier.. 
<fabbione> but well whatever
<fabbione> infinity: can you get Ben to upload a working kernel today?
<doko> right, that was my thinking. there shouldn't be too much code (if any) which needs floating point arithmetics in installation/removal
<cjwatson> fabbione: surely it's less scary
<infinity> fabbione: I tried that yesterday. :)
<cjwatson> given that it involves less work and less code
<infinity> (But yes, I'll try again)
<fabbione> infinity: try harder? ;)
<fabbione> jbailey: is binutils ok for you to upload or does it need more?
<fabbione> doko: did you review binutils?
<doko> fabbione: yes, looks fine to me
<doko> jbailey: ^^^
<fabbione> i know we lack a patch for hppa that miscompile the kernel, but we CAN live with an unbootable hppa kerenl for bootstrapping
<jbailey> fabbione: I'm happy with it from ppc/ppc64/hppa tests.  I haven't looked at i386/amd64.  Given that it's HJ, I suspect those and ia64 are pretty guaranteed.
<jbailey> fabbione: Yes, that's fine.
<fabbione> jbailey: ok.
<infinity> Unbottable hppa kernels don't matter to me right now.
<fabbione> infinity: neither for me
<fabbione> jbailey: what about glibc debian/patches?
<infinity> If you guys are happy with binutils, toss it in the queue SVP.
<fabbione> should we go with what we have and review later?
<jbailey> fabbione: I want to commit what I've got in there.  The Debian patches cause one of the tests to segfault.
<fabbione> jbailey: ok.
<jbailey> (yay debian)
<fabbione> jbailey, doko: i am going to upload binutils then.
<fabbione> i did check the testsuite with .17 and .19 hreaders
<fabbione> there is no difference
<fabbione> so it doesn't matter to wait for the new kernel
<jbailey> Cool.  I'm happy to see binutils go in.
<jbailey> fabbione: You're putting in the same one that I put into bzr?
<infinity> And binutils passes its testsuite with no regressions regardless of whether it's built against edgy or feisty?
<fabbione> jbailey: yes and the same orig
<infinity> (ie: Can I build it now, now, now?)
<fabbione> infinity: yes it can build now now
<infinity> \o/
<jbailey> fabbione: Do you know any timeframe for the kernel patch going in for ppc?
<infinity> jbailey: Being applied on the buildds, you mean?
<fabbione> jbailey: i guess tomorrow... elmo is not around today
<fabbione> infinity: yes
<jbailey> fabbione: I have Angie's ultrasound midday today, but I'd like to beat on this when I'm back to get that patches directory in shape.
<infinity> I can get Znarl to do it.
<jbailey> Lovely, so there's no pressure for today for glibc going in.
<infinity> Oh, unless you want the breathing room.
<infinity> Then I'll, uhm, not get Znarl to do it.
<fabbione> infinity: i have the patch and i can send it to Znarl, but we still need to jump to edgy .17
<fabbione> infinity:  i didn't test the patch on dapper yet
<infinity> Should apply to .15 without terrible issues, I'd suspect.
<infinity> On the other hand, we wanted the PPC buildds upgraded to edgy kernel source for other reasons.
<fabbione> yes it might apply but it's not tested and you don't want to DoS the buildd.. do you?
<infinity> Some sketchy build failures that were kernel-releated.
<infinity> related, too.
<fabbione> infinity: well elmo will have to speed that up a lot
<infinity> I've got a laundry list of things to talk to elmo about, so I'll make sure this gets done.
<infinity> (Still have some sketchiness on jackass to deal with, which takes priority, but only barely)
<fabbione> infinity: he has the patch in an email
<infinity> I know, you CC'd me, remember? :)
<fabbione> infinity: i did? ok
<infinity> Oh, looks like the buildds went to edgy kernels when I wasn't looking anyway.
<fabbione> no i didn't
<infinity> That makes life easier.
<fabbione> binutils on the way
<fabbione> jbailey: does bzr support tagging?
<fabbione> no it doesn't
<jbailey> fabbione: I remember there was a spec for it, dunno where that got to.
<fabbione> jbailey: ok...
<infinity> fabbione: "local DoS fix for ppc", sent to elmo, CCd to pitti and I.
<jbailey> j-a-meinal will be on in an hour or so usually, we can ask him.
<fabbione> infinity: BenC is around!
<infinity> fabbione: Your memory's failing in your old age. :)
<jbailey> infinity: Why not the RT queue so that one of the other sysadmins can deal with it?
<fabbione> infinity: screw you old boy! :P
<fabbione> jbailey: because they don't do kernel stuff.. i did ask on -sysadmin
<infinity> Znarl does kernels occasionally.
<fabbione> infinity: up to you.. without that kernel ppc boxes will die like KITTIES if we upload glibc :)
<fabbione> infinity: binutils uploaded
<infinity> Does it cause the build to fail, or just cause the machine to Zombie half to death?
<infinity> Cause I *do* have remote power on them. :)
<fabbione> machine will die
<infinity> Right, not pleasant.  Will wait.
<fabbione> and the build won't finish
<fabbione> it's pointless
<jbailey> infinity: reboot -f works, too. =)
<jbailey> fabbione: I never reproduced machine death.
<fabbione> jbailey: i did
<jbailey> Just the Hallowe'en drama of things running around yelling "GRAAAAIIIIINNNNSSSS...."
<fabbione> This upload awaits approval by a distro manager
<fabbione> infinity: ^
<infinity> fabbione: Yes dear. :)
<fabbione> slacker! do you want to accept the upload?
<fabbione> i got this email more than 60 secs ago! :P
<infinity> I'm on it, I'm on it.
<infinity> Punk.
<fabbione> you are getting slow.. must be the age
<fabbione> MUHHAHAHA
<infinity> No, it's the latency.
* fabbione claims revenge
<fabbione> yeah between fingers and eyes
<jbailey> fabbione: Bah..  When *I* was young...
<infinity> Takes 12 minutes to do an SSH handshake between .au and the DC.
<jbailey> infinity: Throw *out* the m68k, dude. =)
<fabbione> jbailey: speaking of which.. congratulation.. your bday was yesterday?
<jbailey> fabbione: Yeah, thanks.
<infinity> jbailey: *grin*
<fabbione> there.. i guess we are all set.. more or less
<infinity> Getting there.
<fabbione> infinity: yeah...
<fabbione> jbailey: ok.. i will be back later this evening...
<fabbione> jbailey: so we can look again at glibc
<fabbione> doko: are you ready to upload gcc?
<jbailey> fabbione: 'kay.  I'll try to run the glibc stuff today over the day, but will focus on it tongiht.
<jbailey> I'll also get some more hppa love going.
<jbailey> I've just sent a final "we're doing this, any questions?" email to the parisc list.
<fabbione> jbailey: ok. your tonight is my deep night... should i shift working hours?
<jbailey> Nope, there's not much to share except scrolling consoles.
<fabbione> i don't mind it at all.. i just need to know so that we can work closer
<fabbione> ok
<fabbione> we can still share the orgasms on each line text
<jbailey> fabbione: More useful to have you work when I'm asleep for a final test with goal of upload tomorrow.
<fabbione> jbailey: ok perfect works for me
<fabbione> by tomorrow i should have enough sparc debs to do some kind of tests
<fabbione> ok dok
<fabbione> oky doky
<fabbione> i am off
<infinity> fabbione: Did you forward that ppc fix to BenC too, for inclusion in edgy-updates?
<fabbione> infinity: i think i did?
<fabbione> infinity: wasn't he in the email?
<infinity> Not in the same email you sent me.
<jbailey> fabbione: I'd imagine benh will submit it for the . release, won't he?
<fabbione> infinity: ok. i will talk to him once benh gives me the greenlight for stable release
<fabbione> jbailey: yes i am sure he will
<infinity> Kay.
<fabbione> infinity: there are 2 solutions to that problem.. really
<fabbione> one is the patch
<fabbione> and one is to disable a couple of syscalls in the kernel
<doko> fabbione: davis:~doko/gcc/4.1/tst/
<fabbione> doko: what's that?
<fabbione> doko: ok thanks.
<fabbione> later guys
* fabbione takes off
<fabbione> infinity: and yes.. even pigs can fly given enough thrust
<infinity> It's not nice to talk about my mother that way.
<jbailey> And with the image of FAbio thrusting a pig...  Off to the office I go.
<fabbione> infinity: i miss the association with your mother... if it's there for some reasons it was REALLY not meant
<fabbione> doko: i did build that test case on edgy and it segfaults
<fabbione> doko: should i try on feisty and it should work.. right?
<fabbione> or the other way around?
<fabbione> doko: it segfaults also when built with feisty toolchain
<jbailey> doko: There are libgcc-compat patches in here to expose some extra symbols.  I wonder if they actually matter to anyone.
<jbailey> They're old versions, so nothing new will build with them.
<doko> jbailey: disconnected, maybe I did miss something?
<jbailey> doko: No, sorry.  I started mid-thought.
<jbailey> I'm reviewing all of the glibc patches again.
<jbailey> glibc for awhile leaked some libgcc symbols directly.
<jbailey> When Jakub fixed up glibc to not leak stray things, he removed these, but we brought them back.
<jbailey> Sadly, there's no explanation *why* we did this, and I was wondering if we should maybe not do so.
<jbailey> Not important for right now, but probably something to look at for feisty+1
<jbailey> But it might be nice to start stripping out some of these patches.
<doko> ok
<doko> jbailey: I'm not opposed to a feisty+1 toolchain roadmap, but I think we can do better than the edgy+1 roadmap; we should discuss this next week.
<jbailey> I don't think we booked a bof for it. =)
#ubuntu-toolchain 2006-11-01
<jbailey> fabbione: Awake yet?
<fabbione> jbailey: now
<fabbione> WHOP WHOP
<fabbione> new gcc built on hppa
<jbailey> fabbione: Cool.  Is that using the new glibc?
<fabbione> yeps
<jbailey> Nice.
<jbailey> chroot test on ppc works for libc6.
<jbailey> Doing system test and reboot.
<fabbione> ok
<jbailey> Ah, found a missing patch in libc.postinst.
<fabbione> which one?
<jbailey> Do you wish to restart services? [Y/n]  
<jbailey> The one that eliminates that prompt.
<jbailey> Fixing.
<fabbione> hmmm i thought i did pull it in.. 
<fabbione> ok
<fabbione> cool
<fabbione> those headers changes for IFA_ADDRESS will give us headacke
<fabbione> with this rebuild i got about 30 FTBFS compared to edgy
* fabbione uploads gcc hppa to chinstrap
<jbailey> Hmm.
<jbailey> I thought it had been in there, but I don't see it...
<jbailey> Like, not in edgy, not in dapper.
<jbailey> Well.  I'm still not convinced of that change anyway, so leave it for now, solve it later.
<jbailey> Reboot test.
<jbailey> Weird.  This *feels* faster.
<fabbione> ahhaa
<fabbione> * jbailey has quit ("ping timeout - glibc deteted ** double linked free **")
<jbailey> Eh, you're kidding? =)
<fabbione> of course :)
<jbailey> Bah ;)
<fabbione> it feels faster.... ping timeout.. too fast for internet
<fabbione> lamont, jbailey, infinity: new hppa gcc is on chinstrap
<fabbione> (usual place)
<jbailey> fabbione: Need anything else from me before I go pass out?
<fabbione> did you commit what you have done?
<jbailey> Yup.
<fabbione> let me check one second
<jbailey> 'k, I still need to brush my teeth anyway
<jbailey> Oh which arch was it that you can't build twice?
<fabbione> how can i check just check the commit diff you did?
<fabbione> hppa
<fabbione> i am trying now with new gcc for the sake of it
<fabbione> but the error wasn't gcc related
<fabbione> ok i am good with this
<jbailey> bzr diff -r#..#
<jbailey> 'kay.  I'll look at the hppa problem tomorrow.
<jbailey> I went throught the ppc testsuite failures tonight.  isomac is just a bad test with ldbl-128.  tst-cancel24 is fixed.
<jbailey> That solves ppc64.  The ppc32 stuff, there's something weird with how it calls the shell for one test, I don't understand.
<jbailey> The remaining thread tests I *think* are just from me using a ppc64 kernel.
<jbailey> The other stuff I did solved the segfault and the locale related tests.
<fabbione> ok...
<fabbione> the hppa thingy should be simple for you
<jbailey> Yeah, I suspect so.
<jbailey> Is that the only thing blocking us openning now?
<fabbione> yes it still fails with new gcc
<fabbione> no it's not a blocker
<fabbione> we will need to upload glibc_2.5-0ubuntu2 once gcc is built
<fabbione> that will take another 24 hours round
<fabbione> and the bootstrap for hppa will take longer than that
<jbailey> 'k.  So what's our blockers?  ppc kernel.  What else?
<fabbione> sparc and ppc abi change..
<fabbione> doko gave me a test case but i am not convinced yet
<fabbione> i just need to talk to him
<fabbione> otherwise i would say we only need binutils to hit the archive
<fabbione> and we can upload
<fabbione> and you can go to sleep for today :)
<jbailey> http://sources.redhat.com/ml/libc-alpha/2004-03/msg00241.html
<jbailey> is light reading for you for the nighttime.
<jbailey> There'll be a test in the morning. =)
<fabbione> reading...
<jbailey> fabbione: Passing out in the meantime.  g'n!
<fabbione> jbailey: night dude
<fabbione> wanna-build -d feisty --list=needs-build
<fabbione> Total 0 package(s)
<fabbione> ok.. only a little bit left to complete sparc rebuild
<infinity> Guys, I'm going to do glibc first thing when I wake up so I can babysit it and make sure it goes smoothly.
<infinity> If someone has a new gcc and gcc-defaults for me, I'd love to see those in the queue as well.
<jbailey> infinity: How far away about is that?
<infinity> jbailey: ~8 hours.
<jbailey> I don't think gcc-defaults is changing - we're still on 4.1
<infinity> Oh, we're still 4.1?  Kay.  Coo.
<infinity> Then just the new gcc would be nice. :)
<infinity> If I can complete the dance tomorrow, we can open this bloody thing.
<jbailey> Yup.  Is it useful if you get a tweaked glibc for hppa today, or should that just wait until later.
<infinity> hppa can wait.
<jbailey> Fabio said that it doesn't build itself with the new version, planning on looking at that today.
<infinity> Though I'd like to spend some time with you on hppa sometime tomorrow, if our timezones match up at some point.
<infinity> And yeah, glibc on hppa isn't self-hosting currently.
<infinity> "whoops"
<jbailey> Need to check with my wife, but I think she's working tonight.
<jbailey> She that should be fine.  I'll try to solve the self-hosting problem before that.
<infinity> Cool.  I'll see you when I wake up, then.
<infinity> Toodles and such.
<jbailey> Sleep well, Adam.
<infinity> Bug doko for gcc, if you see him. :)
<doko> infinity: I can upload that, what should we do with th ldbl128 changes?
<infinity> doko: We never got anywhere conclusive with that, did we?
<doko> no
<infinity> Cock.
<infinity> Hrm.
<jbailey> doko: It only affects libraries that have defined ldbl-128 interfaces, right?
<jbailey> Anything calling into glibc will be fine.
<jbailey> It'll otherwise be internally consistant.
<jbailey> I'm inclined to say non-issue and see if I'm right.
<doko> jbailey: yes, I started https://wiki.ubuntu.com/Ldbl128Main
<infinity> Well, the only possible issue is a maintainer script calling into broken code during the upgrade.
<infinity> If that's not a likely problem, we can just hand-wave it all away and make sure the affected bits are rebuilt.
* cjwatson is with infinity on this
<doko> and https://wiki.ubuntu.com/Ldbl128Universe
<jbailey> doko: How are you testing these?  Are you grepping include files?
<fabbione> jbailey, infinity: didn't we agree to upload another glibc after gcc???
<doko> jbailey: yes, and then looking at the packages
<jbailey> doko: 'kay.  Just making sure we're not triggering on internal uses of ldbl - just public interfaces.
<infinity> fabbione: We'll need another one to fix hppa anyway, so that timing will work out perfectly.
<infinity> jbailey: If you can hold off on the hppa-fixing glibc until after I do glibc/gcc on the primary arches, we'll get the "glibc rebuilt with the new toolchain" for free.
<doko> jbailey: and just include files in the binary packages, not the source packages
<jbailey> infinity: 'kay.  I can push the changes to bzr rather than upload.
<jbailey> doko: Right.
<fabbione> infinity: yes i am aware of hppa, but i think we should upload glibc after gcc again before opening 
<fabbione> infinity: and yes.. we get hppa for free that way and that was my plan too
<jbailey> fabbione: He's agreeing with you.
<fabbione> yeps
<fabbione> i am redundant
<infinity> I wasn't going to say it. :P
<doko> infinity, cjwatson: if we don't do anything with it, then we should upload the identified packages having long double in the interface just after the toolchain  upload (and before opening the gates)
<infinity> If you feel like hitting me with a mess of rebuild-only uploads, be my guest.
<fabbione> doko: i think we can do that using edgy source (just version bump) and merge them later
<cjwatson> I think that would be OK by me
<infinity> If we need to order library/app rebuilds, either set tightly-versioned build-deps (which might be a bit icky), or mail me a sort order.
<fabbione> that would probably be the fastest
<cjwatson> oh, fuck, app rdepends
<cjwatson> that's gonna be a LOT of rebuilds, right?
<infinity> A fair few.
<infinity> libgmp has a lot of rdeps, for instance.
<cjwatson> if we could prune the list as much as possible first ...
<fabbione> cjwatson: why? if we upload the libs first then everything that happen after is ok... there will be a short window during initial import that we are exposed, but who cares?
<infinity> On the other hand, I don't much care if APPS in feisty are broken, if we can just rebuild the libs out of the gate.
<infinity> We can catch the apps at a more leisurely pace.
<cjwatson> fabbione: I guess we could just ignore apps and let them get sorted out on merge/sync, assuming that they've changed in Debian
<fabbione> infinity: exactly...
<cjwatson> I'd be a lot more comfortable if we had an automatic way to scan binaries for the old long double ABI
<fabbione> i guess we can track the list and see if something is not rebuilded
<infinity> I'm sure someone could write a quick archive scanner to find it... Maybe?
<infinity> Or is it completely opaque?
<fabbione> infinity: i think you could just unleash glibc on the buildd... some of them will take hours to build anyway
<infinity> fabbione: It's not published yet.
<fabbione> infinity: ppc kernel is ok so buildd should survive 
<jbailey> cjwatson: Not possible, sadle.
<infinity> fabbione: I'll probably get it building before I sleep, though.
<jbailey> cjwatson: The problem is that on arches where long double didn't exist, it came out as double.
<fabbione> it should be published in few minutes :)
<jbailey> sadly, even.
<doko> infinity: once you use a typedef in a header, you can't really find out something about the app without knowing the typedefs
<infinity> doko: Anyhow, either way, get me gcc for tomorrow, pretty please.  We can get this whole library rebuilding mess sorted then.
<cjwatson> jbailey: can we scan for binaries using double at all?
<infinity> (Or you guys can keep hashing it out while I watch TV for an hour and then go to sleep)
<cjwatson> then we could just compare timestamps ...
<cjwatson> or for binaries using long double on i386 but double on powerpc, or something
<cjwatson> sorry, this all feels horribly impractical I know, just thinking out loud until it becomes practical
<jbailey> Umm, probably, since they'd have a floating point register somewhere in the signature?  glibc has some sort of abi check that they use for that.  It's black magic I've not poked by head into though.
<fabbione> shower time..
<fabbione> bbl
<fabbione> re
<doko> why does postfix need long double?
<fabbione> to process faster tons of TB of spam
<infinity> Grr, lib64stdc++6 was in universe.  Promoting to main, glibc will have to rety on ppc/sparc.
* infinity is going to bed, but will attend to it in the morning.
<doko> infinity: gcc-4.1 didn't change, will put it on chinstrap:~doko/uploads/
<fabbione> infinity: eh?
<fabbione> infinity: i did build glibc with what's in edgy main
<fabbione> specially on sparc
<fabbione> this is weird tho
<lamont> doko: where does postfix use long double?
<doko> lamont: http://people.ubuntu.com/~doko/ldbl/ldbl.headers-main/postfix-dev
<jbailey> fabbione, infinity: hppa patch committed for ustat bug.
<fabbione> jbailey: great!
<fabbione> once we get gcc out i will reupload glibc and we can open the dance
<jbailey> Turns out I wrote the patch for it in July. =)
<fabbione> ehhe
<jbailey> fabbione: The build isn't finished here yet, but it's at least past that point.
<fabbione> ok
<jbailey> I'm a bit concerned by the number of testsuite failures in there, but I suspect that most of those go away with a newer kernel.
<fabbione> probably
<fabbione> i guess we will never know till we boot a .19
<fabbione> also.. did you notice that we have unalligned access warnings with 2.5?
<jbailey> Not so far.
<jbailey> Mostly I noticed that my locales appear to be broken on hppa, but I don't remember them being broken at home.
<jbailey> So I'll check again on ppc to make sure.
<fabbione> pitti claims locales is ok for him on amd64 or x86
<jbailey> Weird.  I probably am just missing something that got twiddled from dapper.
<jbailey> fabbione: You just use English on your desktop?
<fabbione> yes
<fabbione> there is no other language for computer stuff
#ubuntu-toolchain 2006-11-02
<infinity> doko: I may be blind, but I'm not seeing this mystical gcc upload on chinstrap (nor in the queue on drescher)
<doko> oh, you want it directly in the queue?
<infinity> Ideally.
<infinity> ~doko/uploads would have bene fine too, but you didn't put it there either. :)
<jbailey> infinity: Didn't you hear?  doko took to heart the worries that edgy wasn't edgy enough - we're switching to gcc-snapshot as the main compiler. =)
* jbailey hides.
<infinity> -snapshot probably wouldn't make a horrible compiler, but the -snapshot packaging is useless for anything but testing.
<infinity> So, I'm going to assume that wasn't his intentio. :)
<doko> jbailey: no release dates for 4.2 yet :-/
<jbailey> doko: At this rate, I'd expect January or February.
<doko> infinity: you get the packages needing a rebuild tomorrow morning (my time), good night
<infinity> doko: Did you give me gcc?
<infinity>   113232 | S- | gcc-4.1              | 4.1.1-18ubuntu1      | 33 minutes
<infinity>          | * gcc-4.1/4.1.1-18ubuntu1 Component: main Section: devel
<infinity> Thanks.
<infinity> So you did.
<jbailey> infinity: Should I upload the glibc with the fix for hppa's building?  It's the only patch in -0ubuntu2 right now.
<infinity> Not yet.  If you do, the binaries for sparc/ppc for the previous version will be rejected./
<infinity> Well, actually, you can upload it, I just won't accept it yet.
<infinity> And look, everyone but sparc is done now.
* infinity gets out behind artigas to push.
<infinity> jbailey: Upload whenever you feel like it.  I won't accept and build it until after gcc.
<jbailey> infinity: Done.  Dinner time, back in a bit.
<infinity> Meh, we really need faster sparc buildds.
<infinity> Oh, there, it's finally entered the testsuite, at least.
<fabbione> infinity: did jeff uploaded glibc?
<fabbione> infinity: please reject Jeff upload. hppa patch is not there
<fabbione> he forgot to checkin the file i think
<infinity> fabbione: Err, are you sure?
<fabbione> yes
<infinity> fabbione: How can you be sure, it's not published in the archive yet. :)
<fabbione> bzr shared repo of death?
<fabbione> ya know.. that thing that helps for development..
<infinity> The patch looks there to me.
<infinity> lp_archive@drescher:~/foo$ debdiff *dsc | lsdiff
<infinity> glibc-2.5/debian/changelog
<infinity> glibc-2.5/debian/patches/series
<infinity> glibc-2.5/debian/patches/hppa/submitted-ustat.diff
<fabbione> it's not in bzr than
<infinity> Entirely possible.
<fabbione> well ok..
<fabbione> let it in
<fabbione> we will just need to rush another upload once he is awake
<infinity> For..?
<fabbione> there is an import ppc fix that needs to go it
<fabbione> but it can wait after this round
<fabbione> i mean it has been there forever
<infinity> Well, if you want to apply this debdiff to bzr, add the PPC fix too, and then re-upload, that's fine by me.
<infinity> Oh, it's a bug we have in 2.4 as well?
<infinity> If that's the case, then I don't much care.
<fabbione> no, it happens only in a specific situation and our kernels can cope with it
<infinity> (And also don't see the rush)
<fabbione> it's the rootcause of the hangs we were seeing
<infinity> Oh, if we have a fix for that, we may as well get it in.
<infinity> Let me toss you the debdiff for this, and you can apply it in bzr and re-upload -0ubuntu2
<fabbione> just go with ubuntu2
<fabbione> our kernels are all ok
<fabbione> it can wait the next upload
* infinity shrugs.
<infinity> Kay.  Then let's not "rush" the next upload. :)
<fabbione> it's something that's triggered at build time only anyway
<infinity> I'd prefer to open with the toolchain that's currently uploaded, if we can.
<fabbione> that's ok
<fabbione> let's open
<fabbione> it's a fix that can go in anytime
<fabbione> and it's not going to change ABI or anything
<infinity> sparc's in "make install"... Yay.
<fabbione> so it's safe for "later"
<infinity> Maybe it'll make the :03 daily... Maybe.
* infinity goes to make some dinner.
<fabbione> probably but unlikely
<fabbione> top - 07:46:43 up 25 min,  3 users,  load average: 2748.72, 1987.47, 879.30
<fabbione> whops
<infinity> Tell me that's not on a machine in the DC...
<fabbione> no
<infinity> Phew.
<infinity> Every time you do that to a DC machine, I cringe.
<fabbione> it's my T2000.. i was building a kernel and typed make -j
<infinity> You really don't get the concept of a "multi-user operating system", do you? :)
<fabbione> instead of make -j $something
<fabbione> aren't we a desktop? how many users can be in front of a desktop at the same time? :P
<fabbione> infinity: i suggest you switch the publisher to manual.. sparc has almost done, but i am afraid it won't make it for :03
<fabbione> it did it :)
<doko> infinity: awake?
<infinity> I am, yes.
<infinity> ust about to get gcc going, unless you're about to tell me not to.
<infinity> s/ust/Just/
<doko> infinity: no, that's ok.
<doko> uploaded gcc-defaults and gcj-4.1 as well
<infinity> We had a default change?
<doko> no, just stuff in libgcj-common
<fabbione> doko: do we need those before a new glibc rebuild?
<doko> fabbione: no
<fabbione> ok
<infinity> Guten Tag, Herr Watson.
<infinity> doko: So, when do I get this mess of library rebuilds for the ldbl128 breakage?
<infinity> doko: Cause once that's done, we're open for business.
<infinity> \o/
* Starting logfile irclogs/ubuntu-toolchain.log
<jbailey> Eh, I notice that the groups test doesn't fail glibc under feisty.
<jbailey> Maybe I can go back to building the zero-regressions framework in.
<fabbione> jbailey: i am ok to wait. there is no hurry my side
<jbailey> Wait?  What's that?
<jbailey> fabbione: Sorry, I lost my backscroll when I rebooted.
<fabbione> <jbailey> fabbione: jakub is proposing a different patch for ppc.  I'm inclined to sit on it for a day since it's a trapped alignment issue
<fabbione> <jbailey> (performance, not correctness)
<jbailey> Ah, cool.
<jbailey> doko: Seems we have a toolchain spec for feisty, not +1.
<jbailey> doko: should we just make it the feisty+1 spec?
<doko> jbailey: we have both, not yet added to the meeting
<jbailey> 'kay.  I'll look up the other one and addmyself to it.
<fabbione> while at it can you add me too please?
<doko> fabbione: I thought, assignees would be scubscribed automatically ;-p
<jbailey> fabbione: Participation required or just show up if you can?
<fabbione> doko: ahaha
<fabbione> jbailey: required
<fabbione> i want to be there
<doko> fabbione: done
<fabbione> thanks
#ubuntu-toolchain 2006-11-03
<Keybuk> is feisty nominally open now?
<doko_> Keybuk: not yet
<doko_> infinity: the first bunch of packages for the ldbl128 rebuild did build, I'm uploading the second bunch of packages now.
<Keybuk> ah ok
<Keybuk> the sync ponies are champing at their bits
<jbailey> OMG Ponies!
<doko_> Keybuk: could you process the packages I just uploaded?
<Keybuk> doko_: can you give me a list
<Keybuk> (ideally space separated)
<doko_> Keybuk: chinstrap:~doko/uploads/ldbl2/00list
<Keybuk> thanks
<Keybuk> (it would have taken the best part of an hour to iterate the queue and figure out which ones you uploaded *sigh*)
<Keybuk> doko_: was that the complete list?
<Keybuk> oh, weird, you did multiple uploads of the same sources?
<Keybuk> either that, or the queue is massively fucked
<doko_> Keybuk: I did upload all files in this dir at once
<doko_> erlang and pnetc got rejected, which I did upload again
<Keybuk> buggered if I know then
<Keybuk> dietlibc is simultaneously in accepted and unapproved
<infinity> Once all these ldbl128 rebuilds are done, if someone wants to find someone with enough access to flip the freeze->current switch, go nuts.
<infinity> I'm going to be heading to the airport in 2 hours, so it can't be me.
<cjwatson> I'll be around for about six more hours
<cjwatson> I'll just watch +builds?
<cjwatson> even if I can't find somebody, I'll at least punt everything from the unapproved queue through
#ubuntu-toolchain 2006-11-04
<doko__> cjwatson: please accept gcc-4.1_4.1.1-18ubuntu2 
<cjwatson> done, though I guess that means we won't unfreeze until I get to SF or thereabouts
<cjwatson> though in some ways that suits me better anyway
<doko__> cjwatson: no, it's not necessary, we can unfreeze earlier if you like. it's an optimization, now tested on OOo and firefox. the other use case is KDE, which needs manual work to use that. but yes, it won't hurt delaying it until Sunday
<cjwatson> oh, damn
<cjwatson> if I'd known that beforehand I'd have left it until after unfreezing
<cjwatson> but too late now, it'll just delay the unfreezing while the buildds catch up
<doko__> ok
<doko__> heading to bed, three hours left
<cjwatson> you're sleeping with three hours to go before leaving?
<cjwatson> you wake up way more reliably than I do
<cjwatson> on those timescales it's about 10x safer for me to just stay up
<doko__> yes, in these case I usually wake up before the alarm even
<cjwatson> wow
<cjwatson> still waiting for sparc and ia64 to catch ...
<cjwatson> er, catch up
<cjwatson> don't care about ia64 much, but the exercise is pointless if we don't wait for sparc, so
<Dvalin> huppeti
<Dvalin> anyone up? :)
<Dvalin> noone around? :(
