[00:01] some of these will definitely be helped by debhelper/cdbs changes; I'll do a few targeted rebuilds in a quantal chroot later to check that [00:11] cjwatson: stackprotector doesn't care about -O [00:12] if it goes away, that's realy odd :( [00:14] examples I see so far are acct, calligrasheets, kexi, libm17n-0, m17n-lib-bin, module-init-tools [00:14] so not super widespread but more than I want to write off as cosmic rays [00:15] can you pastebin the patch? I'll see if I can reproduce it. [00:16] fwfi, we built without that env export just fine for a few releases. stackprotector was made a default in edgy. :P [00:16] http://paste.ubuntu.com/956425/ [00:16] *fwiw [00:18] reproduces on i386 as well as amd64 [00:18] with module-init-tools [00:25] --param=ssp-buffer-size=4 makes no difference [00:25] perhaps interesting that it's only modprobe in that binary package that's affected [00:26] the others just drop fortify due to inadequate CFLAGS [00:28] O_o reproduced [00:29] oh, interesting, even adding -fstack-protector doesn't make any difference to that binary [00:30] so has it just become unable to protect certain binaries? [00:31] well, some source doesn't trigger stack protector to be added. I wonder if something is causing an entry in the relocation tables (which is what readelf -s looks at in hardening-check), that behaves differently with "symbolic" missing? [00:33] the difference is -O2 or lack thereof [00:34] CFLAGS='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security' => good, CFLAGS='-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security' => bad [00:34] oh, I suppose it's possible the function could be changed due to optimization to drop the use of a character array on the stack... [00:34] which would render fortify unnecessary? [00:34] if it got pushed into registers or something weird [00:35] ssp? maybe. fortify is distictly disabled without -O >= 1 [00:36] sorry, I meant to say stack-protector [00:36] diff of the disassembly is a bit too verbose to be enlightening [00:38] this would be the other way round from your hypothesis above, I think: optimisation causes an array to go on the stack when it wasn't before [00:38] since the optimised binary is the one that apparently requires stack protection [00:39] anyway, this doesn't seem desperately worrying [00:40] openbsd-inetd drops pie and bindnow [00:42] which is because it assumes the environment variables it sets are already exported [02:12] cjwatson: back now, sorry, had to prep dinner :) [02:13] hah, so openbsd-inetd is bugged in Debian? they intended it to be PIE, but it didn't work? :P [02:13] seems like it's really the lack of -O2 getting exported that is the biggest deal since it's changing both fortify and ssp. === lynxman- is now known as lynxman [08:35] cjwatson, hmm, iirc last milestone you fixed the md5 summing of the images and the ac100 bootimg was still wrong and required manual mangling of the MD5SUMS file, seems we need to do that for the released images too (MD5 differs) [08:37] (i can do that myself if it just requires editing the file in nusakans www/full/releases dir, i just dont know if you did anything additionally) [08:52] is ben sick this morning? "Page generated on Mon, 30 Apr 2012 02:04:31 +0000" [08:53] perhaps the mirror it uses is timing out [09:02] oh, hmm, seems its a vacation day in the UK ... /me didnt notice, we have one tomorrow ... [09:05] hey skaet, still in the UK? [09:05] heya stgraber, yup, but sitting in the airport right now, flying home today [09:05] :) [09:06] ok :) [09:06] you still in europe? [09:06] yep, hopefully flying back tomorrow, if Air Canada lets me ;) [09:06] I was supposed to fly back yesterday but they moved the flight to tomorrow [09:06] :) coolio. [09:07] oh, not so coolio... [09:07] heh, dont you love travelling [09:07] bah, it's not like it makes a big difference, I don't have to pay for the hotel as I'm staying at my parent's place and working from here or from Canada doesn't make a huge difference [09:07] (except I have 4 times as much bandwidth at my parents' than I do back home ;)) [09:07] yeah, easier though to deal with churn on the homeward stretch though. [09:08] 4x bandwidth - nice.... [09:08] yeah, I could get used to having 100Mbps at home ;) [09:08] yeah, the swiss always tend to exaggerate ... even with their bandwith offerings :) [09:08] :) [09:08] ogra_: still on your 2mbps SDSL? :) [09:09] :P [09:09] 640k are enough for everyone ! [09:09] * ogra_ isnt at home though, no idea what this line here has ... i'm at a friends place in berlin [09:20] kees: openbsd-inetd was fine at the time it was uploaded, when dpkg-buildpackage exported flags in Debian, but has regressed; as it happens there've been no Debian uploads of it since the dpkg change. I filed a Debian bug about it. [09:21] ogra_: if the released checksum file is wrong, I think it must have been wrong in the daily build. feel free to remove *SUMS* and run checksum-directory on that directory [09:21] (to force it) [09:22] iirc there was an issue with the automatic generation for .bootimg [09:22] i dont want to mees up what we have there atm [09:22] *mess [09:23] ogra_: damn you for giving me false hope :-) it's not a bank holiday here today AFAICS [09:24] ogra_: I think the bug was in publication of daily builds; having trouble seeing how it'd be wrong for releases, which are just a copy [09:24] oh, i got it worg, wikipedia said first monday in may ... i just noticed the date [09:24] sorry [09:24] *wrong [09:25] (must be next week then, which doesnt gain you much) [09:30] yeah, I'll swap it [09:39] k, the run of checksum-directory fixed it [09:42] (in case anything went wrong that i didnt notice, /home/ogra/sums-backup has a copy of the old files) [09:56] stgraber: ping === doko_ is now known as doko [10:05] doko: So my test rebuild is still churning, but how strongly do you feel about the possibility of accidentally losing -Wl,-Bsymbolic-functions on various outlying libraries in 12.10? AFAICS the main performance benefit is for libraries that are loaded a lot [10:05] I expect making sure that common desktop libraries get dpkg-buildflags right won't be too hard [10:06] cjwatson, what is the context? not exporting the flags anymore? [10:07] doko: yes, https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035149.html [10:08] some packages lose optimisation too if we do that, mainly visible in the loss of fortify [10:08] but that's easy to scan for [10:09] sounds good [10:10] cjwatson, what steps are done in NewReleaseProcess? [10:10] skaet: still on 17 [10:10] (expected, that step takes some time) [10:11] cjwatson, ok, I'll work on some of the wiki, etc. related ones until my flight leaves. [10:11] will post in the channel as things get done. [10:11] sure [10:12] it's not really coordination-heavy at this point; I think the main thing we need to do now is resolve the dpkg flags export question [10:12] doko: anything else you feel is necessary before opening? [10:13] cjwatson, now gcc-4.7 on armhf is built, I hadn't much luck yesterday investigating the failure on armel. a work-around would be not to build multilib'ed for now on armel, if I can't find the solution [10:13] Is that necessary before opening [10:13] ? [10:13] not really for main [10:14] done step 20, branch-distro completed after a few hours [10:29] done step 24 in cdimage [10:31] done step 28 in ubiquity [10:34] cjwatson, skaet: Should I extend step 12 to also include extras.u.c? IIRC it's been a problem for the past two releases [10:35] stgraber: Not as part of step 12, because extras.u.c comes from a PPA. [10:35] stgraber: Perhaps a separate step to notify whoever controls extras to arrange for quantal to be created there. [10:36] cjwatson: ok, I'll append an entry to the +1 day list then. All it takes is a copy from release => release+1 in the PPA, wait for the ppa publisher to run, thne remove the package [10:38] Right [10:52] I have installed precise so many things that I think I have missed something important here, what is that twitter feed everyone is talking about? [10:53] ev can you help gema out? [10:53] ^ [10:54] gema: there's a twitter feed in the slideshow [10:54] at the very end [10:54] ev: ahh, the slide show :D [10:54] ev: I thought precise would tweet "I have been installed" or something, ok! [10:54] ev, i need to get to you some day. we're unsure what to do with wubi in xubuntu. [10:55] https://lists.launchpad.net/ubiquity-slideshow/msg01139.html [10:56] knome: please feel free to email me with your thoughts on that. Today is a fire fight sort of day [10:56] ev, we need to sit down on it first anyway. but i'll email you - maybe tell the email adress to make life easier :) [10:57] knome: ev@ubuntu.com [10:57] ev, thanks! will get back to you :) [10:58] knome: cheers [11:00] ev: thanks! [11:09] * cjwatson files the LP bugs that showed up while initialising quantal [11:10] (bug 991874, bug 991876) [11:10] Launchpad bug 991874 in launchpad "newly-initialised distroseries not considered dirty on first publisher run" [Undecided,New] https://launchpad.net/bugs/991874 [11:10] Launchpad bug 991876 in launchpad "initializedistroseriesjob starved by other jobs" [Undecided,New] https://launchpad.net/bugs/991876 [11:30] cjwatson, is the dpkg-buildflags issue decided, e.g. should we open with it? [11:37] cjwatson, anything to add? http://paste.ubuntu.com/957295/ [11:38] s/Oneiric/Quantal/ [11:38] oops [11:38] lol [11:38] I think I've decided to open with the proposed dpkg-buildpackage change, but need to uploa that [11:38] *upload [11:38] ok [11:39] There's a pretty fair number of things to fix, but it's manageable, and brings us more into line with Debian; for the most part the consequences of missing something aren't disastrous [11:40] The requirement for a Pre-Depends on dpkg for data.tar.xz will go away, although that probably won't be rolled out until at least tomorrow [11:40] (I'm landing the branch now) [11:40] - Removing build flags exported from dpkg-buildpackage for quantal will [11:40] get us in sync with Debian. Implications and fixes are discussed [11:40] on the ubuntu-devel ML [5]. [11:46] Yep [13:07] About to request opening of quantal; speak now or forever hold your peacec [13:07] with spelling and everything [13:17] cjwatson, announcement email sent, needs approval for u-d-a === cjwatson changed the topic of #ubuntu-release to: Quantal open for development | Ubuntu 12.04 (Precise Pangolin) is released! | Quantal Quetzal Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis [13:20] doko: done [13:22] Any objections to an autosync run? [13:24] "syncs from unstable": it changed then? [13:25] sounds good [13:25] Laney: Hm, communication glitch [13:26] I was intending to run syncs from testing until UDS [13:29] * cjwatson flushes unapproved [13:33] copied stuff from precise-updates [13:35] infinity: did you bootstrap the livefs chroots already? === yofel_ is now known as yofel [13:39] * cjwatson starts auto-sync [13:48] hallyn: Could you update vm-builder for quantal? [13:55] cjwatson: sure. I'd like to finish with the libnl-3 fiasco for necf and libvirt upstream first [13:55] do you expect it to need changes, or just a rebuild? [13:56] hallyn: no idea. NewReleaseCycleProcess says to notify mvo (who isn't here) or you. grep for precise, I suppose. [13:56] ok thanks :) [13:58] Argh, my cloud instance rebooted itself and lost half the results [14:00] cjwatson: =( [14:01] Didn't realise *none* of the storage was persistent ... [14:02] eh? you shouldn't lose anything on an EC2 reboot [14:02] This is Canonistack, not sure which rules apply [14:03] cjwatson: pick EBS backed storage, next time. You don't loose that one. 'instance storage' is lost... [14:03] xnox: are you sure canonistack supports EBS? last I checked it didn't [14:03] see also: Canonistack [14:04] stgraber: /me never was on canonistack, only on amzon EC2... [14:04] Right, but I'm not. [14:04] "At this present time, the Canonical Openstack cloud does not provide attachable storage (EBS-like functionality) for your instances. This will be addressed at a later stage." [14:04] hasn't changed since I last looked apparently [14:05] Went to canonistack and got "Nothing for you here" message =( [14:06] oh well. [14:06] ask IS === bulldog98_ is now known as bulldog98 [14:46] cjwatson: livefs chroots should be good to go already, yes. [14:46] cjwatson: Happened last week, in theory. [14:49] OK, cool [14:50] * infinity is unconvinced that he wants to be awake. [15:27] slangasek: can someone copy my Oneiric SRU kernel to -proposed? bug 985736. thanks! [15:27] Launchpad bug 985736 in kernel-sru-workflow "linux: 3.0.0-19.33 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/985736 [15:28] slangasek: sorry, from proposed to -updates [15:38] I'd be happy to do it, except for the claim that it must be an SRU-team member who does the copy. [15:39] cjwatson: Quick, add me to ~ubuntu-sru [15:39] infinity, thansk [15:40] infinity: Oh yes, you were actually volunteering to do some work there, weren't you? [15:40] bjf: I don't want to muck with anyone's process, but I'll make sure someone SRUish either looks at it or authorizes me to JFDI. :P [15:40] Oh, look, there's someone. [15:40] infinity: Added you. [15:41] Shiny. [15:41] Oh hey, I wasn't a member of that one previously. Was curious about that. [15:42] It's fun to see which teams I'm the oldest member of, and which not. [15:42] Anyhow... [15:42] bjf: Doing the copies shortly. Will poke the bug tasks when done. [15:47] infinity: you know there is a parameter that you need to specify on the script so the packages don't go to universe instead of main ? [15:48] bjf: They'd better already be in main in -proposed, but I'll check. [15:48] bjf: (I imagine you're thinking of the PPA->proposed copy where that breaks) [15:48] infinity: could be [16:16] There, and fresh buildd chroots purged of all remnants of gcc-4.6 [16:36] infinity: can you do linux-lts-backport-oneiric as well ? bug 986000 [16:36] Launchpad bug 986000 in kernel-sru-workflow "linux-lts-backport-oneiric: 3.0.0-19.33~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/986000 [16:38] bjf: Sure. [16:40] * cjwatson commits the first autosync [16:40] Updated: 2994 (27.77%) [16:40] * infinity races to commit the new chroots. :P [16:42] Argh, timeout [16:42] Maybe I need to do this in chunks or something [16:42] It's not async? [16:42] It is async [16:42] Oh. [16:42] Oh dear. [16:42] But maybe the amount of input data was troublesome [16:43] Well, new chroots are up, but nothing in the queue to test and make sure they're sane. I guess you'll solve that problem for me shortly. ;) [16:53] OK, recursive-descent exception handling for the win; let's see what that does [16:55] cjwatson: Is there some policy regarding keeping old kernel cruft around in old releases (say, perhaps, make sure that every published d-i has matching kernels, or something?), or is it sheer inattentiveness that's led to there being six kernel ABIs in oniric-updates (for example, I'm sure every old release is as dirty, or worse). [16:55] "every published d-i has matching kernels" -> that [16:56] in particular, we don't really track point releases in LP, so it's tricky to NBS those reliably [16:56] Kay. Though, six is more than the number of d-i's we have published in updates, so we clearly need a bit of cruft-checking here. :) [16:57] Maybe, but there's no easy way to tell people to upgrade the installer images they downloaded in order to use some random -updates kernel [16:57] They'd just get a hard failure [16:57] I think a bit of cruft is tolerable to avoid that [16:57] There's that. [16:57] * infinity shrugs. [16:58] I know I've tidied old pockets in the past. Perhaps I shouldn't have? [16:59] Arguably - I generally avoid it. [16:59] At the very least you need to take care to avoid LTS point releases. [16:59] Aye. [17:00] This could be done easily enough. [17:00] But the general case is still troublesome. [17:34] now testing my armel multilib patch ... [17:37] doko: Vaguely curious about what broke. [17:40] Second auto-sync attempt still running, but I have to go for dinner now. I'll try to commit it when I get back. [17:41] infinity, see linaro-toolchain [17:45] doko: Strange that it regressed, since the situation should have been the same in 4.6... === gridcube_ is now known as GridCube [19:06] Cannot copy 2975 packages at once; bisecting ... [19:06] Cannot copy 1487 packages at once; bisecting ... [19:06] Cannot copy 743 packages at once; bisecting ... [19:06] Cannot copy 371 packages at once; bisecting ... [19:06] I do hope this is going to actually work at some point [19:07] It's going to end up doing it one at a time. :P [19:07] I doubt it, since my bisector has a cut-off of 100 [19:07] After which I should probably actually investigate [19:08] It worked with a not hopelessly small number towards the end of the precise auto-sync [19:08] Ah, good, the two halves of 371 worked [19:09] So maybe I'll make it use 100-package chunks in future or something [19:10] Anyhow, your builders are filling up now. [19:11] infinity: I am not going to continue adding to the discussion in that release blueprint [19:11] infinity: but I know who you are :P [19:11] I mean, I rather discuss that face to face [19:12] than writing a book in a blueprint [19:13] then I guess I'll wait till the session instead of adding another reply to that discussion on the blueprint ;) [19:13] stgraber: I think it is wise, we'll get more out of it, I think, not sure what the general feeling is [19:13] we can split it in more than one meeting if needed be [19:14] Whiteboards are mostly just good for getting agenda points down, not for serious discussion. [19:14] cjwatson: ack [19:14] that entry on the whiteboard is sure getting pretty long, so face to face discussion will probably be more efficient than "discussing" through whiteboard entries :) [19:14] It does seem to be one of the least coherent methods for arguing on the internet. :P [19:15] haha, you gotta love launchpad and blueprinting :D [19:15] yes, that's not what the whiteboard is for [19:15] knock it off youz guyz :P [19:15] slangasek: haha [19:16] slangasek: I think we are going to need you and pgraner there to organise the discussion... [19:16] I'll be there [19:16] good [19:42] Initial auto-sync is done. Starting on new source packages now. [19:43] \o/ [20:02] Not 100% convinced that all of these syncs actually happened. I guess we'll find out. [20:02] I was expecting a new thailatex (random sample). [20:03] Maybe I'll do another pass after a publisher run. [20:14] * infinity notes that the powerpc situation doesn't seem nearly as dire with the third buildd. [20:15] It's a nice improvement. [20:15] Damn, though, that's a lot of build records. [20:15] Did somebody give Debian a shot of adrenaline or something? [20:15] Heh. [20:15] Did you switch from testing to sid? [20:15] No. [20:15] Or were these all from testing? [20:15] All testing. [20:16] And there are several hundred left to come. [20:16] In that case, maybe we should give ourselves a pat on the back for not doing too much needless syncing over the last 3 months? [20:16] Or maybe chastise ourselves for missing out on a lot of minor bugfixes. [20:16] A little of column A, a little of column B, I guess. [20:18] I wonder if we'll hit 10000 needs-build entries. [20:19] Getting close. [20:19] Time to spin up an AVR port? [20:20] The publisher is going to have some kind of aneurysm. [20:20] infinity: there were probably another 300-500 that were suitable for precise that no one had time to review [20:20] is it still useful to have queuebot running? [20:20] cjwatson: Can't be as bad as the brain bleeding it encounters with kde langpacks. [20:21] slangasek: I like it for the info about stable releases. [20:21] It's slightly useful for watching incoming new entries, but if other people find it noisy I don't mind [20:21] slangasek: The noise on sync/new is a bit unfortunate, but that'll subside. [20:21] I hope I catch the upcoming new flood in time. [20:21] I find it noisy [20:21] I also bitbucket all my ubuntu-sru bug mail [20:22] because those all get batch processed [20:22] Heh. [20:22] You could /ignore queuebot ? [20:22] I could ;) [20:22] * slangasek does so. here's hoping I don't forget to unignore in 5 months :) [20:23] We'll remind you. [20:24] My concern above about syncs not having happened was bogus; the job runner was just still chewing on them [20:24] heh :) [20:24] cjwatson: Is it done now? [20:24] No. [20:25] Then we might hit 10k! [20:25] This is the most exciting thing that's happened to me since... At least an hour ago. [20:25] :-) [20:29] Oh, here we go ... [20:29] * cjwatson tries to catch some of them [20:29] Hahaha. Oh dear. [20:30] cjwatson: And since stgraber added throttling, it won't get kicked for flooding either. :P [20:30] cjwatson: It'll just spend the next 3 hours telling us about it. [20:30] ban it temporarily? [20:30] * Laney goes blind [20:31] * slangasek smiles blissfully in his little bubble [20:31] :) [20:31] hopefully that'll shut it up [20:31] It doesn't. [20:31] At least, not last time we tried. [20:31] bah [20:31] That'll work. :P [20:32] IRC, you fail me [20:32] /kickban ? [20:32] heh [20:34] * infinity imagines queuebot /msging cjwatson with gems like "y u kik lol i do no rong!" [20:35] * Laney catches launchpad OOPSing like its going out of fashion [20:36] yup [20:36] I am pretty confused that +b didn't work, though. It's supposed to. [20:37] you mean q? [20:37] I tried both [20:37] I'm not sure what applies to channel notices [20:37] Could be. Seems like an obvious hole, though. [20:38] was there one after the +q that I missed? [20:38] 21:31 -!- mode/#ubuntu-release [+q queuebot!*@*] by cjwatson [20:38] 21:31 -!- mode/#ubuntu-release [+b queuebot!*@*] by cjwatson [20:38] a notice [20:38] Yes [20:38] I think it's because it's sending notices, not sending to the channel [20:38] Quite a few [20:38] hrm, don't know where that ended up [20:38] * Laney eyes irssi [20:39] slangasek: indeed, but if it didn't suppress both, it would be no good for shutting people up, surely [20:39] (bots should indeed send notices, that's a large part of what notices are for; it stops bots talking to each other) [20:39] I don't usually see banning used without a following kick ;) [20:39] http://freenode.net/using_the_network.shtml documents my attempted use [20:40] cjwatson: I didn't see any notices after the +q, I just vaguely recall it not working in the past. [20:40] I don't see any after it either. [20:40] cjwatson: If you saw some, maybe you were suffering local buffer lag or something weird? [20:41] I suppose it could be, but I saw other people's comments interleaved [20:41] can you give an example? [20:41] I'll see if I saw it before the +q. [20:41] libgtk3-perl [20:42] don't see it at all. [20:42] libdvbcsa [20:42] Oh. [20:42] Hah. [20:42] I bet ops see them. [20:42] Oh, ops get notices? [20:42] Ah yes. [20:42] Should have remembered that. [20:42] hah [20:43] stgraber: You can let queuebot back in. [20:45] so close to 10k [20:45] A few more new packages to do, if auto-sync will get to them in time [20:48] Did anyone ever retest the Chinese edition image? [20:48] I thought we found/had a Chinese tester who claimed they were doing so...? [20:48] (But yes, I just read the same email you did) [20:48] For some reason it seems to have been removed from the localised tracker [20:49] * slangasek doesn't know [20:49] did we ever figure out why the images pitti says were broken were signed off by QA? [20:50] And from the download page, I just get a squid error. Fun. [20:50] slangasek: They thought that those entries meant "take the regular image and boot it in Chinese". [20:50] right [20:50] I wondered [20:51] So, from the download page, you just end up at http://www.ubuntu.com/start-download?distro=desktop&bits=32&release=lts [20:51] I see no reason the above would give a Chinese ISO. [20:51] If it worked at all. [20:51] Which it seems not to currently. [20:51] Well, the claim in that mail isn't that it gives a Chinese ISO :-) [20:52] cjwatson: Right, but the claim in the email is that they used the website download page, which might just be a website error, not an image error. [20:52] Unless the above URL is seriously magical. [20:53] * cjwatson has no idea what it does. The website is opaque to me. [20:55] cjwatson: Oh, did we never actually release the Chinese image at all? :/ [20:55] Had I known that, I would have done something about that on Friday. [20:56] There was so much going on I suspect I just forgot about it. :-( [20:57] I'll admit that after I made sure the livefs chroots were sane for respins, I thought pitti had it in hand. [20:57] Though you'd have had to figure out "publication" (i.e. copying by hand). [20:57] Oops. [20:57] by-hand publication isn't rocket science. [20:57] Never did automate that. [20:58] Hmm. I'm sure all these new php-horde-* packages will be a significant improvement to Ubuntu. [20:59] *smirk* [20:59] If Evan's crash databse is anything to go by, we could drastically improve the quality of our distribution by removing Python. [21:00] I think that's the equivalent of self-selection ... [21:00] yeah, it prints all stack traces, and assigns these to python [21:00] still sucks [21:00] and those bug reports like I/O error shouldn't be filed in the first place [21:00] doko: Hrm? No, it correctly assigns them to the right packages. It just happens that the top crashes are all in python applications. [21:01] but I did give up talking to pitti ... [21:01] cjwatson: done :) [21:01] I thought we'd tried to exclude IOError at some point. [21:01] doko: I'm referring to https://errors.ubuntu.com/ not to automated bug reports. [21:02] infinity, then blame pygobject. there's a reason that no module in the stdlib is allowed to use it [21:02] hrm, I don't think anyone has announced errors.ubuntu.com anywhere. It's the first time I've seen a frontend to the crash db [21:03] * infinity notes that the #1 failure in python-central is pretty clearly a bug, and I'd assume a simple one. [21:03] I think we categorize that bug as "python-central is still here" :) [21:03] but I'm trying to look at the actual bug and failing [21:03] stuck at an openid screen [21:04] Traceback (most recent call last): [21:04] File "/usr/bin/pycentral", line 2371, in [21:04] main() [21:04] File "/usr/bin/pycentral", line 2365, in main [21:04] rv = action.run(global_options) [21:04] File "/usr/bin/pycentral", line 1834, in run [21:04] Oh, that happens on real computers too? Last time I tried I put it down to the N900's browser. [21:04] and not os.path.exists('/var/lib/dpkg/info/%s:%s.list' % (pkgname, arch)): [21:04] happens when removing 2.6 [21:04] NameError: global name 'arch' is not defined [21:04] ^--- A missing import, or something? [21:04] cjwatson: the openid page was apparently just really slow to load [21:04] * tumbleweed just isn't granted access [21:04] that's a straightforward coding error, not even a missing import [21:05] tumbleweed: seems to want canonical membership at the moment, I'm afraid [21:05]