[00:04] <stgraber> slangasek: depends on when you plan to have RC out ? I can quite easily test amd64 and highvoltage can do i386 (or I can download both).
[00:05] <stgraber> slangasek: from what I saw going in the archive today, that means having the new edubuntu-artwork and the xfs/jfs issue solved, if there's nothing else that changed, then I'd appreciate a respin yes
[00:06] <stgraber> (just trying to avoid going from something that's almost-perfect to something worse ;) but the closer we are to the final image, the better)
[00:06] <slangasek> stgraber: out in < 18h
[00:06] <slangasek> stgraber: can you do the re-testing before then?
[00:07] <stgraber> when would we get the new images ?
[00:07] <slangasek> (and yes, that's all that's all that would change)
[00:08] <slangasek> stgraber: well, just missed the publisher, so... in 3h40
[00:10] <stgraber> 11pm here, still possible for me to do the tests, so yeah, please go ahead
[01:43] <slangasek> stgraber: published; edubuntu respin started; ETA now 2h20; I'm going to be afk when they land, so I've marked them on the tracker preemptively so you have somewhere to report results
[01:43] <stgraber> slangasek: ok (I could have added them on the tracker ;))
[01:44] <slangasek> oh, hah, yes you could
[01:44] <slangasek> :)
[02:06] <ScottK> slangasek: re the discussion on wine, since it needs to build and then something needs to build against it too before we start final images perhaps it could be first out of the queue as we start to unfreeze?
[02:06] <slangasek> how long is its build time?
[02:07] <slangasek> we also have a weekend's-worth of langpack builds incoming
[02:08]  * ScottK looks
[02:10] <ScottK> slangasek: 40 - 45 minutes
[02:12] <slangasek> alright
[02:13] <slangasek> I think if we're going to accept it (and I haven't reviewed the actual content of the proposed change to confirm that's appropriate), we should do so in parallel with the RC publishing, then, to get a jump on it
[02:13] <slangasek> (i.e., tomorrow once the trigger is being pulled)
[02:14] <ScottK> Sounds reasonable.
[02:14] <ScottK> I didn't review it either.
[02:31] <ScottK> slangasek: If you have a moment would you please toss "sync 567673 -S unstable" at mass-sync.py?
[02:31] <slangasek> tossing
[02:33] <ScottK> Thanks.
[02:33] <slangasek> done
[02:33] <ScottK> Excellent.
[03:27] <stgraber> slangasek: btw, we received the font for the Edubuntu logo this afternoon and I just played a bit with Inkscape to get something that looks like a new logo ;) I guess we'll be working on that with highvoltage tomorrow and so we'll have a new edubuntu-artwork package uploaded shortly after RC is out.
[04:01] <ScottK> Cleared the non-partner stuff out of New.
[06:43] <slangasek> stgraber: any progress on the edubuntu re-testing?
[07:11] <ara> morning
[07:12] <mvo> good morning ara
[07:12] <ara> morning mvo!
[07:16] <ttx> Good morning
[07:49] <ara> morning ttx
[07:51] <slangasek> morning, all
[07:52] <ttx> Hey ara, slangasek !
[07:52] <ttx> lovely morning for a RC.
[07:52] <slangasek> mvo: I sent you some comments on the OOo merge in one of the bugs - did you get those?
[07:53] <mvo> slangasek: thanks, let me check
[07:56] <mvo> slangasek: thanks, those are good comment! I will answer in the bugreport
[08:27] <slangasek> cjwatson: seems the fix for bug #515023 didn't cover all the cases where this bug will manifest - bug #567182
[08:28] <slangasek> (but I think that's SRU material at this point)
[08:28] <slangasek> well, at least on the hdparm side - the acpi-support fix is straightforward
[09:34] <mvo> slangasek: we may need a lib6 upload too for final, it currently seems to restart gdm happily on hardy->lucid upgrades (which is odd as around beta time I did test that on both real hardware and in kvm)
[09:36] <slangasek> er, odd
[09:37] <slangasek> mvo: or, not odd - sigh, a clear regression in the fix for bug #505838
[09:37] <mvo> yeah, I'm looking into it now
[09:37] <mvo> oh, how wonderful
[09:37] <mvo> I thought it might be this one
[09:37] <mvo> bzr is still fetching the packaging branch
[09:38] <mvo> anyway, I think I have a fix
[09:38] <slangasek> well, wait... why would kill -HUP $(pidof gdm) cause a restart?
[09:38] <slangasek> that's what 'reload gdm' should do
[09:38] <mvo> its seems like "idlopt" need to be checked for "restart" instead of "idl"
[09:39] <mvo> in line 337
[09:39] <slangasek> oh
[09:39] <slangasek> right, because it's sensitive to upgrade order, meh
[09:40] <slangasek> mvo: so, be careful to handle both the case where gdm upgrades first (upstart job - idl=restart) and the case where libc6 upgrades first (init script - idlopt=restart)
[09:40] <mvo> *urgh*
[09:40] <slangasek> actually
[09:41] <slangasek> even that won't do it, I think
[09:41] <slangasek> gdm takes -USR1 as its reload signal, not -HUP
[09:41] <slangasek> I don't know what gdm does on -HUP
[09:41] <mvo> seb128 may know
[09:41] <slangasek> and I'm not testing on this instance of it :)
[09:42] <mvo> -HUP just killed it in my VM
[09:42] <mvo> well, restarted it
[09:42] <seb128> mvo, not offhand no
[09:43] <mvo> slangasek: could we always use the init script for lucid? its provided for compatbility, right?
[09:43] <mvo> in the restart of gdm I mean
[09:43] <seb128>         case SIGHUP:
[09:43] <seb128>                 g_debug ("Got HUP signal");
[09:43] <seb128>                 ret = TRUE;
[09:43] <seb128>                 break;
[09:43] <seb128> it seems it's doing nothing fancy
[09:43] <slangasek> mvo: the init script in lucid isn't an init script, it points at upstart-job and won't DTRT
[09:43] <seb128> there is a comment in the code saying it should be fixed to re-read config, etc
[09:44] <mvo> seb128: is that true on hardy as well?
[09:44] <slangasek> seb128: so it ignores it, which isn't what we want either :)
[09:44] <mvo> slangasek: ok, clearly bad
[09:44] <slangasek> seb128: does the new gdm handle SIGUSR1 the way the old one did?
[09:44] <seb128> mvo, it should, gdm didn't change too much in lucid
[09:44] <mvo> slangasek: let me do a patch and ask for review
[09:44] <mvo> seb128: ok
[09:44] <slangasek> mvo: ok, thanks
[09:45] <seb128> slangasek, what was the old one doing on SIGUSR1? reload config?
[09:45] <slangasek> seb128: yes
[09:45] <seb128> the new one seems to toggle debug mode on SIGUSR1

[09:45] <seb128> "                g_debug ("Got USR1 signal");
[09:45] <seb128>                 /* FIXME:
[09:45] <seb128>                  * Play with log levels or something
[09:45] <seb128>                  */
[09:45] <seb128>                 ret = TRUE;
[09:45] <seb128>                 gdm_log_toggle_debug ();
[09:45] <seb128> "
[09:46] <slangasek> seb128: does the new gdm handle NSS and PAM in-process?
[09:46] <slangasek> or does it spawn a helper?
[09:46] <seb128> I don't know
[09:46] <slangasek> ok
[09:46] <seb128> pitti, ^ maybe you know?
[09:48] <pitti> looking
[09:49] <pitti> PAM is handled in /usr/lib/gdm/gdm-session-worker
[09:49] <pitti> which isn't the daemon, just spawned when you create a new session
[09:49] <pitti> hm, but apparently it's not terminated after starting the session
[09:50] <mvo> slangasek: something simple like http://paste.ubuntu.com/420299/ ?
[09:50] <slangasek> pitti: but is it terminated when you /close/ the session?
[09:51] <slangasek> pitti: and are NSS lookups handled by that process, too?
[09:51] <mvo> oh, so maybe we don't need to handle gdm at all?
[09:51] <slangasek> mvo: at this point it doesn't appear we *can* handle gdm sensibly, so that may have to be the answer anyway
[09:52] <slangasek> gdm-binary calls getpwnam, getpwuid
[09:52] <mvo> thanks!
[09:52] <slangasek> which means that gdm *should* get restarted (gracefully) after a libc upgrade
[09:52] <pitti> slangasek: it's restarted when you log out, and gdm login screen comes back, yes
[09:53] <slangasek> pitti: ok; unfortunately that doesn't help us with NSS, though
[09:53] <pitti> slangasek: what do you mean with "NSS handling"? calling getpwent() and the like?
[09:54] <pitti> gdm doesnt use nss.h
[09:55] <slangasek> mvo: that paste will fix the problem of gdm crashing on upgrade; and it'll handle the upgrade from hardy; so that would be ok with me for upload, despite not fixing the fact that we have other dead code in there
[09:55] <slangasek> pitti: yes, getpwnam, getpwuid, getXXbyXXX
[09:55] <mvo> slangasek: ok, do you need a bug with it or can I just upload as it is?
[09:55] <slangasek> pitti: those calls are the whole reason libc6 has restart handling in its maintainer script
[09:55] <pitti> getpw* is used in the greeter (which restarts with every session close/user switch) and session-worker (restarts with session close), but also in gdm-binary which runs forever
[09:56] <slangasek> mvo: if you're not going to make a bug, please make the changelog entry more verbose about what problem you're fixing
[09:56]  * mvo nods
[09:56]  * mvo adds a bug then
[09:56] <pitti> but gdm-binary apparently only needs it to look up the "gdm" user
[09:56] <pitti> which it runs the greeter session as
[09:56] <pitti> not for actual real users
[09:56] <slangasek> pitti: does it call that once and cache the answer?
[09:57] <pitti> slangasek: no, it looks up "gdm" user/group, then seteuid()s, and forgets everythign
[09:58] <slangasek> pitti: aha
[09:58] <pitti> i. e. if the gdm user should change during dist-upgrade, things break
[09:58] <pitti> but this really really ought not to happen
[09:58] <pitti> (changing uids during upgrade, I mean)
[09:58] <slangasek> pitti: that's not even a valid use case :)
[09:58] <pitti> slangasek: oh, how is it not? pretty much every non-root daemon does it that way?
[09:59] <slangasek> mvo: so we should only fiddle with gdm in the case that we have an init script, *not* an upstart job, because on upgrades, the switch from init script to upstart job is coincident with the switch from old gdm that needs SIGUSR1, to new gdm that needs nothing
[09:59] <slangasek> pitti: the uid of the gdm user changing during dist-upgrade?  that's not a valid use case
[09:59] <pitti> ah, ok
[09:59] <pitti> *phew* :)
[10:00] <pitti> mvo: in general, due to gdm's current architecture it doesn't really need a concept like "reloading", though; the daemon only reads custom.conf, and changing autologin on the fly doesn't make any semantic sense anyway
[10:01] <pitti> mvo: everything else is a separate process
[10:02] <mvo> do we need to care about reloading gdm at all then? or should this just be removed from the list of services checked by the postinst?
[10:02] <pitti> it was necessary for hardy (gdm <= 2.20)
[10:02] <slangasek> mvo: we should care about it as outlined above
[10:03] <pitti> mvo: you mean s/reload/restart/?
[10:03] <pitti> merely reloading config files won't make the running gdm use the new libc6
[10:03] <slangasek> mvo: libc6 configures without reloading old gdm -> X crashes -> gdm still running -> bad
[10:04]  * mvo nods
[10:05] <slangasek> if [ "$idlopt" = restart ]; then if $idl reload > /dev/null 2>&1; then echo "done."; else echo "SQUIRRELS" failed="$service $failed"; fi; fi
[10:05] <slangasek> then in maverick, we remove gdm from the list and kill the nasty special-casing
[10:06] <mvo> sounds like a plan
[10:07] <pitti> so, we are down to one NBS: sugar-0.86; this only has one reverse-recommends (sugar-chat-activity-0.86) which is already uninstallable due to missing python-sugar-0.86, so away with it
[10:07] <slangasek> \o/
[10:08] <pitti> slangasek: if we sync sugar-chat-activity-0.86 we make it installable again (-3 fixed dependencies to work with 0.88)
[10:09]  * pitti checks whether it's on any image
[10:10] <mvo> http://paste.ubuntu.com/420309/
[10:10] <slangasek> pitti: if it were on an image and uninstallable already, we would've heard before now ;)
[10:11] <pitti> true that (I thought about "ship")
[10:11] <pitti> but it's not
[10:11]  * pitti syncs
[10:11] <slangasek> mvo: looks correct to me
[10:12] <slangasek> pitti: nah, we get installability reports for alternate CDs too?
[10:12] <mvo> thanks, I upload it into my test PPA and run a new upgrade test with it
[10:12] <mvo> but it should be fine
[10:17] <ogra> top
[10:17] <ogra> bah, wrong kbd, sorry
[10:18] <slangasek> 31337 ogra   10   0   50m  12m  18m S 95  5.3   32:25.67 xchat
[10:18] <ogra> slangasek, so i found my issue with the ompa netbook image ...
[10:18] <ogra> *omap
[10:18] <slangasek> the omap-lomaps - what's the issue?
[10:19] <ogra> its a bit tricky ... we bumped compcache to get the live session running, then found thats not enough and now omap netbook does only-ubiquity
[10:19] <ogra> which turned out to always end the install in http://paste.ubuntu.com/419902/
[10:20] <ogra> running swapoff and rmmodding both compcache modules before starting the install fixes it
[10:20] <ogra> (since 256M are enough for only-ubiquity that works fine)
[10:20] <ogra> i'm not really sure what to do about it
[10:21] <pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt suddenly started to have a lot of -doc packages which want demotion, but I don't see any recent change to the Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj line; was something changed recently which caused that, or should I investigate more?
[10:21] <slangasek> I honestly don't even know what compcache is, so I have a hard time following that
[10:22] <slangasek> swap compression?
[10:22] <pitti> doubledisk?
[10:22] <slangasek> twitch
[10:22] <ogra> yeah
[10:23] <ogra> its the compression tool we use on low ram installs
[10:23] <ogra> but it seems to have issues with the omap kernel
[10:23] <ogra> essentially it creates a compressed swap file in ram
[10:23] <slangasek> ogra: so compcache was bumped specifically for omap, but the reason for the bumping went away again?
[10:23] <ogra> slangasek, right
[10:24] <slangasek> and turning off compcache fixes the install
[10:24] <slangasek> so isn't reverting the compcache change the right thing to do?
[10:24] <ogra> slangasek, we need to test if its a general compcahce issue with omap or if dumping it back to 25% suffices
[10:24] <ogra> i'm not sure its not the module collidign with the 2.6.33 kernel
[10:24] <ogra> we dont use it in that context anywhere else
[10:25] <slangasek> are lowmem installs on omap a major concern?
[10:25] <ogra> yes
[10:25] <ogra> the beagle we currently support has only 256M
[10:26] <ogra> but we dont run the live session anymore and as soon as you have real swap all is fine (slow indeed, but stable)
[10:26] <slangasek> oh, man
[11:13] <slangasek> pitti: curious that these -doc demotions quite specifically cluster around java and gtkmm - but I also don't see what change would have triggered this
[11:37] <Riddell> slangasek: do we have an ETA for release?
[11:37] <elmo> Riddell: I hear the 29th is likely
[11:37] <cjwatson> slangasek: hdparm> ok, will check
[11:37] <cjwatson> pitti: no change I know wof - I'll investigate
[11:37] <cjwatson> *of
[11:38] <slangasek> Riddell: ETA: 10 more test cases
[11:38] <slangasek> Riddell: I figure a couple more hours, at least
[11:47] <slangasek> ttx, mvo: do either of you know if the warning at https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#MySQL%20upgrade still applies now that mysql-dfsg-5.0 is removed?
[11:48] <mvo> I don't know, sorry
[11:50] <slangasek> no worries
[11:51] <cjwatson> pitti: the problem is that supported *MUST* be last in STRUCTURE - fixing now
[11:52] <cjwatson> mvo: ^- note for future reference :)
[11:52]  * slangasek waves
[11:53] <mvo> cjwatson: ups, sorry, can we add a comment maybe in the file?
[12:00] <slangasek> cjwatson, ttx: does the disabling of splash on server only apply to new installs?
[12:00] <cjwatson> yes
[12:00] <slangasek> ok
[12:00] <stgraber> slangasek: amd64 done for edubuntu, I'll start i386 now
[12:01] <slangasek> stgraber: great, thanks
[12:02] <doko_> mvo: is this eglibc upload planned before the final?
[12:03] <slangasek> doko_: it's fairly important to resolve ASAP, before users en masse start upgrading and having their GDM restarted out from under them
[12:04] <mvo> doko_: so yes
[12:04] <cjwatson> mvo: done
[12:04] <cjwatson> mvo: (documented in germinate(1) too)
[12:04] <mvo> thanks
[12:06] <pitti> cjwatson: ah, cheers!
[12:07] <doko_> mvo: will you upload? I don't have any patches pending, no fix for bug 417757
[12:09] <mvo> doko_: sure, I can do that
[12:19] <cjwatson> slangasek: so should we use udevadm info in hdparm_options if it doesn't already have $ID_PATH, do you think?
[12:20] <stgraber> highvoltage: Hey, could you rsync i386 and test it quickly so we can make super-sure that it works ? ;)
[12:22] <slangasek> cjwatson: is that the most effective means of getting the information, or is poking under /sys/block/$dev/device better?
[12:22] <cjwatson> it seems the shortest way with least messing about
[12:23] <cjwatson> http://paste.ubuntu.com/420367/ is what I'm thinking of
[12:23] <cjwatson> maybe should add 2>/dev/null || true in there somewhere
[12:25] <cjwatson> so http://paste.ubuntu.com/420368/
[12:25] <slangasek> cjwatson: fair.  I assume that udevadm command is tested, since I'm unfamiliar with its semantics
[12:25] <cjwatson> $ udevadm info -n /dev/sda -q property | sed -n 's/^ID_PATH=//p'
[12:25] <cjwatson> pci-0000:00:1f.2-scsi-0:0:0:0
[12:25] <slangasek> cjwatson: also, /usr/lib/pm-utils/power.d/95hdparm-apm might need some work, it calls 'hdparm -i' on each device before ever calling hdparm_options
[12:25] <cjwatson> crap, yeah
[12:26] <cjwatson> wish I'd never touched this package now :)
[12:26] <slangasek> :)
[12:26] <slangasek> cjwatson: I think this bit can reasonably be deferred to SRU given that so far only one user seems to have run into it, so if you have higher-prio bugs...
[12:28] <cjwatson> the only other thing I'm working on right now is the apparent busybox shell bug I mentioned in the foundations meeting yesterday
[12:28] <slangasek> ok
[12:28] <cjwatson> which may be a "could do with a break" thing soon anyhoe
[12:28] <cjwatson> *anyhow
[12:48] <highvoltage> stgraber: doing now..
[12:48] <highvoltage> (syncing, that is, but it should go fast)
[12:54] <ara> stgraber, I am doing i386, almost finishing it
[13:11] <lool> slangasek: Would you consider a kexec arm bugfix: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/568283 ?
[13:11] <lool> I tested kexec with just a kernel some weeks ago, after fixing it, and it worked with just a kernel; this patch fixes it for initrd as well
[13:16] <ogra> lool, tested on all armel arches ?
[13:16] <lool> ogra: I was told by kernel folks that it is broken on all arches
[13:17] <ogra> yeah, but was the fix tested on all arches ?
[13:17] <lool> I can certainly believe that if the offset if fixed and the kernels are about the same size (== too big) on all Ubuntu subarches, it will appear on all subarches
[13:17] <lool> ogra: No, but does it matter given that it's broken on all subarches?
[13:17] <ogra> i wonder if you can just generalize in that 0x8000000
[13:18] <lool> ogra: generalize?
[13:19] <ogra> well, if 0x8000000 fits for all platforms
[13:19] <lool> 0x800000 is 8.4 MB or so; I can certainly believe that all our Ubuntu ARM kernels are bigger than that uncompressed
[13:20] <lool> In fact it's uncompressed size + compressed size
[13:20] <ogra> i.e. are you sure there is no bootloader code in ram befor the kernel for example that would move the kernel to a later place
[13:20] <ogra> i could imagine thats the case with redboot
[13:20] <lool> ogra: I dont understand what you're proposing
[13:20] <ara> edubuntu covered
[13:20] <lool> ogra: This is for kexec
[13:20] <lool> ogra: no bootloader is involved?
[13:20] <ogra> lool, i'm proposing nothing, i was just asking
[13:21] <ogra> lool, so the first kernel doesnt sit in ram ?
[13:21] <ogra> the one you load the second one with
[13:21] <slangasek> lool: would be considered, yes
[13:21] <lool> slangasek: Ok thanks
[13:21] <slangasek> ara: great, thanks!
[13:22] <lool> slangasek: it's in supported-kernel, so probably only on the DVD, didn't see it in any task or other seeds
[13:22] <slangasek> lool: correct
[13:23] <lool> ogra: The kernel loading the other kernel is in RAM, yes; I am not sure what you're asking
[13:24] <stgraber> ara: ok, I found quite a few bugs on edubuntu 32 and 64 bit, all of which are affecting the LTSP install, so don't worry about these, I'll get those fixed very soon and fixed for final
[13:24] <slangasek> so that leaves only edubuntu i386 upgrade untested?
[13:25] <stgraber> slangasek: seems like I'll actually need to upload both edubuntu-artwork and ltsp to fix our current bugs, though the ltsp change affects a file that's only used by edubuntu and won't affect ubuntu alternate (which works correctly)
[13:25] <ogra> lool, well, 0x0 has possibly the bootloader that loaded the first kernel 0x0+$sizeof_first_kernel occupies some space -> kexec gets run new kernel gets loaded to 0x0+$sizeof_first_kernel up to 0x0+$sizeof_second_kernel ... or do i misunderstand the principle ?
[13:25] <slangasek> stgraber: those are both post-RC, I guess (hope)?
[13:25] <ara> slangasek, upgrade edubutnu is marked as started by sbeattie
[13:25] <stgraber> slangasek: yeah
[13:25] <cjwatson> grr, busybox sh does subtle and terrifying things with the stack
[13:25] <slangasek> ara: excellent
[13:26] <slangasek> Riddell: ETA> RSN
[13:26] <ogra> lool, i was just wondering if 0x8000000 would suffice for that amount of stuff on all arches
[13:26]  * Riddell gets excited
[13:26] <sbeattie> slangasek: edubuntu upgrade eta completion in 10min or less.
[13:26] <slangasek> cool
[13:26] <slangasek> it's going to take me a lot longer than that to get everything published; guess I should get started :)
[13:27] <lool> ogra: I'm not sure what memory you're considering; I'm not familiar enough with the kexec and early boot allocation steps, what I see is that the current offset is too small for the size of our uncompressed + compressed Ubuntu kernels, so bumping it b a factor of 16 sounds good
[13:27] <slangasek> mvo: if you have the eglibc upload ready, I would accept that now to get a leg up on upgrades
[13:28] <ogra> lool, ok
[13:28] <slangasek> (rather, I would encourage another release team member to accept it since my hands are full)
[13:28] <mvo> slangasek: ok, uploading now
[13:31] <mvo> slangasek: what are the chances for OOo ? a auto upgrade test with the ooo ppa is currently running
[13:33] <slangasek> mvo: please upload it; I'll want to give armel a little more time to get the last one built before accepting, but we should have time to get it built and on all images in time for next week's ISOs
[13:33] <slangasek> (and in the meantime I'll push as much as possible through the queue)
[13:34] <mvo> slangasek: ok, cool. I will do it, if needed I will do another upload (as I said, full end-to-end test is still running). but I think its final
[13:35]  * mvo mubbles something about kvm being slow today for now obvious reason
[13:35] <slangasek> ok
[13:42] <ogra> slangasek, so plars tested 25% and 10% compcache and saw issues as well, i'd like to propose http://paste.ubuntu.com/420398/ (and adjust the default cmdline accordingly in debian-cd for omap)
[13:43] <sbeattie> slangasek: edubuntu i386 upgrade complete.
[13:43] <slangasek> sbeattie: huzzah
[13:43] <ttx> slangasek: anything you need from the server team, except converging to 110% test coverage rate ?
[13:44] <cjwatson>  * The size 504 was chosen because the Ultrix malloc handles that size
[13:44] <cjwatson>  * well.
[13:44] <cjwatson> how to tell the code you're working on is shiny and modern
[13:44] <slangasek> ogra: have my hands full for the next couple of hours staging the RC for other stuff; perhaps cjwatson or pitti can review?
[13:44] <slangasek> ttx: test test test!
[13:44] <ogra> slangasek, oki
[13:45] <ttx> slangasek: ok :)
[13:45] <cjwatson> ogra: that patch is OK by me
[13:45] <ogra> cjwatson, merci, so i can upload initramfs-tools to the queue ?
[13:46] <ogra> (and adjust debian-cd om antimony)
[13:46] <ogra> *on
[13:46] <cjwatson> yes
[13:47] <ogra> thanks (better asking twice at that stage of release :) )
[13:55] <mvo> if someone from ubuntu-archive could check #567148 that would be nice (another relatively small upgrade issue)
[13:56] <slangasek> ogra, asac: is bug #443147 still in progress for 10.04?
[13:59] <asac> slangasek: yes. we have a fix.
[13:59] <asac> slangasek: but too late for RC ... i have committed it and chrisccoulson will push an update if nothing else pops up today
[13:59]  * slangasek marks 'fix committed' then :)
[14:00] <asac> thanks
[14:10]  * cjwatson finds gross gross gross busybox bug that caused that RAID configuration difficulty
[14:11] <cjwatson> http://paste.ubuntu.com/420414/
[14:13] <ogra> oh my
[14:14] <cjwatson> there's an identical fix already in dash since 2007, although my first working attempt actually reproduced that fix almost character by character without having looked at it
[14:14] <ogra> -ETOOMANYSHELLS
[14:17]  * cjwatson punts queuewards
[14:52]  * slangasek pulls the mirror trigger
[14:52] <ogra> wohoo
[14:53] <slangasek> ogra: do we need to get that initramfs-tools upload in, so we can try again for omap?
[14:54] <ogra> slangasek, did you plan to re-roll any images right now ?
[14:54] <slangasek> ogra: just omap, if it helps get this sorted
[14:54] <ogra> it can wait until next build imho, we know it works if we manually swapoff and unload the modules
[14:54] <ogra> sure
[14:54] <slangasek> better to do it now than tomorrow when the archive may be in flux
[14:54] <ogra> yeah, indeed
[14:58] <slangasek> cjwatson: ^^ you already reviewed the initramfs changes then, yes?  Can you go ahead and accept?
[15:00] <cjwatson> the previous initramfs-tools change also in the queue was mine
[15:00] <slangasek> cjwatson: btw, queuebot seems down
[15:00] <cjwatson> could somebody review that?
[15:00] <slangasek> ok, looking
[15:00] <cjwatson> hmm, it seems to be still running here - I'll restart it
[15:01] <cjwatson> (sorry, may be a bit noisy in a moment)
[15:02] <slangasek> o hai bot
[15:02] <cjwatson> err, wut
[15:03] <cjwatson> um, I think it may be the server side that's busted
[15:03] <cjwatson> not seeing initramfs-tools on http://people.canonical.com/~ubuntu-archive/queue/lucid/unapproved/
[15:03] <slangasek> ah
[15:04] <cjwatson> everything from ubuntu-mono on is missing
[15:04] <slangasek> cjwatson: ack for initramfs-tools 75
[15:05] <cjwatson> stuck on a lock - I've killed it
[15:05] <cjwatson> should catch up in a few minutes
[15:05] <cjwatson> ok, accepted
[15:09] <slangasek> smoser: all ready for you to publish
[15:10] <smoser> ok. just finishing the pages updates. you will promote-daily or you want me to
[15:11] <slangasek> smoser: if you can do it great, otherwise I can do it in a bit
[15:11] <smoser> k. i'll do it.
[15:11] <slangasek> smoser: thanks
[15:13] <slangasek> Riddell: wiki.kubuntu.org doesn't love me, but https://wiki.kubuntu.org/LucidLynx/RC/Kubuntu has a typo - s/Realease/Release/
[15:17] <Riddell> fixed thanks
[15:17] <Riddell> and you can just use wiki.ubuntu.com of course :)
[15:18] <slangasek> yah, but by that point my browser didn't want to let go... :)
[15:20] <ScottK> ogra: Is xf86-video-omapfb on the omap image?
[15:21] <nhandler> lol, omgubuntu is already announcing the RC
[15:27] <smoser> slangasek, i seem to be running into a problem.
[15:27] <smoser>  /srv/ec2-images/releases/lucid/rc wasn't written as expected (not a dir)
[15:27] <slangasek> smoser: ah?
[15:28] <smoser> shoot.
[15:28] <smoser> never mind.
[15:28] <slangasek> ok
[15:28] <smoser> actualy, no. i still need some help.
[15:29] <slangasek> smoser: what've you got?
[15:30] <smoser> so that error is from my script, expecting that when i invoked for-project ubuntu publish-release lucid 20100420 server-uec yes rc
[15:30] <smoser> that it would create that dir above
[15:30] <smoser> instead, i think its creating
[15:30] <smoser>  /srv/ec2-images/simple/lucid/
[15:30] <smoser> s/think/see that/
[15:30] <slangasek> s/yes/named/
[15:30] <slangasek> sorry
[15:31] <slangasek> that's not at all obvious
[15:31] <slangasek> the 'yes' is used when the directory structure is like the one on releases.ubuntu.com (well, more precisely, it's used when the target *is* releases.ubuntu.com)
[15:32] <slangasek> and when you're publishing with per-milestone directories, 'named'
[15:32] <smoser> so 'named' for 'release' also then, right ?
[15:32] <smoser> that seems to have fixed it
[15:33] <slangasek> yes
[15:33] <smoser> alright. the 'all' acls are being set right now.
[15:33] <smoser> and i've updated the ami pages.
[15:34] <slangasek> spiff
[15:36] <ScottK> Is it OK to start accepting seeded packages after review now or should it still wait?
[15:38] <slangasek> ScottK: please accept them but keep an eye on the build queue as you do so, so it doesn't get too deep; there are some others that I wanted to get priority in the queue, but I don't now remember which ones they were and it'll be a bit yet before I can give it my attention, so no sense in leaving the builders idle in the meantime
[15:38] <ScottK> OK.
[15:38] <ScottK> Will do.
[15:42] <mvo> slangasek: please reject openoffice - "libevoablx.so" has a different name depending on the architecture (i386/amd64)!
[15:42] <slangasek> lamont: so is sycamore a little on the slow side?
[15:42] <slangasek> mvo: done
[15:42] <mvo> thanks
[15:42] <slangasek> mvo: what name does it get on armel? :)
[15:42] <lamont> slangasek: should be just like the others... let me go stare at the guts
[15:43] <mvo> slangasek: I think the suffix there is "TAKESTOOLONGTOBUILD"
[15:43] <slangasek> lamont: ok; then I'm probably just being impatient
[15:43] <slangasek> ah crap, just rejected -dictionaries too
[15:43]  * slangasek fishes it out of reject
[15:44] <lamont> Started 1 day, 9 hours, 58 minutes, 39.1 seconds  ago.
[15:44] <slangasek> lamont: ok, so that's just me being impatient :)
[15:44] <lamont> yeah - still have a ways to go... ISTR 42 hours to the timeout fail last time
[15:45] <lamont> which means I should peek in on it in about 5 hours or so
[15:45] <slangasek> lamont: would be nice if https://launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-7ubuntu3/+build/1698510 had the exact time, instead of "started on the 20th"
[15:45] <slangasek> though I guess that's not your dept :)
[15:45] <lamont> since this is the "well, lets see if it crashes at the bottom of the hill again" rebuild with no changes other than being on a different identical machine
[15:45] <ScottK> slangasek: Careful with lamont or you may get the exact time he killed the build there.
[15:45] <lamont> ah..  http://launchpad.net/builders/sycamore
[15:46] <slangasek> lamont: oh, thanks :)
[15:46] <slangasek> lamont: so if you check in on it in 5h and find that it *has* died, please prod here to have someone accept mvo's newer OOo upload
[15:47] <lamont> so... why is xchat suddenly deciding that I must be in mid-text selection and highlighting the world?
[15:47] <lamont> ah, ok
[15:49]  * ScottK looks for arch all things to accept ...
[15:50] <slangasek> not necessarily advantageous, we should be getting a langpack dump here soon too :)
[15:53] <ScottK> There's i386 builders laying around waiting and amd64 already has quite a backlog
[15:53] <lamont> slangasek: so... how would you feel about a 4 hour timeout on armel, instead of 2.5 hours?
[15:54] <slangasek> ScottK: fair 'nuff
[15:54] <slangasek> lamont: very sad
[15:54] <maxb> slangasek: I think all of Launchpad's "friendly times" display the exact timestamp as a tooltip on hover
[15:55] <slangasek> maxb: huh, nice
[15:55] <lamont> yeah - but the stuff that times out elsewhere, sometimes just times out on armel... the timeout we saw on satinash was during dpkg-deb. the other solution is a packaging change in oo.o to not have insanely huge binary packages.
[15:57] <slangasek> lamont: liposuction is not a packaging change
[15:57] <lamont> totally is
[15:57] <lamont> I can just see it.  openoffice.org-core-part{1,2,3,4,5,6,7,8}
[15:58] <ScottK> We could probably lzma the .debs then.
[15:58] <slangasek> isn't that what's actually being done here that's taking so long?
[15:58] <slangasek> I thought OOo was opted in to lzma
[15:59] <slangasek> lamont: oyah, how much ram does sycamore have?  it's probably deep in swap
[15:59] <slangasek> since lzma compression is mem-intensive
[15:59] <lool> slangasek: ericm did some testing of the kexec-tools binaries from a PPA on #ubuntu-arm and confirmed they fix the issue; I discovered that two of our 4 ARM kernels are broken WRT kexec -- but 2 out of 4 are working  ;-) -- so it's half useful, but we probably want to SRU kexec support in these kernels anyway
[15:59] <lamont> 512M, just like all the boards
[15:59] <slangasek> lool: sounds fine
[15:59] <lool> slangasek: I uploaded the package seconds ago; will show up in unapproved soon
[15:59] <lool> http://paste.ubuntu.com/420471/ debdiff
[16:00] <lool> slangasek: bug #517841 tracks kexec borkenness in the kernel
[16:00] <lool>  subject: [ubuntu/lucid] kexec-tools 1:2.0.1-1ubuntu3 (Waiting for approval)
[16:00] <lamont> -$stalled_pkg_timeout = 150;
[16:00] <lamont> +$stalled_pkg_timeout = 240;
[16:00] <lamont> slangasek: wanna +1 that?
[16:00] <slangasek> lamont: go for it
[16:00] <lamont> well, will you, rather than do you want to.
[16:00] <lamont> ta
[16:02] <lamont> slangasek: so I fully expect the current build will spend too long in dpkg-deb
[16:03] <lamont> I suppose I could be evil and tickle the build output via /proc/NN/fd
[16:03] <slangasek> lamont: the change won't take effect until the next attempt?
[16:03] <pitti> ooh, time for queue flush? :-)
[16:03] <slangasek> pitti: cf my comment to ScottK above
[16:03] <lamont> slangasek: correct
[16:03] <cjwatson> hm, queuebot is suffering from excessive caching
[16:03] <pitti> slangasek: if you need/want help with review, should we talk about criteria before?
[16:03]  * cjwatson pokes
[16:04] <lamont> unless you know how to modify perl variables in a running perl instance.
[16:04] <slangasek> lamont: tickling would be nice then, but not essential
[16:04] <pitti> slangasek: i. e. would you prefer only accepting bugs which aren't suitable for SRU (like installer fixes) and minimize package churn now, or also accept "safe and obvious" changes for RC bugs?
[16:04]  * lamont goes to test the theory on some less time-gobbling build
[16:04] <lamont> 'twould be nice if qbot did one line, instead of 99 million
[16:06] <slangasek> pitti: for the moment I think the build queues don't need more help, let me finish getting RC out and then we can talk :)
[16:08] <pitti> alright :)
[16:10] <lamont> totally wicked cool.  tickling works.  with apologies to the eglibc/ppc build log.
[16:11] <lamont> slangasek: in fact, I think I'll just do a while loop that tickles the oo.o build every 90 min or so
[16:11] <slangasek> heh, k
[16:13] <ogra> ScottK, nope, it isnt
[16:13] <ScottK> ogra: OK.  Thanks.
[16:13] <ogra> ScottK, buut users use it on omap for accelerating 2D
[16:14] <ScottK> ogra: We since got an OK to accept stuff that was on an ISO, but I was wondering  at the time if I could go ahead and accept it.
[16:14] <lamont> Compiling: sw/source/filter/html/wrthtml.cxx
[16:14] <lamont> DEBUG: Thu Apr 22 16:13:21 BST 2010
[16:14] <lamont> Compiling: sw/source/filter/html/SwAppletImpl.cxx
[16:15] <lamont> the DEBUG: timestamps are all me.
[16:15] <ogra> ScottK, ah
[16:16] <slangasek> ogra: omap respin queued, btw; will fire off as soon as initramfs-tools finishes publishing
[16:16] <ogra> slangasek, thanks :)
[16:16] <ogra> slangasek, there is also still bug 563618 but i'm happy to discuss that tomorrow
[16:16] <ogra> since you are very busy it seems
[16:16] <ScottK> But since it's armel only, it needn't wait.
[16:16] <ogra> :)
[16:17] <lamont> ogra: fix the clock?>
[16:17] <ogra> lamont, without battery thats hard :)
[16:18] <lamont> mountall bug which does not give the user a maintenance shell when fsck exits but makes it go into an endless loop
[16:18] <lamont> HOW ABOUT WE FIX MOUNTALL?
[16:18] <ogra> lamont, its not mountall and a fix is planned by ted tso
[16:19] <ogra> fsck needs an option that actually ignores the clock instead of forcefully trying to fix it
[16:19] <slangasek> the mountall bug is fix-committed
[16:19] <ogra> he agreed with that
[16:19] <slangasek> but at the end of the maintenance shell you would still have to reboot
[16:19] <ogra> yeah
[16:19] <ogra> thast why i set the clock to last mount time instead
[16:19] <ogra> (+1 min to prevent a race)
[16:25] <ScottK> pitti: There's a build slot open (the only pending am64 stuff in unseeded Universe).  I can accept something unless you've got something that's a priority?
[16:32] <pitti> ScottK: gnome-keyring perhaps
[16:32] <ScottK> pitti: If you've reviewed it, go ahead.
[16:33] <pitti> ScottK: no, I uploaded it myself
[16:33] <ScottK> Ah.
[16:34] <pitti> ScottK: nvidia-graphics-drivers-96  then
[16:34] <pitti> I can review it in a minute
[16:34]  * pitti @ phone
[16:37] <pitti> ScottK: accepted nvidia
[16:53] <pitti> ScottK: for the next slot, mono is pretty clear -- it's a dependency fix which we need to fix for final (I uploaded it, so would be good to have it reviewed/accepted by someone else)
[16:53] <ScottK> pitti: I'll have a look and see if I think I'm comfortable with reviewing it.
[16:55] <pitti> I reviewed libgphoto2, that's also okay and unambiguously appropriate for final (armel ftbfs fix)
[16:56] <ScottK> OK.
[16:56] <pitti> so we spoonfeed the buildds now, instead of just building a queue?
[16:56] <ScottK> Looking at mono now.
[16:56] <ScottK> slangasek said he had some priority stuff and asked me not to let it get too backed up until they were in
[16:56] <pitti> ack
[16:56] <pitti> it doesn't help to have amd64 build wine and eglibc, of course
[16:57] <pitti> but the nvidia driver is a quick one (just shuffling a few bits around)
[16:57] <ScottK> Wine is only in there because there's another build that has to come after it and it's on Ubuntu Studo's ISO
[16:57] <slangasek> yeah, eglibc and wine (if accepted, which it has been) were two of the priorities
[16:58] <ScottK> mono is easy enough.
[16:58] <cjwatson> I can find some review slots if needed, but given the above I won't jump in ad hoc
[16:58] <ScottK> slangasek: Any others?
[16:58] <slangasek> I have my brain back now, there are a couple more priorities which I'm just about to push through
[16:59] <pitti> I can help with review, too, but before we start I'd like to have some consensus which level of fixes we still accept -- i. e. only the absolute minimum (installer and component-mismatches), or securityish ones like gnome-keyring, or also ones which we could SRU, but have safe fixes
[17:00] <pitti> so that slangasek can get to some much needed sleep and rest :)
[17:00] <ScottK> pitti: Makes sense.  I guess we wait for direction from the boss then.
[17:00] <slangasek> pitti: let me finish my cherry-pick, then give me 15min afk, then we can pow-wow?
[17:01] <pitti> slangasek: sounds good (I'll be at dinner then, but I'll be back later on)
[17:03]  * pitti downgrades build score of the older glib2.0
[17:05] <slangasek> ogra: omap build started 10min ago
[17:06] <ogra> slangasek, thanks a lot
[17:07] <slangasek> ok, done picking over the queue; afk for a few
[17:33] <lamont> killed the glib2.0 ubuntu3 build on hubbard, since it's stale
[17:35] <slangasek> pitti, ScottK: so the accept criteria I have in my head are: things that break the installer or upgrades; things needed to get the archive back in shape (component-mismatches, FTBFS fixes); gross security bugs (like gnome-keyring); and selectively, fixes for other high impact bugs *if* the change is obviously correct and carries minimal risk of regression
[17:36] <ScottK> OK.
[17:36] <ScottK> slangasek: Would you review gnomee-keyring then?  Sounds like it's a priority.
[17:36] <slangasek> ure
[17:36] <slangasek> sure
[17:38] <ScottK> slangasek: clamav doesn't ~ fit that criteria, but debconf handling is reasonably broken with what we have and the peinding upload syncs us with with Debian (and that the maintainer is confident enough of he's putting it in Volatile for Lenny users)
[17:41] <slangasek> oh, I think I have one more category in there - things that break users' ability to boot their systems
[17:41] <slangasek> but chances are it'll be me uploading those, and someone else gets to review them :)
[17:42] <slangasek> ScottK: looking at clamav now
[17:42] <ScottK> slangasek: Thanks.
[17:45] <slangasek> ScottK: hmm, haven't ruled it out, but too big for me to review at my current attention level
[17:45] <ScottK> slangasek: I understand.
[17:45] <ScottK> Iit's not urgent to get into today, I'd just really like it in for the release.
[17:49] <pitti> slangasek: understood, thanks
[17:52] <cjwatson> uploaded hdparm per our discussion earlier
[18:14] <stgraber> slangasek: did you see ltsp -0ubuntu8 going through the queue ? I uploaded it this morning but can't find it in the queue or in the archive (last mail from LP was Waiting for approval)
[18:20] <ScottK> stgraber: It's still in queue.
[18:25] <stgraber> ScottK: ah, found the issue, I wasn't looking at "unapproved" ;)
[18:26] <lamont> slangasek: what did you do to acorn? :-p
[18:30] <lamont> slangasek: whatever livecd build you were doing on acorn, do it again maybe? (rebooted acorn from apparent faceplant)
[18:31] <ScottK> lamont: I think he went for a nap.
[18:31] <lamont> I don't blame him
[18:31] <lamont> anyway, oh hai. I killed some dead thing. sry
[19:09] <stgraber> slangasek, cjwatson: As edubuntu finally has its new artwork, we'd like to update our gfxboot logo, where should we do that and how ?
[19:16] <slangasek> lamont: oh man, again? :P  Ok, re-launching
[19:17] <lamont> sorry - have serial this time.
[19:36] <ScottK> slangasek: I screwed up and accepted librsvg for lucid-proposed.
[19:36] <ScottK> Arrgh.
[19:36]  * ScottK takes a break.
[19:45] <slangasek> lamont: um... failed again, much faster this time
[19:46] <slangasek> ScottK: does that need removed back out again?  I don't think having packages in -proposed before final is out hurts anything - or were you just concerned about the procedure?
[19:47] <slangasek> stgraber: I'll have to defer to cjwatson on that one, sorry
[19:48] <ScottK> slangasek: I don't think there's any actual harm.
[19:49]  * ScottK figures rapid confession of errors is a good policy right before release.
[19:49] <ScottK> slangasek: I've been through most of the stuff that was obvious enough for me or I didn't upload it and amd64 is keeping up OK.
[19:51] <slangasek> ScottK: ok, cool.  now that the more-urgent-y stuff is done, there's no reason to rate-limit the accepts since that'll just leave the queue empty later when we're all sleeping :)
[19:52] <ScottK> OK.
[19:52] <slangasek> lamont, ogra: oh, blast; we already have archive skew affecting armel, which is why the second omap retry failed - glib, mono uninstallable :(
[19:52] <slangasek> ogra: will try again once that's cleared up
[20:06] <ogra> slangasek, thanks, no hurry im sure it will work at some point
[20:06] <slangasek> ScottK: quassel> so the only substantive Linux-affecting changes are the ones already in debian/patches - important enough to have the version number bumped to risk a build problem between now and Tuesday?
[20:06] <ogra> and i'm confident its all fixed :)
[20:07] <ScottK> slangasek: Technically the benefit is low, but I think the risk is low (we've never had any misbuild problems with the package), but the social benefits to the upstream relationship are worth the (IMO minimal) technical risk.
[20:19] <pitti> oh, we are already accepting lucid-proposed uploads?
[20:19] <pitti> (librsvg)
[20:19] <pitti> or was that an accident?
[20:19] <ScottK> pitti: Not on purpose
[20:19] <ScottK> (it was an accident)
[20:28]  * slangasek gets some sleep
[20:29] <pitti> slangasek: sleep well!
[20:30] <pitti> mvo: I'm currently reviewing OO.o, and TBH I don't understand the changes just by looking at the diff
[20:30] <pitti> mvo: was that already discussed with ccheney/Debian?
[20:31] <pitti> mvo: also, why was debian/openoffice.org-common.links dropped entirely?
[20:31] <mvo> pitti: what can I do? should I write up the design in the bugreport?
[20:31] <mvo> pitti: openoffice.org-common.links should not be dropped, let me check the diff
[20:31] <pitti> mvo: I'm primarily interested in how much you trust this and how much it was tested
[20:31] <pitti> mvo: and it adds several debian/*.links.in files
[20:32] <pitti> which add retistere-components symlinks
[20:32] <pitti> those look related to "change the way stuff is registered"
[20:32] <mvo> pitti: I talked to _rene_ about it, but did not get that much feedback (other than a principal "that should work"). I talked to ccheny but did not get much feedback
[20:32] <mvo> pitti: it adds two links.in files, yes and changes the way the postinst scripts run
[20:33] <mvo> pitti: please reject it, the -common.links removal is a accident
[20:33] <mvo> pitti: sorry for that
[20:33] <pitti> mvo: (don't get me wrong, I trust you :) but for peer review to make any sense I want to at least roughly understand what's happening here)
[20:33] <ScottK> pitti: There is a sync request pending for nautilus-share that ought to be reviewed by someone who understands Samba better than I do.  The diff is http://pastebin.com/CtNwdmYb.  If you're comfortable with it, the mass-sync rune would be "sync 565418 -S unstable".
[20:34] <mvo> pitti: sure, and it already uncovered the removal of the -common.links file
[20:34]  * pitti has NFC about samba, though; slangasek has, perhaps he can review that when he's back?
[20:35] <pitti> mvo: I take it you already tested upgrades with that version?
[20:35] <mvo> pitti: so, the reason why the pre-depends on openoffice.org-core were needed is that it needs  a working services.rdb file and a working uno (ure) to register the components
[20:35] <mvo> pitti: but the pre-depends make apt fall over badly
[20:35] <pitti> right
[20:36] <mvo> pitti: so the idea is to make sure external components are identifyable via the links in the external-components dir
[20:36] <pitti> mvo: those packages configure stuff in preinst? that seems wrong..
[20:36] <ScottK> pitti: OK.  I thought you knew about everything. ;-)
[20:36] <mvo> pitti: and then openoffice.org-core can unregister (revoke) all of them when it upgrades
[20:36] <ScottK> I'll ask him when he returns
[20:36] <bdmurray> bug 568628 would be worth looking at
[20:36] <mvo> pitti: yes, preinst of -evolution is used to unregister the components
[20:36] <pitti> ScottK: unfortunately I don't yet have that black belt :)
[20:37] <mvo> pitti: ooo needs the component (from ooo-evolution) still loadable in order to unregister
[20:37] <pitti> mvo: (rejected)
[20:37] <ScottK> pitti: I do recall slangasek saying he wanted to give the current OOo build on armel a chance to finish.
[20:37] <mvo> pitti: thanks, I already have a new one with the correct file ready
[20:37] <pitti> ScottK: right, and it seems we need a new upload anyway
[20:38] <pitti> ScottK: right, it's at dh_strip, looking good
[20:38] <pitti> I'm eager to get it accepted soonish, so that it can finish on arm on time
[20:38] <mvo> pitti: so now ooo-evo checks if it can register/revoke (if ooo-core is configured). if not, that is ok, ooo-core will take care of it, it will unregister components when it goes into unconfigured state and re-register them when finished
[20:39] <pitti> mvo: did you run "install from scratch" and "upgrade from hardy/karmic" tests with that?
[20:39] <ScottK> Last time it timed out on one of the dpkg-deb attempts, so we aren't home free yet.
[20:39] <mvo> pitti: yes, that worked, but uncovered a bug in the version in my https://edge.launchpad.net/~mvo/+archive/openoffice/+packages PPA
[20:39]  * pitti gives the buildd hamsters some more proteins
[20:40]  * pitti hugs mvo, thanks for wrestling with this beast :)
[20:40] <mvo> pitti: (broken symlinks because OOo has different names for the lib on different architectures, this is why there is a links.in file now :/
[20:40] <asac> new ooo?
[20:40] <asac> oh no
[20:40] <mvo> pitti: yeah, its a challenge
[20:40] <pitti> mvo: ok, so let's accept this after the current armel build finished and the new one is uploaded
[20:41] <mvo> pitti: I did get various register/unregister/upgrade on my amd64 and once its build in my PPA I will do another i386 upgrade test
[20:41] <asac> previous armel build didnt even finish :(
[20:41] <ScottK> asac: It timed out during the build.
[20:41] <asac> ScottK: ah ok. so its not in yet?
[20:42] <ScottK> lamont installed some special magic that should help this time.
[20:42] <ScottK> Not yet, no.
[20:43] <mvo> pitti: hrm, openoffice.org-common.links needs to become openoffice.org-common.links.in otherwise it will clean it away, but there is no content change, just a rename
[20:43] <pitti> mvo: sounds fine
[20:43] <mvo> thanks
[20:52] <ScottK> pitti and slangasek: I think we'll need to come to a decision about if we are going to allow Sparc's progress to gate what we let in for the release.  There's already more than enough stuff to retry to keep Sparc busy for quite a while.
[20:53] <ScottK> My recommendation would be to not worry about archive skew and Sparc.  It will get as much built as it can.
[20:53] <pitti> it says "six hours", no idea how reliable that is
[20:53] <ScottK> That's so far.
[20:53] <ScottK> I may be wrong, but I suspect it will run way behind.
[20:54] <pitti> it'll build main first, right? so that CD images have at least a good chance to get done, and universe can catch up until the bitter end on Thursday
[20:54] <ScottK> Yes.
[20:54] <pitti> for my part, I'm pretty much done with unapproved, from what I feel able to sign off
[20:54] <pitti> OO.o is still on the plan, and I'm currently reviewing busybox
[21:03] <pitti> slangasek: ah, found the IRC discussion with directhex about indicator-application (I was going to reject it first, but asked him first); accepted and checked banshee-community-extensions; I'll watch/process binNEW/NBS for that
[21:05]  * pitti waves good night
[21:06] <ScottK> Good night pitti.
[21:12] <mvo> pitti: I uploaded a new ooo, you may wait with accepting it a little bit though, the ppa should finish tonight
[21:12] <mvo> pitti: and then I can run another test upgrade
[21:13] <ScottK> We still want the current armel build to finish (or not) first in any case.
[21:15]  * lamont looks in on it
[21:16] <lamont> mmc0: Timeout waiting for hardware interrupt.
[21:16] <lamont> asac: what are you guys doing to me?
[21:21] <asac> ouch
[21:22] <asac> lamont: not progress in build log forever?
[21:24] <lamont> oh.  oo.o is in dpkg-shlibdeps.
[21:24] <lamont> it's getting _close_
[21:24] <lamont> well, to dpkg-deb which is where the pain is
[21:27] <lamont> asac: that error was from acorn
[21:27] <lamont> so maybe during a livecd-rootfs build
[21:28] <lamont> anyway, I expect that we'll see oo.o  finish at some point.  and hopefully 4 hours of idle time is enough, otherwise I'll need to hack in the same "progress" hack
[21:29] <lamont> while [ -d /proc/16409 ]; do echo DEBUG: $(date) >> /proc/16409/fd/1; sleep 90m; done & <-- I win
[21:38] <asac> great. thats life ;)
[21:41] <cjwatson> stgraber: erm.  it's kind of late.  could you check out lp:~ubuntu-cdimage/debian-cd/ubuntu (you won't be able to commit there, it's just a mirror) and send me image files that match data/lucid/edubuntu.{pcx,png} in dimensions and format?
[21:41] <stgraber> cjwatson: I can certainly do that
[21:42] <stgraber> cjwatson: for the kind of late, that's what I told the guys in Canonical design team over the last 6 weeks ;)
[21:43] <ev> can someone remind me if freeze exceptions apply to wubi, or if I can upload a version with refreshed artwork to match the new branding
[21:45] <cjwatson> stgraber: I can imagine ...
[21:48] <stgraber> highvoltage: ^ I've got to go to a meeting, would be awesome if you could do that. We'll need to re-render the logo with the font in white and have it replace the current logo on both files.
[21:58] <lamont> note to self:  2010-04-22 21:45
[22:00]  * lamont wakes up and puts that in the build log where it'll actually have context
[22:06] <highvoltage> cjwatson, stgraber: http://people.ubuntu.com/~jonathan/files/lucid/edubuntu/bootimages/
[22:48] <doko_> how are the bets for the OOo build to die?
[22:52] <ScottK> We're all cheering for it to succees, but I don't think anyone is willing to put up money that it will.
[22:52] <ScottK> Of course, lamont's special magic may be enough.....
[23:03] <lool> slangasek: The dash NEWS entry is useless in Ubuntu; is it useful to drop it?  (it's shown to apt-listchanges users which is in main, not sure if that's common); http://paste.ubuntu.com/420694/
[23:04] <lool> slangasek: uploaded, but please reject if you feel that's too risky
[23:04] <lool> the other entries were relatively relevant, except perhaps the xkeyboard-config one related to ctrl-alt-backspace which I think we also disable since a while