#ubuntu-toolchain 2005-09-01 <jbailey> lamont-away: Hey, do you still maintain bsdmainutils? #ubuntu-toolchain 2005-09-03 * lamont-away grumbles at hppa/breezy's _GOT_ challenges.. <lamont-away> specifically, openexr is FTBFS, because configure trips over _GOT_ issues when checking for -lz. <lamont-away> rebuilding zlib does not fix things <fabbione> morning <elmo> infinity/lamont: I'm going to have to export/import the w-b databases <fabbione> elmo: something new coming up? <fabbione> is there anything i need to do on the sparc buildd? <elmo> no, it's just related to the jackass change of hw, and berkley db not liking being promoted ot 64-bit <elmo> (see backscroll in #c) <fabbione> ok :) <fabbione> thanks <lamont-away> elmo: ok <lamont-away> /usr/include/linux/socket.h:10: error: redefinition of 'struct sockaddr' <lamont-away> feh <lamont-away> jbailey_: if you're bored, could you look at an hppa chroot and see if you can figure out why openexr fails to build? <lamont-away> (symptom is that conftest.c, linking against glibc, gets duplicate _G_O_T_ symbol * lamont-away must run away for a while #ubuntu-toolchain 2005-09-04 <fabbione> morning <jbailey> doko, elmo: fabbiones was nudging me about the binutils update, and I think it might solve the GOT issue on HPPA (it looks very similar). Do you want me to look at it later? <doko> jbailey: sure, yes. elmo, could you place the patch somewhere? maybe we just apply it for sparc and hppa for breezy. <elmo> eww <elmo> the patch is on the mailing list <elmo> I think conditionally applying patches, esp. on a per-arch basis is satanic <jbailey> elmo: Yup, you said you were hacking on it last week - do you have a dpatch? If not, I'll throw it together. <jbailey> And we do that all the time in the toolchain. <elmo> however, I can't justify working on it during the day, not if it doesn't affect a release arch, so you guys go ahead and do what you want for breezy <elmo> jbailey: that doesn't make it right <elmo> and FWIW binutils has never done it :P <jbailey> =) <fabbione> so guys.. how many chances i have to get fixed binutils? <jbailey> fabbione: I'll extract the patch in a few hours. <jbailey> fabbione: When are you passing out tonight? <fabbione> jbailey: around 18:00 UTC <jbailey> Ah, quite early then. <jbailey> Well, hopefully by the time you wake up then. <fabbione> jbailey: well yeah.. i will have dinner at that time.. and i would love to spend sometime with my wife :) <jbailey> I understand. =) <jbailey> We need to get more of us married off so that becomes normal. ;) <fabbione> jbailey: ehehe #ubuntu-toolchain 2005-09-05 <fabbione> morning * mode/#ubuntu-toolchain [-s] by ChanServ <lamont> jbailey: any word on: /usr/include/linux/socket.h:10: error: redefinition of 'struct sockaddr' <jbailey> Arch and/or package, please? <jbailey> My brain's been a bit full lately. <elmo> jbailey/fabbione: the --as-needed stuff is a mess <jbailey> elmo: From the bit that I posted for him? <jbailey> Or do you mean in the archive? <elmo> it has a touch-all testsuite update, which depends on an earlier touch-all testsuite update which isn't easily backportable <jbailey> Right, the testsuite will suck incredibly. <jbailey> I think the best bet for Debian is a CVS update, the best for Ubuntu (hppa, sparc) is to ignore the testsuite and pray. <elmo> well, I'm leaving ubuntu up to you guys <elmo> a CVS update for Debian isn't a horrible idea actually <elmo> let's ask drow <jbailey> elmo: Where are you asking? <elmo> privmsg <elmo> old cabal habits die hard <jbailey> *lol* <fabbione> elmo/jb: i just finished to build binutils... <fabbione> but i am too tired right now to do sensible tests <fabbione> will do it tomorrow morning <jbailey> fabbione: Can you humour me and do hello world at least? <fabbione> jbailey: sure... <fabbione> what was the bug number for the binutils? <elmo> #320697: <fabbione> no .. in ubuntu <jbailey> 12822 <fabbione> there.. <fabbione> thanks <fabbione> jbailey: you know what? <fabbione> grep PROCEDURE_LINKAGE_TABLE * <fabbione> Binary file libGL.so.1.2 matches <fabbione> sparcbuildd@vultus5:~$ gcc hello.o -Wl,--as-needed /usr/lib/libGL.so.1.2 <fabbione> sparcbuildd@vultus5:~$ ./a.out <fabbione> hello world! * fabbione starts the binutils go and die dance because jbailey rocks <jbailey> Did that used to fail? <fabbione> sparcbuildd@vultus5:~$ gcc hello.o -Wl,--as-needed /usr/lib/libGL.so.1.2 <fabbione> sparcbuildd@vultus5:~$ ./a.out <fabbione> hello world! <fabbione> sparcbuildd@vultus5:~$ ldd a.out <fabbione> libc.so.6 => /lib/libc.so.6 (0x70030000) <fabbione> /lib/ld-linux.so.2 (0x70000000) <fabbione> jbailey: yeps :) <fabbione> it works.. <jbailey> And it's Modra that rocks. Glad we don't have to invalidate the archive while we're at it, though. <fabbione> and hello world comes out :) <jbailey> Have a good sleep, Fabio. =) <fabbione> yeah i am in the need of one <fabbione> i think i am getting a big flu <jbailey> fabbione: I'll confirm what to do with doko and try to get you a binutils update. <jbailey> doko: ^^^ <fabbione> jbailey: that would be cool <fabbione> at least to get main done for breezy will rock <jbailey> lamont-away: ping? <fabbione> i am running breezy atm on my buildd.. a suicide :) <jbailey> It's a good workout. <lamont> jbailey: <jbailey> Tests glibc and such nicely. <jbailey> lamont: Hey. Will you have time to test this binutils to see if it's enough love for HPPA as well? <lamont> it was building when I left the house, checking on its status now <fabbione> jbailey: btw.. i did also install an initramfs kernel on sparc... <lamont> I wish expect worked correctly <jbailey> Ah lovely. =) <fabbione> i will let you know tomorrow if it boots <jbailey> fabbione: Boots? <lamont> jbailey: once this build finishes, I'll upgrade said chroot and try building openexr, since that was the simplest failure case before <doko> jbailey: applying that for sparc and hppa conditionally? saves us the testsuite results for the other archs ... <fabbione> jbailey: i don't think we did ever test initramfs on sparc... <fabbione> jbailey: so this will be a test to do :) <jbailey> doko: Right. <lamont> jbailey: on the binutils upload, care to make it say build-depends: ... expect-tcl8.3 [hppa] , expect (>= 5.32.2-1) [!hppa] ... <jbailey> tcl8.4 sucking wind for you? <jbailey> Actually, if this fixes your problem, we'll be disabling the testsuite for hppa anyway, so it doesn't much matter. <lamont> jbailey: rather, the kernel's failure to deliver SIGCLD under some particular and unknown conditions, is. <lamont> ah, true <jbailey> And tcl8.3 solves this? * jbailey bends the voodoo dolls into contortions. <lamont> jbailey: uh, yes. <lamont> and no, I don't know why. <lamont> if I did. we could fix the kernel bug. <lamont> which is affectionately (and incorrectly) known as "the expect bug" <lamont> see the gcc-4.0 build-deps... doko was the one who figured out the hack (and created expect-tcl8.3) <jbailey> We should have a race, who gets working Signals first, the Hurd or parisc-linux? =) <lamont> jbailey: test build running now * lamont grumbles at jbailey for having the same version number for his binutils test-package version <jbailey> lamont: Sorry, I don't bump it until I'm ready to upload. This one unconditionally applies it everywhere. <lamont> right <jbailey> It's really one of those "please only add me by hand in a chroot and you should have to think reasonably hard about doing this" <lamont> otoh, making it -3ubuntu1.0 would be a clue... <lamont> heh * jbailey lkes "are you sure?" prompts that aren't easy to answer reflexively. =) <lamont> jbailey: SCORE!!!! <lamont> checking for strerror... yes <lamont> checking for compress in -lz... yes <lamont> checking for ios_base support in C++ standard library... yes <jbailey> lamont: Izgood? <lamont> sim <jbailey> doko: Awake? <jbailey> doko: It seems sparc and hppa both appreciate this binutils better than a swift kick in the teeth. <jbailey> doko: So I'd like your final blessing to upload with this patch only applying for hppa and sparc, and with the testsuite disabled on those archs. <doko> jbailey: sounds fine. <doko> maybe after the release we should change the name from binutils-static to ld-static <jbailey> I named it that in case it needed to grow more than just ld. <doko> then let's watch how it grows in breezy+1 :-) <lamont> so then. jbailey: yes, I'm happy with the new binutils <lamont> jbailey: how soon should I expect an upload? <jbailey> I'm trying to decide if I want to pick a quote for the top of the changelog file... <jbailey> Feh, my mind is blanking on how to do ifneq ($(DEB_HOST_ARCH),sparc) or ifneq ($(DEB_HOST_ARCH),hppa) <jbailey> Do I have to nest them? <jbailey> Solved a different way. <jbailey> elmo: Around? <lamont> ifeq ($(arch),$(findstring $(arch),hppa sparc)) <jbailey> lamont: What's the best way to bootstrap a breezy chroot these days for hppa from a running sid system? <lamont> I _think_ you can just debootstrap it... but no. <lamont> libgcc2 isn't in main, so life sucks <jbailey> Well, the ubuntu debootstrap scripts aren't in Debian, are they? <lamont> debootstrap hoary from people.ubuntu.com/~lamont/ubuntu-hppa/tree and then dist-upgrade <jbailey> libgcc2? =( <jbailey> You have an abi event with libgcc? <jbailey> s/have/had/ <lamont> well, doko did. <lamont> http://people.ubuntu.com/~lamont/hoary.buildd <lamont> debootstrap with that script <jbailey> When this is done, can I just dist-upgrade off of archive.ubuntu.com? <lamont> no. ports.ubuntu.com <lamont> deb ports.ubuntu.com/ubuntu-ports breezy main restricted .... <lamont> deb-src archive.ubuntu.com/ubuntu breezy main restricted .... <lamont> hppa-hacks/expect-tcl8.3-dev_5.43.0-2_hppa.deb <lamont> hppa-hacks/expect-tcl8.3_5.43.0-2_hppa.deb <lamont> hppa-hacks/expectk-tk8.3_5.43.0-2_hppa.deb <lamont> hppa-hacks/gcc-3.4-hppa64_3.4.4-5ubuntu1_hppa.deb <lamont> hppa-hacks/libgcc2_4.0.1-4ubuntu4_hppa.deb <lamont> hppa-hacks/palo_1.9_hppa.deb <lamont> that's what I have in a local repository which sources.list.main includes <jbailey> Err.. <lamont> those are copies/symlinks to the universe packages <jbailey> Okay, so if I add universe, will I be fine? <lamont> right <jbailey> Oh good. =) <jbailey> Aside from the kernel not booting, is ia64 releasing with Breezy? <lamont> note that if you have universe debs in sources.list, and you build a main package, you may get incorrectly-satisfied build-depends... <lamont> ia64 is tracking breezy nicely <jbailey> Right. At this point I just want to make sure that the binutils package actually applies the patch on hppa correctly. <lamont> except for that little kernel issue <jbailey> The testsuite disabling I've tested. <lamont> ok <jbailey> Hmm. debootstrap seems stuck on I: Checking component main on http://people.ubuntu.com/~lamont/ubuntu-hppa/tree... <lamont> it should be happy... <lamont> you told it hoary, yes <lamont> ? <jbailey> debootstrap --variant=buildd hoary hoary http://people.ubuntu.com/~lamont/ubuntu-hppa/tree <jbailey> And I updated the hoary.buildd from the location you have. <jbailey> s/have/game/ <jbailey> GAVE <jbailey> DAMMIT <jbailey> ROAR <jbailey> don't mind me. <lamont> lol * lamont builds a tarball for jbailey <jbailey> Oh, it's done something useful. <jbailey> How nice of it. <elmo> jbailey: ? <jbailey> You don't have lvm2 or klibc-utils on hppa yet? =( <jbailey> hmm <jbailey> elmo: I've added some stuff to make it possible to specify per-arch which ones should disable the testsuite, and also to make it honour DEB_BUILD_OPTIONS=nocheck <jbailey> elmo: I'd like you to consider these for Debian as well. Will you take a look at the Ubuntu packae that I upload, or do you need a patch in the BTS? <elmo> jbailey: azeem made a patch for the latter already which is in the BTS <elmo> I'm sort of disinclined to make it easy to disable the test suite per-arch, but I'll see what it looks like <elmo> vorlon + drow approved binutils cvs for sid, btw <jbailey> Well, I wrapped the testsuite stuff in ifeq ($(CHECK),), and at the top I set CHECK based on DEB_BUILD_OPTIONS <jbailey> the sideeffect is that you can trivial define CHECK whenever you'd like for other reasons. <jbailey> cool on the cvs binutils for sid. <jbailey> It'll be nice to get this cleaned up everywhere. <jbailey> lamont, elmo: While you're both hereish, any luck on hppa build logs? #ubuntu-toolchain 2005-09-06 * jbailey listens to the crickets. =) * lamont notes that rookery has no buildd.ubuntu.com entry in /etc/apache2/sites-enabled <lamont> jbailey: wget http://people.ubuntu.com/~lamont/breezy.tar.gz (all 111MB of it...) That's breezy,albeit with sources.list* that need to be edited. <lamont> (hppa, buildd chroot) <lamont> and way out of date, fwiw <jbailey> Will it include whatever the lvm2 and klibc failures are? <jbailey> It would be really nice to install ubuntu-minimal in this chroot. =) <lamont> that's a chroot, not logfiles <lamont> that chroot is (supposed to be) essential+build-essential <jbailey> Ah. =) <jbailey> woohoo, it looks like it included the patch for hppa and sparc correctly on the hppa build. <lamont> does that mean it'll get uploaded shortly? <jbailey> I'm just checking to make sure that the testsuite doesn't get run. <jbailey> ISTR j5k being a bit speedier than this. <jbailey> But that might have been ccache love. =( <jbailey> lamont: Aside from that, it's all packaged up and waiting for me to sign/put it. <lamont> heh <lamont> avg build time is ~90 minutes <jbailey> Thanks for the hint. It won't tkae that long. <jbailey> The testsuite is supposed to run midway through the build. <jbailey> Although, I guess I should let it finish the whole way to make sure that it doesn't copy the testresults somewhere unconditionally. <elmo> LARGE AND IN CHARGE. BREEZY-AUTOTEST IS BACK. <jbailey> Uh oh, James has been drinking and hacking again.... <jbailey> ;) <fabbione> morning <jbailey> Heya Fabio <fabbione> hey jb <jbailey> fabbione: Any last things before I go pass out? <fabbione> jbailey: no.. i am still working to recover my box <fabbione> good night dude :) <fabbione> the damage is really really really weird <jbailey> =( <jbailey> Good luck with it. <fabbione> thanks <jbailey> tomorrow is glibc hacking day. =) <fabbione> ehhe <fabbione> time to fix the ipv6 resolver? <jbailey> Probably not before preview freeze, but right after it, yeah. <fabbione> ok <jbailey> Or rather, during it, and I'll get you to test it. Commit after preview freeze. <fabbione> yeah that's an easy thing to test <jbailey> I don't have a proper v6 setup here, so it's too hard for me to feel safe with it. <fabbione> sure.. <fabbione> no problem at all * lamont-away wonders who uploaded the debian binutils <lamont-away> gnbd_monitor.c:575: warning: missing sentinel in function call <lamont-away> wth is a sentinel in this context? * jbailey does the 'summon doko' dance. * lamont notes that libgcj6-dev is b0rked. <lamont> (undeclared Depends: libglitz1-dev, although a rebuild should make the Dep go away) #ubuntu-toolchain 2005-09-07 <lamont-away> doko: any words on "internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101"?? <jbailey> lamont-away: What arch, which gcc? <infinity> lamont-away : Fixed in 4.1, apparently, no one's backported a patch. <doko> lamont-away: reported upstream as PR21123 <infinity> Or is that "will be fixed in 4.1"? <lamont-away> yeah - found the kde/debian page <jbailey> doko /query doko <lamont-away> http://lists.debian.org/debian-devel-announce/2005/09/msg00000.html <jbailey> Feh <lamont-away> jbailey: what if he doesn't want to talk to himself??? <doko> jbailey: ? <jbailey> lamont-away: I've never met a computer geek that didn't talk to himself. =) <lamont-away> dude - that's the _COMPUTER_ we're talking to!!! <lamont-away> well, if there's a computer around, that is. <lamont-away> doko: btw, any plans for a gcc-4.0 upload soonish, before I upload my no-change upload for glitz? <doko> lamont-away: I don't plan any 4.0 uploads for breezy at the moment <lamont-away> ok <lamont-away> I'll work through getting approval and upload it <jbailey> doko: I was chatting with pinskia in #gcj yesterady. It sounds like the 4.1 Java stuff contains a few nice bits <doko> jbailey: yes, there are some improvements, although it still the same compiler, not the rewrite by tromey <jbailey> Ah, too bad. <jbailey> Getting the generics bits in there would've been nice. <jbailey> He also mentioned that for the rest of the compiler at this point there's only 100 regressions vs. 4.0 right now. <jbailey> Handy chatting with the bugmaster. =) <doko> yes, on top to the 200 regressions in 4.0 from earlier versions :-) <jbailey> Mmm, aren't those all versus 2.95? <jbailey> Noone thinks that far back. 4.0 versus 3.3 is a bit of a dream. =) <doko> hmm, I don't know the exact numbers, splitted up for different versions ... <elmo> doko: ? <doko> yep <elmo> doko: -ECHAN, see #u-d <lamont> gcc-4.0 uploaded to fix glitz crap #ubuntu-toolchain 2005-09-08 <infinity> jbailey : (from the gcc-4.0/amd64 build log) lib32z1-dev: Depends: libc6-dev-i386 but it is not installable <infinity> jbailey : This clearly seems Not Good. <doko> infinity: fixed in zlib_1.2.3-3ubuntu4 <infinity> doko : Danke. #ubuntu-toolchain 2005-09-09 <lamont-away> and hppa gets a second buildd. <lamont> doko: gdc_py.c:30:20: error: Python.h: No such file or directory <lamont> gdc_py.c:31:23: error: cStringIO.h: No such file or directory <lamont> please fix python-gdchart_0.6.1-9ubuntu1 * lamont double checks to make sure that's really a breezy-autotest error <lamont> yep. iz ftbfs everywhere <doko> $ apt-cache show python-gdchart <doko> Package: python-gdchart <doko> Priority: optional <doko> Section: python <doko> Installed-Size: 136 <doko> Maintainer: Jonas Smedegaard <lauren32@example.com> <doko> Architecture: amd64 <doko> Version: 0.6.1-8ubuntu2 <lamont> 0.6.1-9ubuntu1 is the current source in the archive, and it's ftbfs <lamont> and /me isn't sure what depends to drop on what... <lamont> hrm.. actually, looks like adding python2.4-dev should fix it <lamont> but I really need to sleep <lamont> and actually, it probably doesn't meet criteria for upload until after preview-freeze lifts #ubuntu-toolchain 2005-09-10 <lamont-away> dpkg-deb: building package `lib32gcc1' in `../lib32gcc1_4.0.1-4ubuntu1+ia32.libs.1.4ubuntu1_ia64.deb'. <lamont-away> dpkg-deb: failed to open package info file `debian/lib32z1/DEBIAN/control' for reading: No such file or directory <lamont-away> dh_builddeb: command returned error code 512 <lamont-away> you guys broke ia64! shame on you <lamont-away> hrm.. I wonder if I just requested biarch support on ia64..... #ubuntu-toolchain 2005-09-11 <fabbione> morning #ubuntu-toolchain 2005-09-12 <fabbione> morning * netjoined: irc.freenode.net -> kornbluth.freenode.net #ubuntu-toolchain 2005-09-13 <lamont> jbailey: doko: one of you want to take a look at http://people.ubuntu.com/~lamont/buildLogs/h/haddock/0.6-2ubuntu1/haddock_0.6-2ubuntu1_20050907-2011-powerpc-failed.gz and then figure out what the right fix to haddock is so that it'll build correctly on ppc64... <lamont> for test-building, you'll need: deb http://people.ubuntu.com/~lamont/ghc6 / <doko> morning <doko> lamont: do we support ppc64? <lamont> doko: that's the issue... we're running a 64-bit kernel on the buildd's, and 32-bit user space. <lamont> hence the build failure. <lamont> what we really want to know is whether the userspace is 32 or 64, and say the right thing accordingly. <lamont> right now, it assumes that kernel-size == userspace-size <fabbione> morning guys <lamont> morning fabbione <doko> lamont: ok, will look <doko> lamont-away, jbailey, infinity: I can only reproduce this, if the chroot is started without linux32. maybe a buildd problem? <lamont-away> doko_: it's possible that I trashed his change... <lamont-away> sigh <lamont-away> but I didn't think I had. <lamont-away> I'll see about fixing that in a short bit - gotta get ready and head officewards shortly <lamont> doko: I figured out my ppc64 issue... PEBKAC. <doko> anyway, I did send you my guess: linux32 forgotten?) <lamont> PEBKAC == "problem exists between keyboard and chair" <lamont> and yes, it's precisely because I said 'sbuild ...' instead of 'linux32 sbuild ...' <lamont> while manually bootstrapping <doko> :) #ubuntu-toolchain 2005-09-14 <fabbione> morning guys #ubuntu-toolchain 2005-09-17 <elmo> lamont/infinity: any objections to a b-at rerun, all components? <lamont> elmo: sounds good to me. * lamont removes his old breezy-autotest logs <jbailey> Anyone know if ben's going to be around today? #ubuntu-toolchain 2005-09-18 <infinity> elmo : I have no objections to it, in fact, I sent dholbach your way. <jbailey> w/in 4 <elmo> GRR <elmo> lamont/infinity: royal's chroot is ghc-fux0red #ubuntu-toolchain 2005-09-19 <lamont> uh - where did binutils-hppa64 go? and what does gcc-3.4 plan to do about it? <lamont> doko/jbailey/elmo: ^^^ <jbailey> Err, it was there last I looked. <jbailey> Can youtell when it dissapeared? <lamont> my brainfart <lamont> must lauren32@example.com, not archive.u.c <jbailey> =) <lamont> doko: gcc-3.4: logwatch never terminates, so the build hangs (outside of timeouts...) would be interesting to hear your thoughts on that.... <doko> breezy or unstable ? <fabbione> lamont: i have seen that happening too once in a while <fabbione> on sparc breezy <fabbione> it disappeared on its own <doko> I don't know how to make that disappear, the trap on exit is removed from the logwatch script. #ubuntu-toolchain 2005-09-21 <lamont> jbailey: klibc failure with linux32 in the mix. kthxbye <lamont> http://buildd.mmjgroup.com/buildLogs/k/klibc/1.0.14-1ubuntu2/klibc_1.0.14-1ubuntu2_20050916-0830-hppa-failed.gz <lamont> linux32 /usr/share/misc/config.guess <lamont> hppa64-unknown-linux-gnu <lamont> linux32 uname -m <lamont> parisc64 <jbailey> lamont: Luvly, thanks. I'll look at it on j5k. <jbailey> Hopefully it's up today. <lamont> jbailey: trivial fix * lamont tests <lamont> jbailey: email sent #ubuntu-toolchain 2005-09-22 <infinity> lamont : Feh, if 'linux32 uname -m' on parisc64 is returning parisc64, not parisc, then parisc64 personalities are broken. I was almost sure that had been addressed long ago, but maybe not (I never owned a parisc64 machine, so this was all from memory) <infinity> My parisc machine was a lowly 32-bit C200. <infinity> lamont : Pretty please, with sugar on top, pester linux-parisc upstream to fix 32/64 kernel personalities, push the patch upstream, and use that patch on your buildd. :) <lamont> infinity: parisc _ALWAYS_ returns parisc64 <lamont> always has (on a 64-bit kernel_) <infinity> No it doesn't. Only when running a parisc64 kernel. <lamont> that's what I said. :-) <infinity> Anyhow, it's broken. It shouldn't. That's what personalities are for (it's ALL they're for) <infinity> We just got it fixed for ppc/ppc64 in 2.6.12, now it's your turn. :) <lamont> yeah - jbailey's going to beat on the parisc folks, but in the mean time, we'll just do the hack to klibc that has been done everywhere else <infinity> <nod> <infinity> I assume you had line-of-sight (and perhaps line-of-office-supply-tossing) with some parisc kernel guys. <infinity> s/assume/assumed/ <lamont> well... certainly when I have a mirror... <lamont> but the issue here is talking to the folks that did the implementation, and figuring out what it really should be saying when. <infinity> If so, tell them to search lkml for ppc64 and uname over the last 4 or 5 months. Should tell them what to fix. :) <lamont> and it's not something to change right now... <infinity> (I could provide a patch, but have no way to test anything) <lamont> esp since we can't build/install the new (fixed) ubuntu kernel until we have a working klibc... * infinity wonders idly if this is also broken on s390/s390x.. <lamont> jbailey wondered the same thing, and ran away screaming at 31-bit worlds <lamont> or something like taht <infinity> I think arm/arm64 is okay. <infinity> Yeah, I don't think s390 would bother with a "linux31" binary, they'd just pretend to be 32-bit and carry on. :) <jbailey> infinity: The fix is almost tribial, but not quite. <jbailey> infinity: They use the personality to change how they handle signals internally. <jbailey> It's almost certainly not what they meant. <infinity> Oh, FUN. <jbailey> I think I have it mapped out as to what needs to change. <jbailey> I'm going to sleep on it and do it then. I have klibc for lamont already. <jbailey> Just need to hand it to fabio, and then I think that's done for breezy. <jbailey> (unless someone comes up with another !@#$ing filesystem they want to use as a root one) * lamont mutters about big kernel changes right before release... <infinity> Well, there's no docs (afaik) saying you can't extend the use of personalities to do other neat hacks/tricks, just what they SHOULD do (fool userspace into believing you're on a 32/64 bit kernel when you're not) <lamont> oh, klibc, not the kernel. <lamont> nm <jbailey> infinity: What they've done in this case is assume that a 32 bit binary means you want a 32 bit personality. <jbailey> infinity: I think. I'm having trouble tracing some of this code. =) <infinity> That's possibly reasonable. * lamont waits for his 2.4-kernel-possessing knoppix 3.7 ISO to burn, then he's gonna reboot and head home <jbailey> It's not how sparc and ppc do it. <infinity> But they're still not munging uname output, which is the issue. <infinity> No, it's not what sparc and ppc do in the slightest, but it seems a valid extension to the use of personalities. <jbailey> sparc and ppc set a threadinfo variable with the info. <jbailey> Which frightens me to think that they might have PER THREAD shit^Wstuff going on. <infinity> I suppose this is where I start being greatful that Motorola never announced a 68k-64 CPU. <jbailey> infinity: Probably. a 4 mhz 64 bit CPU would really suck for data loads. <lamont> hehe <infinity> <grin> <lamont> 64-bit 8051 <jbailey> I still like the idea of just runnign the whole m68k buildd in a nice emulated environment on a large ia64 machine. <infinity> Hey, if they opened up the specs, any goober with access to fab flipchips could get the 68060 scaled ridiculously high, I'm sure. <infinity> It's just that Motorola never upgraded their fabrication, ever. New ones are still the old ceramic things you can clock peopl ein the head with. <jbailey> Why should they, really? If you wanted a small 32 bit chip, the i386 is good enough. <jbailey> Last I checked they were still producing those by the assload. <infinity> <nod> <infinity> Well, Motorola still produces 68k stuff by the assload too, just not the desktop chips. <jbailey> YEah, they still have the embedded medical market. <infinity> The more popular all-in-one stuff with fancy multimedia controllers and such (but, oddly, no MMU) are in high production still. <lamont> well, I'm off <jbailey> g'n LaMont <infinity> Later. <jbailey> infinity: The other reason in particular that magic isn't a good idea is that it means that all 32 bit binaries would always report parisc from newuname <infinity> Yes, including a 32-bit 'linux64' binary. <infinity> That would definitely seem wrong. * lamont-away grumbles at doko for uploading gcc-3.3 without switching hppa to expect-tcl8.3 <doko> laon-taway, ohh, yes, something I forgot ... is it a FTBFS? <doko> lamont-away: ^^^ <lamont-away> doko: well, I can babysit it through, but yeah <doko> lamont-away: no need, m68k died, so I have to reupload #ubuntu-toolchain 2006-09-01 <leoncamel_> hi, folks. how can I install gcc-3.2 into Ubuntu 5.10 ? #ubuntu-toolchain 2006-09-09 <theCore> what is the first program in Ubuntu's toolchain? <Keybuk> the general definition of a toolchain is there isn't a "first" program :p <theCore> oh <theCore> gcc, glibc, binutils? <Keybuk> e.g. gcc is written in C, so needs gcc <Keybuk> and uses make to be built, which is written in C, so needs gcc <Keybuk> and both use glibc, which is written in C and uses make, so needs both <theCore> I see <theCore> I just building a quiz, for #ubuntu-trivia, I thought it could be a good question <theCore> do you know any hard questions? <Keybuk> what kind of questions are you thinking of? <theCore> one-liners <Keybuk> there's fun Ubuntu trivia <Keybuk> "Which Ubuntu core developer originally wrote dpkg?" <theCore> lol <Keybuk> or more fun <Keybuk> "How many Ubuntu core developers have been, or currently are, maintainers of dpkg or apt?" <theCore> thanks, I save this one for the quiz <Keybuk> I think of bad ones though :-/ <Keybuk> "In total, how many laptops have been stolen during Ubuntu conferences?" <theCore> shoot :) <Keybuk> it's probably about 10 so far <theCore> that's nasty <theCore> it will be the third quiz I do today, I'm losing inspiration... <theCore> s/losing/short of/ <Keybuk> that's a lot of quizzes <theCore> 25 questions each <Keybuk> I've never even heard of #ubuntu-trivia :p <Keybuk> I'm curious now, what was the last quiz you did? :p <theCore> an hour ago <theCore> the log are at http://peadrop.com/trivia/ <Keybuk> <theCore> 20. Write a regex that parse phone-numbers. <Keybuk> heh <Keybuk> .+ <theCore> hehe <Keybuk> <theCore> 21. What is the standard treading library for Linux? <Keybuk> not pthreads <Keybuk> (technically) <theCore> bthread? <Keybuk> Native Posive Threading Library would be the correct answer <Keybuk> gah, POSIX :p <theCore> ah <Keybuk> previously it was LinuxThreads <Keybuk> both happen to implement the pthread_* functions, of course <theCore> I'm giving a quiz now <theCore> 1. Complete the description: Upstart is an <??>-based replacement for <??> <theCore> hehe <Keybuk> alchohol ... life <theCore> lol <Keybuk> heh at Mark's FAQ <Keybuk> he's actually ommitted the real reason that "breezy badger" is so named <Keybuk> oh, no, he vaguely has <Keybuk> "Our naming scheme is stupid, what's next? Bendy Badger?!" <Keybuk> "I LIKE IT!" <Keybuk> mdz nearly killed me <theCore> rofl! <theCore> Keybuk: just a random question: does Python has first-class functions? <Keybuk> no idea <Keybuk> I've never really understood what that means :p <theCore> Which Ubuntu core developer originally wrote dpkg? <theCore> who is it <theCore> it isn't you Keybuk? <theCore> Ian Jackson? <Keybuk> no <Keybuk> iwj <Keybuk> yeah <theCore> you maintained dpkg, isn't it? <Keybuk> yes, as did Ben Collins <theCore> did all Ubuntu core-dev maintained dpkg? <Keybuk> no #ubuntu-toolchain 2006-09-15 * Starting logfile irclogs/ubuntu-toolchain.log <fabbione> score <fabbione> gcc in edgy miscompiles silo <fabbione> both 4.0 and 4.1 <fabbione> doko_: so.. what do you need to debug this one? <doko_> does it work with -O0 or -O1? <fabbione> getting there.. it takes ages to reboot the NIagara <fabbione> it seems to be niagara specifc the problem <fabbione> the netra boots fine <fabbione> but the code is exactly the same <fabbione> we are building with -Os <fabbione> want me to switch to -O0 ? <infinity> Try 0, 1, and 2. <infinity> Could try 2 first, since the difference between 2 and s aren't many, and the problematic optimisations in that variance tend to be known. <fabbione> gcc-4.1 -m32 -fno-stack-protector -O2 -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing -DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 bin2h.c -o bin2h <fabbione> which one wins here? <infinity> The last one, I think. Not positive, though. <fabbione> ok.. got rid of -Os <infinity> (base)adconrad@cthulhu:~$ gcc -O2 -o hello2 hello.c <infinity> (base)adconrad@cthulhu:~$ gcc -Os -o hellos hello.c <infinity> (base)adconrad@cthulhu:~$ gcc -O2 -Os -o hello2s hello.c <infinity> -rwxr-xr-x 1 adconrad adconrad 7786 2006-09-15 18:40 hello2 <infinity> -rwxr-xr-x 1 adconrad adconrad 7754 2006-09-15 18:40 hello2s <infinity> -rwxr-xr-x 1 adconrad adconrad 7754 2006-09-15 18:40 hellos <infinity> So, the last one wins. <fabbione> no.. i win.. i removed -Os :) <infinity> ;) <fabbione> -O2 -> no win <fabbione> doko_: what was the last thing you read? <doko_> just my sugestion to build with -O0 and/or -O1 <fabbione> -01 booting now <fabbione> or better.. trying no <fabbione> +w <fabbione> -O1 -> no win <fabbione> -O0 -> no win <fabbione> so what's next? <infinity> Assume it's not miscompilation, but rather incorrect code that was relying on an old GCC bug? <doko_> do I understand it right, that the "hello" testcase is self-contained? <infinity> Hrm? hello.c was just a printf. <fabbione> infinity: on both gcc-4.0 and 4.1? unlikely <fabbione> infinity: and it works on one sparc but not another <fabbione> note that i am building the same code as in dapper and it was working on both <fabbione> so there is no code change in the middle <fabbione> only the compiler <fabbione> and that part is pure asm <fabbione> written by davem ... <infinity> If it's pure asm, then perhaps you're barking up the wrong tree here and you have a binutils bug. <fabbione> hmm that's something to try <fabbione> as soon as this mofo boots up <fabbione> no luck downgrading binutils <fabbione> so what is next guys? <bluefoxicy> doko_: ping? <doko_> what's up? <bluefoxicy> did you get my e-mail? <bluefoxicy> (about potential global toolchain settings for Edgy+1) <doko_> we usually prepare the toolchain before we open the archive for the next release. If you do have tested patches for new things, then you should have them prepared now. everything else should go into edgy+2 <bluefoxicy> Edgy+1 is not open yet is it? <bluefoxicy> The patches I was primarily looking at are actually in Binutils CVS now <bluefoxicy> (since some time around Jul 10 actually) <bluefoxicy> http://sourceware.org/ml/libc-alpha/2006-06/msg00095.html <-- there's the announcement and patches <doko_> we usually don't use unreleased versions. If you would like to see some feature in edgy, please provide the patches as debdiffs, tested for more than one platform <bluefoxicy> Edgy+1, not edgy. Any idea where I can find the version planned for use to check if it made it down from CVS yet? <bluefoxicy> I was hoping to discuss with you, infinity, and mdz at some point.. when's a good time? You're probably all busy as hell preparing for edgy release (next month?) <bluefoxicy> ok, it's in 156.14.161.142.3 at ftp://ftp.kernel.org/pub/linux/devel/binutils/binutils-156.14.161.142.3.tar.bz2 .... It seems it's not in a released glibc (glibc has a patch that makes it use the DT_GNU_HASH during dynamic linking) <bluefoxicy> but i don't know if Ubuntu uses the .50 releases or just the straight 2.16 2.17 etc line <bluefoxicy> it looks like it's in .50.0.1 too <bluefoxicy> either way Jelnek doesn't stick his changes in the ChangeLog because he's a brat :| <doko_> the .50 releases are unsupported versions release by H.J. Lu. Again, if you do want to see it, post the debdiff's. <bluefoxicy> Alright, yeah, I wasn't sure. <bluefoxicy> that means i have to figure out how to make a debdiff... maintainer's guide probably has that <bluefoxicy> <-- noob <bluefoxicy> I have other things to do here, I'll come back to this in a couple days. #ubuntu-toolchain 2006-09-18 <fabbione> doko_: i just started a new OOo build on faure with newer libc <doko_> how far did it go? <fabbione> i just started.. <fabbione> it still hangs in the same place <fabbione> i need food now #ubuntu-toolchain 2006-09-20 <fabbione> doko_: ping? <tmarble> hello <doko_> fabbione: pong <fabbione> doko_: hey dude.. <doko_> tmarble: good morning <fabbione> i am told that you got access to the Niagara boxes ( or box ) at the datacenter <fabbione> doko_: do you think you can look into that linking problem Nikolai is having? <fabbione> i remember i did fix the exact same problem installing lib64stdc++ and rebuilding a C++ apps <fabbione> but the same doesn't help with that C code snippet <doko_> hmm, I think, I don't got a key/login yet. I'll ask jbailey <doko_> which linking problem? <tmarble> doko_: that would help us immensely <tmarble> doko_, i need to file the bug... has to do with linking <fabbione> doko_: the one that Tom did mail to us <fabbione> doko_: login has been sent to you about 2 weeks ago <doko_> hmm, I'll look at it, recovering my email currently <tmarble> doko_ my e-mail to you and fabbione of 9/7 titled "[Fwd: Re: minor trouble with Niagara and Ubuntu] " <tmarble> shall I resend? <fabbione> doko_: i did try but with no luck.. <doko_> no, I have the emails on the server <fabbione> doko_: so help there is appreciated. i am sure it's not a libc6 issue #ubuntu-toolchain 2007-09-01 <arthur-> doko: http://people.dunnewind.net/arthur/doko/ <doko> arthur-: why did you build with -sa? <arthur-> doko: I didn't, I've included it by hand <doko> why? <doko> arthur-: and please file a sync request <arthur-> doko: don't really, sorry if it was a mistake <doko> np, do it better the next time. you don't need to include the source again if it's already in the archive <arthur-> ok :-) <arthur-> doko: here is the sync request: https://bugs.launchpad.net/ubuntu/+source/gdc-4.1/+bug/136578 <arthur-> doko: my sponsor can ACK it if you have no time <doko> arthur-: you need to mention that the ubuntu changes can be overwritten (if you have checked that) <arthur-> "Previous merge don't bring any Ubuntu change to gdc-4.1." <arthur-> doko: this was likely a "fakemerge" right? :-) <arthur-> the -15ubuntu1 upload <doko> yes <arthur-> doko: shall I join the orig for an upload in experimental if the orig is in unstable? <doko> no <arthur-> ok, thanks <doko> arthur-: you need to mention in the bug report, why the ubuntu changes can be dropped <arthur-> wget -O /dev/stdout -q http://patches.ubuntu.com/g/gdc-4.1/gdc-4.1_0.23-4.1.2-15ubuntu2.patch | grep ^diff | grep -v changelog <arthur-> diff -pruN 0.23-4.1.2-15/debian/control 0.23-4.1.2-15ubuntu2/debian/control <arthur-> diff -pruN 0.23-4.1.2-15/debian/lib32gcj7-dev.overrides 0.23-4.1.2-15ubuntu2/debian/lib32gcj7-dev.overrides <arthur-> diff -pruN 0.23-4.1.2-15/debian/README.Debian 0.23-4.1.2-15ubuntu2/debian/README.Debian <arthur-> diff -pruN 0.23-4.1.2-15/debian/rules.parameters 0.23-4.1.2-15ubuntu2/debian/rules.parameters <arthur-> doko: ok <arthur-> doko: done, have to go. <arthur-> doko: http://paste.dunnewind.net/367 don't think I forgot something <arthur-> doko: I'm not sure at all of what I've dont with control.m4, have to test :-) <arthur-> hum <arthur-> forgot the gdc package in control.m4... <arthur-> doko: http://paste.dunnewind.net/368 <doko> arthur-: look, but it's not against the current svn <arthur-> Actualis la rvision 2430. <arthur-> damn <arthur-> doko: http://paste.dunnewind.net/369 <doko> else ifeq ($(PKGSOURCE),gdc-4.1) <doko> gcc-4.2-source (>= 4.2.2) <arthur-> fixed <doko> and the gcc-d-lang.dpatch is missing (please check that it applies in a gcc-4.2 build) <doko> the other things look ok <arthur-> ok <arthur-> doko: http://paste.dunnewind.net/370 testing build right now <doko> arthur-: please send it by email, something is wrong with the paste <arthur-> doko: sure <arthur-> doko: and hum, I'm sure you noticed that, but: http://packages.qa.debian.org/g/gcc-snapshot.html <doko> shit happens <arthur-> sent <arthur-> doko: have you failed a script or something? #ubuntu-toolchain 2007-09-02 <arthur-> doko: cc1: internal compiler error: no multiarch mapping for multilib (32) <arthur-> doko: building gcc-4.1 on sparc <arthur-> (gdc-502.619.2016~exp) <doko> arthur-: debian/rules2 : s/v9/v8/, or update the svn <arthur-> ok, thanks <arthur-> doko: D ping <doko> ? <arthur-> doko: can I upload something like this in experimental? http://people.dunnewind.net/arthur/doko/ <arthur-> (won't include orig tarball this time don't worry) <arthur-> merge from Unstable package, just add a patch to fix build <doko> hmm, I wouldn't use `+ in the release (that's something reserved for binNMUs), plus adding something differentiate your uploads to experimental: -16exp1 <arthur-> doko: ok, I build a -16exp1, I've found an amd64 so I prepare an upload for i386/amd64/powerpc/sparc <arthur-> doko: can gdc be called (description) the "The GNU D compiler" since it uses gcc in middle-end and back-end ? <doko> arthur-: hmm, is the FSF copyright holder? <arthur-> doko: no <arthur-> doko: david Friedman (gdc) and Walter Bright (dmd, digitalmars) <doko> so maybe not <arthur-> I perhaps should ask on the gcc ml <doko> hmm, maybe not, use the name from the upstream project? <arthur-> dmd? yes, gdc uses dmd in font-end <doko> but who does hold the copyright? (I do not mean the authors) <arthur-> Copyright (C) 2004 David Friedman <arthur-> Copyright (c) 1999-2006 by Digital Mars <doko> usually the FSF holds the copyright for GNU software, so I wouldn't name it "GNU D" <arthur-> I wondered, moreover upstream gcc already recognize D, hold on <arthur-> doko: http://people.dunnewind.net/arthur/doko/ <arthur-> doko: gcc/dwarf2.h: DW_LANG_D = 0x0013, <arthur-> doko: gdc builds fine with gcc-4.0, it would perhaps be useful to build a gdc-4.0 package <doko> arthur-: NO! we want to KILL 4.0, not keep it <arthur-> doko: ok =) <arthur-> doko: here will be my changes for -17 http://paste.dunnewind.net/373 (I'll also include them in 4.2 in 4.3 once I would have finish to test it) <doko> arthur-: please send diffs by email <arthur-> doko: just done about 1 sec ago :-) <arthur-> doko: give --disable-proc-maps to libphobos configure should build fix at least on kfreebsd-{i386,amd64} , but how to give it explicitly to libphobos configure? il Makefile.def ? <doko> it should be propageted from the toplevel configure #ubuntu-toolchain 2007-09-03 <arthur-> doko_: dpkg-deb: building package `gdc-4.1' in `../gdc-4.1_0.24-4.1.2-16exp1_kfreebsd-amd64.deb'. <arthur-> doko_: should be ported on k*bsd*-gnu now =) <arthur-> aloiret@asdfasdf:~/gdc-4.1/gdc-4.1-0.24-4.1.2/debian/gdc-4.1$ ./test <arthur-> Hello from kfreebsd-amd64! <doko> lamont, lamont`: how dies java work on hppa <doko> s/dies/does/ ;) <doko> if it does, please build a gcc-snapshot for the archive <arthur-> doko: can I give you tomorrow a patch for gdc/sparc so you test build + a sample D prog? <arthur-> since I don't have access to the sparc anymore <doko> arthur-: maybe not before the weekend <arthur-> doko: ok #ubuntu-toolchain 2007-09-06 <doko> lamont, lamont`: hppa gcj ping <lamont> doko: yes? <lamont> any happy news from the config.guess world? <doko> lamont: can you build ecj/gjdoc now, and on which machines? <lamont> interestingly, debian's hppa buildds are both A500s running 64-bit, and ubuntu's are both Jxxxx machines running 32-bit kernels... <lamont> now as in when did you last upload something new? <doko> lamont: currently I upload hppa binaries <lamont> gjdoc 0.7.8-1 built successfully onhppa's buildd. 0.7.8-2 did not <lamont> ecj hasn't built on debian's buildd since 3.2.2-2 <doko> lamont: could you just test build those and discard the resulting binaries? do the gutsy builds succeed? <lamont> pretty sure I did that already... will do it again right now <lamont> Exception in thread "main" java.lang.IncompatibleClassChangeError <lamont> at org.eclipse.jdt.internal.compiler.impl.CompilerOptions.getMap(CompilerOptions.java:418) <lamont> there's ecj <lamont> checking if uudecode can decode base 64 file... yes <lamont> checking if gij-4.2 works... configure: error: The Java VM gij-4.2 failed (see config.log, check the CLASSPATH?) <lamont> make: *** [config.status] Error 1 <lamont> and gcj <lamont> gjdoc-0.7.8/config.guess <lamont> hppa2.0-unknown-linux-gnu <lamont> I wonder if that's related... <lamont> doko: you were going to check on when/who added the {2.0,1.1} to config.gues <lamont> s <doko> lamont: see my post to parisc-linux, it's unlikely to be changed, but I'll update gjdoc <lamont> ok * lamont goes afk for about an hour #ubuntu-toolchain 2007-09-07 <lamont> doko: any clues on java/hppa stuff? <doko> lamont: sorry, no. I didn't try further <doko> as I say, works for me on the a500 <lamont> ok. I'll see what I can do about reproducing the failure on my A500 then <lamont> doko: maybe at some point I'll want to steal a tarball of the toolchain on your machine. <doko> lamont: sure, /scratch/packages/gcc/ <lamont> thanks <lamont> it'll take me a while before I get to it.. hopefully this weekend - no guarantee though <aquo> hi <aquo> anybody awake? <arthur-> aquo: yes <aquo> I installed ubuntu-minimal with debootstrap and examined the installed packages with aptitude <aquo> libgcc1 has version 4.2.1 <aquo> and libstdc++6 has version 4.2.1 too ... <aquo> if i would install gcc it would have version 4.1 <aquo> gcc depends on gcc-4.1 ... <aquo> build-essentials depends on gcc ... <aquo> which is the official compiler for gutsy? gcc-4.1 or gcc-4.2? <arthur-> aquo: aptitude install gcc; gcc --version should give you an answer <arthur-> aquo: gcc package come from gcc-defaults source package, which provide a symlink on /usr/bin/gcc to the current default gcc version <aquo> arthur-: ok, gcc depends on gcc-4.1, but all the libs are 4.2. why? <aquo> shouldn't have the compiler the same version as the libgcc and libstdc++? <arthur-> aptitude show libstdc++6 <arthur-> Version: 4.2.1-4 <arthur-> aquo: is g++-4.1 installed? <aquo> i just installed ubuntu-minimal, nothing else. <arthur-> aquo: this is libstdc++6-4.2-dev for gcc-4.2 and libstdc++6-4.1-dev for gcc-4.1 <aquo> i am just analysing dependencies for some gutsy-based custum installation <aquo> ok, again ... <aquo> if i install ubuntu-minimal i get libstdc++6-4.2 and libgcc1 for 4.2 ... <aquo> but if i would install build-essentials i would get an gcc with version 4.2, not with version 4.2? <aquo> why? <aquo> but if i would install build-essentials i would get an gcc with version 4.1, not with version 4.2? <aquo> sorry for the error <arthur-> because gcc-4.2 is not the default in gutsy <aquo> ok, but why doesnt libstdc++6 doesn't match the default compiler? <aquo> if i install ubuntu-minimal and build-essentials i get a system wit libstdc++6-4.2 and libstdc++6-4.1-dev <aquo> so headers and library doesn't match <aquo> same with libgcc <arthur-> aquo: maybe libstdc++6-4.2 is a dep providd by dh_shlibdeps, which mean that libstdc++6-4.2-dev was installed in buildd <arthur-> I don't know <arthur-> provided* <arthur-> so c++ packages depends on libstdc++6-4.2 <arthur-> doko: can you please commit gdc-svn-updates? <doko> done <arthur-> thanks #ubuntu-toolchain 2007-09-08 <Mithrandir> aquo: does it matter? The 4.1 and 4.2 packages are binary compatible. <Mithrandir> also, they answer to the question about what the default gcc is "varies by architecture" #ubuntu-toolchain 2007-09-10 <jbailey> doko: Around? <doko> jbailey: yes <jbailey> doko: Is there anything in particular you need help with right now? <doko> glibc merge from unstable? <jbailey> Err. It's September 10th, dude. Aren't we a month late for that? <doko> sure, then extract the fix <jbailey> for James' bug? <jbailey> The IPv4 DNS round-robbining one, that is. <jbailey> Or rather, the failure to do it. <doko> right <jbailey> Sure. <jbailey> That'll be a nice warm up to me getting chroots setup and such. <doko> jbailey: and then, I'm wondering if a new gdb would be more helpful than the old one <jbailey> I haven't followed gdb lately, what's up? <doko> they are preparing for a release in september <jbailey> Ah, new features and such? <jbailey> That probably would be nice to have in now if the next release is an LTS one. <doko> more bug fixes <jbailey> * Resolved 101 resource leaks, null pointer dereferences, etc. in gdb, <jbailey> bfd, libiberty and opcodes, as revealed by static analysis donated by <jbailey> Coverity, Inc. (http://scan.coverity.com). <jbailey> And a couple handy c++ improvements. I suspect it's worth it. But again, we're a ways past UVF. <lamont> sounds like a new gdb would be wonderful. <lamont> speaking of gdb... jbailey: got a patch for offsets.h yet? <jbailey> lamont: Nope, but I do have stuff setup on gsyprf11 now. * doko didn't want to be that direct and let somebody else ask =) <lamont> heh <jbailey> So at least I've got an hppa box to play with again. <lamont> doko: I'm poking elmo to see what we can do to get the dev-machine for ia64 up in the DC as well <jbailey> Hmm. My 20% time is supposed to be directly useful to Google. I wonder if "Keeping the Canonical toolchain maintainer and an archive admin happy" counts. Let's assume yes. =) * lamont also really wants to make time to understand the diffs between doko's A500 and lamont's A500, and why gcj-4.2 only works on the former. <lamont> jbailey: sounds about right <lamont> google's big on ubuntu <doko> lamont: sorry for the noise, but ia64 did become worse during gutsy <jbailey> My dapper chroot is just updating to gusty atm, and my new ssh key is in on launchpad. <lamont> yeah - it gets neglected by me large parts of the tiem <jbailey> lamont: Is my LDAP password supposed to work when connecting from the outside world to gsyprf11? <jbailey> Or is it only when hopping through 10? <jbailey> Or if helps if I use the right username. <jbailey> Whee, so I'm in to gsyprf11 from my work account now. <lamont> jbailey: it doesn't care where you come from, just that you spell your username/pass the same :) * lamont is building a dapper git-core <lamont> well, dapper-backport of current gutsy git-core * jbailey lunches #ubuntu-toolchain 2007-09-11 <jbailey> The hppa box I have access to (gsyprf11) doesn't have the build-dep's installed for gdb, so I'm trying to figure out how to get those in. glibc next. <jbailey> (lamont got palo already) <jbailey> l_: *poke* #ubuntu-toolchain 2007-09-13 <arthur-> doko: D ping <arthur-> doko: do you plan to upload gcc 4.1 -17 soon? I'm in contact with upstream and he has checked in some Debian patches (kfreebsd-gnu port) and perhaps fixed the sqrt bur on powerpc <arthur-> doko: so I have to update SVN, I'll try to do it the evening <doko> no, currently not. <arthur-> ok, thanks <arthur-> have a nice day #ubuntu-toolchain 2007-09-18 * Starting logfile irclogs/ubuntu-toolchain.log <arthur-> doko: thanks ;-) <doko> np <arthur-> doko: would a new gdc-4.1 upload be possible with a -16d1 rev for example? #ubuntu-toolchain 2007-09-24 * Starting logfile irclogs/ubuntu-toolchain.log <doko> lamont: could you take care about the expat/expat-tcl8.3 syncs? <arthur-> doko: http://people.dunnewind.net/arthur/doko/gdc-4.1_0.24-4.1.2-16d1_multi.changes ;-) <doko> arthur-: sorry, not that much time this week, I'll have a look later this week <arthur-> doko: ok, never mind <lamont> doko: well, actually, I need to fix the expat-tcl8.3 ftbfs... and the expect sync has been requested. <lamont> seems tcl8.3 vs 8.4 was non-trivial for things that import lots of internal crap... <lamont> do we need expect-tcl8.3 any more? <doko> lamont: your call, it was once needed for hppa to get reliable test results <lamont> yeah -it masked a bug that has been fixed #ubuntu-toolchain 2007-09-27 <arthur-> p/w 19 <lamont> doko: I have a gcc patch for you... <lamont> er, glibc <lamont> well, I will once I port it.. <lamont> (I heard a rumor you have a glibc upload in the works...) <doko> lamont: ok, please commit to the repo * lamont will have to find the repio <lamont> repo, even <lamont> doko: please add entries similar to the following to debian/control: <lamont> XS-Vcs-Browser: http://git.debian.org/?p=users/lamont/util-linux.git <lamont> XS-Vcs-Git: git://git.debian.org/~lamont/util-linux.git <lamont> and, uh, where is the repo? <doko> sftp://bazaar.launchpad.net/~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package/ <lamont> bzr? * lamont watches bzr slowly churn checking out the repo <Mithrandir> bzr+ssh is a bit faster than sftp, fyi <lamont> so bzr+ssh://.... <lamont> ? <Mithrandir> yeah <lamont> doko: my test build is running ( at least an hour before it gets to where -1ubuntu7 failed). If you're impatient in the meantime, picking up chinstrap:/home/lamont/local-private-futex-lamont.diff won't hurt <lamont> who knows, maybe my clone of the repo will finish by then :-) <doko> lamont: not today anymore <lamont> ah. bzr clone finised <lamont> finished <lamont> doko: care if I upload -1ubuntu8 with just my change? <lamont> one line patch to ports/sysdeps/hppa/nptl/tls.h, assuming there's nothing else <lamont> doko: and are you including changelog as part of the commits? <doko> lamont: yes, but no specific format <lamont> I'm assuming that the checkout did the right thing, and that what I have is a debian directory <lamont> given that... There are a few diffs between the unpacked source I downloaded (-1ubuntu7) and the bzr tree... <lamont> Only in glibc-debian/control.in: libc0.3 <lamont> Only in glibc-debian/control.in: libc6 <lamont> Only in glibc-debian/control.in: libc6.1 <lamont> Only in glibc-debian/: include <lamont> Only in glibc-2.5-package/: locales.NEWS.Debian <lamont> Only in glibc-2.5-package/patches: ia64 <lamont> Only in glibc-2.5-package/patches: s390 <doko> ignore the ones in control.in, the other ones should be empty directories <lamont> the last 3 being empty stuff <lamont> ignore as in "we don't care if my upload has them or not" or what? <lamont> ah, and include is probably because I have a build going where I rsync'ed glibc-2.6.1/debian from <doko> probably <lamont> do you have gcc-4.{1,2} uploads planned this week? <doko> lamont: yes <lamont> ok #ubuntu-toolchain 2008-09-22 <munckfish> Hi, I'm trying to create powerpc cross compiler out of intrepids gcc 4.3.2 sources and I've hit problem. <munckfish> When it compiles the 64bit version of libgcc it's looking to link with libc6 <munckfish> but can't
{'channel': 'ubuntu-toolchain', 'month': 9}