[00:04] 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] 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] (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] stgraber: out in < 18h [00:06] stgraber: can you do the re-testing before then? [00:07] when would we get the new images ? [00:07] (and yes, that's all that's all that would change) [00:08] stgraber: well, just missed the publisher, so... in 3h40 [00:10] 11pm here, still possible for me to do the tests, so yeah, please go ahead [01:43] 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] slangasek: ok (I could have added them on the tracker ;)) [01:44] oh, hah, yes you could [01:44] :) [02:06] 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] how long is its build time? [02:07] we also have a weekend's-worth of langpack builds incoming [02:08] * ScottK looks [02:10] slangasek: 40 - 45 minutes [02:12] alright [02:13] 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] (i.e., tomorrow once the trigger is being pulled) [02:14] Sounds reasonable. [02:14] I didn't review it either. [02:31] slangasek: If you have a moment would you please toss "sync 567673 -S unstable" at mass-sync.py? [02:31] tossing [02:33] Thanks. [02:33] done [02:33] Excellent. [03:27] 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] Cleared the non-partner stuff out of New. [06:43] stgraber: any progress on the edubuntu re-testing? [07:11] morning [07:12] good morning ara [07:12] morning mvo! [07:16] Good morning [07:49] morning ttx [07:51] morning, all [07:52] Hey ara, slangasek ! [07:52] lovely morning for a RC. [07:52] mvo: I sent you some comments on the OOo merge in one of the bugs - did you get those? [07:53] slangasek: thanks, let me check [07:56] slangasek: thanks, those are good comment! I will answer in the bugreport [08:27] cjwatson: seems the fix for bug #515023 didn't cover all the cases where this bug will manifest - bug #567182 [08:27] Launchpad bug 515023 in hdparm "ATA pass-through commands preventing external HDD to be mounted" [High,Fix released] https://launchpad.net/bugs/515023 [08:27] Launchpad bug 567182 in hdparm "can't update acpi-support package on lucid running of an external hdd" [Undecided,New] https://launchpad.net/bugs/567182 [08:28] (but I think that's SRU material at this point) [08:28] well, at least on the hdparm side - the acpi-support fix is straightforward [09:34] 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] er, odd [09:37] mvo: or, not odd - sigh, a clear regression in the fix for bug #505838 [09:37] Launchpad bug 505838 in eglibc "Logic to restart services on NSS upgrade misses some" [Undecided,Fix released] https://launchpad.net/bugs/505838 [09:37] yeah, I'm looking into it now [09:37] oh, how wonderful [09:37] I thought it might be this one [09:37] bzr is still fetching the packaging branch [09:38] anyway, I think I have a fix [09:38] well, wait... why would kill -HUP $(pidof gdm) cause a restart? [09:38] that's what 'reload gdm' should do [09:38] its seems like "idlopt" need to be checked for "restart" instead of "idl" [09:39] in line 337 [09:39] oh [09:39] right, because it's sensitive to upgrade order, meh [09:40] 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] *urgh* [09:40] actually [09:41] even that won't do it, I think [09:41] gdm takes -USR1 as its reload signal, not -HUP [09:41] I don't know what gdm does on -HUP [09:41] seb128 may know [09:41] and I'm not testing on this instance of it :) [09:42] -HUP just killed it in my VM [09:42] well, restarted it [09:42] mvo, not offhand no [09:43] slangasek: could we always use the init script for lucid? its provided for compatbility, right? [09:43] in the restart of gdm I mean [09:43] case SIGHUP: [09:43] g_debug ("Got HUP signal"); [09:43] ret = TRUE; [09:43] break; [09:43] it seems it's doing nothing fancy [09:43] mvo: the init script in lucid isn't an init script, it points at upstart-job and won't DTRT [09:43] there is a comment in the code saying it should be fixed to re-read config, etc [09:44] seb128: is that true on hardy as well? [09:44] seb128: so it ignores it, which isn't what we want either :) [09:44] slangasek: ok, clearly bad [09:44] seb128: does the new gdm handle SIGUSR1 the way the old one did? [09:44] mvo, it should, gdm didn't change too much in lucid [09:44] slangasek: let me do a patch and ask for review [09:44] seb128: ok [09:44] mvo: ok, thanks [09:45] slangasek, what was the old one doing on SIGUSR1? reload config? [09:45] seb128: yes [09:45] the new one seems to toggle debug mode on SIGUSR1 [09:45] [09:45] " g_debug ("Got USR1 signal"); [09:45] /* FIXME: [09:45] * Play with log levels or something [09:45] */ [09:45] ret = TRUE; [09:45] gdm_log_toggle_debug (); [09:45] " [09:46] seb128: does the new gdm handle NSS and PAM in-process? [09:46] or does it spawn a helper? [09:46] I don't know [09:46] ok [09:46] pitti, ^ maybe you know? [09:48] looking [09:49] PAM is handled in /usr/lib/gdm/gdm-session-worker [09:49] which isn't the daemon, just spawned when you create a new session [09:49] hm, but apparently it's not terminated after starting the session [09:50] slangasek: something simple like http://paste.ubuntu.com/420299/ ? [09:50] pitti: but is it terminated when you /close/ the session? [09:51] pitti: and are NSS lookups handled by that process, too? [09:51] oh, so maybe we don't need to handle gdm at all? [09:51] mvo: at this point it doesn't appear we *can* handle gdm sensibly, so that may have to be the answer anyway [09:52] gdm-binary calls getpwnam, getpwuid [09:52] thanks! [09:52] which means that gdm *should* get restarted (gracefully) after a libc upgrade [09:52] slangasek: it's restarted when you log out, and gdm login screen comes back, yes [09:53] pitti: ok; unfortunately that doesn't help us with NSS, though [09:53] slangasek: what do you mean with "NSS handling"? calling getpwent() and the like? [09:54] gdm doesnt use nss.h [09:55] 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] pitti: yes, getpwnam, getpwuid, getXXbyXXX [09:55] slangasek: ok, do you need a bug with it or can I just upload as it is? [09:55] pitti: those calls are the whole reason libc6 has restart handling in its maintainer script [09:55] 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] 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] but gdm-binary apparently only needs it to look up the "gdm" user [09:56] which it runs the greeter session as [09:56] not for actual real users [09:56] pitti: does it call that once and cache the answer? [09:57] slangasek: no, it looks up "gdm" user/group, then seteuid()s, and forgets everythign [09:58] pitti: aha [09:58] i. e. if the gdm user should change during dist-upgrade, things break [09:58] but this really really ought not to happen [09:58] (changing uids during upgrade, I mean) [09:58] pitti: that's not even a valid use case :) [09:58] slangasek: oh, how is it not? pretty much every non-root daemon does it that way? [09:59] 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] pitti: the uid of the gdm user changing during dist-upgrade? that's not a valid use case [09:59] ah, ok [09:59] *phew* :) [10:00] 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] mvo: everything else is a separate process [10:02] 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] it was necessary for hardy (gdm <= 2.20) [10:02] mvo: we should care about it as outlined above [10:03] mvo: you mean s/reload/restart/? [10:03] merely reloading config files won't make the running gdm use the new libc6 [10:03] mvo: libc6 configures without reloading old gdm -> X crashes -> gdm still running -> bad [10:04] * mvo nods [10:05] if [ "$idlopt" = restart ]; then if $idl reload > /dev/null 2>&1; then echo "done."; else echo "SQUIRRELS" failed="$service $failed"; fi; fi [10:05] then in maverick, we remove gdm from the list and kill the nasty special-casing [10:06] sounds like a plan [10:07] 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] \o/ === james_w`` is now known as james_w [10:08] 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] http://paste.ubuntu.com/420309/ [10:10] pitti: if it were on an image and uninstallable already, we would've heard before now ;) [10:11] true that (I thought about "ship") [10:11] but it's not [10:11] * pitti syncs [10:11] mvo: looks correct to me [10:12] pitti: nah, we get installability reports for alternate CDs too? [10:12] thanks, I upload it into my test PPA and run a new upgrade test with it [10:12] but it should be fine [10:17] top [10:17] bah, wrong kbd, sorry [10:18] 31337 ogra 10 0 50m 12m 18m S 95 5.3 32:25.67 xchat [10:18] slangasek, so i found my issue with the ompa netbook image ... [10:18] *omap [10:18] the omap-lomaps - what's the issue? [10:19] 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] which turned out to always end the install in http://paste.ubuntu.com/419902/ [10:20] running swapoff and rmmodding both compcache modules before starting the install fixes it [10:20] (since 256M are enough for only-ubiquity that works fine) [10:20] i'm not really sure what to do about it [10:21] 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] I honestly don't even know what compcache is, so I have a hard time following that [10:22] swap compression? [10:22] doubledisk? [10:22] twitch [10:22] yeah [10:23] its the compression tool we use on low ram installs [10:23] but it seems to have issues with the omap kernel [10:23] essentially it creates a compressed swap file in ram [10:23] ogra: so compcache was bumped specifically for omap, but the reason for the bumping went away again? [10:23] slangasek, right [10:24] and turning off compcache fixes the install [10:24] so isn't reverting the compcache change the right thing to do? [10:24] slangasek, we need to test if its a general compcahce issue with omap or if dumping it back to 25% suffices [10:24] i'm not sure its not the module collidign with the 2.6.33 kernel [10:24] we dont use it in that context anywhere else [10:25] are lowmem installs on omap a major concern? [10:25] yes [10:25] the beagle we currently support has only 256M [10:26] 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] oh, man [11:13] 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] slangasek: do we have an ETA for release? [11:37] Riddell: I hear the 29th is likely [11:37] slangasek: hdparm> ok, will check [11:37] pitti: no change I know wof - I'll investigate [11:37] *of [11:38] Riddell: ETA: 10 more test cases [11:38] Riddell: I figure a couple more hours, at least [11:47] 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] I don't know, sorry [11:50] no worries [11:51] pitti: the problem is that supported *MUST* be last in STRUCTURE - fixing now [11:52] mvo: ^- note for future reference :) [11:52] * slangasek waves [11:53] cjwatson: ups, sorry, can we add a comment maybe in the file? [12:00] cjwatson, ttx: does the disabling of splash on server only apply to new installs? [12:00] yes [12:00] ok [12:00] slangasek: amd64 done for edubuntu, I'll start i386 now [12:01] stgraber: great, thanks [12:02] mvo: is this eglibc upload planned before the final? [12:03] 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] doko_: so yes [12:04] mvo: done [12:04] mvo: (documented in germinate(1) too) [12:04] thanks [12:06] cjwatson: ah, cheers! [12:07] mvo: will you upload? I don't have any patches pending, no fix for bug 417757 [12:07] Launchpad bug 417757 in eglibc "[karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups" [High,Fix released] https://launchpad.net/bugs/417757 [12:09] doko_: sure, I can do that [12:19] slangasek: so should we use udevadm info in hdparm_options if it doesn't already have $ID_PATH, do you think? [12:20] highvoltage: Hey, could you rsync i386 and test it quickly so we can make super-sure that it works ? ;) [12:22] cjwatson: is that the most effective means of getting the information, or is poking under /sys/block/$dev/device better? [12:22] it seems the shortest way with least messing about [12:23] http://paste.ubuntu.com/420367/ is what I'm thinking of [12:23] maybe should add 2>/dev/null || true in there somewhere [12:25] so http://paste.ubuntu.com/420368/ [12:25] cjwatson: fair. I assume that udevadm command is tested, since I'm unfamiliar with its semantics [12:25] $ udevadm info -n /dev/sda -q property | sed -n 's/^ID_PATH=//p' [12:25] pci-0000:00:1f.2-scsi-0:0:0:0 [12:25] 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] crap, yeah [12:26] wish I'd never touched this package now :) [12:26] :) [12:26] 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] 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] ok [12:28] which may be a "could do with a break" thing soon anyhoe [12:28] *anyhow [12:48] stgraber: doing now.. [12:48] (syncing, that is, but it should go fast) [12:54] stgraber, I am doing i386, almost finishing it [13:11] slangasek: Would you consider a kexec arm bugfix: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/568283 ? [13:11] Ubuntu bug 568283 in kexec-tools "kexec fails on ARM boards because initrd is placed too close to the kernel image" [Undecided,New] [13:11] 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] lool, tested on all armel arches ? [13:16] ogra: I was told by kernel folks that it is broken on all arches [13:17] yeah, but was the fix tested on all arches ? [13:17] 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] ogra: No, but does it matter given that it's broken on all subarches? [13:17] i wonder if you can just generalize in that 0x8000000 [13:18] ogra: generalize? [13:19] well, if 0x8000000 fits for all platforms [13:19] 0x800000 is 8.4 MB or so; I can certainly believe that all our Ubuntu ARM kernels are bigger than that uncompressed [13:20] In fact it's uncompressed size + compressed size [13:20] 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] i could imagine thats the case with redboot [13:20] ogra: I dont understand what you're proposing [13:20] edubuntu covered [13:20] ogra: This is for kexec [13:20] ogra: no bootloader is involved? [13:20] lool, i'm proposing nothing, i was just asking [13:21] lool, so the first kernel doesnt sit in ram ? [13:21] the one you load the second one with [13:21] lool: would be considered, yes [13:21] slangasek: Ok thanks [13:21] ara: great, thanks! [13:22] slangasek: it's in supported-kernel, so probably only on the DVD, didn't see it in any task or other seeds [13:22] lool: correct [13:23] ogra: The kernel loading the other kernel is in RAM, yes; I am not sure what you're asking [13:24] 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] so that leaves only edubuntu i386 upgrade untested? [13:25] 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] 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] stgraber: those are both post-RC, I guess (hope)? [13:25] slangasek, upgrade edubutnu is marked as started by sbeattie [13:25] slangasek: yeah [13:25] grr, busybox sh does subtle and terrifying things with the stack [13:25] ara: excellent [13:26] Riddell: ETA> RSN [13:26] lool, i was just wondering if 0x8000000 would suffice for that amount of stuff on all arches [13:26] * Riddell gets excited [13:26] slangasek: edubuntu upgrade eta completion in 10min or less. [13:26] cool [13:26] it's going to take me a lot longer than that to get everything published; guess I should get started :) [13:27] 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] mvo: if you have the eglibc upload ready, I would accept that now to get a leg up on upgrades [13:28] lool, ok [13:28] (rather, I would encourage another release team member to accept it since my hands are full) [13:28] slangasek: ok, uploading now [13:31] slangasek: what are the chances for OOo ? a auto upgrade test with the ooo ppa is currently running [13:33] 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] (and in the meantime I'll push as much as possible through the queue) [13:34] 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] ok [13:42] 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] slangasek: edubuntu i386 upgrade complete. [13:43] sbeattie: huzzah [13:43] slangasek: anything you need from the server team, except converging to 110% test coverage rate ? [13:44] * The size 504 was chosen because the Ultrix malloc handles that size [13:44] * well. [13:44] how to tell the code you're working on is shiny and modern [13:44] 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] ttx: test test test! [13:44] slangasek, oki [13:45] slangasek: ok :) [13:45] ogra: that patch is OK by me [13:45] cjwatson, merci, so i can upload initramfs-tools to the queue ? [13:46] (and adjust debian-cd om antimony) [13:46] *on [13:46] yes [13:47] thanks (better asking twice at that stage of release :) ) [13:55] if someone from ubuntu-archive could check #567148 that would be nice (another relatively small upgrade issue) [13:56] ogra, asac: is bug #443147 still in progress for 10.04? [13:56] Launchpad bug 443147 in firefox "Firefox on ARM inappropriately adds scroll bars to many frames and images" [Unknown,Confirmed] https://launchpad.net/bugs/443147 === ogra_ is now known as ogra [13:59] slangasek: yes. we have a fix. [13:59] 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] thanks [14:10] * cjwatson finds gross gross gross busybox bug that caused that RAID configuration difficulty [14:11] http://paste.ubuntu.com/420414/ [14:13] oh my [14:14] 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] -ETOOMANYSHELLS [14:17] * cjwatson punts queuewards [14:52] * slangasek pulls the mirror trigger [14:52] wohoo [14:53] ogra: do we need to get that initramfs-tools upload in, so we can try again for omap? [14:54] slangasek, did you plan to re-roll any images right now ? [14:54] ogra: just omap, if it helps get this sorted [14:54] it can wait until next build imho, we know it works if we manually swapoff and unload the modules [14:54] sure [14:54] better to do it now than tomorrow when the archive may be in flux [14:54] yeah, indeed [14:58] cjwatson: ^^ you already reviewed the initramfs changes then, yes? Can you go ahead and accept? [15:00] the previous initramfs-tools change also in the queue was mine [15:00] cjwatson: btw, queuebot seems down [15:00] could somebody review that? [15:00] ok, looking [15:00] hmm, it seems to be still running here - I'll restart it [15:01] (sorry, may be a bit noisy in a moment) [15:02] o hai bot [15:02] err, wut [15:03] um, I think it may be the server side that's busted [15:03] not seeing initramfs-tools on http://people.canonical.com/~ubuntu-archive/queue/lucid/unapproved/ [15:03] ah [15:04] everything from ubuntu-mono on is missing [15:04] cjwatson: ack for initramfs-tools 75 [15:05] stuck on a lock - I've killed it [15:05] should catch up in a few minutes [15:05] ok, accepted [15:09] smoser: all ready for you to publish [15:10] ok. just finishing the pages updates. you will promote-daily or you want me to [15:11] smoser: if you can do it great, otherwise I can do it in a bit [15:11] k. i'll do it. [15:11] smoser: thanks [15:13] Riddell: wiki.kubuntu.org doesn't love me, but https://wiki.kubuntu.org/LucidLynx/RC/Kubuntu has a typo - s/Realease/Release/ [15:17] fixed thanks [15:17] and you can just use wiki.ubuntu.com of course :) [15:18] yah, but by that point my browser didn't want to let go... :) [15:20] ogra: Is xf86-video-omapfb on the omap image? [15:21] lol, omgubuntu is already announcing the RC [15:27] slangasek, i seem to be running into a problem. [15:27] /srv/ec2-images/releases/lucid/rc wasn't written as expected (not a dir) [15:27] smoser: ah? [15:28] shoot. [15:28] never mind. [15:28] ok [15:28] actualy, no. i still need some help. [15:29] smoser: what've you got? [15:30] 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] that it would create that dir above [15:30] instead, i think its creating [15:30] /srv/ec2-images/simple/lucid/ [15:30] s/think/see that/ [15:30] s/yes/named/ [15:30] sorry [15:31] that's not at all obvious [15:31] 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] and when you're publishing with per-milestone directories, 'named' [15:32] so 'named' for 'release' also then, right ? [15:32] that seems to have fixed it [15:33] yes [15:33] alright. the 'all' acls are being set right now. [15:33] and i've updated the ami pages. [15:34] spiff [15:36] Is it OK to start accepting seeded packages after review now or should it still wait? [15:38] 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] OK. [15:38] Will do. [15:42] slangasek: please reject openoffice - "libevoablx.so" has a different name depending on the architecture (i386/amd64)! [15:42] lamont: so is sycamore a little on the slow side? [15:42] mvo: done [15:42] thanks [15:42] mvo: what name does it get on armel? :) [15:42] slangasek: should be just like the others... let me go stare at the guts [15:43] slangasek: I think the suffix there is "TAKESTOOLONGTOBUILD" [15:43] lamont: ok; then I'm probably just being impatient [15:43] ah crap, just rejected -dictionaries too [15:43] * slangasek fishes it out of reject [15:44]