[01:28] lamont: *poke* [01:39] jbailey: I cannot reproduce fabbione's build failures of 3.4 on sparc, so the toolchain seems to be in shape for all archs except hppa ... [01:40] doko: Great. I'm just about to do the hppa work. [01:41] doko: Did you and lamont touch the -0ubuntu4 glibc that I put on chinstrap to enable biarch amd64? [01:44] Oo, looks like goto might have already done a bunch of the porting work. === jbailey builds what Debian has on hppa to see. [01:45] jbailey: no [01:45] gcc cannot do biarch for hppa [01:45] doko: 'kay. The last point was the libgcc1 depends on amd64-libs, and I'm conflicting against it. [01:45] No, I meant the biarch i386/amd64 stuff [01:47] haven't tried yet, I'm currently working on the C++ ABI transition [01:47] It works fine. I need to know what you want to do about the amd64-libs confict. I'd like to just conflict against it, and ask for it to be removed from breezy. [01:48] But I don't want to cause you more problems enabling the biarch compiler. [01:48] Or I can drop this all until the C++ transition is done. [01:48] yes, the latter would be nice [01:49] 'kay. I will get hppa in shape today hopefully and get a glibc uploaded. [01:49] I have ppc64 ready to go and amd64 ready to go as soon as you have time for either of those. [01:51] yes, let's decouple these, although svenl is poking about ppc biarch [01:52] No prob decoupliung them, but there's no reason not to do them in the same day. [01:52] Given that we have to coordinate them at the time, it might be easiest if one of us handled them, or if we locked down a time for you and I to sit down at the same time and slug through them when we're ready. [01:52] feel free to update the gcc packages :-) [01:53] Cool, I can do that. [01:53] I'll do the c++ transition with you first though. [01:55] jbailey: looks like it's finished for the libraries in main, although the motus may need some support converting the remaining universe libraries [01:57] WOw, that's incredible. [01:57] Did you sleep? =) [01:59] a bit [02:01] When are you bumpding gcc-defaults? [02:02] anyway, I'll sleep *now* [02:02] when lamont and elmo are awake and syncs & uploads for same packages are frozen, maybe Mo/Tu [02:04] Cool, good sleeps doko. === Riddell_ [jr@muse.19inch.net] has joined #ubuntu-toolchain [02:09] jbailey: note that the new glibc is still waiting for a usable libgcc1 [02:11] lamont: Right, Sounds like we'll wait until later this week when gcc-defaults bumps, and I'll pick a time to sit down with you and Just Do It from all sides, including gcc. === doko [~doko___@dsl-082-082-197-172.arcor-ip.net] has joined #ubuntu-toolchain === infinity stares at doko. [04:35] infinity: It's not nice to stare at someone when they're sleeping. [04:35] When did we go from "help us out on Monday/Tuesday" to "finished for the libraries in main"? [04:38] Oh well. I'd feel more guilty, if I hadn't been moving all weekend. === jbailey fires up an hppa glibc build with Carlos' patches. [05:51] Off to watch a show while this builds. [07:01] hi jbailey [07:01] jbailey: did you not want to send me some new biarch glibc packages ? [07:11] svenl: I posted them, didn't I? [07:11] Nope, I didn't. [07:12] svenl: Sending, I'll let you know when it's done. [07:16] Hmm. I think I need to spend part of tomorrow moving glibc bits into baz or something. [07:22] svenl: http://testhaus.cns.utoronto.ca/~jbailey/ppc64-nptl/ [07:23] svenl: Bed time now. I'll be back in around 6 hours. [07:32] jbailey: ok, thanks. [07:35] I want the source packages also :) === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain === Riddell [jr@muse.19inch.net] has joined #ubuntu-toolchain [11:05] morning all [11:07] morning doko [11:08] hi chmj [11:08] infinity: there are more things to do ... [11:48] doko: what's the status of the toolchain transition? has any qt/kde stuff been uploaded or is that tomorrow? [11:50] Riddell: qt and kdelibs are prepared, amu did a qt 3.3.4 merge [11:50] Riddell: please search the BTS for gcc-4.0 and prepare patches for the kde specific things. I don't know, if amu did work on these [11:51] doko: how can I change over to g++ 4 to test things? [11:52] https://www.ubuntulinux.org/wiki/CxxLibraryList [11:52] see the sources line at the top [11:54] thanks [11:55] doko, is the g++4.0 app test build been done ? [11:56] chmj: which one? [11:57] I mean,all apps. there is surpose to be an automatic rebuild right ? [11:58] so we can see which ones fail? [11:59] chmj: yes, this one is prepared as well. Riddell, do you want to do this for the KDE apps? [12:00] doko: sounds like a good idea, what would I have to do? [12:01] Riddell: make a chroot, add my test builds to it and rebuild all of KDE in main ;) [12:02] doko: I'll give it a shot [12:06] doko, what do you mean prepared? [12:07] chmj: sources ready for upload [12:08] doko: sweet [12:23] svenl: ocaml FTBFS with 4.0 [12:58] doko: mmm. [12:58] doko: on ubuntu ? [12:58] doko: i will have a look later on ppc. [12:58] doko: or maybe you do have a log ? [12:58] doko: what version of ocaml is this anyway ? [12:59] svenl: should fail in unstable/experimental as well. [01:00] doko: well. [01:00] doko: i prefer working on the ubuntu/breezy machine, i have killed the hoary install by installing random glibc/gcc upgrades anyway. [01:03] doko: i will contact upstream if we have something serious and get a patch. [01:15] re [01:15] doko: as i said.. right in time :) === doko [~doko___@dsl-082-082-212-246.arcor-ip.net] has joined #ubuntu-toolchain [01:40] doko: if i have both gcc-4.0 and gcc-3.4 installed, which one will it default to ? [01:41] svenl: That's up to gcc-defaults [01:41] jbailey: hi. [01:41] svenl: Check to see what /usr/bin/gcc points to. [01:41] jbailey: so how do i make sure gcc-4.0 is used ? CC=gcc-4.0 ? [01:41] Yup [01:41] Although in Breezy, that's the default now. [01:41] CXX is still gcc-3.4, though [01:41] err. [01:41] 3.3 [01:41] gcc-3.3 [01:41] ocaml? no, there's something like -cc gcc-4.0 in debian/rules [01:42] svenl: deb http://people.ubuntu.com/~doko/GCC-4.0/i386 ./ [01:42] launch started. [01:43] doko: what should i do with that ? I have some serious doubt it will be usefull on my powerbook. [01:43] deb http://people.ubuntu.com/~doko/GCC-4.0/powerpc ./ [01:44] doko: not the official gcc-4.0 in breezy ? [01:44] you did want to change the defaults, didn't you? [01:45] nope, its ok, i use the -cc gcc-4.0 trick, should do just fine. [01:45] ok, build launched, will tell you how it goes. Is using jbailey's latest glibc. [01:46] svenl: the ppc64 snap that I gave you? [01:46] doko: i would really like to build a biarch compiler myself though. [01:46] jbailey: sure. [01:46] Cool. [01:46] jbailey: i killed my hoary install anyway, upgraded to breezy, and installed your snaps. [01:46] why do you try to compile ocaml on powerpc? [01:46] svenl: Remember to pin glibc. [01:46] it works [01:46] doko: do you think i will have more chances in the gcc-4.0 ? [01:46] svenl: There's a newer one than that in the archive that doesn't have ppc64 support. [01:47] doko: because i have powerpc machines. [01:47] jbailey: mmm. [01:47] jbailey: how do i pin glibc ? [01:48] svenl: Something in some apt configuration. In practice, I just don't run apt-get upgrade after. [01:48] jbailey: :) [01:48] jbailey: maybe better would be to always rebuild newest ppc64 enabled glibc for each official version, so you don't have this problem. [01:49] svenl: I was thinking earlier that I might move the glibc packaging into bzr so that it's easy for me to do updates of the biarch i386/amd64 and ppc/ppc64 glibcs that aren't in the archive yet. [01:49] jbailey: when will they be in the archive ? [01:50] doko: do you mean the gcc-4.0 on powerpc will not manifest the ocaml bug ? [01:50] svenl: amd64 support will go in the archive after the c++ transition is finished (I don't want to interfere with that) [01:50] svenl: ppc64 will go in the archive as soon as we figure out how to make the biarch compiler build on a 32 bit kernel. [01:51] (subject to the same limitation as amd64 beyond that) [01:51] svenl: http://people.ubuntu.com/~lamont/buildLogs/o/ocaml/3.08.3-3/ [01:56] doko: oh. [01:56] doko: well. [01:56] doko: i guess gcc-4.0 is buggy on i386. [01:57] bng_ia32.c: In function 'bng_ia32_mult_add_digit': [01:57] bng_ia32.c:111: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' [01:57] well. [01:57] doko: i don't deal with register starved broken archs :) [01:59] doko: i can't really help you there, i have one amd64 with a pure64 install and only ppc boxes apart from that, and one m68k. [02:00] svenl: install a i386 chroot on your amd64 ;-P [02:00] svenl: Going to start the Ubuntu m68k port? =) [02:00] doko: i would write to http://pauillac.inria.fr/bin/caml-bugs [02:00] jbailey: nope. === jbailey would love to see m68k and arm as the first buntu targets. [02:01] jbailey: i lost my apus card, so only an mmu-less 68020 in it. [02:01] oh, but i have an amiga 4000 waiting for me in oberursel. [02:01] will try to get it next week. [02:01] doko: i could do that. [02:04] doko: not today though. [02:06] doko: what is your email address ? [02:06] hey doko [02:06] hi svenl [02:06] doko@ubuntu.com ? [02:06] hi fabbione [02:07] svenl: yes [02:09] doko: does gcc 4.0 eat up more registers than 3.4 used to do ? [02:10] doko: i just filled a bug upstream, CCed you on it even. [02:10] svenl: thanks [02:56] fabbione: you can find the gcc-3.4 build for sparc in my home on chinstrap. did build properly in a fresh breeeezy chroot [02:57] fabbione: YEs, and regular sparc ideally, but still need to figure out whether we continue to care about pre sparc9 [02:58] i did complete the build manually [02:58] (For those that are confused, consider this the equivalent of renaming a file in CVS) [02:58] jbailey: pre v9 are 32 bits, right? [02:58] if so just kill them [02:58] fabbione: 32 bits only. [02:58] i don't care [02:58] All the classic sparc joy. [02:58] perfect.. KILL THEM ALL [02:59] 'kay. Then in that case, we have opt packages for sparcv9 and sparcv9b. [02:59] Should the sparcv9 one go away? [02:59] whatever fits you better is ok with me :) [02:59] see.. i am very simple [03:00] doko: what kind of chroot did you creat? [03:01] breezy [03:01] doko: try to bootstrap a buildd chroot :) [03:01] why? [03:01] debbootstrap --variant=buildd [03:01] it's a different set of base packages? [03:02] doko: at what time are we going to start? [03:03] sorry, why is it different to deboostrap breezy and install the build-deps? === lamont wanders off for a while [03:03] doko: because breezy has plenty of things that are not installed on a buildd [03:03] fabbione: elmo around, lamont around, xorg packages updated [03:04] what about sparc-utils? [03:04] also sparc-utils [03:04] you need to install that manually on the buildd... i forgot to add it to the list when i did debootstrap ubuntu34 [03:04] why is sparc-utils not in the buildd? [03:05] because i forgot to add it to the list when i did debootstrap ubuntu34 [03:05] afk a sec. [03:06] doko: when are we going to start the transition? [03:07] (also.. elmo is not here ;)) [03:08] fabbione: elmo needs to freeze the import of C++ packages, lamont needs to prepare the buildd's, daniels needs to upload xorg compiled with 4.0 [03:08] is it going to happen today? [03:10] I have my doubts now ... [03:10] well fuck i come back from holidays for this transition === fabbione goes for a smoke [03:25] checking whether the C++ compiler (g++-4.0 -O -DDEBIAN ) works... no [03:25] configure: error: installation or configuration problem: C++ compiler cannot create executables. [03:25] hmmm [03:27] which package? [03:27] mozilla [03:27] same error on all arches [03:30] yes, firefox works, mozilla maybe needs an update [03:46] fabbione: Well, now my client won't talk to CAnonical's imap server. [03:46] *cRy* [03:47] jbailey: get a serious client... [03:47] fabbione: I use evo because that's what I have to support. It makes sense for me to know it very well. === jbailey turns on various debugs. [03:49] jbailey: well.. i use thunderbird.. it's crap.. it crashes, but i can open N imap mboxes without any problem :) [03:49] fabbione: This was all working on my laptop on Friday. [03:49] No idea why it deteriorates on my main box. Main difference is that the laptop is i386 and this is ppc. [04:21] fabbione: Oh ouch. This client is going through and doing a STATUS on each file in buildLogs. =( [04:21] amen [04:21] no wonder it takes ages [04:21] well i am not too worried about bw usage... [04:21] it will just be slow for you [04:29] jbailey: if you prefer i can even setup a forward to you, but that means getting all the logs from the buildd... [04:31] I'm trying to beg for better behaviour in #evolution [04:32] doko: wouldn't be a good idea to start bitching elmo, lamont and daniels? [04:33] otherwise you can forget to start the transition :) [04:40] :( [04:56] should we revisit all the steps, one by one just to be 200% sure before we start? [05:08] doko: "prepare the buildds" == ?? [05:10] lamont: i think he means installing the new gcc-defaults [05:11] fabbione: ok === lamont needs to run to the post office this morning sometime, but that's only 15 min from home [05:12] lamont: we are still waiting for elmo, so i think it's safe to go right away :) [05:12] lamont: do you think it's worth to let the new gcc-defaults in so that it can be built? [05:12] but not installing it in the chroots? [05:12] that would probably save sometime for the process [05:13] the chroots will install it at the start of a build if it's a dependency. Likewise, around 0215 DCT (Data Center Time), the chroots are automatically upgraded [05:15] ok than we should wait i guess [05:15] but nothing build-dep on gcc-defaults [05:15] it's pulled in as part of build-essential iirc [05:23] libtool: build-depends gcj which comes from gcc-defaults. [05:25] hmm right [05:26] yeah it does here too [05:26] ops [05:28] yeah - that's currently uninstallable, hence the ease of finding it... :-) [05:30] if I have 40 minutes, I'm going to run away and visit the postoffice. [05:31] lamont: probably much more than that :) [05:31] right. back in a bit then [05:31] oky [06:21] lamont: Around? [06:21] yo [06:22] lamont: Are you brave enough to step me through reading hppa assembler, or should I wait until Carlos is around? =) [06:22] hppa assembly is my frien d [06:23] lamont: Lovely, might be something for the evening hacking session then. [06:23] woot [06:23] lamont: The story so far is basically: [06:23] still no elmo? [06:23] 10: 00000000 0 NOTYPE GLOBAL DEFAULT UND memcmp [06:23] 11: 00000000 764 FUNC GLOBAL HIDDEN 1 __GI_memcmp [06:23] apparently no [06:23] lamont: And the similar file on ppc has it defined. So I think I need to see what's up. =) [06:25] hrm.. that's not assembly... that's .o format. :-) [06:25] Right, but I want to see what it's feeding to the assembler. [06:25] For the symbol to not exist at all. [06:27] ok. note that gas and I are not always good friends, but the actual machine code is one of my oldest friends... [06:28] 'kay. =) === doko [~doko___@dsl-082-082-213-004.arcor-ip.net] has joined #ubuntu-toolchain [07:04] still no elmo? [07:20] lamont: still around? [07:20] bah eek.. brb [07:20] heh === jbailey can smell the pizza in the oven. [07:28] lamont: we don't know where elmo is, do we? === lamont bets on .uk. [07:29] (that'd be a "no") [07:29] ahaha [07:29] mind you, I could be wrong... :-) [07:30] sorry... phone call [07:33] re [07:33] lamont: i need to go offline soon [07:33] and without elmo we cannot do the transition [07:33] lamont: can you check if you still have access to the sparcbuildd [07:33] and stop it when needed [07:35] have I mentioned that I hate transitions that require manual steps on all the buildd's? [07:35] esp since hppa isn't able to do the walk at the same time as the rest? [07:35] lamont: yes and i am with you [07:35] since sparc is the slowest === lamont glares at doko/jbailey, just for good measure [07:36] fabbione: just vultus5 [07:36] ? [07:37] br [07:37] b [07:37] lamont: yes.. there is only vultus5 [07:37] coolness [07:37] back in a couple === jbailey runs off for lunch, ecaping the glares from lamont. [07:37] leave me alone ... [07:37] jbailey: stop! [07:37] later guys [07:37] doko: Eh? [07:37] doko: try to summon me.. if i won't respond in a decent time lamont will stop the buildd [07:38] and we will look at it tomorrow... [07:38] but this really suck [07:38] jbailey: please have a look at the latest directfb build failure on amd64. [07:38] and sparc.... [07:38] conflicting types in {sys,asm}/types.h ? [07:38] bbl [07:38] doko: Does it have to be before lunch? The timer just rang. [07:38] fabbione: have fun [07:39] no [07:39] Lovely. =) === jbailey goes for lunch. =) === lamont is informed that lunchtime approaches === lamont makes sure that jbailey has his cell, on the off chance that elmo surfaces before he gets back from lunch... === lamont goes to lunch with the wife, back in a while - holler if/when I'm needed [08:42] Enjoy. [09:20] doko: Around? [09:25] jbailey: yes [09:32] Was just following glibc on hppa and noticed that upstream actually released the new binutils. Do you want me to add that to my queue of things to test? [09:35] doko: I'll look at directfb on ppc first, since I have one of those here. [09:40] jbailey: yes, these are already packaged and tested. one regression on ia64, just waiting for elmo's ok [09:40] Nice. Did you see http://sources.redhat.com/ml/binutils/2005-05/msg00360.html ? [09:44] interesting [10:28] directfb is a cast-as-lvalue failure, I'm trying to figure out what the current best practice is supposed to be. [10:29] data8 = (unsigned char *)data16 = (void*)0; [10:29] Isn't allowed anymore. [10:45] jbailey, did you get the .22 version from the archive [10:45] jbailey: ^^^ [10:56] current dirctfb version should be 0.9.22-0ubuntu1 [10:58] Ah, nope. apt-get source had fetched me .20-0ubuntu1 === jbailey fetches. [10:59] err .20-5 === warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain === Topic for #ubuntu-toolchain: GNU Compiler Collection, Glibc, Binutils, Linux-kernel-headers | GLIBC Todo: hppa, sparc NPTL, i386 biarch === Topic (#ubuntu-toolchain): set by jbailey at Wed May 11 01:20:59 2005 === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-toolchain [06:28] morning [06:28] damn my server died again [06:28] how is it going guys? === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [08:17] jbailey: hi. [08:30] Mmm, gcc 4.0 is better, since it builds libgcc1 package, but not the 64bit stuff. [08:45] need to find how gcc decide wheter to build lib64gcc1 or not, doesn't seem obvious. === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain [09:27] morning === Seveas [~seveas@ksl403-uva-131.wireless.uva.nl] has joined #ubuntu-toolchain === doko [~doko___@dsl-082-082-205-075.arcor-ip.net] has joined #ubuntu-toolchain [10:19] hey doko [10:19] hey doko [10:20] hi fabbione [10:21] doko: so what is the status for the transition? [10:26] fabbione: let me wade through my mail first ... [10:26] ok === Riddell [~jr@jasmine.wyrdweb.com] has joined #ubuntu-toolchain === cartman [foobar@cartman.developer.konversation] has joined #ubuntu-toolchain [11:29] doko: hi. [11:29] doko: i built gcc-4 biarch. [11:29] doko: it is better, since there is a non-empty libgcc1, but still no 64bit libs. [11:30] doko: i have searched some, but am at a loss on where in the gcc makefiles the building of the 64bit stuff is defined. Do you have any hint on that ? The debian stuff tries to build the 64bit packages but fails. [11:32] doko: also, i was told to use --added-target=powerpc64-linux when building by hand. I see no trace of this in the debian files. [11:33] --enable-targets=powerpc64-linux that is. === Riddell_ [jr@muse.19inch.net] has joined #ubuntu-toolchain === Seveas [~seveas@ksl403-uva-131.wireless.uva.nl] has joined #ubuntu-toolchain === daniels [~daniels@amnesiac.heapspace.net] has joined #ubuntu-toolchain [02:08] represent === mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-toolchain [02:12] fabbione, daniels, lamont, jbailey, elmo: ping [02:13] Running /build/buildd/gcc-4.0-4.0.0/src/gcc/testsuite/gcc.c-torture/compile/compile.exp ... [02:13] make[1] : *** [stamps/06-check-stamp] Terminated [02:13] make: *** [check] Terminated [02:13] Build killed with signal 15 after 150 minutes of inactivity === lamont grumbles at doko [02:13] morning doko [02:13] doko: wassup === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain [02:14] morning elmo [02:14] time plan for tomorrow ... === lamont is about to get dragged off for breakfast for 20-30 minutes [02:16] 1) freezing the imports/syncs 2) upgrading the buildd's 3) freezing the archive for C++ application uploads 4) library uploads [02:17] 1) and 2) make only sense, if things for 4) are ready, xorg is outstanding. for 1) and 2) we need lamont and elmo [02:17] xorg is going to be fun [02:17] we need to get 3 arch: all NEWs in, then xorg [02:18] doko: why not today? [02:18] fabbione: daniels prepares the final xorg source upload [02:19] daniels: i understood it was ready.... [02:19] i've been working with joshtriplett so we have the same stuff between debian and ubuntu [02:19] and i want to try some more upgrade tests [02:19] in any case, it's 2220 here and I'm fucking tired, so I'd love if I could do it tomorrow [02:20] but if it needs to be done tonight, sure [02:20] doko: I'd also be interested in hearing how this will work for the buildd's that don't even have a gcc-4.0 right now. [02:20] (hppa) [02:20] lamont: is hppa ok? [02:20] hppa has the build failure pasted aboge [02:20] above, even [02:20] ohh, they don't? [02:20] no. still don't [02:21] back in about 20 minutes. sorry [02:21] lamont: disable the testsuite :-( [02:21] well the sooner the better [02:22] daniels: what is missing from your packages? [02:22] hmm, ok. so let's sort out hppa later [02:22] only upgrade tests? [02:24] fabbione: yeah, and I need to reversion it too [02:24] daniels: but are you going to upload the monolithic tree right? [02:24] reversion it? [02:25] the monolithic tree ... plus modular packages of xc/include/*.h and lib/xtrans/* [02:25] wouldn't be wise to just do the C++ transition with the monolithic and split everything else later? [02:26] unfortunately I only did the C++ transition later [02:26] and it would take more time to split out all the patches with gcc4 fixes etc and fix all the offsets than it would to test all this [02:26] is there any option to upload only libglu from the splitted? [02:27] hmm? [02:27] iirc that's the only library that has to do the C++ transition [02:27] xorg 6.8.2-$foo [02:27] -> libgluwhateversoname-$foo [02:27] yeah, it's libglu1-xorg now [02:28] from xlibmesa-glu [02:28] if you upload libgluwhateversoname-$bar [02:28] where $bar is > $foo [02:28] that's all you need to start with [02:28] but can libglu1-xorg build abe uploaded that way? [02:28] from the modular tree? nope [02:28] if so there is no need to get the entire splitted tree in [02:28] mesa is going to be the hardest part of this lot [02:29] doko: how much can we do without X? [02:30] not much, the whole KDE depends on it. and other libs as well. [02:31] KDE is an application :) [02:31] what about the other libs? [02:31] how many of them? [02:31] it's ok, we can do libglu [02:32] so, i'll try to get x-common, x11proto-core-dev and xtrans-dev in tonight [02:32] and get packages of xorg up on chinstrap for testing and building on powerpc [02:32] and then upload that tomorrow morning? [02:32] fabbione: it doesn't make sense to have the archive in an unusable state for too long. this just adds 24 hours [02:33] daniels: sounds ok. do the packages need new love? i.e. is elmo awake tomorrow morning? [02:33] the first 3 packages need NEW love [02:33] they will mostlikely need elmo's love for NEW [02:33] all the sources are new [02:33] libglu1-xorg will need NEW love for the binary package too tho [02:34] would preseeding be useful here? [02:34] that's sure thing [02:34] elmo will still need to do the manual uni->main [02:34] ahr [02:34] same for all these new library binary packages ... [02:35] elmo: will you be around for the next couple of hours? [02:35] mostly, yes [02:36]