[12:05] you may want to enable building the shared lib64gcc1 package in debian/rules.defs ... [12:06] until gcc-4.0 builds it [12:10] Yeah. The other thought I had was that if we do gcc-4 first for these then a new gcc-3.4 can be built without overriding CC [12:11] I discovered this by forgetting to override CC when I updated to thge gcc-3.4 from this morning and it still built. [12:12] upload the 3.4 which builds lib64gcc1, it can be overwritten by 4.0 later [12:12] 'k [12:45] hey guys [12:51] lamont: ping? [12:52] lamont: can you kick back db4.2 on i386? [12:52] there is no reason why it failed at all [12:52] ubuntu5 is exactly as ubuntu4 with one line change in debian/rules that doesn't touch i386 [01:01] elmo: please move gnat-4.0 to main [01:57] doko: please seed it [03:15] doko: uhm, xbase-clients doesn't depend on xlibmesa-glu [03:16] doko: unless it crept in through ${shlibs:Depends}, which would be annoying [03:16] and also shouldn't happen [03:19] daniels: it did happen, and it is annoying :-) === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [04:02] elmo: do any of the buildd chroots have xlibmesa-glu-dev installed? if so, can they please not? === doko_ [~doko___@dsl-082-082-201-232.arcor-ip.net] has joined #ubuntu-toolchain [06:57] morning [07:06] Heya Fabio [07:06] hey jeff! [07:09] latest glibc is almost done on sparc :) [07:09] Nice! [07:09] This version decouples the locales dependancy [07:09] AH COOL! [07:09] So if you want to skip glibc for a rev or two after this, you're welcome to without penalty. [07:11] jbailey: you tell me :) [07:12] i can ban it from being auto built [07:12] specially if you plan to do 3/4 uploads with no benefits for sparc [07:12] fabbione: I don't see any reason why not to ban it for most of this week unless I tell you otherwise. It looks like we'll be in good shape to do some biarch/multiarch work, i386/amd64 and ppc/ppc64. [07:13] fabbione: It makes sense to tweak sparc/sparc64 at the same time to look the same. [07:13] But it won't be first.... [07:14] of course :) [07:41] dpkg is still fucked [07:41] dpkg-architecture -qDEB_HOST_GNU_SYSTEM [07:41] linux-gnu [07:42] this break at least kernel-package [07:43] Well, at least it's now reporting what config.{guess,sub} does so there won't be inconsistancy anymore. [07:43] But it took two glibc and two gcc uploads to get it right for us. [07:46] jbailey: so the final decision is linux-gnu? [07:47] I didn't realise there had been any discussion about it. [07:48] well we need to decide and fast [07:48] otherwise i can't upload the kernel [07:48] that is a big blocker for me atm [07:48] dpkg 1.13.2 contains the change pretty explicitely, so it's not an error. [07:48] doko and I each fixed other toolchain bits to cope. [07:49] Although both of us included bits for backwards compatibility. [07:49] well i need to change kernel-package [07:49] and hounestly i can just build-dep on a specific version of it [07:49] + add a versioned depends on dpkg [07:50] that in this case it is allowed due to the mess [07:50] (even if dpkg is essential) [07:50] hi jbailey [07:51] ifeq ($(DEB_HOST_GNU_SYSTEM),linux) [07:51] DEB_HOST_GNU_SYSTEM := linux-gnu [07:51] endif [07:51] that would work too [07:52] are you aware of other entries that did change? [07:52] svenl: Heya [07:52] fabbione: I'm just looking at what doko did in gcc [07:52] # configure as linux, not linux-gnu [07:52] TARGET_ALIAS := $(subst linux-gnu,linux,$(TARGET_ALIAS)) [07:52] jbailey: i want to give rebuilding glibc/gcc a try again. [07:52] hmm that can be done too [07:52] svenl: I haven't got all the packaging sorted out yet. =( [07:53] svenl: The latest gcc-3.4 in Ubuntu is very close, though. === svenl quite of wonders if there is not some svn/arch/baz/whatever repo with all those changes on it, instead of going begging to jbailey or doko to try stuff out :) [07:53] svenl: The source changes aren't the important bits. It's a tiny change to glibc and to gcc. [07:53] Ok, i will give it a try. [07:53] The problem is that you need to start from working binaries. === svenl hoping that today's breezy will cure my powerbook :) [07:54] Yep. [07:54] Well, not necessarily, as we have all started in some other way. [07:54] I mean, you originally built glibc with a cross compiled biarch gcc, didn't you ? [07:55] I don't know how it was generated, doko gave it to me. [07:55] the glibc ? [07:55] I'd assume so, though. [07:55] or the gcc ? [07:55] the gcc. [07:55] Oh, so you where not the first one in building it. [07:56] mmm, no xfonts-utils this morning too. [07:56] No. Before it gets uploaded to Ubuntu, though, I'm tempted to do a clean bootstrap of the whole thing so that I can feel very happy about it. [07:57] bah, gnome still gives me a message entitled Xession, and a little lamp, but without further text. [07:57] jbailey: :) [07:57] Does recovery mode work for you? [07:58] session de secours gnome ? [07:58] Sounds right. [07:58] ah, works much better. [07:58] My gdm isn't set to french, only my login sessions. [07:58] mmm. [07:58] there it is. [07:59] all gnome plugin are dead though, i guess because loads of gnome libraries are bogus. [07:59] mmm, gnome-panel just crashed. [08:00] What are you doing to your box? =) [08:00] My system has been stable all day.. [08:00] Unless there was some mid-day update. [08:00] svenl: i assume the binaries for xfonts-utils are waiting on NEW love [08:00] daniels: indeed, there are no xfonts-utils on ppc. [08:00] daniels: do you have unofficial ones ? [08:01] (it all started because i wanted to compile biarch gcc :/) [08:01] oh well, standard session seems to call xsession and not gnome-session. [08:02] http://people.ubuntu.com/~daniels/xfonts/xfonts-utils_6.8.2-12_all.deb [08:02] daniels: :) [08:03] oh, seems better, if i validate the xsession dialogue, i get a working gnome-session. [08:03] daniels: do you know where that xsession dialog comes from ? [08:03] probably missing fonts, particularly if you have no text [08:03] svenl: I'm uploading to people.ubuntu.com/~jbailey/glibc [08:03] jbailey: thanks. [08:03] I have a slow DSL uplink and I'm headed to bed. [08:04] daniels: your xfonts-utils will help me on that. [08:05] svenl: The most recent gcc-3.4 in the archive is mostly setup for the biarch. You need to change debian/rules to set CC to gcc-3.4 (the one that you got from me before), debian/rules.defs to enable the biarch config, and debian/binary-gcc.mk to fix the dh_link bug (missing $(PF) and missing some \'s. [08:05] svenl: maybe. if it doesn't, remember to change your paths from /usr/lib/X11 to /usr/share/X11 in xorg.conf [08:05] jbailey: ok, will give a try today. [08:05] Sorry, scratch the CC bit in rules. Current gcc seems to build biarch gcc fine. [08:05] daniels: yep, i did that. [08:05] cool [08:05] daniels: well, actually, they are not in /usr/share/X11 for some reason, so i have them pointing to /usr/X11R6/... [08:06] However with all that, the current package doesn't produce lib64gcc_1.so. That's where I go to before going out for drinks this evening. [08:06] errrrrrr [08:06] if they're not in /usr/share/X11, then you're not using the packages from xfonts-core [08:06] which is xfonts-* 6.8.2-12 [08:06] svenl: Oh yeah, I had to redo my font config this morning, are you on a pegasos box? [08:06] daniels: i only have type1 and truetype in shate. [08:06] jbailey: nope, powerbook. [08:06] svenl: Ah, okay. [08:06] svenl: then you need -75dpi, -100dpi, and others from 6.8.2-12 [08:06] svenl: Otherwise I'd send you my xorg.conf [08:06] jbailey: it's not pegasos-specific by any means [08:07] daniels: i have a couple of fonts upload waiting for xfonts-utils.. [08:07] svenl: um, for ubuntu? [08:07] daniels: sure. [08:07] main or universe packages? [08:07] daniels: all of them, breezy even. [08:07] cool [08:07] daniels: Yeah, I wasn't looking for a good solution to the problem, just to offer him a working config if he happened to be on the same system as I. [08:07] =) [08:08] send the universe ones to the motu guys at #ubuntu-motu [08:08] heh [08:08] i did install x-window-system though, which may have been a mistake, as i tried to solve the font dissapeared issue cluelessly. [08:10] xfonts-utils -16 is conflicting with xutils -10 :? [08:10] :/ even [08:12] mmm, forcing it. [08:13] ok, that seems to fix it, thanks daniels [08:14] daniels: altough the fonts and co are only at -11 [08:15] yeah, update-fonts-* was in xutils until about -15 or so [08:15] and the binaries are stuck in NEW [08:15] but when that gets fixed, we'll have -12 everywhere, and dist-upgrades will pick up what's needed [08:16] daniels: do you have unofficial fonts package too ? [08:16] not going to upload them, they take about an hour on my DSL [08:17] daniels: can i build them from source ? [08:18] sure, the .diff.gz is in the repository [08:19] Sleep time, g'n all! [08:19] night dude [08:20] night [08:30] infinity: ping? [08:45] fabbione : pong. [08:45] fabbione : I'm in the middle of insalling Ubuntu on my girlfriend's amd64 machine, so I have something faster to work on. [08:46] infinity: eheh neat... i had a question for you.. just a sec i need to find the reference again [08:46] fabbione : Was it a toolchain question, or are you just picking random channels to ping me in? :) [08:48] #$secondary_daemon_threshold = 70; [08:48] random chan :) [08:48] it's a buildd question [08:48] prefer in pvt? [08:48] Nah, public is cool. [08:49] what does that option do exactly? [08:49] Allows a second daemon to be spawned if the queue is over $x deep, IIRC. [08:49] i understand that if there are more than N pkgs in needs-build, buildd will fork.. but how and with what criteria? [08:49] what's the point of spawning if the chroot is locked by another package? [08:50] If you want "whate precisely does it do when it forks?", I'd recommend reading the source. As you may imagine, that's a feature I never turn on. :) [08:50] or there is a way to specify a seconday chroot for the same distro? [08:50] well the code doesn't say much.. [08:50] that's why i was asking :) [08:51] Heh. Well, given that all my buildds are really slow single-CPU machines, the very idea of forking more instances is just plain wrong, so I've not examined that codepath. [08:51] If it's sharing a chroot, though, that does seem broken, I agree. [08:52] buildd:# New config var $conf::secondary_daemon_threshold: If not at least that [08:52] buildd: if ($total && $conf::secondary_daemon_threshold && [08:52] buildd: $total < $conf::secondary_daemon_threshold) { [08:52] it seems only to add a log entry [08:53] there is no code basically [08:53] or i am misreading it [08:54] ahhhh [08:54] i get it [08:54] if that var is set [08:54] and you run a second instance of buildd [08:54] than it will fork [08:55] but it seems like it will share the same configs and chroots [08:55] it looks bad [08:55] Hrm. Yeah. [08:56] I wonder who thought that was a good idea? [08:56] You'd have sbuilds walking all over each other with package installations/removals... [08:57] probably sbuild has some kind of locking protection? [08:57] otherwise /var/sbuild/src-lock would have no meaning :) [08:57] or whatever is called [08:58] meh debbuild [08:58] srcdep-lock? [08:59] sub check_srcdep_conflicts { [08:59] yeah [08:59] it's done at sbuild level the next check [08:59] yeah that one [09:00] All srcdep-lock does, IIRC, is lock when sbuild is installing packages. [09:00] It doesn't hold any locks during a build. [09:00] well i am not going to turn that on since the code isn't really clear [09:00] Or, if it's meant to, that feature doesn't work. :) [09:00] hahha [09:00] (Cause the lock dir is pretty much always empty..) [09:01] yeah i was checking right now [09:01] I think the w-b suite is littered with unfinished features, so I wouldn't be surprised if this was another. [09:01] yeah i can see that [09:10] Oh, great. GRUB blew up the Windows boot sector, and it can't chainload Windows properly. Yay, I lose! === infinity tries to remember how to recover WinNT bootsectors without the WinNT install CD... [09:10] infinity: eh? you kidding.... [09:10] it did never happen here [09:12] Oh, I told it to eat the Windows boot sector. But I didn't tell it to suck at loading Windows, that part it's done on its own. [09:12] infinity: have fun :) [09:12] i have no idea on how to recover a wincrap boot sec [09:14] Well, usually, with the install CD. Which I don't have a copy of here. === infinity ponders. [09:27] switch the entire box to linux :) [09:27] and kill winnt [09:27] and i mean.. NT?? [09:27] put her on XP at least === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [10:19] infinity: fdisk /mbr? [10:19] infinity: you trashed zofia's xp mbr, didn't you? [10:21] fabbione : It is XP... Which is NT 5.1. [10:21] daniels : Maybe. [10:21] daniels : Downloading an install CD right now to fix it. :) [10:21] doko_: you there ? [10:21] (fdisk /mbr is a DOS thing, and also would only work if I had a floppy drive) [10:27] <\sh> hmmm [10:27] hi sh [10:27] hi \sh [10:27] <\sh> what is the replacement for xlibmesa-gl-dev [10:27] even [10:27] <\sh> g'morning svenl :) [10:28] <\sh> found it :) [10:28] \sh: what was it ? [10:29] \sh: xlibmesa-gl-dev is still xlibmesa-gl-dev [10:30] daniels: don like to install on ppc though, since libglu are not in sync. [10:31] <\sh> daniels: i have here build-deps on libglu-dev-xorg (because of libstdc++) xlibmesa-* wasn't compiled against libstdc++6 [10:32] svenl: huh? [10:32] \sh: xlibmesa-glu-dev wasn't built against libstdc++6; xlibmesa-gl-dev is not C++ [10:33] libglu1-xorg and libglu-dev-xorg were built against libstdc++6, unless there's been a terrible, terrible compiler mishap [10:34] (on the buildds) [10:34] daniels: well, my error, it needs : xlibmesa-dev libglu-dev-xorg libglu1-xorg [10:34] these are the ones, but they will uninstall half my system for now, including gdm and such stuff. [10:34] well, half my system is exagerated. [10:34] seems to work alright for me [10:35] daniels: 2$ sudo apt-get install xlibmesa-dev libglu-dev-xorg libglu1-xorg [10:35] Les paquets suivants seront ENLEVS: [10:35] freeglut3 gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools hwdb-client libgksu1.2-0 libgksuui1.0-0 [10:35] libgle3 libglut3 python-opengl python2.4-opengl rss-glx xbase-clients xlibmesa-glu xlibmesa-glu-dev xprint xprint-common [10:35] xprt xscreensaver-gl [10:35] <\sh> daniels: right..but if xlibmesa-glu-dev is now libglu1-dev-xorg, is there also a name change in xlibmesa-gl? [10:35] ENLEVE -> REMOVED, obviously. [10:35] enlevs -> removed? [10:35] right [10:35] \sh: no. [10:36] <\sh> chaos ;) [10:38] well, versioned provides just don't work [10:38] so I want to avoid changing the package name unless I have to [10:38] bbl [10:38] dinnertime [11:05] <\sh> hmmm [11:05] <\sh> libglu-dev-xorg: Depends: libglu1-xorg (= 6.8.2-16), xlibmesa-gl-dev | libgl-dev, libstdc++5-3.3-dev | libstdc++-dev, libc6-dev | libc-dev [11:09] \sh: welcome to breezy :) [11:10] <\sh> svenl: well... [11:10] <\sh> it doesn't have to do with breezy [11:10] <\sh> because [11:11] <\sh> libglu1-xorg: Depends: libc6 (>= 2.3.4-1), libgcc1 (>= 1:4.0.0-7), libstdc++6 (>= 4.0.0-7), libxext6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1 [11:11] <\sh> ;) [11:11] so what is that for??????? [11:11] \sh: bah. [11:13] <\sh> fabbione: the dependencies for binary package and dev package are not fitting together :( and I need this stuff to fix a package here [11:13] \sh: well but that's for breezy or not? [11:17] <\sh> fabbione: yepp [11:17] <\sh> think i need a cup of coffee and a cigarette [11:21] morning all [11:22] hi doko [11:23] is daniels coming back? [11:23] hi doko. [11:23] doko: he went for dinner.. so i guess yes [11:23] doko: maybe. [11:24] doko: what is the latest version of your biarch gcc .debs you have available ? [11:25] svenl: the same as before, let jbailey sort it out this week, then it should be ready [11:26] doko: i wanted to build it myself today. [11:27] is it known locales' dep is SNAFU on amd64? [11:28] oh well. [11:29] elmo: to what level of SNAFU? [11:29] because jb did relax the locales depends: [11:29] to something like >= ${Source-Ver} [11:30] uninstallable SNAFU [11:30] instead of = [11:31] katie@jackass:~$ dpkg -I pool/main/g/glibc/locales_2.3.5-1ubuntu3_all.deb | grep Depends [11:31] Depends: glibc-2.3.5-0ubuntu1, debconf (>= 0.2.26) [11:31] looks fairly = to me [11:31] I think that's meant to be provided by everything with the same locale API or similar [11:32] amd64 just hasn't built the new glibc yet [11:32] $ dpkg -f libc6_2.3.5-1ubuntu3_i386.deb Provides [11:32] glibc-2.3.5-0ubuntu1 [11:33] why do they have a virtual package whose version number is divorced from the source version number? that's just whack [11:34] the glibc build is just stalled on amd64 [11:34] same idea as shlibdeps, just done with a virtual package because the package name is different on different architectures [11:34] well, not quite the same as shlibdeps [11:34] root 31196 0.0 0.0 9132 696 ? SN May22 0:00 \_ /usr/bin/sudo perl -e kill( -15, 17624 ) [11:35] sudo perl -e kill? [11:35] omg [11:49] <\sh> argl [11:49] <\sh> daniels is working on the xorg stuff right? [11:56] \sh: kdebindings and base are in, we could probably try for pyqt pykde? [11:56] <\sh> Riddell: no [11:56] <\sh> the deps are not as they should [11:57] what's needed? [11:58] <\sh> xlibmesa-glu is replaced by libglu-xorg and libglu-dev-xorg...but the deps for libglu-dev-xorg are set against libstdc++5-3.3 and not like the bin package libglu1-xorg against libstdc++6-4.0 [12:00] \sh: that shouldn't hurt, libstdc++-dev already is installed on the buildd's. [12:02] <\sh> doko: but not on my update ;) [12:02] <\sh> lunch [12:03] \sh, install build-essential first [12:06] doko: what's the current state of play with the freeze? [12:06] did lamont unfreeze c++ apps? [12:08] elmo: as I did write on IRC yesterday, lamont wasn't online yesterday [12:09] meh [12:09] can _I_ unfreeze them? [12:09] by unfreeze you mean, put the new cxxapps.txt in effect? [12:11] elmo: yes, if unfreeze is limited to c++ apps in main === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-toolchain [12:18] doko: cxxapps.txt still has main apps? [12:19] yes, those depending on mozilla-dev [12:19] hmm, yes, I can remove the KDE things as well [12:20] elmo: ok, done [12:21] and I removed aptitude from the cxxapps in universe, so mvo can play the apt upgrade game [12:22] doko: aptitude is main [12:23] mvo: even better [12:23] never used it ... [12:24] the installer kind of does ;) [12:25] Kamion: is it only used for the installation of the tasks? or for more stuff? [12:25] mvo: for task installation, and for fallback if that fails [12:26] thanks [12:32] so the build daemons are now going to go nuts? [01:00] <\sh> doko: it's installed :) [01:00] <\sh> so lunchtime is over :) [01:12] elmo: is the cxxapps.txt updated on the buildd's? if yes, I could at least upload all packages, for which we have ubuntuN versions [01:14] doko: no, I want to talk to mdz about buildd stuff [01:14] + first [01:14] btw, you might as well upload apps, they just won't get built yet [01:25] better to have them ready to build than not.. === doko_ [~doko___@dsl-082-082-209-087.arcor-ip.net] has joined #ubuntu-toolchain [01:31] hmm, daily disconnect ... [01:32] elmo: ok, assume a upload a -buildN, which you then sync with a newer version. will the buildd build both versions, if both are available when the buildd restarts building the apps, or will it skip the older one? === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [01:33] eh [01:33] doko: for any given arch, only one version of a package is in a suite at any one time [01:35] elmo: do you sync with the new cxxapps.txt today? then I'll wait with the upload of the -buildN packages until after the sync [01:36] what about cxxlibs? is that up-to-date? [01:38] heh, that updated a whole 3 apps [01:42] elmo: cxxlibs updated. yes, we don't have that many C++ stuff in main, and most is modified anyway. which are the three apps? [01:42] uh, dunno, check breezy-changes? [01:42] doxygen, lftp and something [01:44] knew about doxygen, still waiting for the mails [01:44] sorry, it got mixed in with a bunch of your uploads, and it's now hard for me to tell what's what [01:45] ok, uploading the buildN's as well, so one will get rejected [01:45] that's fine [01:51] how's the universe transition being handled, given the uploads are blocked on certain keys? [01:51] oh, we're not anymore, nm me [01:53] checking whether the C compiler works... configure: error: cannot run C compiled programs. [01:53] Mmm, i guess something failed badly here :) [01:54] the universe part of cxxlibs.txt and cxxapps.txt shouldn't be synced, but libs should be built. [01:57] elmo, mvo: I made a mistake: uploaded synaptic, would probably be better, if this one does not enter the archive. sorry for that one [01:58] doko: the above test, does it check that the result from the compilation run is actually runnable, right ? [01:58] that's all right, the sync will overwrite it? [01:58] doko: and this is the place where it fails on 3 bit ? [01:58] 32bit even. [02:00] elmo, mvo: aptitude as well [02:10] morning [02:11] hi lamont [02:11] still need cxxapps unblocked on the buildds? [02:11] glibc did timeout in some network tests on amd64 [02:11] _again_. === lamont whaps jbailey [02:12] redland-bindings is ftbfs for me... no swig. Wonder if that's everywhere... [02:12] I already gave it back [02:12] lamont: yes, but I updated cxxlibs.txt and cxxapps.txt [02:12] elmo: coolness [02:12] lamont: but it had hung pretty spectacularly, the 'kill -TERM' invocation was hung too [02:12] neato [02:13] elmo wanted to talk with mdz about the buildd's first [02:13] no, that's fine, if lamont's here, go for it [02:16] doko: so another round of 'replace the list we have with what's currently in cxxapps'? [02:18] lamont: yes please, basically remove all of main, keep all of universe. thom just told me that he's preparing a mozilla upload, so I remove the one's depending on that as well. [02:19] lamont: done [02:22] chinstrap:~doko/cxxapps.txt, yes? [02:23] correct [02:23] lamont, fabbione: but keep the installed one on the sparc and hppa buildd [02:24] maybe not necessary for sparc, it's building binutils, glibc, gcc-* this week anyway ;) [02:24] lamont: Hey, not my fault the kernel hangs in the middle of a syscall. =( [02:26] lamont: I've gone over the test-ifaddrs code, as has vorlon - it's a quite simple bit of code. Following it with strace, it goes in to ask a question and just never seems to come back. [02:26] it seemed stuck in recvmsg, does that sound right? [02:27] lamont: perl on i386 did fail in network test ... interesting, dist-upgrade now wants to remove build-essential [02:27] When I traced it I think it was in getgid or something like that, but I don't have notes handy. [02:27] ok [02:28] I'm surprised to see it triggered twice in a row on amd64, though. [02:28] Usually on Debian it would be months between uploads where it would die. [02:28] doko: fixed perl [02:28] doko: it kinda assumes that 'localhost' resolves, which isn't necessarily true, but we decided it should.... [02:29] and terranova was down when I upgraded all the chroots by copying in /etc/hosts.... [02:29] lamont: how's yellow been? [02:30] elmo: FWIW, I loosened the locales dependancy with this upload, so hopefully if there's glibc problems on an arch in the future it won't bring the whole thing to a grinding halt. [02:31] jbailey: finally ... :) [02:32] jbailey: yay, thanks [02:32] tho, to be honest, I don't mind grinding halt in ubuntu [02:32] our glibc really shouldn't be out of sync [02:32] at least for release arches [02:34] Right. It's one of those changes that I hope I can convince gotom to pick up that he might not be willing to. [02:37] jbailey: so we won't have a chance to build the compilers, because one of the architectures will be broken at any time ;) [02:38] elmo: seems to be doing OK [02:38] lamont: ok [02:38] doko: I'll have the changes made sometime in the next 20-40 minutes [02:38] doko: Nah, elmo said he doesn't mind breakage. =) [02:39] Anywho running off to spend the morning with my belle. [02:39] jbailey: well, it may be interesting for sparc and hppa === cartman [foobar@cartman.developer.konversation] has left #ubuntu-toolchain ["Ich] [03:04] doko: ia64 is ready for this change too? [03:06] lamont: yes [03:09] ok. chroot-upgrade/buildd restart now in progress [03:09] cc1: error: unrecognized command line option "-fwritable-strings" [03:09] is there a comparable option in 4.0? [03:10] lamont: no [03:10] unicode.c:19:26: error: linux/string.h: No such file or directory [03:10] grumble === chuck_ [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [03:13] cool. dies on i386 too. /me bugzillas [03:15] will take some porting if it expects writable strings, probably ... [03:19] Kamion: yeah. [03:19] the i386-too was hfsplus. the writable strings is palo (which no one but hppa cares about) [04:07] lamont: powerpc-given-back.gz what does that mean on the build logs ? [04:08] it means that the buildd decided it shouldn't even try, and gave it back [04:08] and inside the log should be an error that gives a hint... [04:08]