=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain [05:13] fabbione: Awake yet? [05:47] jbailey: now [05:51] WHOP WHOP [05:51] new gcc built on hppa [05:54] fabbione: Cool. Is that using the new glibc? [05:54] yeps [05:55] Nice. [05:55] chroot test on ppc works for libc6. [05:55] Doing system test and reboot. [05:56] ok [05:56] Ah, found a missing patch in libc.postinst. [05:56] which one? [05:56] Do you wish to restart services? [Y/n] [05:57] The one that eliminates that prompt. [05:57] Fixing. [05:57] hmmm i thought i did pull it in.. [05:57] ok [05:57] cool [05:59] those headers changes for IFA_ADDRESS will give us headacke [05:59] with this rebuild i got about 30 FTBFS compared to edgy === fabbione uploads gcc hppa to chinstrap [06:06] Hmm. [06:06] I thought it had been in there, but I don't see it... [06:06] Like, not in edgy, not in dapper. [06:08] Well. I'm still not convinced of that change anyway, so leave it for now, solve it later. [06:09] Reboot test. === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain [06:16] Weird. This *feels* faster. [06:16] ahhaa [06:17] * jbailey has quit ("ping timeout - glibc deteted ** double linked free **") [06:17] Eh, you're kidding? =) [06:17] of course :) [06:17] Bah ;) [06:18] it feels faster.... ping timeout.. too fast for internet [06:20] lamont, jbailey, infinity: new hppa gcc is on chinstrap [06:20] (usual place) [06:25] fabbione: Need anything else from me before I go pass out? [06:26] did you commit what you have done? [06:26] Yup. [06:26] let me check one second [06:27] 'k, I still need to brush my teeth anyway [06:28] Oh which arch was it that you can't build twice? [06:28] how can i check just check the commit diff you did? [06:28] hppa [06:29] i am trying now with new gcc for the sake of it [06:29] but the error wasn't gcc related [06:31] ok i am good with this [06:33] bzr diff -r#..# [06:33] 'kay. I'll look at the hppa problem tomorrow. [06:34] I went throught the ppc testsuite failures tonight. isomac is just a bad test with ldbl-128. tst-cancel24 is fixed. [06:34] That solves ppc64. The ppc32 stuff, there's something weird with how it calls the shell for one test, I don't understand. [06:34] The remaining thread tests I *think* are just from me using a ppc64 kernel. [06:35] The other stuff I did solved the segfault and the locale related tests. [06:35] ok... [06:35] the hppa thingy should be simple for you [06:35] Yeah, I suspect so. [06:36] Is that the only thing blocking us openning now? [06:36] yes it still fails with new gcc [06:36] no it's not a blocker [06:36] we will need to upload glibc_2.5-0ubuntu2 once gcc is built [06:36] that will take another 24 hours round [06:37] and the bootstrap for hppa will take longer than that [06:38] 'k. So what's our blockers? ppc kernel. What else? [06:38] sparc and ppc abi change.. [06:38] doko gave me a test case but i am not convinced yet [06:38] i just need to talk to him [06:42] otherwise i would say we only need binutils to hit the archive [06:42] and we can upload [06:42] and you can go to sleep for today :) [06:48] http://sources.redhat.com/ml/libc-alpha/2004-03/msg00241.html [06:48] is light reading for you for the nighttime. [06:48] There'll be a test in the morning. =) [06:50] reading... [06:51] fabbione: Passing out in the meantime. g'n! [06:51] jbailey: night dude [07:48] wanna-build -d feisty --list=needs-build [07:48] Total 0 package(s) [07:48] ok.. only a little bit left to complete sparc rebuild === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-toolchain === Mez [n=Mez@ubuntu/member/mez] has joined #ubuntu-toolchain === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain [02:01] Guys, I'm going to do glibc first thing when I wake up so I can babysit it and make sure it goes smoothly. [02:01] If someone has a new gcc and gcc-defaults for me, I'd love to see those in the queue as well. [02:01] infinity: How far away about is that? [02:01] jbailey: ~8 hours. [02:02] I don't think gcc-defaults is changing - we're still on 4.1 [02:02] Oh, we're still 4.1? Kay. Coo. [02:02] Then just the new gcc would be nice. :) [02:02] If I can complete the dance tomorrow, we can open this bloody thing. [02:02] Yup. Is it useful if you get a tweaked glibc for hppa today, or should that just wait until later. [02:03] hppa can wait. [02:03] Fabio said that it doesn't build itself with the new version, planning on looking at that today. [02:03] Though I'd like to spend some time with you on hppa sometime tomorrow, if our timezones match up at some point. [02:03] And yeah, glibc on hppa isn't self-hosting currently. [02:03] "whoops" [02:03] Need to check with my wife, but I think she's working tonight. [02:04] She that should be fine. I'll try to solve the self-hosting problem before that. [02:04] Cool. I'll see you when I wake up, then. [02:04] Toodles and such. [02:04] Sleep well, Adam. [02:04] Bug doko for gcc, if you see him. :) [02:04] infinity: I can upload that, what should we do with th ldbl128 changes? [02:04] doko: We never got anywhere conclusive with that, did we? [02:04] no [02:04] Cock. [02:04] Hrm. [02:04] doko: It only affects libraries that have defined ldbl-128 interfaces, right? [02:05] Anything calling into glibc will be fine. [02:05] It'll otherwise be internally consistant. [02:05] I'm inclined to say non-issue and see if I'm right. [02:05] jbailey: yes, I started https://wiki.ubuntu.com/Ldbl128Main [02:05] Well, the only possible issue is a maintainer script calling into broken code during the upgrade. [02:06] 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 [02:06] and https://wiki.ubuntu.com/Ldbl128Universe [02:06] doko: How are you testing these? Are you grepping include files? [02:07] jbailey, infinity: didn't we agree to upload another glibc after gcc??? [02:07] jbailey: yes, and then looking at the packages [02:07] doko: 'kay. Just making sure we're not triggering on internal uses of ldbl - just public interfaces. [02:07] fabbione: We'll need another one to fix hppa anyway, so that timing will work out perfectly. [02:08] 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. [02:08] jbailey: and just include files in the binary packages, not the source packages [02:08] infinity: 'kay. I can push the changes to bzr rather than upload. [02:08] doko: Right. [02:08] infinity: yes i am aware of hppa, but i think we should upload glibc after gcc again before opening [02:08] infinity: and yes.. we get hppa for free that way and that was my plan too [02:08] fabbione: He's agreeing with you. [02:09] yeps [02:09] i am redundant [02:09] I wasn't going to say it. :P [02:11] 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) [02:12] If you feel like hitting me with a mess of rebuild-only uploads, be my guest. [02:12] doko: i think we can do that using edgy source (just version bump) and merge them later [02:12] I think that would be OK by me [02:12] 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. [02:12] that would probably be the fastest [02:13] oh, fuck, app rdepends [02:13] that's gonna be a LOT of rebuilds, right? [02:13] A fair few. [02:13] libgmp has a lot of rdeps, for instance. [02:13] if we could prune the list as much as possible first ... [02:13] 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? [02:14] 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. [02:14] We can catch the apps at a more leisurely pace. [02:14] fabbione: I guess we could just ignore apps and let them get sorted out on merge/sync, assuming that they've changed in Debian [02:14] infinity: exactly... [02:14] I'd be a lot more comfortable if we had an automatic way to scan binaries for the old long double ABI [02:14] i guess we can track the list and see if something is not rebuilded [02:15] I'm sure someone could write a quick archive scanner to find it... Maybe? [02:15] Or is it completely opaque? [02:15] infinity: i think you could just unleash glibc on the buildd... some of them will take hours to build anyway [02:15] fabbione: It's not published yet. [02:15] infinity: ppc kernel is ok so buildd should survive [02:15] cjwatson: Not possible, sadle. [02:15] fabbione: I'll probably get it building before I sleep, though. [02:16] cjwatson: The problem is that on arches where long double didn't exist, it came out as double. [02:16] it should be published in few minutes :) [02:16] sadly, even. [02:16] infinity: once you use a typedef in a header, you can't really find out something about the app without knowing the typedefs [02:16] doko: Anyhow, either way, get me gcc for tomorrow, pretty please. We can get this whole library rebuilding mess sorted then. [02:16] jbailey: can we scan for binaries using double at all? [02:16] (Or you guys can keep hashing it out while I watch TV for an hour and then go to sleep) [02:16] then we could just compare timestamps ... [02:17] or for binaries using long double on i386 but double on powerpc, or something [02:17] sorry, this all feels horribly impractical I know, just thinking out loud until it becomes practical [02:17] 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. [02:18] shower time.. [02:18] bbl [02:46] re [02:47] why does postfix need long double? [02:47] to process faster tons of TB of spam [03:15] 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. [03:18] infinity: gcc-4.1 didn't change, will put it on chinstrap:~doko/uploads/ [03:21] infinity: eh? [03:21] infinity: i did build glibc with what's in edgy main [03:22] specially on sparc [03:23] this is weird tho [04:12] doko: where does postfix use long double? [04:13] lamont: http://people.ubuntu.com/~doko/ldbl/ldbl.headers-main/postfix-dev === jbailey [n=jbailey@montreal.canonical.com] has joined #ubuntu-toolchain === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-toolchain === mlpug [n=user@a84-231-238-186.elisa-laajakaista.fi] has joined #ubuntu-toolchain [09:18] fabbione, infinity: hppa patch committed for ustat bug. [09:20] jbailey: great! [09:20] once we get gcc out i will reupload glibc and we can open the dance [09:20] Turns out I wrote the patch for it in July. =) [09:21] ehhe [09:22] fabbione: The build isn't finished here yet, but it's at least past that point. [09:23] ok [09:23] 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. [09:24] probably [09:24] i guess we will never know till we boot a .19 [09:24] also.. did you notice that we have unalligned access warnings with 2.5? [09:26] Not so far. [09:26] Mostly I noticed that my locales appear to be broken on hppa, but I don't remember them being broken at home. [09:26] So I'll check again on ppc to make sure. [09:27] pitti claims locales is ok for him on amd64 or x86 [09:27] Weird. I probably am just missing something that got twiddled from dapper. [09:27] fabbione: You just use English on your desktop? [09:28] yes [09:28] there is no other language for computer stuff === doko [n=doko@dslb-088-073-093-229.pools.arcor-ip.net] has joined #ubuntu-toolchain === doko [n=doko@dslb-088-073-105-202.pools.arcor-ip.net] has joined #ubuntu-toolchain === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-toolchain