[00:27] No one minding the store? Still looking for armel desktop images. ETA? [04:14] Good morning [04:15] nice, seems the auto-posting worked? except for ubuntu desktop [04:16] Meh. Details. [04:16] How many people care about that one? [04:16] ;-) [04:17] GrueMaster: should be there now [04:18] post-qa 20111010.1 ubuntu/daily-live/oneiric-desktop-{i386,amd64,amd64+mac} [04:18] for some reason that doesn't error out, but doesn't do anything [04:19] posted manually [04:20] erm, what? adding in the UI doesn't work either [04:20] stgraber: help [04:21] I reenabled the images, but they have a wrong version (10, not 10.1) [05:06] I assume a seamonkey upload tonight is still fine in a few hours? (yes, I know it's close) [05:08] micahg: since it's in universe, yes [05:09] (and since we're still before the "1.5 days before release" cutoff for unseeded) [05:09] hopefully for P it will be actively maintained [05:43] gah [05:44] * cjwatson misses the bus and furthermore does not have the correct change. I may be a bit late to the office today [05:46] * slangasek listens to a transformer explode in the distance [05:48] * skaet will save a seat for cjwatson in the room [05:50] ... mind you this taxi driver has made me want to take my glasses off, so maybe I won't be that late [05:51] :) [06:20] good morning [06:20] .. cjwatson [06:20] cjwatson: so you are back home? [06:33] pitti, hiya, I believe cjwatson's on his way into Millbank right now. [06:37] * skaet --> breakfast, biab [07:07] pitti: good morning [07:07] pitti: so what needs changing on the tracker? [07:17] 6907 | 202 | 26 | 29315 | 20111010 | 2011-10-10 16:59:44 | 0 | 8 6904 | 202 | 26 | 29315 | 20111010.1 | 2011-10-10 16:59:16 | 3 | 10 [07:17] hmm, that didn't copy/paste well [07:18] basically the DB shows that Ubuntu Desktop i386 has been updated twice within 30s, once for 20111010 and once for 20111010.1 [07:18] stgraber: the ubuntu deskto images ought to be 20111010.1 [07:19] stgraber: but neither with post-qa nor with the web UI I'm able to change it [07:20] yeah, that's because 20111010.1 is already in the DB [07:20] post-qa apparently posted it 30s before posting 20111010 over it [07:22] strange [07:22] stgraber: so this needs some DB hacking? [07:22] yes, I'm on it [07:23] ok, should be good now [07:24] stgraber: thanks [07:24] apparently thaht killed the existing results, but that's no biggie [07:24] * pitti re-posts his results [07:25] ok, breakfast time, then running to Millbank [07:35] * skaet heading in to millbank. [07:39] well, so much for breakfast, didn't feel like waiting half an hour to get in ;) [08:01] stgraber: hm, that wasn't me as it happens, but maybe somebody else ran it by hand; the timestamps are such that I don't think those were automatic runs [08:02] maybe at some point I'll refactor the interface to make it more robust [08:17] morning all [08:18] apologies for the late-ish upload of jenkins - I've been testing the fix locally for the last few days to make sure it was good [08:18] if it could be accepted much appreciated [08:18] jamespage: that doesn't seem to be on the server image, is it? [08:18] No. [08:18] Server builds from main, so it can't be. [08:18] no - its in universe [08:19] jamespage: Accepted. [08:20] infinity, thanks [08:22] slangasek: Does that initramfs-tools upload fix my garbled plymouth? [08:22] * infinity might test in a bit. [08:29] * pitti reserves ross for ^ [08:30] slangasek, cjwatson: above ubiquity fixes bug 872119, which isn't a showstopper, but a bit of a wart [08:30] Launchpad bug 872119 in ubiquity (Ubuntu) ""Error occurred while copying the network settings" on bcmwl machine (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/872119 [08:30] skaet: ^ [08:30] yep, saw [08:30] what's your feeling, is that worth a respin? [08:30] (it's not limited to bcmwl) [08:31] accepted [08:31] yes it is [08:31] I mean yes it is worth it; I'll take care of it [08:31] ok [08:31] you'll drive the rebuilds? [08:31] yep [08:31] edubuntu-live should appear very soon including the exact same fix (that code was copy/pasted between the two) [08:31] in between fighting with libdevel-bt-perl [08:31] stgraber: already looking :) [08:32] accepted [08:32] made ubiquity/powerpc build jump the line all the way to the front, should start in a few mins [08:34] slangasek: That initramfs-tools did nothing for my corrupt plymouth. But I might fiddle with that idea a bit later. [08:45] i assume there will be another rebuild for the new ubiquity ? [08:45] oh, i should read backlog and not only -changes mails :P [08:59] ogra_: Ideally, yes. ;) [09:10] I hate to upload seamonkey like this, but I want to call it a night and the package works, also, it's not really any worse than it was before in terms of lintian unhappiness [09:26] micahg: "Not any worse" is a ringing endorsement. [09:27] it's pretty bad, the last 2 cycles, I've uploaded at the last minute, so not much cleanup has happened...now we hopefully have someone to care for it [09:34] I can't make libdevel-bt-perl work on current kernels. Although it's built on amd64/armel/i386, that's only because those buildds are on old kernels. Does anyone object if I remove the binaries on all architectures? [09:35] zero rdepends, sounds fine to me [09:36] g [09:36] (ops) [09:37] to clarify, I can make it work, just not reliably :-/ [09:37] I think I have some async-signal-safety bug somewhere - it sporadically hangs [09:44] can I get someone to reject the seamonkey upload? [09:46] micahg: sure, doing [10:17] ok, seamonkey issue was a false alarm, would it be possible to have it reviewed and unrejected/accepted? [10:21] ugh, 58 MB diff, reviewing that won't make too much sense.. [10:21] I'll have a look at the debian/ parts [10:21] pitti: thanks, for upstream, we have the exception anyways [10:24] micahg, does seamonkey build with the official branding? the channel is set to "nightly" in the packaging still [10:25] which should switch off official branding [10:25] chrisccoulson: yes, I don't think seamonkey has unofficial branding [10:25] are we also not creating translations for seamonkey? [10:26] chrisccoulson: it's broke ATM and I wasn't going to spend time on it right now (not a regression) [10:26] what's broken about it? [10:26] chrisccoulson: let's go back to -mozillateam [10:31] pitti: too late to leave rejected?, we're going to try one more time to get the locales to build if that's ok? [10:33] micahg: already accepted, sorry [10:33] pitti: ok, well, would you mind a second upload enabling translations then? [10:33] micahg: fine for me [10:33] ^ both of those should be ok (pitti acked the exceptions), please accept [10:34] review debian/ if you like [10:41] respins in progress === Riddelll is now known as Riddell [11:04] ... and started the preinstalled respins too, which I forgot [11:04] (but I forgot to set CDIMAGE_POST_QA=1 for those so I'll have to do it manually) [11:13] thanks :) [12:09] anyone on the server team seen https://code.launchpad.net/~gandelman-a/ubuntu/oneiric/cobbler/lp850880-850866/+merge/78904 [12:18] Aren't we past the 1.5 day mark now? [12:18] Doesn't seem that's a showstopper. [12:19] oh, are we? will we release Thu morning? [12:19] * tumbleweed assumed evening too [12:21] "unseeded universe [12:21] final freeze will be on Oct. 11 at 1200 UTC. " [12:21] from the mail [12:21] ah, thanks [12:23] we can't build anythign on powerpc right now anyway, unless we ask IS to kill the gcc-snapshot build (in an emergency) [12:24] think we want to squeeze in one more universe upload [12:24] then it will be done [12:24] pitti: seamonkey is killable...but it should be done soonish (30 min-1hr) [12:25] but seamonkey is release and also builds long, it must finish by tomorrow [12:25] ah, true [12:25] ~4 hours left on gcc-snapshot going by the last build [12:25] gcc shouldn't build for that long any more, though [12:26] so if we want fwts (can't hurt to have it), we could get it this evening [12:26] fwts and guichan, that'll be it [12:37] oh, I can't change the topic. Wanted to add the Unseeded Universe Final Freeze in there. [12:48] ^ looks good after some heavy filtering [14:12] infinity: why is your plymouth garbled? I don't see a bug report from you :) [14:20] slangasek: I'm not sure why mine is, and I don't care deeply right now. [14:21] slangasek: However, people using binary nvidia drivers (not me) seem to have an option between either "no X" or "no consoles". [14:21] slangasek: Daviey and davidm both have this issue. [14:21] infinity: as of when? [14:21] Not sure. davidm only upgraded today. [14:22] And Daviey's had no consoles "for a long time" and never reported it. [14:22] Special, no> [14:22] slangasek: Basically, vesafb conflicts with nvidia, so the default failure mode is no X. If you blacklist vesafb, you get X, but no consoles. I'm trying to sort out a magical combination that might get both. [14:23] infinity: I have tested vesafb+nvidia here and saw no conflicts; and support for the vesafb fallback was landed back in natty [14:23] so I need an actual bug report to go on [14:24] slangasek: I can file a bug on their behalf. I'm not sure how that's more informative than the above. ;) [14:24] I'm also not entirely sure who or what to blame. [14:24] (ie: where to file) [14:25] no, make them file it with ubuntu-bug so we get useful hardware info [14:25] I don't want proxy bugs :P [14:25] they can file it on plymouth, that's what everybody else does ;) [14:27] I will encourage such bug filings in a few minutes when I give up trying to sort out how to hackishly fix davidm's consoles. [14:34] infinity: do the affected systems have cryptsetup installed? [14:37] slangasek: Yes, in davidm's case. Not sure about Daviey. [14:37] ok [14:37] Damnit, same breakage with uvesafb. Consoles, but X doesn't start. [14:38] does cryptsetup need to prompt for a passphrase in the initramfs? [14:38] testing with FRAMEBUFFER=n forced could be illuminating [14:38] No encrypted root here no. [14:39] right, so FRAMEBUFFER=n could be safe to test [14:39] (overriding cryptsetup's setting) [14:39] slangasek: Forcing FB=no is most easily done with a snippet in conf.d still? [14:39] yes [14:43] slangasek: FB=n gets me no consoles and a working X. [14:43] heh [14:43] slangasek: Which sort of makes sense, since that's about the same as blacklisting vesafb. [14:43] no it isn't? [14:43] it just means vesafb is loaded at the end of boot (/etc/init/udev-fallback-graphics.conf), not from the initramfs (which would put it before nvidia module load) [14:43] https://wiki.ubuntu.com/BootGraphicsArchitecture btw, if you haven't seen it yet [14:44] But udev skips modprobe blacklists, right? [14:44] I vaguely recall that it did. [14:44] Maybe not. [14:44] so you have vesafb explicitly blacklisted somewhere? [14:45] yes, udev skips modprobe blacklists [14:45] Yeah. I can undo that, but that tends to not end well. ;) [14:45] oh? you've tested this scenario already (nvidia loaded before vesafb)? [14:46] Well, re-testing now with the blacklist removed, though if you claim udev will load it regardless, this should be the same as the last boot. [14:46] Oh, no. This got me no X. [14:46] I'm unconvinced the FRAMEBUFFER=n did anything. [14:47] well. is there framebuffer stuff in the initramfs? [14:47] Yeah. [14:48] Possibly because I can't spell FRAME. [14:48] FWAMEBUFFAW [14:48] heh === sagaci_ is now known as sagaci [14:49] Well, no, even spelling it correctly, the initrd contains fb stuff. But, wait, why wouldn't it? [14:49] cryptsetup will still pull it in, even if it's not going to get loaded, surely? [14:51] you're meant to put the FRAMEBUFFER=n somewhere that it overrides the cryptsetup hook... I thought conf.d was late enough, maybe not [14:51] Right, with correctly-spelled FRAMEBUFFER=n, I still get consoles and no X. [14:51] just mangle the cryptsetup hook to unset it and call it good [14:53] And that gets me X and no consoles. ;) [14:55] slangasek: dmesg confirms nvidia loading before vesafb, and fb0 being initialised, but no actual consoles displaying. [14:56] slangasek: (and if the load order is the other way, consoles work, but X dies on init) [14:56] fb0 initialized - how about fbcon? [14:57] slangasek: Nothing prefaced with fbcon. Just "Console: switching to colour frambuffer device 160x50" (which seems sane, but...) [14:58] * infinity scratches his head. [14:58] There's no fbcon modules anymore? [14:58] Built-in? [14:58] I guess. [14:58] built in, yes - but does it show up in dmesg? [14:58] for boot speed iirc [14:59] slangasek: Nein. [14:59] [ 2.120016] fbcon: inteldrmfb (fb0) is primary device [14:59] that's the kind of thing you should get [14:59] what's /proc/cmdline? [14:59] slangasek: Yeah, I get that on my nouveau drm system too. No such luck on this vesafb boot. [15:00] cmdline is root=foo ro i8042.nopnp quiet splash vt.handoff=7 [15:00] * infinity wonders what that i8042 thing is all about. [15:00] well, the 'switching to colour frame buffer' should also be decisive [15:01] You'd think. [15:01] I wonder if it may have something to do with missing VBE modes. [15:01] does grub come up graphically? [15:01] It's giving me a 1280x800 vesafb, then we switch to a 1920x1080 mode for X. [15:01] hmm [15:02] And vbeinfo from grub doesn't list the 1920x1080, plus I can't force it. [15:02] So, it's really not there. [15:02] I can force grub to 1280x800 (tested that), but it's coming up 640x400 (or whatever) by default. [15:03] ok [15:09] Could we have a little more communication for those of us not at the sprint please. Trying to grab images, test them. and keep hoping that another respin is not in progress is getting really difficult [15:10] charlie-tca, fair point. [15:11] respins appear to have been mentioned above on the channel - did they not get marked for respin in a timely manner on the tracker? [15:11] Right now what's happening is we're finishing off the last builds. Last night's builds to fix for OEM caused regressions. [15:12] jibel, please post in this channel any of the potential blockers bugs so that others know what we're investigating. [15:12] They got marked as being done, and they got marked as finished. We used to get told the images were being rebuilt and were ready, too. Now it is watch the ISO tracker or the server to see when they finished. [15:12] and the tracker doesn't always get updated to match the image server [15:13] Scrolling here and in #ubuntu-testing, I see nothing says Xubuntu got finished, or even were being respun. I found it looking at the tracker. [15:13] charlie-tca, we've been working on getting it automated, so it no longer needs to be a manual step (ie. wait for someone to notice). [15:14] skaet: when I am running tests, to find when entering stuff on the tracker that the images are being rebuilt, means I wasted a couple of hours, again. [15:14] There were some issues with it that got debugged this morning. Are any of the images up there right now not matching what's on the server. [15:15] charlie-tca. Your point is valid. We should have been more verbose on this part as we were transitioning. [15:19] charlie-tca: are you not subscribed to the xubuntu test cases in the ISO tracker? That's supposed to result in an email notification whenever a new image is available [15:20] now, I don't think that notifies that an image is down for respinning, mind [15:21] Yes, I am subscribed, and I get the emails, but there again, it is an instant notification process. [15:22] I synced last nite here, burned cd-r's as 9pm, got up at 6am, and and 7am find we are respinning images. it is now 9:20am, and I have two hours of syncing images, before I can even begin to test them [15:23] eek, buildds are being kernel-ppa-ed [15:23] I was hoping we could get in fwts [15:24] fwts? [15:24] in the queue [15:29] pitti: It's universe anyway, does it matter if the builds don't happen immediately? [15:29] infinity: no, just if they don't happen until tomorrow [15:29] They will. [15:29] I wouldn't like to release with an out of date pacakge [15:30] we can score it up, of course, so that it builds after the next set of kernels [15:30] Exactly. [15:36] charlie-tca: well, I'm in the room and I didn't know xubuntu finished building ;) [15:36] Hm, maybe you people ain't really getting the word either. [15:40] well, it's all automated now, so nobody has to add them to the tracker which means nobody knows they're done building unless they're subscribed to them or look on the tracker [15:57] stgraber: I haven't been getting notifications either, and afaik, I am subscribed (or I was). [15:57] Going through and resubscribing now. [16:03] I will say the way the tracker notifies now is really nice. It sends out an email for each item on the tracker, as they become available. [16:03] No more waiting to see both arches are ready [16:06] that's because cjwatson's script post them as they're done building, instead of having one of the ISO tracker admin check periodically and post them in batch [16:17] good night everyone [16:21] thanks pitti, good night. [16:21] I do see notification as a "good thing" :) [16:27] * GrueMaster twiddles thumbs while waiting for yar (yet another rebuild) to finish. [16:29] stgraber: did you see the open-isci bug I've assigned you? [16:29] stgraber: nevermind ;) [16:43] Rebuilds failed on arm (or at least that was the email I just got). [16:45] Generating MD5Sums of the images [16:45] /usr/bin/md5sum: write error: No space left on device [16:45] /usr/bin/sha1sum: write error: No space left on device [16:45] who drives antimony atm ? [16:46] seems we need some disk space cleanup [16:47] * ogra_ has access but doesnt feel like randomly deleting images there [16:48] skaet, bug 870214 -> release notes [16:48] Launchpad bug 870214 in open-iscsi (Ubuntu Oneiric) (and 2 other projects) "iSCSI root installation creates manual eth0 configuration + long boot (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/870214 [16:49] thanks jibel. [16:49] skaet, see above ... thats critical i guess [16:49] antimony ran out of space [16:49] ogra_ [16:49] ack, looking at it. [16:50] I already have a ticket filed with IS [16:51] they need to actually do it [16:51] (and armel will need a cron.daily-preinstalled run afterwards) [16:51] I will go and kick them [17:06] done some temporary mitigation of the space problems, rest is with IS [17:10] only one image failed due to that, which I'm rebuilding [17:10] two other problems which I can look at latere [17:10] *later [17:11] thanks ! [17:11] GrueMaster, should all be in order again in a few [17:12] sigh. [17:12] ?? [17:12] * GrueMaster re-enters holding pattern...again. [17:12] you can test everything already but omap4 [17:12] oh and TBH I think I've been about as communicative here as I would have been while at home; I did mention doing respins [17:13] would it be better if I didn't rebuild your image? :P [17:13] * ogra_ hugs cjwatson [17:13] Well, actually since I had already downloaded and tested them prior to the respin... [17:13] GrueMaster, omap4 should be ready in a few mins as well, since it only needs the post-processing bit again [17:13] But I understand the need to get fixes in to final. [17:14] ogra_: yep, and that's all I'm running [17:14] * ogra_ thought so [17:15] it'll be at least half an hour until kubuntu preinstalled comes out, probably a bit more [17:15] skaet: can we add http://uec-images.ubuntu.com/oneiric/20111011/ to the tracker for the Ubuntu Cloud images? [17:15] unfortunately I forgot to export the magic variable in that shell so I'll have to post it by hand [17:16] * ogra_ isnt sure who tests kubuntu preinstalled [17:16] i guess thats scott [17:16] ScottK, ^^ kubuntu preinstalled. [17:16] is it too late to do a removal from universe? [17:16] utlemming, trying now. [17:16] i'd really like to get rid of webfav [17:17] or GrueMaster proxying him in his spare time :) not sure [17:17] ogra_: I usually end up testing it. No one on kubuntu has omap/omap4 hw (they all have Efika systems). [17:17] GrueMaster, which doesnt help at all sadly [17:17] * ogra_ hopes we'll get mx5 images that can actually run on efikas too next round [17:18] * GrueMaster refrains from comment. [17:18] I'd like to find the time to do that. [17:18] But... [17:18] It may end up being another subarch if I can't figure out a cleverly hackish way to unify them. [17:18] And ew. [17:19] infinity, no, please dont, we have enough images :) [17:19] Exactly. [17:20] i was expecting linaro to provide us better bits and pieces to make that work actually [17:20] with a single image [17:20] A unified uBoot? Good luck with that. [17:20] There are 4 builds for mx53 alone. [17:20] a unified u-boot for one arch, yeah [17:21] chrisccoulson: it should still be possible [17:21] chrisccoulson: file a bug and subscribe ubuntu-archive, I (or somebody) will process the removal queue tomorrow morning [17:21] cjwatson, thanks. i'll do that now [17:21] I'm somebody! [17:22] * infinity feels special. [17:22] yay [17:22] utlemming, I'm running into a script error. Will figure it out when I get back from dinner. [17:23] I apologize for earlier ranting. I am aware the perceived lack of communication has nothing to do with the sprint. [17:24] skaet: np, enjoy dinner :) [17:25] charlie-tca, more communication should have been happening though. [17:25] will try. :) [17:26] Team here in Milbank is breaking for dinner right now, all images except a couple of the arm ones are posted on the iso tracker, and no rebuilds anticipated. [17:26] you should put some mics and a voice recognition SW up in the rooms and make it paste here :P [17:27] ogra_, it would mostly be picking up typing actually. :) [17:27] heh, yeah [17:27] I may not be able to post kubuntu preinstalled in a timely fashion; if it succeeds I would appreciate somebody posting it [17:36] cjwatson: eta? [17:40] um, let's see if I can get me in more trouble now. [17:40] bug 872374 [17:40] Launchpad bug 872374 in onboard (Ubuntu) "Feature Freeze exception request: new version with GI, gsettings,... (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/872374 [17:40] Probably too late, maybe advise for a SRU? [17:40] slangasek, it'll be at least half an hour until kubuntu preinstalled comes out, probably a bit more [17:41] that was at 15 past the hour [17:43] mmk [18:06] kubuntu preinstalled built; publishing [18:06] GrueMaster, ^^ [18:06] Yep, pulling all desktop images now. [19:31] Can we still add things to the release notes? [19:33] Is it on purpose that software-properties was uploaded to updates and not proposed? [19:40] I have a confirmed fix for https://bugs.launchpad.net/ubuntu/+source/libdvdread/+bug/869003 should I upload to -proposed now, or hold off until release? [19:40] Launchpad bug 869003 in libdvdread (Ubuntu Precise) (and 3 other projects) "dvdbackup: symbol lookup error: /usr/lib/libdvdread.so.4: undefined symbol: dlopen (affects: 5) (heat: 32)" [Undecided,New] [19:40] kees: seems like it belongs in oneiric-proposed [19:41] ScottK: I just noticed that too.. seems odd [19:50] kees: there are other things in -proposed already, so I believe its okay to upload to there now. [19:52] kees: and bonus, I'm reviewing the proposed queue right now, so should land quickly. :) [20:05] SpamapS: oooh-ho, let me shove it in then, one sec === chrisccoulson_ is now known as chrisccoulson [20:59] SpamapS: We're going to start uploading KDE 4.7.2 shortly. No need to accept it until it's all there ... [21:00] ScottK: thanks for the heads up [21:00] I think I'm done with oneiric-proposed reviews for today [21:10] utlemming, images posted to the tracker now. [21:11] skaet: thank you kindly :) [21:14] Is the pad out of date? Reading it, I'd be expecting rebuilds that I'm pretty sure we already did. [21:18] right, phew, I think all respins are finally done [21:19] I've updated the pad, I think [21:20] unless server team cares about getting that open-iscsi issue fixed for final, I guess [21:20] Daviey: ^^ are delays on first boot after installing on iscsi root critical to you? (If not, we can fix it in SRU) [21:21] I'm going to steal antimony for a little while to do some timings of mirroring [21:21] and hopefully improving matters [21:24] charlie-tca, have looked at 872374 and commented in the bug. Its too late for now, but we would like to pick it up in an update. See comments in bug. [21:25] slangasek, I talked to Daviey earlier, and he's ok with release noting it. [21:26] ok [21:26] stgraber: ^^ so open-iscsi to -proposed please :) [21:27] could someone rescore fwts and guichan so they get built before release please? [21:28] skaet: thank you for looking [21:28] lamont: ^^^? [21:28] Probably too late for pitti. [21:30] ScottK: nearing EOD myself, maybe slangasek/skaet could poke the vanguard [21:30] Who is that? [21:30] I think it's darrenS [21:30] skaet: I have a bug in omap images (bug 838200), but it can be worked around with a little hackery. I've marked it as serious for netboot only, as networking is kind of critical for net install. [21:30] Launchpad bug 838200 in u-boot-linaro (Ubuntu Precise) (and 2 other projects) "No network support on Beagle XM (affects: 1) (heat: 9)" [Undecided,New] https://launchpad.net/bugs/838200 [21:30] ScottK: actually, dblawson, this channel, atm [21:31] Thanks. [21:31] erm s/channel/server/ [21:31] Linaro knows about it and I have documented a workaround. Also, not all beagleXM users I have talked with are seeing it. [21:31] skaet: ^^^ would you please ask dblawson to do laney's rescores? [21:32] Looks like NCommander or doko could do it too. [21:33] or anyone on the TB ... [21:33] ScottK: NCommander is afn. Pulled an all-nighter. [21:33] Oh. infinity still haz powerz too. [21:33] which package? [21:34] fwts and guichan [21:34] so does doko [21:35] skaet: I see some text corruption in https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview#New_App_Developer_Site - not sure what "the central point" is supposed to link to, if anything? [21:35] skaet: Looks like it's taken care of. [21:36] ScottK, ack. [21:36] slangasek, looking. [21:36] rescored [21:36] I had a temporary brain failure as to how or I'd have beaten you to it [21:36] :-) [21:36] cheers lots [21:37] doko: Thanks. [21:41] slangasek, yup, looks like dpm had some issues in his input, we need to get it cleaned up. If you can figure out what it should be, feel free to change, otherwise I'll work with him tomorrow morning. [21:41] * skaet sees slangasek has it locked. :) [21:41] skaet: I really have no clue what page he wanted that pointed to [21:41] skaet: meh, ignore my lock [21:41] there should be a better way to release a lock [21:42] slangasek, ok, I'll take some guesses, and see if I can figure it out. [21:42] you know, like 'cvs checkin' [21:42] CVS > MoinMoin [21:43] You say that like it's news. [21:49] slangasek, ok, think I've made it make sense. flag if you disagree. [21:49] woo, I think I may have fixed the slow universe sync to cdimage [21:49] *\o/* [21:49] just shelved it to do a timing of universe-ports [21:50] but for universe that went from 11m26s to 30s [21:51] and from 7000-odd files transferred for a no-op sync to 0 [21:53] open-iscsi is now in oneiric-proposed [21:56] smoser, utlemming - was reading through the ReleaseProcess checklist, and came across a stale link. What should https://wiki.ubuntu.com/UEC/Images/Publishing be now? [21:58] https://wiki.ubuntu.com/UbuntuCloud/Images/Publishing [22:00] Thanks slangasek. [22:00] * skaet editing now [22:10] * cjwatson finds a slew of files in the primary cdimage mirror owned by non-cdimage users - definitely not all recent since some are e.g. owned by tfheen [22:10]