[00:00] My laptop takes ~4 mins to boot, but it might be a config issue.. I was going through it last week with slangasek. [00:35] Daviey: 870214 shows a broken /etc/network/interfaces. What created this? [00:38] slangasek: I *believe* installing open-iscsi overwrites that file. [00:41] hmm, i'm not sure. [00:43] slangasek: http://irclogs.ubuntu.com/2011/10/07/%23ubuntu-server.html#t17:13 , is all i know... looks like install time setting. [00:45] -> bed [02:03] Backlog is cleared less one package saved out for stimulating the publisher if needed. === micahg_ is now known as micahg [04:26] cjwatson, stgraber: bug #870832 triaged, I've at least found two bugs in ubiquity-dm; will be interested to know if fixing those bugs addresses the problem [04:26] Launchpad bug 870832 in ubiquity (Ubuntu Precise) (and 1 other project) "Plymouth not shown during live disk shutdown. (affects: 2) (heat: 14)" [Medium,Triaged] https://launchpad.net/bugs/870832 [04:35] slangasek: I have no idea why your compressed manpages don't match. Different versions of gzip for each build, maybe (though that seems unlikely). Did a test rebuild in amd64/i386 chroots reproduce the problem? [04:36] infinity: I tested recompressing the different files with the amd64 and armel gzip, and I get output that matches the original i386 output; I'm not sure what else there could be affecting it [04:36] haven't done a full test rebuild... I figure I probably need to try to reproduce with all the $mangler packages if I'm going to do so [04:38] Maybe, thought we don't mangle manpages, do we? Unless pitti added something scary since the last time I looked. :P [04:38] I guess my "two versions of gzip" theory is possible. Just sees pretty unlikely. Which package was it again? [04:39] libpam-modules... *goes to look* [04:40] And no gzip upgrades in either log. [04:41] I wonder if it's time to add gzip_$version to the toolchain manifest at the beginning of builds. :P [06:00] So how did the Kubuntu alternates shrink 20MB all of a sudden? [06:00] (and can we add more language packs and respin?) [06:31] infinity: You could work it out from the chroot SHA1s. [06:31] If they differ, find when each first appeared. [06:37] wgrant: Surely, we don't keep all the old chroots in the librarian? [06:37] infinity: note that neither gzip nor zlib have been updated this cycle, either [06:38] slangasek: Yeah, I noticed that. [06:38] slangasek: I dunno. I'm stumped. [06:39] infinity: yeah; well, no-change rebuild SRU proposed now [06:39] slangasek: Figuring out why it happened would be nice, though, since multiarch somewhat depends on various compressed files being identical. [06:39] right, but given that this is the first we've heard of it, it's uncommon [06:39] I've been running multiarch since natty and hadn't hit it [06:41] infinity: No, but you can work out when a chroot was created easily enough. [06:41] infinity: Which should be a good guide as to which version of a package it has. [06:42] Ish. [06:42] Well, unless it wasn't upgraded when it was updated, in which case buildlogs will show the upgrade. [06:43] Very awkward and Launchpad, but doable if stuff breaks and necessitates such awfulness. [06:44] cjwatson: auto-posting code> thanks, will look for this next time, and add to the pad [06:45] cjwatson: FYI the cocoplum Translations indexing deployment is going ahead at 0830, as expected. [06:45] slangasek, skaet: right, as I wrote in the bug, the uploaded binutils looked very wrong anyway [06:46] infinity: unless you enable pkgbinarygrammar :) [06:46] infinity: no, it doesn't mangle manpages [06:46] slangasek: Weird that amd64 was the only odd man out, the other 3 matched each other. [06:46] infinity: there were "wrong" files on each of amd64 and armel, but a different one in each case [06:47] slangasek: Ahh, I was just looking at pam_shells. [06:47] slangasek: That's even more disconcerting. [06:47] the files on i386 all matched the ones I get from zcat | gzip -9nf [06:47] slangasek: Sort of rules out cosmic rays if armel had a different difference. [06:47] if it were cosmic rays, I wouldn't have expected the file to decompress cleanly [06:48] oh, seems someone already posted the new ISOs, thanks [06:49] slangasek: FTR, no off-hand idea about the manpage mismatch; certainly nothing the mangler touches [06:49] right, I wouldn't expect it to be anything the mangler is doing deliberately [06:49] but it's the part of the build process that I'm least familiar with, so it's where I'm casting aspersions ;) [06:50] * pitti posts the remaining images, such as preinstalled [06:53] done [06:53] slangasek: This is just bizarre. [06:55] * pitti goes through pkgbinarymangler with a fine comb, to see where it could possibly act up [06:56] pitti: I don't see how it could possibly be involved in this. [06:57] it matches "zip" in two places: truncating changelogs (where it re-compresses with gzip -9n) [06:57] slangasek: looking at bug 870832, shouldn't ubiquity-dm do an exit 1 which AFAIK should prevent lightdm/kdm from starting as ubiquity is started from a "on starting" event? [06:57] Launchpad bug 870832 in ubiquity (Ubuntu Precise) (and 1 other project) "Plymouth not shown during live disk shutdown. (affects: 2) (heat: 14)" [Medium,Triaged] https://launchpad.net/bugs/870832 [06:58] and compressing the _translations.tar.gz; it doesn't use -n there, but it's a hardcoded filename [06:58] slangasek: or doing "stop $JOB" (not sure if the exit 1 actually works with "on starting") [06:58] the former is dch=usr/share/doc/$PKGNAME/changelog.Debian.gz [06:58] that can't possibly match a manpage [06:58] hmm [06:59] stgraber: there's no reason that ubiquity-dm exiting 1 should prevent the dm from starting [07:00] moreover, the job is 'normal exit 0 1', so 1 is considered a reasonable exit status for the job anyway [07:01] nor does "stop kdm" help (see my comments in the bug about this hanging indefinitely...) [07:05] slangasek: ok, I'll have a look a bit later to add the signal handler to the code and have it wait after calling reboot rather than exit [07:05] stgraber: ok. Have you seen the bug in question yourself, btw? [07:05] i.e., would you be able to test the fix out and confirm that it works [07:06] I haven't been able to get a graphical plymouth splash in a VM, myself [07:11] slangasek: Unless there was just some underlying weirdness that day, the part where it happened on two files on two architectures in the same day is pretty high frequency. Maybe we've just been lucky to not notice it so far? [07:12] infinity: how would we not notice it? Every multiarch package has a changelog, all those changelogs have to be compressed the same to be installable [07:12] maybe dh_compress is somehow doing it wrong and pkgbinarymangler is doing it right, but I can't see how that would be [07:12] let's first see whether the files now end up identical once pam is built; if it reproduces, we have at least something to look into [07:12] slangasek: But is anyone running with every multiarch lib installed? [07:12] infinity: er, I am? :) [07:13] slangasek: nope, though maybe VirtualBox gives you a graphical plymouth, haven't tried yet. My current idea is to switch upstart into a very verbose mode and look at the log just before the actual reboot [07:13] slangasek: dh_installman does do some utf-8 mangling on manpages, but given that the unzipped copies are identical, I fail to see how that could hurt. [07:13] granted, not *all*, just the relevant ones... which is about 90% of those currently in the archive [07:13] infinity: right [07:13] 95% even [07:14] slangasek: Maybe you've been lucky to have the bug mostly hit armel and ppc, and you only have x86 installed? ;) [07:16] I dunno. I'm willing to believe there was just something weird going on on August 18th, but gzip being non-deterministic twice in a row is concerning. [07:16] $ dpkg -l '*:armel' | grep -c ^ii [07:16] 33 [07:16] $ [07:16] :P [07:17] I guess I should shower and get ready for the commute across the river. [07:19] save time, swim across the river [08:03] Hi, I believe bug 869420 should be release critical for Ubuntu Studio and that the attached debdiff should be uploaded right away [08:03] Launchpad bug 869420 in libffado (Ubuntu) (and 2 other projects) "jackd crashes with SIGABRT in raise() when jackd2-firewire is installed (affects: 16) (dups: 10) (heat: 128)" [High,Confirmed] https://launchpad.net/bugs/869420 [08:04] Is this the right channel to ask for such upload? [08:07] it's just on the studio images, so doesn't invalidate the others [08:08] diwic: you need sponsoring? [08:08] pitti, yes I do [08:09] uploaded [08:09] markign studio for rebuild on the tracker [08:09] pitti, thanks [08:10] one more bug squashed :-) [08:11] stgraber: fwiw, in my own tests getting anything at all out of upstart log-wise was a challenge; maybe if I do a full install it'll work better. Anyway, if/when you have a patch for the signal handler+reboot issue I'm happy to test [08:11] diwic: will rebuild studio once it's published [08:11] for release team, ^ marked so on the pad [08:12] pitti, ok, ubuntu studio will be happy :-) I hope [08:12] slangasek: ok, working on that now [08:17] hiya pitti, why is ubuntu studio marked for rebuild? [08:17] skaet: see a couple of lines up, bug 869420 [08:17] Launchpad bug 869420 in libffado (Ubuntu) (and 2 other projects) "jackd crashes with SIGABRT in raise() when jackd2-firewire is installed (affects: 16) (dups: 10) (heat: 128)" [High,Fix released] https://launchpad.net/bugs/869420 [08:18] skaet: I updated the pad [08:18] pitti, thanks!! [08:19] Bah, queuebot's dead? [08:19] you set off sirens in skaet's house :-) [08:19] pitti: Or did you just accept before the scan? [08:19] infinity: could be; it's lagging behind for 5 or so minutes [08:19] * infinity nods. [08:19] I used mdebdiff on cocoplum to speed it up [08:26] slangasek: ok, so the wait indefinitely part is easy, adding is SIGTERM handler is quite easy too, having the SIGTERM handler do the right thing is going to make the diff a bit bigger though [08:27] stgraber: none of these changes are oneiric-appropriate, so I don't mind a bigger diff :) [08:27] slangasek,stgraber: I have a test system I can do real-hardware installs on if that would help? [08:27] cjwatson: I do as well [08:33] cjwatson: Are you still planning to come down, or have you opted against? [08:33] infinity: tomorrow [08:33] (to Thursday) [08:33] Ahh. [08:33] Kay. [08:40] slangasek: http://paste.ubuntu.com/705305/ is the general idea, haven't tried it though [09:04] Hrm. [09:04] Was https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/820028 RC, or should we get mvo to re-upload that to -proposed? [09:04] Launchpad bug 820028 in software-properties (Ubuntu Precise) (and 2 other projects) "software-properties-gtk crashed with UnicodeEncodeError in RemoveSource(): 'ascii' codec can't encode characters in position 99-100: ordinal not in range(128) (affects: 24) (dups: 15) (heat: 170)" [High,Fix committed] [09:05] infinity: I'm fine uploading it to proposed too [09:06] mvo: We'll leave it there for now. If something else forces us to rebuild, I'll accept your upload too. [09:06] mvo: If nothing does, I'll reject it and you can push to proposed. [09:06] mvo: Sound good? [09:08] sounds good, thanks === doko_ is now known as doko [09:13] stgraber: maybe better to kill the server with SIGTERM first followed by server.wait(), to be sure there's no race in freeing the console? [09:16] slangasek: indeed [09:20] slangasek: http://paste.ubuntu.com/705321/ [10:08] todays images still have the pre-beta release warning in ubiquity [10:12] argh [10:13] yay process [10:13] ev: ^- could you fix that please? I'm helping with archive firefighting at the moment (hence, probably not worth uploading urgently) [10:14] cjwatson: I'm already working on it [10:15] ah, thanks stgraber [10:15] mind you, that's just in Kubuntu [10:26] new ubuntustudio posted with ffado bug fix [10:27] thanks pitti [10:28] mvo: Your update is in. [10:28] infinity: oh, are we going to respin? [10:29] pitti, see above :) [10:30] pitti: ubiquity. [10:32] infinity, skaet, cjwatson: modified CONF.sh for OFFICIAL, too [10:32] pitti: Danke. [10:33] http://paste.ubuntu.com/705341/ is the debdiff for the ubiquity that'll land in the queue in a few minutes [10:33] pitti, goodness. [10:34] stgraber: thanks, looks good [10:35] infinity: \o/ [10:36] infinity: I have another (rare) update-manager crash fix pending, but its not entirely clear to me yet what the best fix is, still working on it [10:38] ^ grabbing for review [10:39] building now [10:39] will re-trigger all desktop-y images once it's built [10:39] cjwatson, ogra_: I assume the alpha warning doesn't affect the preinstalled images? [10:39] stgraber: ^ [10:40] i. e. only desktop/DVDs affected? [10:40] .disk/info still says Beta at least on Edubuntu [10:40] stgraber: ah, right, that'd be the cdimage config change [10:40] so we need alternates, too [10:41] I can't change that code (at least I don't know how), so would be great if someone could do it before we respin everything [10:41] ogra_: do the preinstalled images have a .disk/info counterpart which needs updating to say "final"? [10:41] stgraber: I just did it [10:41] pitti: ok, thanks [10:42] pitti: could you commit that CONF.sh change, please? [10:42] (bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd) [10:43] (not the other bits that are cowboyed on antimony though) [10:43] cjwatson: will do; there is another diff on antimony which changes the _MKISOFS options [10:43] which I'll ignore [10:43] right [10:44] cjwatson: done [10:45] I'll rebuild the alternates for now, to pick up the CONF.sh change [11:03] pitti: No, preinstalled doesn't have any such thing. [11:03] infinity: thanks for confirming; so not rebuilding those [11:05] pitti: Eh? [11:05] pitti: We can't ship them with an out-of-date package installed. [11:05] infinity: ah, for oem-config, right [11:05] good, marking for rebuild, too [11:06] infinity: server armels could stay, though? [11:07] and core [11:11] stgraber: confirmed that http://paste.ubuntu.com/705321/ fixes the ubiquity-dm handling of SIGTERM [11:11] stgraber: I still get the wrong dots-on-text though [11:12] as well as the problem that whatever's going on affects *all* VTs, so I can't get back to a command prompt for further debugging :P [11:12] (pressing Alt+F2 and having the dots follow you - annoying!) [11:12] slangasek: can you add an upstart script that mounts /target, dumps the process list to disk and unmount /target just before reboot? [11:13] stgraber: I suppose so. I'm going to get some sleep first though :) [11:13] sounds like a good idea :) [11:13] There are four netbooks all with the latest daily-live on a USB stick in the corner of the room if anyone wants to do some smoke testing. [11:14] pitti: server armel is still oem-config. [11:14] pitti: core doesn't need rebuilding for any arch, though. [11:14] ok, thanks [11:21] http://paste.ubuntu.com/705348/ - is what I've uncovered by smoke testing so far. Nothing release critical though. [11:21] I'll file bugs as appropriate [11:22] just fyi, the u-m upload is not essential, it fixes a crash in the rare case that the user has no "main" source on his/her system and u-m needs to adds it. if its rejected I would really like to get it in as a 0-day SRU [11:24] ev: I saw you had a machine installed in Chinese, did you try chinese input in the installer? [11:24] mm, I did not! [11:25] did that break it? [11:25] I'm doing another chinese test install in install-only and I can't input anything in Chinese [11:25] suspecting it works if you start ubiquity from live session though [11:30] Do we need ibus or something else running in the ubiquity-only session for this? I can't recall exactly how all those bits fit together. [11:31] yes, I think we need dbus + ibus running, I remember fixing ubiquity to use ibus if it's on, so we probably just need to tweak ubiquity-dm to start ibus [11:32] I'll make sure it works from live and file a bug so that we change ubiquity-dm to start ibus for P [11:32] and release-note for Oneiric that you need to use the live environment if you plan to enter characters that require ibus [11:39] FYI BTW, the publisher is still on manual as we're firefighting i18n/Index issues [11:39] so don't be too surprised about builds being slow to show u [11:39] *up [11:39] ah, good to know [11:40] so I should update this channel on that and ask for feedback [11:41] this morning's ftpmaster deployment was to turn on i18n/Index generation to fix bug 572128 [11:41] Launchpad bug 572128 in debmirror (Ubuntu) (and 1 other project) "Ubuntu Archive translations are missing Index metadata file (affects: 3) (heat: 18)" [Undecided,Invalid] https://launchpad.net/bugs/572128 [11:41] this caused all oneiric builds to fail because the buildd chroots were running a slightly old version of apt which failed 'apt-get update' in the presence of any i18n/Index files [11:42] this apt bug was fixed in 0.8.16~exp5ubuntu9 [11:42] unfortunately, 0.8.16~exp5ubuntu6 (which was buggy) was shipped with 11.10 beta-1 [11:42] this means that systems installed with beta-1 cannot be upgraded if we keep this change [11:42] at least not without manual hackery [11:43] if we back out this change, it means that debmirror archives don't get any long package descriptions, due to the work on moving long descriptions out of Packages and into Translation-en to reduce the bandwidth hit for multiarch [11:44] so in order to fix that, we would also need to turn that feature off (which is a matter of an API request) for oneiric, and turn it back on for precise [11:45] and we would furthermore need to make sure not to upload DDTP tarballs for oneiric-updates; historically we haven't done that anyway, although it does cause some problems (bug 672314) [11:45] Launchpad bug 672314 in apt (Ubuntu) (and 1 other project) "No translated package descriptions for -updates repository (affects: 3) (dups: 1) (heat: 9)" [Undecided,Confirmed] https://launchpad.net/bugs/672314 [11:47] cjwatson: I'm not sure that being able to upgrade beta->final from GUI tools is a huge deal, is it? [11:47] it will generate support [11:47] historically we've promised that you can [11:48] cjwatson: Well, wait. Was this "broken" apt the same one that I was just using in the chroots? [11:48] yup [11:48] Cause, yeah. It's grumpy on apt-get update, but it still works. [11:48] It just exits non-0. [11:48] oh? what effect does that have on u-m then? [11:48] That breaks the buildds, but that won't break update-manager. [11:48] At least, it shouldn't. [11:48] Ah, here. [11:48] Cause you still get new Packages files. [11:49] mvo: ^- if you could test that, then, that would be lovely [11:49] I don't care if beta-1 users get an irritating popup about apt failures before they finish upgrading; that's eminently release-notable [11:49] If it was broken to the point where you didn't get packages files, fixing the chroots would have been much more annoying. [11:50] But I didn't have to copy in a new apt and dpkg -i or anything, update/upgrade still worked. [11:50] Just with a non-0 exit on update. [11:50] Not big deal. [11:50] s/Not/No/ [11:50] Hm, OK, that does sound less panic-worthy [11:50] so as long as the GUI tools aren't a complete nightmare, it's tolerable [11:51] mvo: *poke* [11:51] infinity: *poke back* [11:52] mvo: Okay, so, apt-get update works fine (thought exits non-0, but it does update the indexes) [11:52] mvo: Are you concerned that u-m will do something extra broken on top of that? [11:53] infinity: I'm not sure that it does not break stuff, it appears the "broken index protection" kicks in and it won't actually update the /var/lib/apt/lists files, not even the Packages list file, but I need to double check with a actual b1 apt [11:53] what's the typical lag time between the release and it starting to show up in update-manager? Is it roughly 1 day, given that's how often the apt-get update cron job fires? [11:53] mvo: Well, the chroots worked. [11:53] mvo: That's my point. [11:53] mvo: The broken version we're all talking about just worked to upgrade 4 buildd chroots. [11:53] mvo: The only reason the buildds didn't work automatically was because update exited non-0. [11:53] mvo: But doing it manually, it went fine. [11:54] but will python-apt-based programs raise IOError all over the show ... [11:56] or aptdaemon raise TransactionFailed [11:56] ev: it used to be about a day, but we changed it in oneiric to the same frequency as the regular updates (so 7 days) [11:56] Even if they do, is it the end of the world to release note that people with that specific apt version from beta1 just need to "apt-get update ; apt-get install apt" from a console? [11:56] We expect beta users to be vaguely technical. [11:56] infinity: hm, good point [11:56] That's certainly a possibility. I'd like to know for sure though [11:56] * mvo will test in a wee bit [11:57] Alright. I might go sandwich hunting. [11:57] mvo: okay, and if they hit "check" they'll see it straight away, right? [11:57] ev: yes [11:58] thanks [12:02] ubuntu/kubuntu/xubuntu/server alternates posted [12:07] ^ oh, ok; ditching them again [12:08] disabled, pad updated for update-manager build [12:09] thnx [12:11] skaet: FYI, I'll leave image rebuilds alone for the time being, until above apt issue was figured out, ok? /me leaves for lunch, bbl [12:11] pitti: next time you need to post an image to the tracker, let me know, I'd like to test the new tool [12:11] pitti, ack. [12:11] thanks [12:12] cjwatson: ack, wanted to ask you about that at some time [12:12] I'd actually forgotten to commit it until a moment ago [12:15] infinity, cjwatson: good news, I just tested this with the b1 live-cd and while u-m complains and show a error it will display the updated apt and let me install it. after instlaling the updated apt everything works as excepted (no more error on check) [12:19] oh, that is good news [12:20] and b2 had the fixed version [12:20] so release note and leave this turned on, then? [12:22] I think so, yes [12:22] essentially people just need to ignore the error message [12:39] mvo: \o/ [12:46] I've filed https://bugs.launchpad.net/ubuntu-release-notes/+bug/871731 [12:46] Launchpad bug 871731 in ubuntu-release-notes "Direct upgrades from beta-1 will produce annoying error message (affects: 1) (heat: 6)" [Undecided,New] [12:49] publisher back on auto [13:00] stgraber: have you uploaded ubiquity 2.8.5 or am I able to get one more fix in? [13:00] 11:36 -queuebot:#ubuntu-release- New package: ubiquity (main) [2.8.4 → 2.8.5] [13:01] 11:40 -queuebot:#ubuntu-release- Removed package: ubiquity [13:01] updates it is then [13:18] * cjwatson goes out for the better part of an hour [14:10] skaet, infinity, cjwatson: new ubiquity and update-manager are in; shall I kick off new images, or are we waiting on something else? [14:10] pitti: Are you respinning alternates too? [14:12] ScottK: yes, for update-manager and oem-config [14:12] pitti: I'd like to add more language packs to the Kubuntu alternate since it looks like it's got room. [14:12] ScottK: you know langpack-size? [14:12] pitti: Go for it. I was just about to, but I'm happy to have you drive. [14:12] pitti: I usually guess ~5MB per. [14:12] pitti: Well, once ScottK's done fiddling. :) [14:13] pitti: If I get it wrong, it's not like respinning an alternate takes long ... [14:13] cjwatson: ah, or do you want to set off new builds with trying your new auto-tracker-posting magic? [14:14] infinity: if you guys at the sprint want to drive this, fine for me (might be easier for coordination) [14:15] ScottK: http://paste.ubuntu.com/705403/ [14:15] ScottK: you want the "K" column [14:16] Thanks. [14:16] Let me double check then. [14:16] infinity: ah, cjwatson is still out, I figure [14:16] pitti: No, no. Be my guest. [14:17] pitti: I'm chasing all sorts of things here. [14:17] pt is huge. [14:17] infinity: alrighty; he said "when you post", so I guess this can build already [14:17] Let me back one off. [14:17] ScottK: http://paste.ubuntu.com/705404/ <- complete list [14:18] desktop/preinstalled running [14:19] waiting for ScottK's signal to kick off alternates [14:19] pitti: Pushed the seed change in bzr. [14:20] thanks; alternates builds started [14:56] ug, kubuntu/daily/20111010.1 oversized [14:56] * ScottK looks [14:56] ScottK: ^ seems one too much? [14:57] Yeah. Just on i386 though. [14:57] * ScottK fiddles [14:57] pitti: just tell me when you're ready to post it and I'll try posting manually [14:57] cjwatson: ah, back [14:58] cjwatson: ubuntu alternate is ready to post [14:58] pitti: Fixed. [14:58] cjwatson: the kubuntu one will be rebuilt, so if you can control this, please don't post that one yet [15:00] ok, let me have a go [15:03] ... oh, I need to set cdimage up as an admin, one moment [15:06] cjwatson: on the tracker? do you have access to Drupal's admin interface? [15:20] stgraber: could you make ubuntu-cdimage an admin? [15:20] I just created that account [15:21] cjwatson: done [15:24] rock on. set up [15:24] cjwatson: xubuntu alternate, core, server preinstalled are now also waiting for posting, for the record (in case you want to check with output of your magic script)_ [15:24] $ post-qa 20111010.1 ubuntu/daily/oneiric-alternate-amd64+mac ubuntu/daily/oneiric-alternate-amd64 ubuntu/daily/oneiric-alternate-i386 ubuntu/daily/oneiric-alternate-powerpc [15:24] worked [15:24] I'll try the others [15:25] that's only for if you need to post an image semi-manually; normally, 'CDIMAGE_POST_QA=1 for-project ubuntu cron.daily' etc. should just work [15:26] I wonder if it will work after I log out in my browser [15:27] ah, nice, will remember for teh next time [15:27] apparently not ... [15:27] (so don't use it yet, still working on this) [15:27] cjwatson: added to the pad, with the "being tested" caveat [15:27] I need to disappear for a bit, back later [15:28] can someone post the images as they come in in the meantime? [15:28] oops, misversioned ubuntu-core [15:29] (fixed) [15:29] pitti: server preinstalled dates from 20111009 - is that really waiting for posting? [15:29] I've done the others [15:30] cjwatson: ah, no; I guess the cron.daily-preinstalled is still running then, sorry [15:30] * ogra_ thought there was a respin in progress [15:30] its 90min per image for the rootfs plus about 1h for the post processing for all images [15:31] (or 45min for the latter) [15:31] looks like it's still in progress, yes [15:34] * ScottK is reviewing ^^^ === micahg_ is now known as micahg [15:51] Kubuntu alternates are up and they fit now. [15:51] cjwatson: Could you post them to the tracker? [15:55] ScottK: done [15:55] cjwatson: Thanks. [16:46] re [16:48] cjwatson: do you want to publish the new images with your script for testing, or want me to? [16:50] trying post-qa with server [16:51] $ post-qa post-qa 20111010.1 ubuntu-server/daily/oneiric-server-amd64 [16:51] No iso.qa.ubuntu.com product found for 20111010.1; skipping. [16:51] cjwatson: ^ apparently not the right incantation? [16:53] erk, ignore me please [16:54] cjwatson: studio and server i386/amd64 posted, but this fails: [16:54] $ post-qa 20111010.1 ubuntu-server/daily/oneiric-server-amd64+mac [16:54] KeyError: "Product 'Ubuntu Server amd64+mac' not found" [16:55] I have a ubiquity upload that I'm going to shove in the queue as soon as pbuilder finishes. It mainly fixes bug 838048, which will only occur if you've disabled wireless and selected the "connect to this network" radio button on the wireless page. I leave it to you lot to decide if that's sufficiently high priority to warrant a respin. :) [16:55] Launchpad bug 838048 in ubiquity (Ubuntu) "ubiquity crashed with TypeError in __new__(): object of type 'NoneType' has no len() (affects: 8) (dups: 6) (heat: 62)" [High,Fix committed] https://launchpad.net/bugs/838048 [16:55] ah, we build them, but don't have amd64+mac in the tracker, I see [16:56] skaet: Edubuntu OEM install doesn't work because of one of my ubiquity plugins. I'm testing a fix now and I'll upload a new edubuntu-live fixing it. I'll want a respin of Edubuntu for that if possible (package is only shipped on Edubuntu) [17:04] cjwatson: posted all pending images using post-qa, working fine [17:06] pitti: I think everything we build ought to have a corresponding tracker product, and maybe this will help us discover omissions :-) [17:07] we've had a few rather ridiculous conversations of the form "this image hasn't been tested" "but it isn't even in the tracker, so how can we expect it to be" [17:12] Riddell, IIRC had something he wanted to get into Ubiquity KDE. [17:12] ev: Do you know if Riddell committed anything for ubiquity-kde? [17:13] probably removal of the alpha warning [17:13] which stgraber took care of [17:13] OK. Great. [17:14] He's not online now and he didn't say. Thanks. [17:15] ev: I don't think that was it [17:16] ah, fair enough [17:18] I just emailed him. [17:18] pushed a fix for the Edubuntu OEM bug. edubuntu-live should hit the queue soonish [17:19] debdiff: http://paste.ubuntu.com/705501/ [17:19] pitti, skaet: would be great if this could go in and then rebuild Edubuntu ^ [17:20] so I guess I shouldn't bother posting the ones that are currently built then? [17:20] indeed [17:22] now we need to rebuild all images for ubiquity, so that's no small cost [17:29] I have a report of crashes in language-selector-kde, which would affect all Kubuntu images and Edubuntu. [17:29] Details when I have them. [17:30] stgraber: edubuntu-live accepted [17:32] "it crashes on startup all the time" <-- language-selector-kde [17:32] Bug being filed. [17:33] "* LanguageSelector/LangCache.py [change not affecting KDE]" was apparently wrong. [17:33] ScottK: I had some serious trouble testing that; I tried beta-2 Kubuntu CD, and couldn't figure out for the life of it how language-selector was integrated [17:33] so, test case appreciated [17:34] I have someoene working on both the bug and a fix. [17:35] all images marked for rebuild in tracker for ubiquity/edubuntu-live/language-selector issue [17:36] pad updated [17:39] pitti: language-selector-kde is in System Settings -> Locale -> System Languages [17:40] can anybody approve my packages, please? As discussed with slangasek, I uploaded "nvidia-graphics-drivers" and "fglrx-installer" in oneiric-proposed (since they are on some dvd images) while the other packages "nvidia-graphics-drivers-updates", "nvidia-graphics-drivers-173", "nvidia-graphics-drivers-173-updates", "nvidia-graphics-drivers-96", "nvidia-graphics-drivers-96-updates" and "fglrx-installer-updates" sho [17:54] * skaet --> dinner, back on later [18:00] * ev is going for a run. Will have my cell phone on me, but I forgot my armband so it'll be tucked away in my backpack. Call if the installer catches fire and hopefully I'll hear it [18:02] debfx, ScottK: I have a fix, is there a bug # for this? [18:02] ah, got it [18:06]