[01:27] <jbailey> fabbione: I'ts in the sparc64 pass.  I'm going to watch the test log for the first sparc32 pass, but the v9 and v9b passes failed to build.
[01:27] <jbailey> Seems gcc-3.3 only includes __thread support for plain sparc32.
[01:29] <jbailey> Huh, I had forgotten how freakishly long this takes to build. =)
[01:51] <fabbione> jbailey: don't worry.. it's only the first time that takes so long
[01:51] <jbailey> Yeah, except that next pass I'll probably do it with gcc-3.4
[04:36] <zul> heylo
[07:24] <fabbione> morning
[01:24] <fabbione> jbailey: i am afraid l-k-h is still borked on sparc
[01:24] <fabbione> i am getting some weird FTBFS
[01:29] <jbailey> fabbione: Can you point me to some errors reports?
[01:30] <fabbione> jbailey: check in ~/logs/libgtop2_2.10.1-1
[01:30] <fabbione> it builded on all arches other than sparc with something related to signals
[01:32] <fabbione> jbailey: also iproute and iptraf have weird FTBFS
[01:32] <fabbione> ignore iptraf.. that one fails all over
[01:33] <fabbione> but iproute is same as libgtop2
[01:33] <jbailey> Same two signals?
[01:33] <fabbione> nope
[01:33] <fabbione> iproute fails with other errors still related to includes
[01:34] <jbailey> Interesting, those two signals are only defined in asm-frv/signal.h in lkh.  /me checks pure kernel source.
[01:34] <fabbione>  /usr/bin/ld: cannot find -lstdc++
[01:34] <fabbione> this is sdl-mixer :)
[01:35] <fabbione> i saw 2 or 3 of this kind
[01:35] <fabbione> we also need to allign the Toolchain
[01:35] <fabbione> The following packages have unmet dependencies:
[01:35] <fabbione>   g77: Depends: g77-3.4 (>= 3.4.3) but it is not installable
[01:35] <fabbione>   gcj: Depends: g++ (>= 4:4.0-0) but 4:3.3.5-4 is to be installed
[01:36] <jbailey> fabbione: One at a time. =)
[01:37] <fabbione> jbailey: yeah.. i was grabbing the most common ones
[01:37] <jbailey> Is gcc-defaults broken on your system, though? 
[01:37] <fabbione> jbailey: do you have an imap setup?
[01:37] <jbailey> fabbione: I'm using the corporate IMAP server...
[01:38] <fabbione> jbailey: ok so you use a client that have imap :)
[01:38] <jbailey> Right, evolution.
[01:38] <jbailey> Why?
[01:38] <fabbione> i am sending you a mail..
[01:39] <fabbione> given that i can find your key with the ubuntu.com UID
[01:40] <fabbione> well i did send it @debian.org
[01:41] <jbailey> I don't have an ubuntu.com on my GPG key yet.  I'm still trying to decide what I want to do there.
[01:41] <jbailey> I will probably create a work-only key and get that signed at UDU.
[01:41] <fabbione> eheh
[01:46] <jbailey> It's not an lkh bug, it's a glib bug.
[01:46] <jbailey> /usr/include/bits/signum.h doesn't include SIGSTKFLT or SIGUNUSED
[01:46] <fabbione> nice..
[01:47] <fabbione> but only on sparc... right?
[01:47] <fabbione> since it builded on the other platforms
[01:47] <jbailey> It's hard to assert "only".
[01:47] <jbailey> The problem doesn't occur on PPC at least.
[01:47] <fabbione> well considering the few arches we are working on.. sparc is one of four
[01:47] <fabbione> 3 have built
[01:47] <fabbione> i have the option to say "only" :P
[01:48] <jbailey> Did ia64 fail to build?
[01:48] <fabbione> there is no ia64 atm
[01:48] <jbailey> Oh? a'ight then.
[01:50] <jbailey> Upstream source does not include SIGUNUSED or SIGSTKFLT in asm-sparc*.  Reassigning to kernel maintainer. ;)
[01:51] <fabbione> humpf
[01:52] <jbailey> It is likely a kernel bug - everything from m32r, cris up to x86_64 includes them.
[01:52] <fabbione> i was checking that it did build in debian
[01:52] <fabbione> the 1st of Feb
[01:52] <fabbione> on sparc
[01:53] <jbailey> Lemme check the ChangeLog.  I think these files are manually generated.
[01:54] <fabbione> let's scare doko a bit :)
[01:57] <jbailey> Last change was in Apr 2003, so there's no change in this file between Hoary and Breezy.
[01:59] <jbailey> fabbione: LOL You're cruel... ;)
[02:01] <jbailey> Got anything else I can punt back to you? =)
[02:02] <jbailey> I feel a little bad.  I sent the guy from 9824 to his doom.
[02:02] <jbailey> I told him to go talk to drepper if he had issues with malloc.
[02:02] <jbailey> I think this will be another black mark on my soul.
[02:02] <fabbione> ehhe yeah in this chan we are true bastards :)
[02:02] <fabbione> so you are telling me that it is a kernel problem...
[02:03] <fabbione> now my next question would be...
[02:03] <fabbione> given that the kernel hasn't changed between hoary and breezy
[02:03] <jbailey> fabbione: In that this arch doesn't appear to define those signals, and I suspect it should.
[02:03] <fabbione> and that the package did build for hoary...
[02:03] <fabbione> who should i blame?
[02:03] <jbailey> Has the package changed?
[02:03] <fabbione> yeps.. new version.. dunno the details tho
[02:03] <fabbione> i can check that
[02:03] <jbailey> My guess is they now assume those signals exist.
[02:04] <jbailey> And by the looks of who all supports them, it possibly should be a valid assumption.
[02:04] <jbailey> But I can't add them to glibc until I know what signal numbers get assigned to them.
[02:04] <fabbione> right...
[02:07] <jbailey> Got your email, nice!
[02:07] <jbailey> When I ran a buildd we used pop3 so that it acted like a mutex-wrapped stack for us. =)  Whoever got the emails needed to deal with them.
[02:08] <fabbione> jbailey: well it's the same in ~/logs :)
[02:08] <fabbione> just easier to parse ;)
[02:08] <fabbione> and yes the certificate name mistmatch is ok
[02:08] <jbailey> 'k
[02:09] <T-Bone> ohayo
[02:10] <fabbione> jbailey: i can readd the signals in signals.h, but the question is, why were they missing in the first place?
[02:11] <jbailey> fabbione: Right, which is why I need to punt it back to you.  I have no way of knowing that, and benc is willing to answer your mails and not mine. =)
[02:11] <fabbione> and readding them with random numbers (since the ones declared for the arches are already in use in sparc), is it ok or can create more mess?
[02:11] <doko> fabbione: you should add to the topic "there are no compiler and kernel bugs" ... 
[02:11] <fabbione> jbailey: he didn't answer the second one...
[02:12] <jbailey> Ahahahah
[02:14] <jbailey> fabbione: Well, the problem with readding them with a random number is that these are about to be hardcoded into programs.  So if they're seriously wrong (like a signal comes along and triggers the wrong behaviour) then we have 1) Unpredictable behaviour 2) A pile of binNMUs to do, since it's effectively a kernel->userspace ABI break.
[02:15] <fabbione> jbailey: that's what i was scared about
[02:16] <fabbione> i need to wake up my wife...
[02:17] <fabbione> and puts an end to my nerding weekend :/
[02:17] <jbailey> *lol*
[02:17] <jbailey> fabbione: Maybe fire off an email to davem first?
[02:18] <fabbione> i will mail him tomorrow...
[02:18] <fabbione> i want to build some more packages from universe first
[02:18] <fabbione> since main is stalled
[02:18] <fabbione> i need elmo to sync sparc.u.c for me
[02:18] <fabbione> at least all the packages that could be built for main did
[02:18] <fabbione> there are only a few left
[02:19] <jbailey> Is there another one you want me to quickly look at?  Otherwise I will go back to other hacking.
[02:19] <fabbione> checking....
[02:20] <fabbione> jbailey: sdl-mixer
[02:20] <fabbione>  /usr/bin/ld: cannot find -lstdc++
[02:20] <fabbione> it looks really weird to me
[02:20] <fabbione> btw 9824. you did ok
[02:21] <jbailey> Bah.  This one's toolchain.  Don't use cc for compiling c++ apps.
[02:21] <jbailey> gcc works around it when the version of gcc and g++ match, but when they don't, you'll get strange things.
[02:21] <fabbione> ok
[02:22] <fabbione> so we need to allign the toolchain :)
[02:22] <fabbione> jbailey: thanks a lot.. that's all for today
[02:22] <jbailey> fabbione: Anytime. ;)
[02:22] <fabbione> since i know that a kickback should be enough, i am not too scares
[02:22] <fabbione> scared
[02:25] <jbailey> Yeah.  I imagine that the signals issue will be a quick enough fix.  Once it's in upstream, we can shuffle it along easily enough.
[02:25] <jbailey> upstream kernel, that is.
[02:30] <fabbione> yeah i will mail davem tomorrow.. mind if i add you in CC?
[02:31] <jbailey> Not at all.
[02:31] <fabbione> ok
[02:31] <fabbione> just because if he starts asking too many specific questions, i might not be able to answer in details
[02:32] <jbailey> Totally no worries.  I can see what the problem is.  I suspect if I knew anything about signal internals in the kernel I could find the answer really quickly.
[02:32] <fabbione> well.. this should push you to a new challenge.. learn the signal internals in the kernel :)
[02:33] <jbailey> Et tu, Brutes?
[02:33] <fabbione> ehehe
[02:33] <fabbione> anyway.. wife is awake...
[02:33] <fabbione> time to start doing stuff around the house
[02:33] <jbailey> Go, before she delivers you to UDU in 6 boxes.
[02:34] <fabbione> ahahahha
[02:34] <fabbione> cya tomorrow
[02:34] <jbailey> 'bye. =)
[02:39] <jbailey> fabbione: If you happen to float by the terminal - Do you have the last successful log of glibc being built?  I'd like to see if the same testcases fail in each case.
[02:42] <jbailey> Ah, nothing like a 40 meg build log.
[02:43] <T-Bone> you perv ;)
[02:44] <jbailey> Once regex failure (timeout) and message queueing doesn't appear to timeout correctly.
[02:58] <jbailey> ../nptl/sysdeps/unix/sysv/linux/sparc/lowlevellock.h:80:2: #error SPARC < v9 does not support compare and swap which is essential for futex based locking
[03:46] <lamont> T-Bone: step 1) fix the ftbfs in gcc-4.0 and glibc from breezy, building on top of hoary.  (glibc requires linux-kernel-headers, gcc-4.0 requires doxygen).
[03:46] <lamont> then it'll matter
[03:59] <T-Bone> lamont: i thought we were planning to provide clean hoary in the meantime...
[04:01] <lamont> T-Bone: yeah - I need to process the archive through, that's true
[04:01] <lamont> right now, I'm busy dealing with the fact that my entire body hurts.
[04:01] <T-Bone> lamont: you told me we would need to rebuild main too
[04:01] <T-Bone> lamont: oh? What happened?
[04:02] <lamont> 20kg on your back.  3 miles.  you have 45 minutes. you may begin.
[04:02] <T-Bone> interesting
[04:02] <lamont> not after the first 1/2 mile.
[04:02] <T-Bone> i wonder if that's any worse than carrying around 350kg of material as i did last week :)
[04:02] <lamont> heh
[04:03] <T-Bone> truth told, my body hurts too ;)
[04:03] <lamont> yeah
[04:04] <T-Bone> hmmm
[04:04] <lamont> as for the main rebuild, if you just remove everything but main from your sources.list, and then rebuild just main packages (since universe will fail to fetch source), those packages will be what we can use
[04:04] <T-Bone> lamont: i don't get it, doxygen is in your pool
[04:04] <lamont> doxygen from breezy is needed for gcc-4.0 in breezy
[04:04] <T-Bone> oh
[04:05] <T-Bone> ic
[04:05] <lamont> yeah
[04:05] <lamont> what I was trying to do last week was bootstrap breezy on hppa (while I was waiting for the builds on the other architectures)...
[04:05] <lamont> and gcc-4.0 and glibc are both ftbfs
[04:06] <T-Bone> sweet baby love :P
[04:06] <T-Bone> lamont: am i to fear the expect bug btw?
[04:08] <lamont> I'm running our 2.6.12_2.6.11.90-1-hppa64 right now... haven't decided if SMP is a factor in the failures.
[04:08] <T-Bone> lamont: so i want to build doxygen and l-k-h from breezy in a hoary chroot, and then build gcc-4.0/glibc in a polluted hoary chroot, correct?
[04:09] <jbailey> T-Bone: lkh doesn't care where it's built.
[04:09] <T-Bone> fair enough
[04:09] <jbailey> Linuxthreads suckage.
[04:09] <T-Bone> almighty fuck. I won't touch that :)
[04:09] <jbailey> We just need a merge from Carlos.
[04:10] <lamont> T-Bone: well enought
[04:10] <T-Bone> ?
[04:17] <T-Bone> bwahahaha
[04:17] <T-Bone> lamont: all main package needing build (those who aren't already in your pool) are all FTBFS
[04:17] <T-Bone> afaict
[04:19] <lamont> T-Bone: then I guess hoary is happy :-)
[04:19] <T-Bone> lamont: i've triggered a build just to make sure, but I think there's not much to hope
[04:19] <T-Bone> it's console-data/d-i/kde
[04:19] <T-Bone> basically
[04:20] <lamont> console-data I'll make sure we get one of, although I'm not too worried if we're a little bit out of date - I'll check the changelog to make sure I don't care.
[04:20] <T-Bone> ok
[04:21] <lamont> d-i built for me, but is kinda useless without all the module stuff...
[04:21] <T-Bone> it's not d-i which is missing, afaict. There are d-i stuff missing
[04:21] <T-Bone> eg
[04:21] <T-Bone> debian-installer/bterm-unifont_0.011 [-:uncompiled] 
[04:21] <T-Bone> debian-installer/cdrom-checker_1.02ubuntu5 [-:uncompiled] 
[04:21] <T-Bone> debian-installer/lowmem_1.06ubuntu1 [-:uncompiled] 
[04:21] <lamont> ah, ok
[04:22] <T-Bone> 50 packages needs-build. I'll see what comes out once buildd has munched the list
[04:23] <lamont> I have lowmem built here, the others didn't come over with my mirrorring, it appears.
[04:24] <lamont> ah, I have cdrom-checker_1.02ubuntu5 built as well
[04:24] <T-Bone> heh, nevermind, i doubt they'll take much time to build :)
[04:25] <lamont> anyway, back in a few hours
[04:25] <T-Bone> cya
[07:38] <fabbione> jbailey: yes.. it's always in ~/logs
[07:38] <fabbione> jbailey: the biggest one is usually the success :)
[07:41] <fabbione> lamont: still around?
[07:42] <fabbione> jbailey: ah this one is interesting... hfsplus
[07:44] <fabbione> anyway i am off for dinner...
[07:44] <crimsun> bye
[07:44] <fabbione> there are only a bunch of packages that fails in main
[07:45] <fabbione> otherwise sparc is building universe already :)
[07:45] <crimsun> cool
[07:45] <crimsun> fabbione: I know of at least 3 excited ubuntu sparc users
[07:45] <crimsun> so you _do_ have a growing userbase :)
[07:45] <fabbione> are they using it, or waiting for it?
[07:45] <crimsun> one's currently using it right now
[07:46] <fabbione> ah rocking!
[07:46] <crimsun> (I pointed him to sparc.ubuntu.com a while back but alerted him to the pending change to ubuntu-ports)
[07:46] <fabbione> right..
[07:46] <fabbione> i am happy :)
[07:46] <fabbione> but i really need to go now
[07:46] <crimsun> cya :)
[07:46] <fabbione> cya tomorrow
[10:59] <T-Gone> lamont: http://archive.slashdirt.org/incoming/ <- main built from main, signed