=== daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain [03:32] sigh. that took _WAY_ too long [04:06] fabbione: which patch? [04:07] oh, I see [04:07] fabbione: got it [04:47] doko: Around? === doko [~doko___@dsl-082-082-200-046.arcor-ip.net] has joined #ubuntu-toolchain [06:09] morning [06:09] daniels: ping? [06:10] pong [06:10] daniels: did you see my patch on people? [06:11] yeah, already merged it [06:11] thanks [06:11] i am uploading -15 right now [06:11] no worries [06:11] -15 of what? [06:11] as soon as i get the accepted you are free to go for -16 :) [06:11] xorg [06:11] oh, for sparc [06:11] yes [06:11] phew [06:12] if you upload -16 before, the -15 bins will be rejected [06:12] sure [06:13] finally i can start buildd again :) [06:29] http://www.theregister.co.uk/2005/05/18/vibrating_knickers/ [06:29] AHAHHAHAHA [06:56] daniels: ok you can go anytime [06:56] -15 has been accepted [06:56] cool [06:58] thanks dude [06:59] fabbione: are you uploading binaries that are non-virgin??? you bad man you. [07:01] lamont-away: yeah it's cheating on a package :) [07:01] aren't you supposed to be sleeping? [07:01] yeah - came out to check on the buildd, and change the laundry === lamont-away notes that his local archive has xorg_6.8.2-15hppa2 in it. :-) [07:02] anyway, g'night again [07:02] btw kernel: i need updated chroots on concordia and davis otherwise i can't test build [07:02] yeah - saw that in -kernel. [07:02] lamont-away: too lazy to change the version [07:02] specially because -16 with the fix will hit archive soon [07:03] lamont-away: before you go... xorg gcc -> buildd? === lamont-away bets it was the same fix that he gave daniels earlier in the week. [07:03] is there anything else i need to take care of? [07:03] lamont-away: i doubt... the fix was sparc specific [07:03] lamont-away: uhm no, it was a sunffb-specific fix :P [07:03] sunffb driver compilation options [07:03] i didn't know what -mv8 was before I started on -15 [07:03] and I still don't [07:04] unless it specifies the particular sparc revision or some shit [07:04] prior to unleashing the buildd: 1) cxxapps.txt -> @no_auto_build, 2) fresh versions of gcc-4.0, gcc-defaults, dpkg, xorg (and their build-deps, of course). [07:04] i think it's some gcc optimization flag [07:04] ah, ok [07:04] lamont-away: yeps.. all of that it's already in place [07:04] then you're _go_ for sparc buildd [07:04] coolness [07:04] once those are in the archive, that is. [07:04] they are [07:04] i did build all of them manually [07:05] yeah [07:05] yup === fabbione unleashes buildd on breezy [07:05] good night lamont :) === lamont-away has 30 failed builds sitting in his hppa buildd mailbox [07:05] yeah i wonder how many i will get here [07:06] some of those are hppa specific (console-tools, ubuntu-meta) But a bunch of them are /usr/include/X11 or gcc-4.0 or such [07:06] + i still have some old craft to cleanup [07:06] 232 packages built, 151 of them uploaded... damn straws [07:08] i guess i am going to hit some build-deps madness... [07:08] oh yeah, big time. [07:08] ehhehe [07:08] not to mention lots of NEW packages, depending on how you have your overrides set up... [07:09] i didn't setup overrides [07:09] there are still a few packages in universe that need to move to main to fix the archive. [07:09] oh [07:09] well i don't mix universe/main anymore [07:09] after ports has been up [07:09] is in scrollback from doko just before he left. [07:09] that's good [07:09] so the ogre model is complete again [07:09] now the local pkg cache is down to 2 hours === lamont-away cheers [07:10] so possiblities to hit a mix are very very very low [07:11] anyrate, time to sleep again. g'night [07:11] night lamont [07:14] daniels: btw.. elmo mentioned that xtrans had some .c files in /usr/include/X11 [07:14] dunno if you fixed that already [07:14] it's not fixable [07:14] that's how xtrans works [07:14] eh? [07:15] you #define a bunch of crap and then #include the .c files [07:15] it's utterly, utterly disgusting [07:15] JEEEEE [07:15] now you see why I have such a deep-seated hate for xtrans === fabbione pukes [07:15] can't we move the .c files somewhere like /usr/share/ ? [07:15] just for the goddam sake of it? [07:16] we've already had that argument upstream, the consensus was that we'd put it in /usr/include and try to kill xtrans [07:16] BRRRRRRR [07:17] we need to get an #u-x chan or something [07:17] this is the sort of shit I have to deal with upstream as well as downstream :P [07:18] daniels: you are d00m3d [07:19] indeed [07:20] omg! doko! another gcc-3* full set upload? [07:21] i wonder if i will ever get to the point to actually build something else than toolchain [07:34] morning all [07:34] hey doko === gollum [~root@218-162-217-166.dynamic.hinet.net] has joined #ubuntu-toolchain === gollum [~root@218-162-217-166.dynamic.hinet.net] has left #ubuntu-toolchain ["less] [07:43] infinity: ping? === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain === doko starts to hate the change to DEB_*_GNU_SYSTEM === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [12:16] doko: all those libraries are still in NEW - I'm leaving them to elmo [12:19] hmm, getting all these renamed libraries into the archives is really suboptimal :-( [12:26] Kamion: the debconf build needs kdebindings fixing for amd64 from Riddell [12:27] koffice will need http://janeway.no-ip.org/~cartman/filters_gcc4.patch btw [12:27] just in case === Riddell is working on kdebindings just now [12:29] might take a few hours [12:29] cartman: which version of koffice is that against? [12:29] head [12:29] but filters rarely changed [12:30] should apply cleanly [12:30] cartman: have you sent it back to the koffice developers? [12:30] Riddell: trying now, psn resisting ;) [12:31] cartman: is that compiled on 64 bbit or 32 bit? [12:31] Riddell: only errors on amd64+gcc4 [12:31] cartman: ah, then you'll be adding errors to x86 :) [12:32] hmm no [12:32] similar fix went into kmail last week [12:32] :/ [12:32] should be safe [12:32] you cast it to long before casting to something else to preserve precision [12:32] doko: debconf hasn't built for ages anyway :( [12:33] cartman: ok, maybe you're right [12:33] Riddell: I will wait for dfaure to be sure [12:33] he's the man [12:33] yep [12:36] out->fScratch = ((int)(long)in & 1); is there really no better way? just looks ugly [12:37] well I stole the solution from kmail where they were casting int* to int [01:08] erm. what's the type of 'in'? [01:09] ehy Kamion [01:09] Kamion: do you still have katie suppah p0w3r? :) [01:10] Kamion: const char* I think [01:10] cartman: EWWWW. so you're basically working around crappy typing elsewhere. [01:10] fabbione: yes ...? [01:10] Kamion: its msword/mswrite filters, what do you expect? honest :) [01:11] Kamion: just for curiosity... what is the status of knetworkconf 0.6.1-3ubuntu4 (hoary-updates)? [01:11] fabbione: same as it was when the last two people asked about it :P [01:11] fabbione: source is in the archive, but I don't think hoary-updates is building ... [01:11] Kamion: i am asking becuase i could see the source and the sparc buildd got it in needs-build, but it was not taking it [01:12] ah ok, but it is safe for me to upload it? [01:12] sparc did built it fine [01:12] I'm assuming it's turned off in w-b or something, I'm not actually sure [01:12] ok, don't worry [01:12] I don't know if it's safe or not - it probably is, but that's an elmo question [01:12] ok, i will just keep it stand-by somewhere [01:12] thanks a lot [01:13] it might get rejected by the C++ transition check in jennifer [01:13] uh right... === fabbione checks [01:13] which isn't distribution-guarded [01:13] no it's banned as c++apps in buildd.conf [01:13] i forgot that kde is all c++ [01:14] or almost :) [01:14] so yeah.. it can be built, but it's not since @no_auto_build is not distro aware [01:14] and the filter is applied [01:23] ah, buildd.conf, ok [01:24] yeah it was the simplest solution to filter apps [01:24] i just forgot to look there before asking :) [01:38] kdebindings doesn't want to compile [01:39] it gets stuck on sipqtpart0.cpp and sits there chewing up CPU cycles forever [01:39] Riddell: try to lower the optimization for that file [01:42] doko: that did it [01:42] elmo: I NEWed dbus_0.33-0ubuntu3, openh323_1.15.3-2ubuntu2, libtunepimp_0.3.0-2ubuntu7 for c2 changes [01:42] not sure how to lower the optimisation other by hand though [01:45] Riddell: please save the preprocessed file, and put it in a bug report, need the architecture and command line options as well === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [02:56] <\sh> morning === Seveaz [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [03:48] jbailey: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../grove -g --pipe -O3 -ffunction-sections -D_REENTRANT -MT GroveApp.lo -MD -MP -MF .deps/GroveApp.Tpo -c GroveApp.cxx -fPIC -DPIC -o .libs/GroveApp.o [03:48] /usr/include/OpenSP/RangeMap.cxx: In member function 'unsigned int OpenSP::RangeMap::inverseMap(To, From&, OpenSP::ISet&, OpenSP::WideChar&) const': [03:48] /usr/include/OpenSP/RangeMap.cxx:50: error: 'wideCharMax' was not declared in this scope [03:48] wanna fix openjade? === lamont should learn C++ better sometime [03:53] lamont: hi [03:53] I'm looking at it [03:54] thansk [03:54] lamont: kdebase needs some love, the deps are in main now === lamont kicks kdebase, unixodbc/ppc and libgnomeuimm2.6/*64 [03:56] lamont: openjade did build on all archs ... [03:57] that's from hppa - haven't double checked to make sure it dies on i386 [03:57] ruby1.8. otoh is another dpkg victim === doko would like to play hang-man ... ;) [04:00] ruby1.8 => #11040 [04:09] it's ok, if you see the breakage, but there's silent breakage as well. hmm, maybe it's better to just revert this change until Debian switches to the new dpkg as well [04:10] interesting idea [04:13] hey lamont [04:15] lamont: it would be interesting to implement @no_auto_build per distro [04:15] fabbione: heh [04:15] today digging in the w-b database i noticed a knetworkconf (hoary-updates) not taken for build [04:15] because it's banned in breezy [04:15] it would also be good to to make SIGHUP re-read it [04:16] hm? [04:16] yeah === fabbione kicks gcc test suite [04:18] it's too slow! [04:18] doko: you must do something about it [04:19] doko: might be that doing a breezy-test world with dpkg changed might be the right answer. [04:19] ifeq arch=sparc and bbuilder=fabbione, then fail. exit 0 [04:19] that's fast! [04:19] fabbione: did I tell you that I need another 3.4? [04:20] doko: i am still building gcc-3.3 [04:20] so i don't really care [04:20] doko: did you fix that problem with libvtest thing? [04:20] doko: so if you upload the new gcc-3.4 now it's ok [04:20] well, 3.3 does have interesting libc dependencies now ... [04:21] i am still building 3.3 [04:21] but i care more about 3.4 [04:21] fabbione: I don't know, I built it, and I don't see the failure [04:21] since we build the kernel with 3.4 [04:21] doko: bah you suck :P [04:21] i told you.. the target is not called [04:21] come on dude... [04:21] you can manage :) === fabbione whispers to doko: "FIX IT!" [04:23] doko: i will see if it happens again with the next build [04:23] if so i will put our buildd chroot somewhere so you can look at it [04:24] fix ruby1.8 while you're waiting ;-) [04:24] doko: are you going to do cleaning in my house in the meanwhile? [04:24] lamont: could you remove the Dep-Wait for xerces25 and xerces26? [04:24] doko: sorry sure [04:25] done [04:25] fabbione: hmm ... === lamont hopes the new 3.4 actually builds on ppa [04:26] doko: trust me.. you will be more happy fixing ruby1.8 too :) [04:26] + i hate c++ [04:26] with all myself [04:27] <\sh> jesus [04:27] <\sh> kdelibs4c2 is in [04:27] \sh: that was doko et. al., not jesus [04:27] doko has short hair... [04:27] <\sh> when doko uploaded it, he's jesus ;) [04:27] \sh, call me as you like it ;-) [04:28] <\sh> fabbione: and? in africa, jesus has a dark skin colour [04:28] naa, Kamion did give it some love ... [04:28] doko drinks beer... jesus doesn't [04:28] or didn't... [04:28] depends how you want to see it :) [04:28] fabbione: wine, beer, what's the diff? [04:29] jesus was more for wine... [04:29] <\sh> fabbione: we can't be sure [04:29] <\sh> jesus had something with maria magdalena [04:29] lamont: beer is like so... german.. wine is more italian :) [04:29] well, if the books are to be believed, he was of jewish descent... [04:29] Riddell, amu: kdebase fails ... [04:29] kate.la.o(.text+0xe): In function `main': [04:29] collect2: ld returned 1 exit status [04:29] make[4] : *** [kate] Error 1 [04:30] <\sh> the life, the universe and the rest [04:30] anyway... time to go and do some cleaning [04:30] <\sh> let me finished libchasen [04:30] /build/buildd/kdebase-3.4.0/obj-i386-linux-gnu/kate/app/kate.la.cpp:2: undefined reference to `kdemain' [04:30] <\sh> -ed [04:30] doko: you forgot that line [04:31] yes, xchat did grab it [04:31] yeah [04:31] fabbione: one idea ... [04:31] doko: ? [04:31] hppa's uploader is only 86 packages behind... sigh. [04:31] are there dangling symlinks in /usr/lib/gcc/3.4.4/sparc*/64/ [04:32] or in /usr/lib/gcc/3.4.4/sparc*/ [04:32] to libgcc* [04:32] doko: i dunno... [04:32] and i can't really check [04:32] fabbione, look and you will see ... [04:32] do you want me to look if the build fails? [04:32] it's a small miracle ;) [04:33] one moment [04:33] hmm, no, that can't be the reason, we don't use the stage1 compiler at this point [04:34] just found out, why gcc-3.4 -m32 is broken on amd64, jbailey could be interested ... [04:35] lamont: could you make sure, that all the buildd's get the current state of the archive, so that I could start uploading cxxapps from main? [04:35] are all libs builded? [04:35] doko: you should still be sure that the apps build-dep on a proper version of the libs [04:36] fabbione: no, in this case we have to touch all 700 cxxapps packages. [04:36] doko: dude.. that will make another breezy debootstrap impossible [04:36] doko: you need to change the apps to versioned build-dep [04:37] fabbione: why will it be impossible? [04:38] apps which get synced from Debian don't have changed build-deps either [04:38] because you can build packages on top of old libs if you are not extremely carefull [04:38] I did always think, that the hppa and sparc buildd admins are careful, but I can be wrong ;-) [04:38] doko: you can upload cxxapps, but they won't get built until we change @no_auto_build... :-) [04:39] doko: it's not just hppa and sparc.. [04:39] i think not changing the build-deps is just wrong [04:39] lamont: elmo told me that I could upload anyway [04:39] fabbione: they build-dep on foo-dev, which is unchanged... [04:39] fabbione: what do you make in case of the synced apps? [04:39] ISTR doko saying they might just work... [04:40] usr/lib/gcc/sparc-linux/3.4.4 # ls -lR [04:40] no dangling symlinks [04:40] fabbione: it can be handled as an archive event... painful, but it works... [04:40] hmmm [04:40] ok [04:41] lamont: archive event? [04:42] doko: what we're doing. [04:42] probably i am just too much of a purist [04:42] draw a line, and make sure that nothing on the right side needs anything that wasn't fixed on the left side. [04:42] fabbione: we'll get these build-deps, when Debian is doing the transition [04:42] given that sparc was out of hoary thanks to gcc-4.0 unversioned build-deps.... [04:42] note that archive events are, by definition, a royal pain in the tail for any buildd admin [04:43] lamont: oh yeah.. i agree [04:44] i need to go.. doko: last offer to come and clean my house in exchange of kernel upload with mISDN [04:44] (our kernel is really free like in beer ;)) === lamont cries. b180 took xorg [04:44] b180? [04:44] is the slowest one? [04:44] slow hppa ... [04:44] 180MHz 32-bit UP hppa [04:44] amen [04:44] well, there's only 2 of them,. [04:45] heh, and it fails ... [04:45] lamont: why don't you add it to @no_auto_build ? [04:45] I just did [04:45] a bit too late i guess :) [04:45] lamont: you can still share the ccache between the 2 buildds [04:45] it had never built it (since it _was_ in n-a-b), so it didn't show up when I added all the really long build-time stuff to n-a-b [04:45] it will be less painful when packages hit the slow one [04:46] fabbione: yeah, but that's so much like work [04:46] and disk I/O isn't exactly the fastest here... [04:46] uh why? [04:46] NFS my friend [04:46] well, for starters, the machines are 2-switches away from each other [04:46] that's what i use here to share ccache all over [04:46] Not a File System [04:46] lamont: OCFS2 with the next kernel upload :) [04:47] OCFS2? [04:47] Oracle Cluster Filesystem2 [04:47] my wife is so going to kill me if i don't go and clean [04:47] http://people.ubuntu.com/~fabbione/Screenshot.png [04:48] lamont: does openoffice.org build? [04:48] on hppa? no [04:48] me must go now [04:48] cya later [04:48] lamont: i386 and powerpc [04:49] it's in the @no_auto_build list [04:49] so it's not going to even try anywhere [04:49] <\sh> hmmm... [04:50] ommmmm [04:50] <\sh> i was just informed, that I'm now have a new portable 160gb usb2 hd [04:50] <\sh> it's ready to pick up [04:50] <\sh> strange thing is, i've never ordered one [04:51] <\sh> and I don't have to pay it [04:51] <\sh> weired [04:51] lamont: are you able to change the @no_auto_build lists? [04:51] are we ready for me to? [04:52] and note that when I do, it'll be 'empty the list' on each buildd as it's done... I'm not going to do it one package at a time [04:52] lamont: all cxxapps in main but KDE. but we can enable KDE as well, it will just fail, because kdebase isn't installable. [04:52] yes, let's wait for kdebase, then we can do it === lamont adds cxxlibs to his package list for his local mirror, and starts a sync, cringing [04:55] openjade is an hppa-specific issue. sihg [04:56] <\sh> hmm [04:56] <\sh> think i will setup an ubuntu mirror [05:01] lamont: could you report it upstream? === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [05:02] doko: will do, although I want to investigate it a bit first... [05:03] jbailey: just noticed that gcc-3.4 -m32 didn't work [05:04] <\sh> doko: u reviewed some of those debdiff outputs? [05:04] doko: For which arch? [05:05] (I'm lagging a bit at the moment, I updated to the new X and it won't start. I'm just poking it a bit) [05:05] \sh, ok, will do [05:06] jbailey: -m32 ... [05:06] doko: I think it worked fine for me the other day on amd64. It may have been sparc, though. [05:07] <\sh> doko: i saw some u reviewed :) u r working too much i think ;) [05:07] hmm, the 32bit libgcc symlinks are dangling links [05:09] doko: I'll take a look in a moment then. === jbailey kicks his computer. === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [05:17] doko: I think kdebase just needs visibility turned off, checking now === lamont heads to town for a while [05:27] Riddell, yes, I did see this as well ... hope, that not every KDE packages has this check ... [05:27] Ah, lovely. got X again. [05:27] *bounce* === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [05:29] mps [05:29] doko: compiles now, should I upload? [05:31] doko: Now that I'm actually paying attention.. =) [05:31] doko: I have 3 questions: [05:31] 1) What was that about -m32? [05:32] 2) I've confirmed that glibc builds with -g2 on ppc at least, so I'll set that for the next upload. [05:32] 3) What would be good timing for me to do the i386/amd64 biarch stuff so that I don't interfere with you. [05:33] <\sh> Riddell: that means we will have a running kdebase at least today? ,-) [05:33] \sh: it means we should have a compiling kdebase [05:33] running is a different matter === Riddell awaits doko's command to upload [05:44] Riddell: please do [05:45] jbailey: 1) dangling symlinks [05:45] 2) now ;) get the 0ubuntu2, that I did upload some minutes ago [05:45] no, this was 3) ;) [05:46] Does #3 also solve #1? =) [05:46] yes [05:47] Excellent! =) [05:47] doko: that file that I said didn't compile did finish after two hours. I innocently gave up hope after 1 hour [05:47] doko: Do you have brainspace for me to ask you about biarch setups and ppc64? [05:54] kdebase_3.4.0-0ubuntu21_source.changes ACCEPTED [05:56] fabbione: If you're bored at some point, I had asked the main Splack guy about his throughts on requiring v9 or newer for a Sparc distro. He says that he gots alot of requests for support from classparcs. [05:57] fabbione: I Don't know if that's a good reason to support them, or a good reason to run screaming. =) [05:57] jbailey: the latter :) [05:57] jbailey: btw xorg did build fine with your fix [06:02] fabbione: Yay! [06:02] fabbione: Any other crazy blockers? [06:03] jbailey: not right now.. util-linux did build as well [06:11] Riddell: anyway, having the preprocessed source would be very useful [06:12] jbailey, yes, why not [06:13] doko: it's a 9MB file [06:13] doko: Right now our bi-arch configs, i386, sparc, and s390 all succesfully build a biarch setup on a 32 bit kernel. [06:13] KDE bindings is a bit crazy [06:14] Riddell: doesn't matter [06:14] <\sh> Riddell: do u want to disable the python qt/kde bindings in kdebindings? [06:15] yes, do they? I did assume that the buildd's for s390 and sparc are 64bit [06:15] doko: From looking at the logs, it looks like ppc is trying to actually run a built ppc64 binary. Is that something in our packaging, or is that something upstream that needs to be poked? [06:15] \sh: arn't they already apart from qt-dcop? [06:15] doko: nope.. sparc userland is almost all at 32bit [06:15] and it doesn't matter what kernel are you running to build [06:16] <\sh> Riddell: i don't know...they're only disabled (in the last source tree i saw) I wanted to use the normal upstream packages... [06:17] \sh: "do u want to disable" "they're only disabled" which are they? [06:17] that should be coded in gcc/config.ml (guessing if the compiler works) [06:18] <\sh> Riddell: I saw u complaining about python-qt sip things...I just wondered if they're enabled again [06:18] config-ml.in in the toplevel directory [06:19] \sh: right. I suspect they're compiled and then no package is made of them [06:19] which is a bit silly [06:20] <\sh> Riddell: so remove them from configure.in and makefile.am ;) [06:20] <\sh> I will come to python-sip4-qt and kde stuff later this day [06:21] <\sh> patches are already there for pkde [06:21] great [06:22] <\sh> i don't like this "copy upstream packages into kdebindings" === waldi [~waldi@waldi.developer.debian] has joined #ubuntu-toolchain [06:30] Heya Bastian. [06:30] hi [06:31] hey waldi === fabbione goes back cleaning [06:32] waldi: moin [06:37] doko: When should we do the binutils update? [06:41] 2.16.1 will be released next week. I didn't had a chance yet for testing on ia64 with glibc 2.3.5 [06:42] doko: Do you mean with the new bintuils or in general? [06:42] ia64 with glibc 2.3.5 in general is working fine. [06:42] I can give you access to my box with the breezy chroot if you'd like,. [06:44] with 2.16, I see one regression in the binuitls testsuite (on unstable) [06:44] Ah, drow message about releasing 2.16.1 I had missed it. Cool. === waldi [~waldi@waldi.developer.debian] has left #ubuntu-toolchain [] [06:44] jbailey: no need, just build the package from experimental in this chroot [06:44] doing [07:00] Feh, getting false testsuite failures because it's failing to spawn and such. [07:02] Lemme boot the box, there's some d-i build processes lying around probably tying up resources. [07:03] doko: can i push you a clean breezy chroot somewhere, so you can test a gcc build? [07:04] hm, not a good time for a debootstrap upload - aptitude needs to be rebuilt first [07:04] uh? [07:05] depends on libsigc++*c102 [07:05] Kamion: i have a diff for the buildd variant [07:05] but i am waiting for the last c++ stuff to complete the transition [07:05] or do you test that one too? [07:05] mail it to me and I'll do it in one upload when everything else is done? [07:06] Kamion: sure.. buildd isn't that important and can be done "anytime" [07:07] but if you turn out to be in a hurry for it, then feel free [07:07] fabbione: ok [07:07] no no.. it's no hurry [07:07] the main scripts just need unusual handling [07:08] Kamion: mvo told me that he did test apt and aptitude on all four archs, so maybe I'll just build it [07:15] Riddell: "Bash 3.0-14ubuntu1 hangs on amd64 after any command taking up 99% CPU cycles", I cannot reproduce this behaviour, the testsuite looks ok as well [07:16] doko: hmm, it's definatly very reproducable on amu's machine [07:16] doko: old chroot and fresh one [07:17] lamont: ^^^ maybe do not update the buildd's while we are working this out [07:38] oh great [07:38] doko: gcc-3.3 fails too [07:38] mv debian/tmp/usr/lib64/lib*c++*.{a,so} debian/tmp/usr/lib/gcc-lib/sparc-linux-gnu/3. [07:38] 3.6/64/. [07:39] mv: when moving multiple files, last argument must be a directory [07:39] Try `mv --help' for more information. [07:39] make[1] : *** [stamps/08-binary-stamp-libstdcxx-dev] Error 1 [07:39] btw.. it did start building gcc-3.4 [07:39] should i stop it? [07:42] this is weird [07:42] gcc-3.3 did create the debs and failed? [07:44] oh yeah.. it was building the debs when it failed [07:44] hmm, why is the target directory not present ... strange [07:45] doko: i have almost done with the chroot :) [07:57] Mmm. It's not harmful to have packages in debian/control that are never built, is it? [07:59] jbailey: given that you don't create the deb... [07:59] jbailey: not unless they ever were built [07:59] I think... [07:59] anyway, really running off now [08:00] later lamont [08:00] 'bye lamont [08:00] 'k thanks. [08:01] jbailey: no, that's ok [08:02] I'm trying to reduce what I have to do to enable ppc64 in my build. =) [08:04] debian/rules.defs: look for biarch [08:05] Sorry, still on glibc. [08:05] ;) [08:12] guys when do you think i can start working on a ppc64 kernel? [08:12] to do that i need the toolchain in place [08:12] and breezy-ppc64 chroot is borked afaik [08:12] night folks [08:13] configure: WARNING: I have to compile Test.class from scratch [08:13] checking if java works... configure: error: The Java VM java failed (see config.log, [08:13] check the CLASSPATH?) [08:13] db4.2 [08:13] night kid [08:14] ../dist/configure: line 21554: 28092 Bus error $JAVA $JAVAFLAGS $TEST [08:14] interesting :) [08:14] g'n Daniel. [08:15] fabbione: The ppc64 toolchain is blocked on the fact that it wants a ppc64 kernel to build. [08:15] I'm trying to convince it otherwise. [08:24] doko: Was it an ld failure? [08:25] I see on unepxcted, but schwab posting something to the binutils list that I Can try. [08:25] http://sourceware.org/ml/binutils/2005-05/msg00601.html [08:28] jbailey: yes, that's the regression I did see === fabbione goes off line for the evening... [09:33] ok, submitted #11050 for the dpkg behaviour === fabbione goes off line for real [09:44] lamont: where can I find the icu build? it's marked as uploaded, but not installed [09:52] Wow. The binutils patch system *doesn't fail* if a patch fails to apply. [09:53] could be dpkg-breakage? ;-) sorry, couldn't resist === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [09:54] If only/ I confirmed it with debian/rules patch =( [09:54] So doing the ia64 test. [09:54] +re [09:55] I'm leaving in a moment, too, so I'll let you know how it goes later. [09:55] I'm also building a ppc64 glibc. [09:55] jbailey: err, it so does? [09:57] It didn't for me. A lovely bit in debian/patched/123_ldwhatever_I_called it [09:58] that nicely logged that the patch hadn't applied. [09:58] And it merrily carried on. [09:58] Anyhow, Angie's poking me to go, back in a few hours. [10:00] well, new dpatch might not, but new dpatch grew crackful maintainers :( [10:05] elmo: packages from cxxapps cannot be built, even if I upload them signed with my key? [10:10] doko: I didn't restrict building of apps, that's lamont [10:10] I only restricted source uploads [10:11] well, you CERTAINLY can't upload binaries, signed by your key [10:11] ;) [10:12] where's icu currently stuck, is it buildd or new? [10:12] icu | 2.1-2ubuntu1 | breezy/universe | source, amd64, ia64, powerpc [10:13] REJECT [10:13] Rejected: icu-doc_2.1-2ubuntu1_all.deb: old version (2.8-4) in breezy >= new version (2.1-2ubuntu1) targeted at breezy. [10:13] Rejected: icu-doc_2.1-2ubuntu1_all.deb: old version (2.8-4) in hoary >= new version (2.1-2ubuntu1) targeted at breezy. [10:15] hmm, where can I see this? [10:15] you can't [10:16] the queue/REPORT stuff is not visible because it contains security uploads too [10:16] kamion/mdz can see it. and lamont gets the REJECT mails [10:17] hmm, well, something we should talk about [10:18] anything else rejected from the cxx stuff? [10:18] I've no idea, I'm not trawling through all the possible rejects :P [10:19] as I said, the buildd admin gets the emails ... === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain