#ubuntu-toolchain 2006-03-20
<mjg59> doko: binutils_2.16.1-2ubuntu7_i386.deb  works, binutils_2.16.1cvs20051109-1ubuntu1_i386.deb doesn't
<fabbione> hey doko_ 
<doko> hi fabbione
<fabbione> doko: hey...
<fabbione> doko: do you think it is possible to switch default gcc build option for sparc?
<doko> fabbione: sure, should be possible
<fabbione> doko: --with-cpu=v7 -> --with-cpu=v8
<fabbione> when do you think that could be done?
<fabbione> or sort of.. when do you plan to upload the next version of gcc?
<doko> as long as I can add hppa specific fixes, so that lamont doesn't glare ...
<doko> today
<fabbione> ok great!
<fabbione> that's fine
<lamont> doko: LP is building dapper/hppa now, so I don't care so much... 'twould be nice to let it catch up sometime soon, though... :-)
<jbailey> lamont: Meh.  You have 3 buildds, don't you? =)
<doko> yes, one for gcc-4.0, gcj-4.0, gcj-4.1 ;-P
<lamont> jbailey: not sure how many of them are online yet
<lamont> jbailey: I see 2 so far (primero, kohnen)
<lamont> and yes, primero is building gcj-4.0
<lamont> er, 4.1
<jbailey> Well, it'll be nice to maybe see the 'pending' list in Soyuz actually get down to zero. =)
<infinity> jbailey: That won't happen until backports is sorted, unfortunately.
<infinity> (Which I should get on, I guess)
<infinity> jbailey: Also, didn't you say you had some breezy-updates uploads pending?
<jbailey> infinity: I did.  Colin asked me to resubmit them, and I haven't.
<infinity> jbailey: I could be on crack, but I'd swear someone else set up breezy-updates chroots wen I wasn't looking, cause I see some successful builds in that pocket.
<jbailey> I also have glibc timezone updates for our three live ones.
<jbailey> Yeah, breezy-updates is working now.
<infinity> glibc timezone updates kinda need to happen NOW.
<infinity> We're dangerously close to that being a problem here in Melbourne.
<jbailey> Oh right.  Aussie's and their screwed up timezone bits.
<infinity> Like, the bug hits in a week or something.
<jbailey> Okay.  I'll try to send through warty, hoary and breezy sometime today.
<jbailey> BEWARE THE IDES OF MARCH
<infinity> (Don't feel too bad, I only saw the update come in on Windows Update a week or so ago...)
<infinity> jbailey: Ping Kamion and I both when you've uploaded them, so he can approve them immediately, and I can babysit and make sure all three pockets actually work (I suspect only breezy-updates does, and even that I'm suspicious of)
<jbailey> I've used packages from breezy-updates. =)
<infinity> Yeah, I'm more suspicious of the chroots than of the publishing. :)
<infinity> It does seem to more or less work right.
<jbailey> https://launchpad.net/+builds/+build/174707
<mjg59> doko: Are there any binutils packages earlier than the November CVS?
<jbailey> mjg59: Probably breezy-final
<jbailey> There was only what, 3 weeks in there?
<infinity> Which was non-CVS.
<infinity> jbailey: Lots more than 3 weeks upstream.. :/
<jbailey> Yeah, point.
<doko> mjg59: no have to build these myself
<mjg59> doko: Ok
<infinity> mjg59: http://snapshot.debian.net/archive/2005/09/06/debian/pool/main/b/binutils/binutils-dev_2.16.1cvs20050902-1_i386.deb
<infinity> mjg59: Looks like snapshot's back up. :)
<infinity> mjg59: That may help give you a small window to search in.
<mjg59> Hurrah
<infinity> Err, s/-dev//
<infinity> http://snapshot.debian.net/archive/2005/09/06/debian/pool/main/b/binutils/binutils_2.16.1cvs20050902-1_i386.deb
<infinity> Better.
<jbailey> mjg59: Binary searching for the EFI build breakage?
<infinity> mjg59: You've rebuilt the binutils 2.16.1 package with our current toolchain to make sure that it's not some scary "GCC started miscompiling binutils recently" bug, right?
<mjg59> infinity: Yes
<infinity> (Though, given your initial findings in the binary diff, I suspect it's binutils alone at fault)
<mjg59> jbailey: Yup
<mjg59> 20050902 works, 20051109 doesn't
<mjg59> doko: 20051001 works
<mjg59> Given a CVS checkout from a certain date, can I just update it to a later date?
<mjg59> (Or, indeed, revert it to a previous date?)
<infinity> Assuming it has the CVS dirs in it, sure.
<mjg59> How? update -D?
<infinity> -D or -d, I don't recall.
<infinity> -D
<infinity> cvs up -D 2005-10-13
<infinity> Or so.
<mjg59> Ok
<mjg59> Breakage was between the 22nd and 27th of October
<infinity> That's getting much more narrow.
<mjg59> Yes
<mjg59> I'm doing the 25th now, then I'll just diff the trees
<mjg59> 25th is broken
<mjg59> 24th works
<jbailey> \o/
<jbailey> Now to figure out if it's opcodes, bfs, binutils, gas...
<mjg59> Hm. 2773 lines of diff.
<mjg59> Pile of changes in bfd
<mjg59> And also in gas
<mjg59> And in ld
<mjg59> Ho-hum
<infinity> 2773 lines isn't so bad, in binutils land.
<mjg59> Ok, it's either the ld or bfd changes
<mjg59> Which takes us down to 1312 lines
<mjg59> I blame bfd.
<mjg59> Since the ld changes are just down to changes in bfd
<mjg59> doko: It's either H.J. Lu's changes on 2005-10-23 or one of the changes on 2005-10-24
<mjg59> doko: Does that narrow things down enough for you?
<doko> mjg59: yes, thanks! still having OOo fun at the moment ...
<mjg59> doko: No problem
<mjg59> doko: Ok, it's H.J. Lu's fix for PR/1487
<mjg59> The one from 2005-10-23
<doko> mjg59: looks like you couldn't rest ;-)
<mjg59> Heh
<jbailey> CANT SLEEP.   GENETICALLY ALTERED FIREFLYS (or whatever it is you grow) WILL EAT ME
<mjg59> Fruitflies
<jbailey> mjg59: One of these days I'd like to take you for a drink and get you to tell me how one does gene alterations.
<mjg59> Haha
<mjg59> doko: The diff is at http://www.codon.org.uk/~mjg59/tmp/binutils.diff
<mjg59> If that's reversed, it's happy
<doko> ok, submitting an upstream bug report
#ubuntu-toolchain 2006-03-21
<jbailey> mjg59: Can you see what the bad asm output is enough to get a testcase added?
<doko> http://sourceware.org/bugzilla/show_bug.cgi?id=2464
<doko> heading to bed now ...
<mjg59> jbailey: The asm output is fine
<mjg59> It's the linking that's broken
<jbailey> mjg59: Bdale emailed me about the efi emulator, btw: http://www.intel.com/technology/efi/main_sample.htm
<mjg59> jbailey: Ah, cool
* lamont grumbles, just so doko knows he's reading #ubuntu-meeting
<doko> ;-P
<lamont> hey - I thouhgt about grumbling in #u-m.. :-)
<lamont> anyway, must run - all day training class
#ubuntu-toolchain 2006-03-22
<doko> jbailey, lamont: gcj-4.1 on dapper shows 500 test failures in libjava, not seen in current unstable.
<doko> see chinstrap:~doko/gcj-4.1*
<doko> nearly all interpreted test cases fail
<doko> jbailey: in which ways differ the stack unwinding bits in glibc in unstable and dapper on hppa?
* doko wonders why lamont is not grumbling anymore ...
<jbailey> doko: Eh?  No idea off hand.
<jbailey> AFAIK, everything's sync'd now.
<lamont> jbailey: so what did doko break in gcj-4.1 then? :-)
<doko> just verified, that the same source works on unstable, but not dapper. so either lamont did touch the kernel, or jbailey glibc ;-)
<lamont> hrm.. could signals compatibility be part of it?
<doko> lamont: maybe, the stacktrace I did send, started somewhere in the garbage collector
<lamont> hrm
<doko> jda cannot reproduce it either, but maybe my chroot is corrupt
<lamont> your dapper chroot, or your sid chroot?
<doko> dapper
<lamont> it's possible that dapper will debootstrap from ports.u.c right now...
<infinity> lamont: Well, the chroots are completely built with packages from ports.u.c now, if that's any consolation.  debootstrap *should* work.
<lamont> infinity: cool
<lamont> yeah - it was more a question of the transient nature of things while it's playing catchup
<infinity> lamont: No, I meant I *just* rebuilt the hppa chroot with ports.u.c, like, an hour ago, so really, it SHOULD work. :)
<lamont> oh, rock.
<infinity> Nothing toolchain-wise is coming from rockhopper anymore, just some -desktop stragglers.
<infinity> I hope to turn off the rockhopper repo completely in a day or two, once GNOME is fully bootstrapped again.
<infinity> (It was a big help, BTW, thanks...)
<lamont> n ice
<lamont> well, when debhelper isn't installable, life just isn't fun
<infinity> Generally not, no.
<infinity> GNOME's bootstrapping issues are just as un-fun, when you're behind too.
<infinity> Took me a week to untangle ia64, so the fact that hppa Just Works (because it was mostly up to date, and just building new versions againast themselves) was a big help.
<infinity> Heck, even powerpc needed untangling, and it wasn't "broken" to start with.  Boy, I love new GNOME versions. :)
<doko> jbailey: ping
<doko> jbailey, lamont: it's missing glibc patch
<lamont> doko: coolness.
<infinity> doko: If it's a straighforward patch that's in Debian already, smack it at Malone, and I can apply it.
<infinity> doko: In theory, jbailey's backing off glibc maintenance... In theory. :)
<doko> infinity: currently building on hppa ...
<doko> wondering why jbailey did rename all the debian patches ...
<infinity> Patch reorg, meant to get pushed back to Debian, hasn't been yet.  I need t odiscuss it with some Debina folk.
<infinity> Debian, too.
<doko> lamont: how can I ask about libunwind on ia64?
<doko> s/how/who/
<doko> should stop for today ...
<lamont> doko: can you tell me which patch, and I'll upload a new glibc (or even check with jbailey...)
<lamont> libunwind... hrm...
<doko> lamont: chinstrap:~doko
<doko> eh-frame-pointer
<lamont> doko: uh... ENOFILE
<doko> on chinstrap?
<lamont> doko: yeah - was looking on chinstrap in ~doko
<lamont> no file named 'eh-frame-pointer'
<lamont> nor anything named *-frame-pointer* anywhere under ~doko
<jbailey> infinity: They've basically agreed to it.  I need to switch us to quilt first.
<doko> lamont: glibc*
<lamont> ah, the diff of glibc.  got it
<lamont> doko: and that diff/dsc are uploadable?
<lamont> rather, they have that fix, and just that fix?
<lamont> and we know it'll fix things.
<lamont> ?
<doko> lamont: my build is still running, currently rebooting m yi386 machine witht this glibc, please don't be IMPATIENT!
<lamont> ah, ok.
<lamont> doko: I'll let you/jbailey work it out, no hurry here
<doko> yes, I will ask jbailey before uploading ...
<jbailey> doko: Yeah yeah sure.  Just don't break other things ;)
<jbailey> My pending glibc uploads are all for various -updates.
<jbailey> Thinking of which, they've probably finished by now.
<doko> btw: lamont:
<doko> <doko> lamont: who can I ask about libunwind on ia64?
<jbailey> So hmm.
<doko> jbailey: for dapper as well?
<jbailey> Should I put out a call for testers of the new glibc for warty/hoary/breezy, or should I do the usual chroot test and upload it if it works? =)
<jbailey> doko: No.  Dapper already has the fix.
<lamont> doko: mossberger seems to be the consensus
<doko> ok
<doko> jbailey: who do you ask? there are not many people on the channel?
<jbailey> Who do I ask for what, sorry?
<doko> <jbailey> Should I put out a call for testers of the new glibc for warty/hoary/breezy, or should I do the usual chroot test and upload it if it works? =)
<jbailey> Oh, I see.
<doko> or maybe that was a rethoric question 
<jbailey> More talking to myself but announcing it in case someone had an opinion.
* lamont considers saying "just don't break other things :-)"
<jbailey> Well, that's more what I'm worried about here.
<jbailey> Since it's a timezone update and we haven't done one of those before, I can't guess what it might break.
<jbailey> It *should* be nothing.
<doko> ok, i386 did survive the eh-framepointer reboot 
<lamont> oh.  that fix
<lamont> xgcc: Internal error: Segmentation fault (program as)
<lamont> that'd be breezy-security's gcc-3.4 on hppa
<doko> lamont: try to configure dash as sh on hppa and see some nice segfaults building glibc
<lamont> I see
<lamont> the normal medical suggestion in such a situation is "don't do that, then"
<lamont> doko: re libunwind - have you tried pinging the pkg maintainer/
<lamont> >?
<doko> hmm, no, it's more the gcc related patches that fc and opensuse has
<lamont> still, I think the debian maintainer is probably well connected to upstream...
<lamont> and therefore a reasonable resource to involve in the search
#ubuntu-toolchain 2006-03-23
<doko> upcoming fun ... http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html
<jbailey> doko: Whee
<infinity> doko: So, you uploaded to fix one gcj-4.1 breakage on hppa, but still haven't uploaded for the other (where's my libgcc4?)... <poke, poke, poke, poke>
<doko_> infinity: hmm, the hppa buildd sees the gcc-3.4 testsuite still running ...
<infinity> doko_: That was the traditional "logwatch is retarded and sometimes doesn't exit properly" bug, which I still see on m68k occasionally too.
<infinity> doko_: Did you change logwatch in 4.0 and 4.1, cause I've seen it on the DC buildds with 3.3 and 3.4, but I don't recall seeing the bug on 4.0/4.1
#ubuntu-toolchain 2006-03-25
<lamont> jbailey/doko: did we get the new hppa-loving glibc uploaded?
<infinity> lamont: Yes.
<infinity> lamont: That was ubuntu10
<lamont> soog
<infinity> lamont: If you're noticing that java packages (like db4.3) still fail to build, I noticed the same thing.
<lamont> woot, even
* infinity need to poke that in a bit.
<lamont> do we have anything that gives the list of recent failures (I don't care about successes...)(
<doko> lamont: please tell me why openoffice.org doesn't start on ia64, if openoffice.org-gnome is installed 
<lamont> hrm... for newer machines, I expect it's because they don't do i386 in hardware... :)
<lamont> for older machines, nfc
<infinity> lamont: Hit up the buildd pages (all three of them), then filter by build state.
<lamont> but I'll play with that some during the work week
<infinity> lamont: That's the only real way (currently) to get all the failures for an arch.
<lamont> sigh
<doko> lamont: apparently it's an old machine, because it starts _without_ gnome
<lamont> doko: yeah.  zx1 or earlier
<lamont> maybe even zx2... dunno
<lamont> infinity: I think I'll fire up a w-b instance for dapper again, just to see the status... :-)
<infinity> doko: Is there a hope in hell of having native 64-bit OpenOffice for dapper+1?
<infinity> lamont: Sad...
<infinity> lamont: I could build some custom queries on drescher.
<lamont> infinity: already have one for breezy-security, nothing extra to do for dapper, other than add it to the list of suites
<infinity> lamont: Also, http://people.ubuntu.com/~cjwatson/testing-ports/dapper_outdate.txt is useful.
<doko> infinity: I'll have to find out if it's targeted for 2.0.3, which is late May ...
<infinity> doko: I suspect you can't wait to stop maintaining all the goofy ia32-libs collections. :)
* lamont finds himself tempted to upload a no-change ispell-fi, so that it's ftbfs everywhere, instead of just ia64/hppa
<lamont> infinity: very useful - bookmarked
<infinity> Oh, there are a few of those.  File bugs if you haven't yet.
<doko> infinity: dude, it's not *my* stuff ...
<infinity> lamont: Also, ../testing/dapper_outdate.txt is for non-ports.
<infinity> lamont: I need to ask Colin to do that as a unified file (easier to pikc out what fails everywhere), but right now, I wget and sort them together into one file.
<lamont> Totals by arch:
<lamont>     * hppa:92
<lamont>     * sparc:29
<lamont>     * ia64:23 
<lamont> hppa rocks
<lamont> that's dapper-problems
<infinity> hppa's getting there.
<infinity> It was 300 or something a while ago.
<infinity> dapper_problems is almost getting readable.
<lamont> esp for non-ports
<infinity> non-ports is just waiting on package removals, otherwise it's "perfect"
<infinity> Someone really should fix the findutils FTBFS though.
<jbailey> doko: Wow: Stage 2 ends already?
<doko> yes, but better not base dapper+1 on 4.2 ...
<jbailey> Well, with a 6 week delay, 4.2 will be theoretically released, right? ;)
<doko> jbailey, infinity: could one of you go over the debian repository and scan for patches not applied in the ubuntu package?
<jbailey> Anything you're looking for in particular?
<jbailey> (assuming you mean glibc, right? *g*)
<doko> yes :)
<jbailey> doko: Is there anything in particular fix that you're looking for?
<doko> the particular one last weekend was "find the java breakage on hppa"
<doko> which turned out as eh-frame-terminator.diff ...
<jbailey> Sure.  Although the hppa patches in our glibc were the ones that the Debian hppa guy had said were best to be in there.
<jbailey> Thinking of which.  Carlos had said that he'll try to have me hppa patches for nptl on 2.4 for next week.
#ubuntu-toolchain 2006-03-26
<infinity> doko: I don't think java on hppa is completely fixed yet anyway...
<doko> infinity: hmm, what's the concrete problem?
<infinity> I haven't had a chance to do a manual build yet and check the logs to see.
<infinity> I just know that something is failing. :)
<infinity> (check the uninformative log for db4.3 or db4.4)
<infinity> I'll do a manual build in a bit and scour config.log for what's actually going wrong.
#ubuntu-toolchain 2007-03-21
* Starting logfile irclogs/ubuntu-toolchain.log
<fabbione> doko: ok... should we?
<doko> ok
<fabbione> apt-get source redhat-cluster-suite
<fabbione> the incrimated .deb is rgmanager
<fabbione> the binary in rgmanager is /usr/sbin/clurgmgr
<fabbione> that executable links with libcman.so.2.0 and libdlm.so.2.0
<doko> all archs?
<fabbione> what's happening is that at random (at least on i386) 
<fabbione> it is dynamically linked.. while other times (like the last build on the buildd) gets statically linked
<fabbione> ia64 gets always static.. i didn't check yet amd64/sparc/ppc
<fabbione> the very strange thing is that it happens ONLY with these 2 libraries
<fabbione> because the other libs seem to be always dynamic
<fabbione> now.. what i am not sure is why it happens at random.. why only with these 2 libs (built from the same source)
<fabbione> and it changes behaviour on different arches
<fabbione> i can't find a pattern in it except that you build once and it's static.. you build another and it's dynamic
<fabbione> redhat-cluster-suite-2.20070315/rgmanager/src/daemons/clurgmgrd
<fabbione> and it usually happens for the binaries in that dir
<doko> ugly
<fabbione> at least this is what i noticed
<fabbione> there might be more binaries around with that issue
<fabbione> so i need some help here to understand if it is the build system or our toolchain
<doko> but it only happens with these two shared libs, correct?
<fabbione> yes so it seems
<fabbione> those are the 2 i noticed
<fabbione> for example clvmd (lvm2) links against the same 2 libs but it does it properly (at least it did it in the last build)
<doko> so how can we trigger that?
<fabbione> build the source .. check ldd
<fabbione> repeat until
<fabbione> that's what i did
<doko> I could imagine to build/link with a newer/pure upstream toolchain
<fabbione> it usually happens quicklu
<fabbione> quickly even
<fabbione> like in 2/3 builds
<fabbione> i experience this sometimes on every build that there was a change in the linking
<fabbione> so it shouldn't take you too long to trigger
<fabbione> but i wasn't able to isolate what triggers it
<fabbione> otherwise i would know more
<doko> did you call the compiler/linker with -v to see some difference in the output?
<fabbione> yes
<fabbione> i noticed none
<doko> I can try to build with our feisty+1 toolchain, but this does not differ too much
<fabbione> no i would really like you to check what's happening in feisty first
<fabbione> we need to know if this is a toolchain bug or a build system bug
<fabbione> if feisty is affected we need to try and see how much
<fabbione> this can be a security nightmare for pitti if all of the archive is affected
<fabbione> try to imagine random binaries being statically linked
<fabbione> and we need to rebuild half of them for a security fix in lib foo
<doko> sure, but you asked for 20min, not two weeks ;-p
<fabbione> yes 20 minutes to explain the problem to you :)
* fabbione didn't mention the fallout :)
<doko> I will try to have a first look at it today
<fabbione> ok thanks
<fabbione> see 14 minutes to explain you the issue :()
<fabbione> less than 20 :P
<fabbione> doko: another thing i noticed. if that's of any help
<fabbione> the build system uses -L../path/to/local/built/libs -ldlm -lcman
<fabbione> if i instead remove those and force ../path/to/local/built/libs/libdlm.so.2.0 (and same for cman) the link is ok and dynamic
<fabbione> (force as in object to link in the final binary)
<fabbione> doko: you can reject okaratas from the team. He does attempt to join all possible teams with no answer to any query on why 
<fabbione> hey tmarble 
<doko> fabbione: ok, will do
<tmarble> hi fabbione!
<fabbione> how you doing tom?
<tmarble> insanely busy, thanks
* tmarble starting more meetings now :-/
#ubuntu-toolchain 2009-03-20
<kees> doko: so, in comparing testsuite output between Debian and Ubuntu, I notice that there some failures on Debian too, so I was going to skip those.
<doko> kees: yes, that's ok. for upstream inclusion, prepare these tests for trunk/4.4 ...
<kees> doko: okay, sounds good.  I'm worried they will ignore a lot of them that add things like "-Wno-format" to dg-options.  Any thoughts if they'll accept those kinds of things?
<kees> also, I'm curious about one part I haven't been able to sort out yet.  Part of the testsuite does not honor dg-options, so it requires a .x file, but something seems to be removing it before the test.  (I added a .x and it shows up after debian/rules patch, but not after debian/rules build)  Seen anything like that before?
<kees> and, as far as stuff that doesn't pass in Debian, this one tries to allocate an insane about of memory (and fails):
<kees> gcc.c-torture/compile/limits-blockid.c
<kees> you've swapped out.  :)
<kees> oh, nm about the ".x" file, I just figured it out.  :)  still curious about upstream attitudes.
<kees> doko: the gcc build runs the testsuite normally and with -fno-stack-protector.  the latter is breaking the ssp tests since the "no" option is overriding the dg-options.  Since there are no differences (besides ssp) between the two testsuite runs, can we just drop the -fno-stack-protect run?  (it'd speed up builds too)
<doko> kees: away now, will answer tomorrow or Monday
<kees> doko: okay
