[06:28]  * skaet notices WUBI not on iso tracker,  starts it off
[07:25] <Laney> !?!?!?!?
[07:27] <Laney> the reason it was up to .7 is because it got retried several times while clearing the locking bug
[07:27] <Laney> there weren't 7 respins...
[07:43] <babyface_> upgrade from precise to quantal failed(both i386 and amd64) with a error ::41:20,898 ERROR Dist-upgrade failed: 'The package 'unity-2d' is marked for removal but it is in the removal blacklist.'
[07:43] <babyface_> anybody has idea on this?
[07:49] <jibel> babyface_, yes, please file a bug
[07:50] <babyface_> jibel,  ok. thanks.
[07:50] <jibel> babyface_, against update-manager
[07:50] <babyface_> jibel, ack.
[07:54] <Laney> babyface_: jibel: the blacklist lives in ubuntu-release-upgrader-core (so bugs for it to ubuntu-release-upgrader)
[07:54] <jibel> Laney, right, sorry
[07:54] <Laney> np
[07:54] <babyface_> Laney,  ok, thanks .
[07:55] <Laney> thanks for noticing it
[07:56] <Laney> I can reupload with that entry dropped if someone confirms to me that doing that is necessary and sufficient
[07:57] <mvo> jibel, Laney: uh, I can fix this, I guess that does no longer makes sense :)
[07:58] <Laney> ah, great, thanks mvo
[07:59] <Laney> didn't the automated tests catch this?
[07:59] <mvo> Laney: a good question, I don't know
[08:00] <jibel> Laney, it did, that how babyface_ found it.
[08:00] <mvo> babyface_: is there a bugreport already that I should reference? if not, I can just upload as its a pretty small change
[08:00] <jibel> https://jenkins.qa.ubuntu.com/job/quantal-upgrade-precise-desktop/126/ARCH=amd64,LTS=non-lts,PROFILE=desktop,label=upgrade-test/artifact/results/main.log
[08:01] <babyface_> mvo, not yet
[08:01] <babyface_> mvo, so feel free to upload
[08:01] <mvo> babyface_: ok, don't worry, I just upload
[08:02] <mvo> thanks for the report babyface_
[08:02] <babyface_> mvo, yw
[08:02] <Laney> jibel: that is good. is this a new test? the change happened about 3 weeks ago IIRC
[08:08] <jibel> Laney, it is not a new test, and it is the first time it is detected. Something must have changed the upgrade path.
[08:08] <Laney> interesting
[08:17] <Laney> mvo: are those other changes automated?
[08:18] <mvo> Laney: yes
[08:18] <Laney> cheers
[08:18] <Laney> approving them
[08:18] <mvo> Laney: its demoted packages that are automatically calculcated on each build
[08:18] <Laney> then
[08:18] <mvo> ta
[08:19] <Laney> jibel: ^-- would you be able to re-run this test when the new package is available?
[08:21] <jibel> Laney, of course, no problem.
[08:21] <Laney> \o/
[08:23]  * jibel wishes next release will be named 'rapid rabbit', Q is soo sloow without the appropriate hardware.
[08:31] <cjwatson> I suspect what happened with unity-2d is that I only got around to moving it to universe yesterday IIRC
[08:31] <cjwatson> The transitional packages that is
[08:34] <Laney> aha
[08:43] <Laney> are we really trying to get the gtk2 indicators back in for b1?
[08:43] <ogra_> lubuntu and xubuntu would likely like that
[08:45] <Daviey> Laney: it should be done.. universe only.
[08:45] <Laney> Daviey: with seed changes / respins
[08:49] <Laney> gah
[08:49] <Laney> knome: Hey, you here? Is anyone taking care of the seed changes to get the indicators back, do you know?
[08:49] <Laney> micahg: ^ you might know
[08:58] <Laney> plars: psivaa: babyface_: Are you relatively happy so far?
[08:58] <Daviey> Laney: I'm going to guess, gilir doing the change and phillw will help let the communities know.
[08:58] <Laney> Daviey: I tried to nick complete gilir but he's not here so that failed :-)
[08:59] <Laney> ah, phillw: I wanted to clear up your confusion from yesterday
[08:59] <Daviey> Laney: I'd just wait out, it's not ohnoes urgent to get it span, right?
[08:59] <Laney> .7 didn't mean there were 7 respins, just that the script to increment the release number was called 7 times
[08:59] <Laney> there was infact only one
[09:01] <Laney> Daviey: Well, it's up to them. I'm trying to provide people with as much time as possible to do their validation. ;-)
[09:09] <psivaa> Laney, is this question about the time given for testing or the quality in general?
[09:09] <Laney> all of it
[09:09] <Laney> I saw there was a bit of confusion yesterday where people were expecting server respins that weren't happening
[09:15] <psivaa> i know plars was talking about a possible server respin yesterday but i was not sure what made him think, could verify that today when he comes online
[09:16] <cjwatson> There was talk about it at one point but we decided against it, I think.
[09:16] <ogra_> psivaa, possible respins should be in the pad
[09:17] <cjwatson> Because ubiquity was uploaded and builds packages on the server image, but in practice the bug in question didn't affect server.
[09:17] <ogra_> hrm, why is the pad url gone from the topic again ?
[09:17] <ogra_> i know skaet added it last milestone
[09:17] <Laney> needs an op to fix (preferably to set mode -t)
[09:18] <cjwatson> We occasionally get -party refugees in here so I think I prefer +t, but
[09:19] <iulian> Heh.
[09:19] <Daviey> aww, topics. I remember reading those.
[09:19] <ogra_> cjwatson, thanks !
[09:22] <xnox> opportunity translation ('french') respin for ubiquity see bug 1045695
[09:22] <ubot2`> Launchpad bug 1045695 in ubiquity "ubiquity-debconf need translations refreshed from launchpad (e.g. french is incomplete)" [Undecided,New] https://launchpad.net/bugs/1045695
[09:24] <cjwatson> We don't normally respin for translation improvements - we'd be there all day
[09:24] <cjwatson> It can ride along with some other upload, but I wouldn't bother listing it explicitly in the pad or anything
[09:26] <xnox> ok.
[09:31] <iulian> Laney: Someone just filed an FFe bug but what he really wants is a backport. Do you guys want a new bug filed or can he just edit the existing one?
[09:31] <Laney> reassign it to backports
[09:32] <iulian> Okey-dokey.
[09:32] <Laney> it would be nice if you could ask him to include the template information too (open requestbackport and paste it into the existing bug description)
[09:33] <Laney> or close it and ask him to file a new one with requestbackport, whatever you think's best
[09:35] <iulian> OK. I'll just close it and tell him to file a new one using requestbackport.
[09:36] <Laney> grand
[10:03] <cjwatson> I'm trying to resolve various NBS and such which has led me down the path of poking at the tiff transition.  As part of this I'm syncing sdl-image1.2 from experimental, which drops some dependencies of libsdl-image1.2-dev.  This isn't the whole story for sdl-image1.2, but I'm pretty sure that it will improve buildability of reverse-deps, some of which currently fail due to trying to mix libtiff4-dev and libtiff5-dev.  ...
[10:03] <cjwatson> ... I'll test reverse-deps after sdl-image1.2 has built and fix up anything that breaks.
[11:23] <knome> Laney, i don't know
[11:32] <mvo> could someone please reject the apt waiting for review to go into precise-proposed? as its not in yet I will add another fix to it and re-upload
[11:32] <ogra_> hmm, omap4 server doesnt look so good
[11:33]  * ogra_ blames Daviey 
[11:35] <seb128> mvo, done
[11:38] <mvo> seb128: thanks!
[11:38] <seb128> yw ;-)
[11:40]  * cjwatson develops a nasty suspicion about bug 987418
[11:40] <ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Triaged] https://launchpad.net/bugs/987418
[11:40] <cjwatson> Don't tell me that it's misbracketing
[11:57] <cjwatson> It is.  How embarrassing.
[12:01] <plars> psivaa: regarding the server respin, I was told that there had been one kicked off on accident so it was just going to happen even though it wasn't really needed.
[12:03] <knome> cjwatson, at least its fixed now.
[12:03] <knome> :)
[12:03] <psivaa> plars, ahh ok, was wondering if there was any of such information at the pad
[12:03] <cjwatson> Laney,psivaa: I would like to fix bug 987418 for beta-1.  The fix is http://paste.ubuntu.com/1185617/, but would of course require a respin of pretty much everything.  What do you think?
[12:03] <ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Triaged] https://launchpad.net/bugs/987418
[12:04] <cjwatson> Well, everything except core/server/netboot.
[12:05] <cjwatson> I'd probably want to do a translation update at the same time, per xnox.
[12:05] <xnox> =)
[12:06] <Laney> I defer to QA: it seems like it should be alright to release note that and get it in immediately after, but also the bug is irritating. If they don't mind re-QAing then fine by me.
[12:07] <cjwatson> We've been release-noting it (or at least I think we have) for a while, but it's the kind of bug people don't notice and then end up with a subtly trashed system.
[12:08] <psivaa> i agree with Laney, for redoing the whole images for a single use case seem less efficient :), and getting forgotten after release noting does not seem to be a good reason for resping imho
[12:08] <jamespage> query re: radosgw - its been promoted to main in quantal but it still has a pending MIR review - bug 1017978
[12:08] <ubot2`> Launchpad bug 1017978 in libfcgi "[MIR] libfcgi, ceph (radosgw)" [Medium,Fix released] https://launchpad.net/bugs/1017978
[12:09] <jamespage> radosgw and rest-bench (both built from ceph) should be in universe until that is sorted one way or the other...
[12:09] <cjwatson> psivaa: You're fine with a release note that basically says you must use manual partitioning if you're installing from USB?
[12:09] <cjwatson> jamespage: oh, I didn't notice that there was per-binary MIRing going on
[12:10] <cjwatson> jamespage: moved back to universe
[12:10] <jamespage> cjwatson, yeah - sorry - its a little obfuscated...
[12:10] <jamespage> ta
[12:11] <psivaa> cjwatson, yes, i  guess because as per the bug this is occurring only for side-by side installation
[12:12] <cjwatson> I'm not convinced about that.
[12:12] <cjwatson> Let me see if I can reproduce it otherwise.
[12:13] <psivaa> cjwatson, please and if we tried usb installations and they worked fine apart from side by side
[12:13] <psivaa> s/please and if//
[12:15] <ogra_> stgraber, hmm, could i get a testcase for armhf+ac100 lubuntu-desktop on the tracker ?
[12:22] <cjwatson> psivaa: Hmm, it may be that the "erase disk" option overrides the boot device in some way I've forgotten
[12:22] <cjwatson> I'm uncomfortable with this, but I guess I'm not the one who has to do the testing.
[12:23] <psivaa> cjwatson, i understand your concern, but when you see this bug was first reported on  2012-04-23 and we have managed to live with it.. even for precise
[12:24] <cjwatson> I've used the "we released with this before" argument myself, but I think this has resulted in rather a lot of subtly corrupted installations.  Subtle corruption scares me.
[12:25] <cjwatson> Distressingly, this appears to have been a late regression I introduced in precise due to fixing bug 984989.
[12:25] <ubot2`> Launchpad bug 984989 in ubiquity "grub install fails. installing from /dev/sda to /dev/sdb" [High,Fix released] https://launchpad.net/bugs/984989
[12:26] <cjwatson> The test case I added there didn't work quite right because I didn't consider the case where boot_device is None.
[12:27] <cjwatson> Which happens when partitioning hasn't been done yet.
[12:28] <cjwatson> (IOW, we only released precise with it because it was a sufficiently late and subtle regression that we didn't have time to realise its importance.)
[12:28] <cjwatson> Anyway, I've said my piece.
[12:33] <psivaa> cjwatson, well, as i said that's very a valid bug that needs urgent fixing but i am not personally convinced that this has to be done 2 days before the release, as you said above the fixes are regression prone
[12:38] <stgraber> ogra_: sure, I guess I can just copy what's currently assigned to the armel one?
[12:44] <ogra_> stgraber, well, its lubuntu-desktop now
[12:45] <stgraber> ogra_: oh right, sorry my eyes missed the "l" ;)
[12:53] <Riddell> kubuntu upgrade bug 1029150 should be fixed with lightdm-kde in queue
[12:53] <ubot2`> Launchpad bug 1029150 in lightdm-kde "precise to quantal upgrade does not work" [Undecided,Confirmed] https://launchpad.net/bugs/1029150
[13:04] <Laney> cjwatson: do you want to upload as an opportunity target? e.g. for kubuntu ^
[13:10] <cjwatson> Laney: I was wondering whether I might be able to fix bug 1038522 if I was doing that
[13:10] <ubot2`> Launchpad bug 1038522 in ubiquity "manual partitioning in installer crashes" [High,Triaged] https://launchpad.net/bugs/1038522
[13:10] <cjwatson> Combination of (a) you have to use manual partitioning when installing side-by-side from USB and (b) manual partitioning busted with KDE frontend is kind of unhelpful
[13:11] <cjwatson> (Though to be fair I've not tested whether (a) happens with Kubuntu)
[13:11] <Laney> sounds reasonable
[13:14] <cjwatson> Riddell: ^- unless you think somebody might be able to attack that ASAP?
[13:14] <cjwatson> The KDE frontend is a bit outside my comfort zone these days
[13:17] <Riddell> currently the candidate desktop image for kubuntu doesn't seem to be working well :(
[13:17] <Riddell> was going to try and recreate that bug
[13:17] <cjwatson> Urgh, you can't even get that far?
[13:18] <Riddell> it's just rediculously slow
[13:20] <cjwatson> 3D?
[13:22] <Riddell> cjwatson: dunno, kwin has accelatation off
[13:22] <jibel> xnox, I get bug 1045812 with LVM (not sure if doing the installation in French has anything to do with the crash)
[13:22] <ubot2`> Launchpad bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [Undecided,New] https://launchpad.net/bugs/1045812
[13:23] <xnox> Volume group "ubuntu" has insufficient free space (4034 extents): 4028254 required.
[13:23] <xnox> jibel: =/
[13:23] <xnox> jibel: thank you very much for testing all this by the way! you are finding bugs that I was not hitting in my testing!
[13:23] <jibel> xnox, /bin/perform_recipe_by_lvm: 136: [: Illegal number: 16919822,34
[13:24] <jibel> xnox, blame French
[13:24] <cjwatson> Well
[13:24] <jibel> , instead of .
[13:24] <cjwatson> . wouldn't work either there
[13:24] <cjwatson> [ wants integers
[13:24] <xnox> it must be integer, yeah.
[13:25] <xnox> fixing partman-lvm will result in respinning everything but the cloud images and maybe netboot images?!
[13:25] <cjwatson> Wouldn't need to respin netboot for that, no
[13:25] <cjwatson> Might want to retest it, but server tests would probably be enough
[13:27] <xnox> jibel: was the second time in a row you were installing onto the same disk? or am I missreading the logs that say "activate existing ubuntu VG"
[13:27] <skaet> cjwatson, am not spotting the updated Chinese image from yesterday on: http://china-images.ubuntu.com/quantal/daily-live/
[13:27] <skaet> Laney,  did anything happen with the build?
[13:27] <Laney> let's look
[13:27] <cjwatson> skaet: I didn't rebuild it; I uploaded the fix and then said I was leaving
[13:28] <Laney> I was under the impression it was going to break and need to be respun though
[13:28] <cjwatson> The last respin of the Chinese edition was before my fix.
[13:28] <cjwatson> I mean the last attempt.
[13:29] <skaet> cjwatson,  the version there is from 08/31,  so am wondering if some publishing glitch?
[13:29] <Laney> I'll retry it now
[13:29] <cjwatson> skaet: No.  Nobody attempted to rebuild following my fix.
[13:29] <Laney> going
[13:30] <jibel> xnox, on this system, I reinstalled over and existing installation, but the second message ("No root filesystem") is with a fresh disk (fresh = no partition table at all)
[13:30] <skaet> cjwatson,  that would explain it.    I thought it was included in the build set that Laney ran.
[13:30] <Laney> it was, but it was broken at that point
[13:30] <cjwatson> skaet: It might have been, but that was before my fix, wasn't it
[13:30] <cjwatson> ?
[13:30] <Laney> no failure mail, though
[13:31] <cjwatson> No, build-chinese-edition doesn't implement that
[13:31] <cjwatson> Life was too short
[13:31] <skaet> if it was at the end though,  it would have been included I would have thought.
[13:31] <cjwatson> skaet: Honestly, it was before my fix.
[13:31] <cjwatson> I've checked, twiwce.
[13:31] <cjwatson> *twice
[13:31] <xnox> jibel: from the code it's comparing to variables guided & free space, it does convert guided space into bytes / integer value before hand. Not sure if the free space is the one that is decimal. What was the size of the virtual drive?
[13:31] <cjwatson> 17:40
[13:32] <cjwatson> That's probably UTC, but either way I didn't upload my fix until 18:41 +0100
[13:32] <skaet> cjwatson,  gotcha.    sorry.      rebuilding now will catch it.
[13:32] <jibel> xnox, 16.00GB
[13:33] <cjwatson> I think it was indeed pretty much at the end, although I don't know what was happening with Wubi.
[13:35] <Riddell> I can't recreate bug 1038522 it must be doing some action in the manual partitioner I'm not doing
[13:35] <ubot2`> Launchpad bug 1038522 in ubiquity "manual partitioning in installer crashes" [High,Triaged] https://launchpad.net/bugs/1038522
[13:35] <Riddell> xnox: have you recreated it or did you just spot the bug?
[13:36] <xnox> Riddell: received 2 duplicates & two more comments on the duplicate. Maybe it's precise only? From comments you need to have a few existing partitions (existing dual/triple boot) installs and then enter partitioning to generate the crash.
[13:37] <xnox> Riddell: I was hoping that for Qt people it would be obvious why the traceback says that some attribute is missing
[13:46] <skaet> cjwatson,  I triggered a rebuild last night - but am not seeing it on the iso tracker.
[13:46] <skaet> rebuild came back looking positive.
[13:46] <cjwatson> Rebuild of ...?
[13:47] <jibel> xnox, I added /var/log/installer/debug with ubiquity -d if it helps
[13:47] <xnox> jibel: let me look =)
[13:48] <skaet> rebuild of WUBI
[13:48] <cjwatson> odd, doesn't seem to be a log file
[13:48] <cjwatson> There's one yesterday from 07:37 and one today from 07:09 (?)
[13:49] <skaet> ubuntu-wubi-i386 on cardamom.buildd finished at 2012-09-04 07:09:05 (success)
[13:49] <skaet> Tue Sep  4 07:09:43 UTC 2012
[13:49] <cjwatson> Oh, your last night not my last night :-)
[13:49] <cjwatson> Bah timezones
[13:49] <skaet> its the one today,  that was kicked off earlier.
[13:49] <skaet> yes,  sorry,  still need coffee on this side.  ;)
[13:49] <cjwatson> Nah, that was my fault
[13:50] <cjwatson> The log claims to have posted to the tracker
[13:50] <Laney> http://china-images.ubuntu.com/quantal/daily-live/current/
[13:50] <Laney> haz chinese images
[13:50] <cjwatson> And it seems to be on the tracker ...
[13:50] <cjwatson> "Ubuntu Wubi amd64" version 20120904, i386 likewise
[13:50] <skaet> thanks Laney
[13:51] <skaet> *blink*,  ok bad web page cache refresh on my side then.  sorry.
[13:54] <Riddell> Laney: can lightdm-kde be let in?  it's not needed for the images only for upgrade
[13:54] <Laney> do we not get the zh_CN images on the tracker?
[13:54] <Laney> Riddell: oh, yes, let me look
[13:54] <cjwatson> We should do ...
[13:54] <Laney> I don't see them for .1 either
[13:54] <Laney> unless we didn't release it then
[13:54] <cjwatson> Oh, maybe not
[13:55] <cjwatson> No post-qa in publish-chinese-edition
[13:55] <cjwatson> Bah
[13:56] <cjwatson> Well, except wasn't it supposed to be QAed by PES, or on the localised tracker, or something?
[13:56] <cjwatson> localized-iso.qa.ubuntu.com has a product entry for Chinese
[13:56] <cjwatson> But I don't think we have configuration for auto-posting there at the moment
[13:56] <cjwatson> How about I say "not yet" and leave it at that
[13:56] <skaet> cjwatson,  ok by me
[13:57] <skaet> I'm pointing the PES folk at them directly.   Would be nice to get it hooked up before beta 2 though.
[13:57] <skaet> s/them/web page/
[13:57] <cjwatson> Somebody should probably file an ubuntu-cdimage bug as a reminder
[13:57] <Laney> Riddell: there you go
[13:57]  * skaet doing
[13:57] <cjwatson> It could be posted to the tracker manually
[13:58] <cjwatson> xnox: so do you think jibel's problem is respin-worthy?  if so we probably need to run that past the QA contact ...
[13:58] <Laney> Riddell: so you don't need it on the images because the previous postinst would DTRT due to it always being a fresh install?
[13:58] <Riddell> Laney: yes
[13:58] <cjwatson> (and in that case I'd definitely like my fix for 987418 to ride along)
[13:58] <jibel> (+1 for 987418)
[13:59] <Laney> if we're building up a stock of installer fixes then it makes respinning more compelling for me
[13:59] <skaet> plars, ^ since you're on point for QA this cycle.  Any comments?
[13:59] <xnox> cjwatson: i don't know yet. trying to reproduce it locally with extra debugging.
[13:59] <xnox> and have a fix.
[13:59] <cjwatson> psivaa nacked it on its own but one of his arguments involved undesirability of respin-for-single-fix
[14:01] <plars> skaet: having trouble sorting which thing in the backlog you're referring to
[14:01] <plars> bug #987418 ?
[14:01] <ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Fix committed] https://launchpad.net/bugs/987418
[14:01] <plars> or jibel's problem? (and which was that?)
[14:03] <skaet> plars,  yes both.   However I don't know the bug number for jibel's either  (lost some backscroll from earlier)
[14:03] <plars> looks like 987418 is jibel's too
[14:03] <xnox> catching rides Bug 744283 is an a11y theming fix.
[14:03] <ubot2`> Launchpad bug 744283 in ubiquity "Steps "Preparing to install" and "Erase disk" are unreadable with high-contrast theme enabled" [Medium,Fix committed] https://launchpad.net/bugs/744283
[14:03] <xnox> diff is a bit poluted by glade changes.
[14:03] <cjwatson> that wasn't the bug of jibel's I was referring to - I meant the LVM issue several pages deep in scrollback
[14:03] <plars> ah, maybe bug #1038522
[14:03] <ubot2`> Launchpad bug 1038522 in ubiquity "[kde] manual partitioning in installer crashes" [High,Triaged] https://launchpad.net/bugs/1038522
[14:03] <cjwatson> bug 1045812 I think
[14:03] <ubot2`> Launchpad bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,Confirmed] https://launchpad.net/bugs/1045812
[14:03] <plars> jibel, cjwatson is that the one?
[14:03] <cjwatson> no
[14:03] <henrix> infinity: when you have a minute, could you please copy into -updates (and -security) the kernels from bugs 1036553, 1036178 and 1041217?
[14:04] <ubot2`> Launchpad bug 1036553 in linux "linux: 2.6.32-42.96 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036553
[14:04] <ubot2`> Launchpad bug 1036178 in linux "linux: 3.0.0-25.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036178
[14:04] <ubot2`> Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217
[14:04] <cjwatson> that's unreproducible at this time apparently
[14:04] <cjwatson> (1038522)
[14:05] <Laney> u-cdimage bug filed
[14:05]  * Laney goes out for ~1h
[14:07] <skaet> cjwatson, plars, jibel -  has the status of the bugs in play, been captured accurately now?
[14:07] <plars> skaet: don't think so
[14:08] <cjwatson> plars: So, for clarity, I'm asking xnox to look into whether bug 1045812 is reproducible and reasonably fixable, and asking QA whether it's reasonable for my committed fix for bug 987418 to ride along with such a fix
[14:08] <ubot2`> Launchpad bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,Confirmed] https://launchpad.net/bugs/1045812
[14:08] <ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Fix committed] https://launchpad.net/bugs/987418
[14:09] <plars> ok, so it is that one
[14:09] <skaet> plars, please make edits to pad for waht you believe is missing.
[14:09] <skaet> *what
[14:10] <skaet> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/971353 - is it going to be possible we can get a fix for this one today?
[14:10] <ubot2`> Ubuntu bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed]
[14:10] <plars> do we even have a fix for https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1045812 already?
[14:10] <ubot2`> Ubuntu bug 1045812 in ubiquity "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,Confirmed]
[14:10] <plars> cjwatson: ^
[14:10] <xnox> no. working on it. will let you know asap
[14:11] <cjwatson> as above, "... to look into whether [that] is reproducible and reasonably fixable"
[14:11] <seb128> skaet, no, it's there since before precise, why is it important now for quantal beta1?
[14:12] <plars> xnox: do you believe it's possible that it could really be language related? I haven't tried lvm by itself, but I have done lvm+encrypted and it worked ok
[14:12] <xnox> plars: it's nothing to do with language. There is invalid sell syntax passed to expr
[14:12] <xnox> s/sell/shell/
[14:13] <xnox> i need to work out which of the 2 variables, trace it back and make sure it's converted/rounder correctly to an integer
[14:13] <plars> ok, good, I wouldn't have thought so
[14:18] <skaet> seb128, lot seem to be running into it, and it came up in the testing yesterday.
[14:19] <skaet> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1045419
[14:19] <ubot2`> Ubuntu bug 1045419 in gnome-settings-daemon "[power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode() (dup-of: 971353)" [Undecided,New]
[14:19] <ubot2`> Ubuntu bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed]
[14:19]  * skaet wishes tags would copy over from duplicate to master.  :P
[14:21] <cjwatson> I think that's a philosophical thing - the problem with copying metadata from duplicate to master is that it gets tricky if you realise you made a mistake and want to unduplicate
[14:21] <cjwatson> the current design makes undoing mistaken duplication a lossless process
[14:24] <len-dt> cjwatson, in ubuntustudio with bug 1045650, is it best to just set automounting off? (the DE mounts ubiquity's freshly formated partition and ubiquity won't install) or is there a ubiquity timing issue? It used to work fine this way.
[14:24] <ubot2`> Launchpad bug 1045650 in ubiquity "after ubiquity formats drive it automounts and ubiquity fails" [Undecided,New] https://launchpad.net/bugs/1045650
[14:25] <Riddell> skaet: superficial but important bug in kubuntu, bug 1045839, I think I want rebuilt images
[14:25] <ubot2`> Launchpad bug 1045839 in kde-workspace "plasma init script not run " [Undecided,New] https://launchpad.net/bugs/1045839
[14:25] <seb128> skaet, errors.ubuntu.com disagrees with the "lot seem to be running into it", the only g-s-d issue showing up on the mainpage is a one in the xsettings plugin which score 25 reports today where we have bugs > 300 for jockey and ubuntuone-installer
[14:26] <cjwatson> len-dt: Maybe your desktop environment changed the interface to disabling automounting yet again?  See http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2008-04-12-desktop-automount-pain.html
[14:26] <cjwatson> len-dt: Find what the new method is and we can add that too ...
[14:26] <len-dt> cjwatson, thanks
[14:26] <skaet> Riddell,  ok. mark it up on the pad please,  has a fix been uploaded?
[14:26] <seb128> skaet, so this g-s-d issue is some magnitude bellow other bugs we hit, somewhat it seems qa guys run into it often though, it might be a "under kvm" issue
[14:26] <Riddell> skaet: kde-workspace there is the fix ^^
[14:26] <cjwatson> len-dt: What DE is this?
[14:27] <seb128> skaet, or a "on CD only", like a timeout reached because of the media slowness
[14:27] <skaet> psivaa, ^ can you provide more background to seb128:?
[14:28] <len-dt> xfce4.10
[14:28] <len-dt> cjwatson, ^^
[14:28] <skaet> Riddell,  ok, as soon as publisher run has it up there,  we'll retrigger,  unless you want to wait for some of the other fixes to land.
[14:29] <cjwatson> We currently try devkit-disks --inhibit and udisks --inhibit in addition to the methods listed in that blog post
[14:29] <cjwatson> And possibly a couple of others
[14:29] <len-dt> cjwatson, I think I will just set it to default off. It is probably better for our use anyway.
[14:29] <psivaa> seb128, i was able to rerproduce it a number of times using the actual hardware, (mac-mini -amd64+mac amd dell inspiron-amd64)
[14:29] <cjwatson> I'd like to know how to fix this in ubiquity anyway
[14:30] <cjwatson> Otherwise somebody makes a derivative, changes the default to automount, and their installer explodes
[14:30] <cjwatson> Not ideal
[14:30] <Riddell> Laney: can you review and accept that kde-workspace?
[14:30] <cjwatson> Are you still using thunar?
[14:30] <seb128> psivaa, is that on CD,slow medias?
[14:30] <len-dt> cjwatson, I understand, we use thunar as the desktop background but nowhere else
[14:31] <cjwatson> Do you know what specific component does the automounting?
[14:31] <cjwatson> We used to be able to poke ~/.config/Thunar/volmanrc
[14:31] <psivaa> seb128, it was on a usb
[14:31] <len-dt> The config ends up in the thunar config.
[14:33] <seb128> psivaa, ok, I dunno then, can you reproduce it on demand?
[14:33] <len-dt> cjwatson, ack! default system and user are different. I will have to do some looking. I had better boot the live to make sure I know exactly.
[14:34] <len-dt> cjwatson, I will get back to you.
[14:36] <plars> xnox: psivaa was able to reproduce it with french on desktop, but not english.  On server, I tried french and got through the partitioning just fine (also fine with english)
[14:36] <plars> skaet: ^
[14:36] <plars> so it appears to be fairly isolated
[14:36] <xnox> plars: i saw.
[14:38] <psivaa> seb128, sure it occurs almost every time on amd64+mac.
[14:38] <seb128> psivaa, ok, I will try to find somebody to have a look
[14:39] <psivaa> seb128, thanks
[14:40] <psivaa> xnox, the bug is not reproducible in some other indian language as well
[14:43] <skaet> Riddell, no Kubuntu Active?   just Desktop and Alternate?
[14:47] <bencer> anybody from the -release team could have a look at this FFe #1043654?
[14:50] <Riddell> skaet: no for the respin no
[14:50] <Riddell> skaet: not for the respin no
[14:50] <skaet> Riddell,  ack.
[14:58] <len-live> cjwatson, in xfce4.10 thunar's automounting seems to happen in ~/.config/xfce4/xfconf/xfce-perchannel-xml/thunar-volman.xml
[15:00] <iulian> bencer: I shall have a look at it in a few hours if no one beats me to it. In the meantime, could you please attach the build/install/run logs to the bug report?
[15:04] <ogra_> how sad ... moving fromm a nice rc file to xml
[15:05] <cjwatson> len-live: yow
[15:05]  * cjwatson wonders how many tons more code that'll be
[15:05] <ogra_> heh
[15:05] <ogra_> but its *standard* now :P
[15:05] <cjwatson> len-live: I don't suppose there's some kind of interface to it that isn't poking the XML directly?
[15:05] <cjwatson> There must be some kind of configuration frontend
[15:06] <cjwatson> If I could reuse a library or something from Python that would help
[15:06] <len-live> cjwatson, the settings manager does this.
[15:06] <len-live> but that means an app that shows in the settings manager container
[15:10] <cjwatson> Well, I certainly don't mean starting an application; I mean whatever code it uses
[15:10] <cjwatson> Behind the scenes
[15:10] <len-live> cjwatson, I understand. I am just looking for what I can find
[15:13] <len-live> cjwatson, thunar-volman-settings is a binary
[15:15] <bencer> iulian: as i said in the ticket, there is no migration path, and current status is broken, kind of special situation :)
[15:18] <xnox> cjwatson: reproduced jibel 's LVM bug.
[15:19] <xnox> cjwatson: it compares if $guided_size -ge $free_size
[15:20] <xnox> where guided size is 16900000000 (which is 16.9 TB, yet it's only 16 GB system....)
[15:20] <xnox> and free size is 16919822,34
[15:20] <cjwatson> I guess guided_size is actually bytes.
[15:20] <cjwatson> On a call now though.
[15:20] <xnox> which looks slightly better.
[15:20] <xnox> cjwatson: ok.
[15:21] <xnox> cjwatson: ok. I will upconvert free_size to bytes and check if that is correct.
[15:22] <cjwatson> Yeah, it's bytes
[15:22] <cjwatson> Note e.g. 'guided_size="$free_size"000'
[15:22] <xnox> yea.
[15:22] <cjwatson> Oh, no, wait
[15:23] <xnox> why does it do that assignment and then compare the two of them.....?!
[15:23] <cjwatson> See the comment just above, "Convert back to (decimal) kilobytes"
[15:23] <cjwatson> So it actually should be KB by that point
[15:23] <cjwatson> You might want to get a set -x trace
[15:23] <cjwatson> Sorry, the code isn't desperately type-safe or anything
[15:23] <doko> cjwatson, please could you reject the openjdk-6 and openjdk-7 uploads? will build these in a ppa first for testing, then maybe propose a copy after testing
[15:27] <xnox> cjwatson: free_size=$(vgs -o vg_free --units K --noheading --nosuffix $VG_name | sed -e 's/^[[:space:]]*//; s/\..*//g')
[15:27] <xnox> if only all locales / languages used '.' to separate decimal places
[15:28] <xnox> jibel: it is l18n issue =) when vgs "helpfully" uses localised number formatting
[15:29] <xnox> cjwatson: so prefixing that with LANG=C solves it.
[15:29] <cjwatson> Ah - that makes sense
[15:29] <cjwatson> Maybe LC_ALL=C for safety
[15:29] <xnox> ok.
[15:31] <xnox> jibel: english can't write numbers correctly =) it should be ' for thousand's separator and , for decimals. For once russian & french agree =)
[15:32] <jibel> xnox, I kindly disagree it should be space for thousand's separator ;)
[15:32]  * xnox ..
[15:33]  * tumbleweed wonders why all our FFe bugs are suddenly coming in with status=Triaged
[15:35] <xnox> tumbleweed: you know what to do ;-)
[15:35] <tumbleweed> already done, but it appears taht we need to slap people too
[15:39] <iulian> bencer: I'm not talking about the current status but the future one, that's what matters. I'm interested in how the packages behave after this update. And thus, logs are essential.
[15:44] <bencer> iulian: current packages won't install as they are not compatible with current depends on the archive, after uploading zentyal-common and zentyal-core, but i can attach an update from precise, true
[15:47] <tumbleweed> yeah, it isn't particularly easy for us to objectively review a FFe when it fixes breakage caused by an upload that should have waited for an FFe
[15:49] <bencer> tumbleweed: yup, i agree, current situation is a bit messy, that's why i wanted to upload the new stuff and leave it in a working state
[15:50] <bencer> iulian: tumbleweed which logs should i attach? dpkg.log? upgrade output?
[15:51] <tumbleweed> the output is fine
[15:52] <bencer> ok, going to check that now
[15:56] <Riddell> apport nice to have for release but doesn't effect images ^^
[15:57] <Riddell> no upgrade target on http://iso.qa.ubuntu.com/qatracker/milestones/232/builds ?
[16:01] <Riddell> Laney: new kde-workspace packages are on the archive, could you respin kubuntu i386 and amd64 images?
[16:19] <hallyn> would it be possible to get a judgement on FFE for bug 1043052 ?
[16:19] <ubot2`> Launchpad bug 1043052 in lxc "[FFE] add pre-mount container startup hook" [Medium,New] https://launchpad.net/bugs/1043052
[16:26] <xnox> Please approve partman-auto-lvm this is the one out of two uploads required to fix bug 1045812
[16:26] <ubot2`> Launchpad bug 1045812 in partman-auto-lvm "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,In progress] https://launchpad.net/bugs/1045812
[16:26] <xnox> the second upload of ubiquity, will follow after that one is published.
[16:27] <xnox> it affects most installations of lvm which are done in a locale which uses ',' for decimal separator
[16:27] <ogra_> so all the sane one then
[16:27] <ogra_> :)
[16:27] <ogra_> *ones
[16:28] <xnox> ogra_: Ja, naturlich ;-)
[16:28] <ogra_> haha
[16:28] <xnox> ogra_: more importantly it affect's the default Quantal's locale - French
[16:29] <xnox> ;)
[16:29] <Laney> Riddell: I think we should wait for these ^ installer fixes; do you agree?
[16:32] <Riddell> Laney: yeah if there's stuff coming in sure
[16:33] <Laney> xnox: approving, but you changed the timestamp of an old d/changelog entry somehow(!)
[16:34] <Riddell> I noticed timestamp changing on old changelogs in my apport upload, an extra dch that gets it out of sync maybe?
[16:34] <Laney> skaet: so, looks like we're going to be respinning for these fixes
[16:34] <skaet> summary of specific bug numbers?
[16:35] <skaet> ie.  s/these/actual bug numbers... /  please
[16:35] <Laney> 14 + 12 on the pad
[16:35] <xnox> Laney: hmm... well yeah the old upload was not committed, so I had to fake it. Obviously I didn't do a good job at faking it =)
[16:36] <Laney> that's... bug 1045812 bug 987418
[16:36] <ubot2`> Launchpad bug 1045812 in partman-auto-lvm "Partitioner failed with "Failed to partition hard drive" with LVM selected" [High,In progress] https://launchpad.net/bugs/1045812
[16:36] <ubot2`> Launchpad bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Fix committed] https://launchpad.net/bugs/987418
[16:36] <xnox> Laney: please wait. I need partman-auto-lvm published & reupload ubiquity.
[16:36] <Laney> i am waiting
[16:36] <xnox> ok =)
[16:36] <henrix> RAOF: do you have some time to copy the kernels from bugs 1036553, 1036178 and 1041217 into -updates (and -security)?
[16:36] <ubot2`> Launchpad bug 1036553 in linux "linux: 2.6.32-42.96 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036553
[16:36] <ubot2`> Launchpad bug 1036178 in linux "linux: 3.0.0-25.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036178
[16:36] <ubot2`> Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217
[16:36] <skaet> Laney,  refactor the rebuilds so that the arm triggering ones aren't mixed in with the others.
[16:37] <skaet> on the pad.   We should be able to pull down the rebuild time.
[16:37] <Laney> you mean have a separate arm step?
[16:37] <Laney> set ARCHES everywhere?
[16:37] <highvoltage> eek! it's beta1 week already!
[16:37] <xnox> well ubiquity fixes affect arm desktop images....
[16:38] <xnox> highvoltage: yeah... it's been hectic for me since friday....
[16:38] <Laney> xnox: the problem is that we wait for all arches to get live filesystem builds and then build the cd images
[16:38] <xnox> I see.
[16:38] <Laney> which means that you bunch up behind the slowest one, ie arm
[16:39] <skaet> Laney, no,  just move those with ARM in them to their own set.
[16:39] <skaet> so the others don't bunch up behind.
[16:39] <Laney> what doesn't build arm?
[16:39] <skaet> trigger in 3 separate windows,   1 for only i386/amd64,  1 for only alternates,  1 for i386/amd64/armhf/powerpc
[16:40] <Laney> edubuntu lubuntu ubuntustudio
[16:40] <skaet> Laney,  Xubuntu, Edubuntu Studio -
[16:40] <Laney> and x
[16:40] <cjwatson> Is it worth it?  More manual rearrangement => more risk of error
[16:41] <cjwatson> doko: Looks like somebody did that - sorry for delay
[16:41] <Laney> Indeed — can't we fix the pipeline more generally?
[16:41] <cjwatson> Blocked on the Python rewrite, really
[16:41] <cjwatson> It's too difficult to improve in the current context
[16:41] <skaet> we had a different pipeline (more along lines set up above) for alpha 3
[16:41] <skaet> just want to go back to something closer to that.
[16:41] <Laney> can you dig it up?
[16:41] <skaet> yeah,  I'll dig.
[16:41] <cjwatson> Haven't other things changed, though?
[16:42] <skaet> cjwatson, fewer alternate and images dropped.
[16:43] <cjwatson> So it would be a complex reverse merge, not just reverting ...
[16:44] <cjwatson> I dunno.  Your call.  It just makes me nervous.
[16:44] <skaet> Laney,  while I'm digging, can you update the pad with the targets that need rebuild to pick up 12, 14, and 15?  so we can get multiple eyes looking at them.
[16:45] <skaet> cjwatson,  the blocking that went on yesterday seemed a bit of a waste, and we're going to want the respun images in folks hands as soon as possible.   What's there right now, won't do it thanks to the arm limitations.
[16:46] <Laney> which of the ubiquity ones are specific to the gtk+ frontend?
[16:46] <cjwatson> I'm not prepared to say that any of mine are specific to the GTK+ frontend.  It might be possible that they are due to some odd frontend-specific behaviour but I haven't demonstrated it.
[16:47] <cjwatson> skaet: Trade-off between computer time and human attention, I guess.
[16:47] <Laney> fine, we're respinning everything that could be affected anyway so it was just bookkeeping
[16:48] <Laney> I don't see any flavours fixing their seeds for the gtk2 indicators so they don't get those this time
[16:49]  * skaet nods
[16:51] <len-dt> cjwatson, just for clarification should I change ubuntustudio-default-settings to no automount for now or is a ubiquity fix likely? I'm ok either way.
[16:52] <xnox> len-dt: no fix in ubiquity, unless you tell us what api needs changing =)
[16:52] <len-dt> xnox, I will change our settings then thanks
[16:52] <xnox> len-dt: preferably pragmatically e.g. CLI tool to change that setting.
[16:52] <skaet> Laney,  cjwatson,  can you turn off image purging so we don't loose this image set?
[16:53] <xnox> len-dt: do you know if you can run  pseudo-code `$ xubuntu-settings-daemon set automount off`
[16:53] <xnox> or something like that?
[16:53] <xnox> Thunar and Xfce4 are in transition from using HAL and ThunarVFS, being currently deprecated, to using GIO, ConsoleKit, PolicyKit and the kernel udev architecture for detecting and automounting removable media.
[16:53] <xnox> hmm...
[16:54] <len-dt> xnox I'm not up on it myself.
[16:54] <xnox> len-dt: tell me about it.... neither am I.
[16:55] <len-dt> xnox, I can make three edits to a config file commit it and beta 1 will work. That I know how to do :)
[16:56] <xnox> len-dt: go for it.
[16:56] <len-dt> xnox, on my way.
[16:59]  * skaet just went and enabled the Upgrade tracking tests.
[16:59] <cjwatson> skaet: done
[17:00] <cjwatson> (purge-old-images disabling)
[17:00] <Daviey> skaet: I'd quite like to get a new maas upload into beta.
[17:00] <Daviey> it's on the cd.
[17:00] <skaet> thanks cjwatson
[17:01] <Daviey> skaet: do you hate me for that? :)
[17:01] <skaet> Daviey, have you added it to the pad with a bug number?    what's it affecting and is QA ok with retesting it?
[17:01] <skaet> :)
[17:02] <Daviey> skaet: no
[17:03] <skaet> hmm... no to pad/bugnumber,  no to QA being ok.  ?   correct interpretation?
[17:05] <Daviey> correct. :)
[17:05] <Daviey> skaet: it was just put my way.
[17:05] <xnox> len-dt: xfconf-query -c thunar-volman -p /automount-drives/enabled -s true or false
[17:06] <xnox> len-dt: can you test it locally with a usb stick and check if (i) it prevents auto-mounting (ii) changes the xml settings same way you wanted to do it (iii) that xfconf-query is available on affected images (xubuntu, lubuntu, ubuntu studio?! others?!)
[17:07] <xnox> len-dt: and then maybe we can add it to the ubiquity upload which will be done soon for the respins.
[17:07] <cjwatson> xnox: FYI you don't *have* to wait for partman-auto-lvm to be published, it's just easier
[17:07] <xnox> yeah...
[17:08] <cjwatson> You can: cd d-i; mv manifest manifest.old; rm -r source/partman-auto-lvm; dpkg-source -x /path/to/partman-auto-lvm.dsc source/partman-auto-lvm; ./update-control; ./update-changelog
[17:08] <xnox> cjwatson: so xfconf is seeded on all those XFCE~ish images. worth a try?
[17:09] <cjwatson> I've got a Xubuntu image here
[17:09] <len-dt> xnox, cjwatson ubuntustudio-default-settings is commited I need someone to release it. I normally ask micahg , but his nick says away
[17:09] <cjwatson> Let's see
[17:09] <xnox> cjwatson: yeah, i was doing that when testing my 'local' udeb packages.
[17:09] <plars> skaet: as far as I've heard, only desktop is requiring a respin at this point, but the MAAS update would require a server respin
[17:10] <cjwatson> len-dt: I think a Ubiquity change would be lower net risk, if we can manage it
[17:10] <plars> I'm not sure who tests maas, I think server team handles that part
[17:10] <cjwatson> But if you think that's an appropriate *permanent* change for studio then I could upload that for you
[17:10] <plars> but if we respin server we'd have to retest them all
[17:10] <cjwatson> If you gave me the URL
[17:10] <skaet> Daviey,  will you please put a bug number on the pad in the under consideration, and mark the images affected.   Right now server testing is mostly done, and need to understand the tradeoffs a bit better.
[17:11] <plars> it would probably need to be really convincingly bad to warrant a respin late on a Tuesday
[17:11] <xnox> len-dt: i don't think you want to disable automounting in live-cd mode permamently, because it is useful to plugin in stuff during live session for testing e.g. photo cameras.
[17:12] <len-dt> cjwatson, https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio. Having something automount while recording could be bad too.
[17:12] <skaet> plars, understood.
[17:12] <len-dt> most of the auto mounts are turned off already
[17:12] <xnox> plars: for what it's worth parman-auto-lvm and oem-config packages do go onto server CDs, while they shouldn't change anything on the server CDs , it is a different package version....
[17:12] <xnox> len-dt: ok.
[17:13] <xnox> are xubuntu folks here? cause they also reported thunar misbehaving, e.g. during manual partitioning.
[17:13] <plars> xnox: but there's no need to respin server for them at this point as I understood things
[17:13] <xnox> plars: correct.
[17:13] <Laney> indeed, we haven't been caring about that
[17:14] <len-dt> xnox, cjwatson fixning ubiquity is beyond my talents right now. I agree it needs to be done though.
[17:14] <cjwatson> OK, let's just change u-d-s for beta-1 then and defer the ubiquity change
[17:15] <cjwatson> len-dt: I'm fixing up the bug task so that you don't claim to have already done it, then :-)
[17:15] <len-dt> No problem...
[17:19] <cjwatson> len-dt: Uploaded
[17:20] <len-dt> cjwatson, Thank You.
[17:21] <cjwatson> ^- somebody else please review
[17:23] <stgraber> cjwatson: doing
[17:30] <skaet> cjwatson,  what is the difference between lubuntu and lubuntu-preinstalled on the rebuild set on the pad?  I'm not seeing what lubuntu-preinstalled corresponds to on the iso tracker
[17:31] <Laney> http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/current/
[17:31] <Laney> it appears not to post
[17:31] <Laney> cruft?
[17:31] <skaet> also not sure why we're building mythbuntu - its not part of 12.10
[17:31] <xnox> ogra_: ^^^^ preinstall images are cruft?
[17:32] <Laney> mythbuntu is likewise cruft - remove it
[17:32] <skaet> ogra_:  ^,  what xnox said.   You releasing this for beta 1
[17:32] <Laney> and from crontab too please
[17:33] <skaet> Laney,  not so sure about the crontab for mythbuntu,  thought the agreement had been reached to keep the dailies going.
[17:33] <Laney> really?
[17:33] <Laney> fair enough if that's what you want
[17:33] <skaet> we just were not publishing as part of development releases.
[17:33] <Laney> i suppose that's why I put it in the pipeline though; I constructed it from what was being cronned
[17:33] <cjwatson> skaet: No idea, sorry
[17:34] <Laney> on the expectation that daily builds match what we want to release
[17:34] <skaet> Laney,  not quite,  some arches we don't publish
[17:34] <cjwatson> If we don't keep the Mythbuntu dailies going, we'll have to fix 18 months of accumulated problems at the start of the R cycle
[17:35] <skaet> cjwatson,  its ok,  Laney pointed me at it,  its ac100+armhf - am moving it to arm specific builds.   waiting to hear from ogra_ if it needs to be on the iso tracker for community testing or not.
[17:35] <cjwatson> I thought I asked for this to be a requirement when the Mythbuntu LTS plan came up before the TB
[17:35] <skaet> cjwatson,  that matches my memory.
[17:35] <Laney> sounds good
[17:35] <Laney> a comment then ;-)
[17:37] <xnox> skaet: I think I saw ogra_ asking stgraber to add ac100+armhf to the isotracker for desktop testing (it's ubuntu desktop, but using lubuntu due to lack of graphics power)
[17:37] <Laney> .
[17:37]  * xnox s/R cycle/T cycle/
[17:38] <ogra_> skaet, would be nice to hav, but its lubuntu anyway now
[17:38] <skaet> gilir,  phillw - is there someone lined up to test it?
[17:39] <skaet> s/it/lubuntu ac100+armhf/
[17:39] <ogra_> skaet, i will test it
[17:39] <skaet> ogra_, akc.
[17:39] <ogra_> (as usual)
[17:39] <ogra_> i'll ask community people too for additional testing indeed :)
[17:39]  * ogra_ is off for the evenin
[17:39] <ogra_> g
[17:41] <phillw> ogra_: thanks, I know one of the lubuntu devs has arm hardware - Nicholas has already been in touch with him, but his free time is very limited and cannot commit to testing on a regular basis.
[17:41] <skaet> phillw,  its not on the iso tracker right now, but will be added later today.   Please ask anyone able to test to consult http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/current/ for now.
[17:42] <ogra_> phillw, well, that build is for a specific netbook, but there is a community of users that are also willing to help
[17:42] <phillw> skaet: I'll give Jonathan a ping
[17:42] <ogra_> anyway, really out now :)
[17:42] <phillw> he's the only one who came forward when I asked our mailing list for those who have ARM hardware.
[17:43] <phillw> skaet: balloons is the one holding the list, AFAIK
[17:43] <skaet> phillw, ack.
[17:54] <skaet> Laney, can your review http://pad.ubuntu.com/ubuntu-release to make sure I've got the brackets correct (see Revised section,  I left the originals intact)
[17:55] <skaet> ?
[17:57] <stgraber> xnox: yeah, it's on my todo
[17:57] <Laney> skaet: what's the first lot?
[17:57] <skaet> DESKTOPS (no arm, but powerpc):
[17:57] <Laney> and actually I'd probably rather someone who will be up runs these respins
[17:57] <Laney> oh hang on
[17:57] <skaet> Laney,  ok,  I'll handle it.
[17:57] <Laney> you put an ARM: in the first set
[17:57] <Laney> but that's core
[17:58] <skaet> see lower down
[17:58] <skaet> Revised version
[17:58] <Laney> yes, I get it, but it looked like the first lot had been changed too
[17:58] <skaet> yes,  my bad
[17:58] <skaet> I started to change there, and decided best to leave those completely alone for now.
[17:59] <skaet> (didn't undo the print statement)
[18:04] <Laney> I think you might as well keep core separate; doesn't take much time
[18:05] <Laney> otherwise I can't spot anything, but it's hard to without running it
[18:05] <xnox> ^ fixes respin triggers #12, #14
[18:05] <Laney> hoho, /me just went to ping about ^
[18:06] <Laney> then it was in queue "27 seconds ago"
[18:06] <Laney> stgraber: would you care to review it?
[18:06] <stgraber> Laney: can do
[18:06] <Laney> thanks
[18:06] <xnox> Laney: can I go to the pub now then ;-) wel... tescos to get crisps =)
[18:07] <Laney> no, you can go to your local independent store :-)
[18:07] <xnox> i don't think respin trigger #13 will make it at all. As the current fix is incomplete.
[18:07] <xnox> Laney: they are rip off 24h corner shops
[18:07] <xnox> I am in London remember ;-)
[18:08] <xnox> I'll wait for review/approval. In case it needs fixing.
[18:08] <xnox> it's massive because of translation updates dump....
[18:09] <stgraber> xnox: there's that usual tzsetup template diff... probably because your system wasn't clean when building the source package...
[18:09] <stgraber> I've seen that a few times and it doesn't seem to be a problem, so will ignore, but that's an extra delta making the diff harder to read...
[18:09] <xnox> stgraber: i did clean the tree twice and once after a build and both times they came out with it.
[18:09] <xnox> stgraber: i wonder if the .28 was dirty
[18:10] <stgraber> xnox: could be
[18:10] <stgraber> I usually do a bzr push to another directory, then build from there to avoid it
[18:10] <xnox> stgraber: it gets rebuild / re-sorted anyway
[18:10] <xnox> stgraber: i see... will remember to do that.
[18:11] <stgraber> changelog is missing mention of test_misc being updated
[18:11] <bjf> ls
[18:11] <balloons> cjwatson, when you get a moment, I'd like to chat about how ubiquity uses the network during installation
[18:11] <stgraber> anyway, rest looks good and matches changelog, so accepting
[18:11] <xnox> stgraber: that entry is not under my name
[18:11]  * xnox is whistling like nothing happened
[18:12]  * xnox \0/
[18:18]  * skaet starts waiting for the publishing....
[18:20] <stgraber> bumped the score for armhf and powerpc so we don't have to wait 3 hours for them to build
[18:28] <skaet> thanks stgraber
[18:33] <phillw> skaet: if gilir does appear can you let him know, he's active as there are bug emails coming in from him. I'd like him to be told before the email goes out :)
[18:36] <skaet> phillw,  I'll ping gilir before I start off the rebuilds, and mark them on the tracker then.
[18:37] <phillw> skaet: he'll be okay, it is a courtesy I would afford our head of dev :)
[18:49] <phillw> skaet: you have mail
[19:03] <kenvandine> ubuntu-wallpapers included a wallpaper that wasn't actually submitted by the original creator, bug 1045841
[19:03] <ubot2`> Launchpad bug 1045841 in ubuntu-wallpapers "Ownership of Blue Dandelion image cannot be confirmed so it must be removed from 12.10 release" [Undecided,New] https://launchpad.net/bugs/1045841
[19:04] <kenvandine> i have the package prepared removing it, should i go ahead and upload? or wait until after beta1?
[19:04] <kenvandine> i'd like to get it in before b1, so we don't end up with the image in b1
[19:04] <kenvandine> skaet, ^^
[19:06] <skaet> kenvandine, go ahead.  Ill wait for it.   Less problems long term
[19:06] <kenvandine> indeed
[19:07]  * skaet still waiting for ubiquity on powerpc and armhf
[19:21] <skaet> stgraber, slangasek if either of you is around could you review ubuntu-wallpapers please?
[19:22] <stgraber> skaet: sure, will do
[19:22] <skaet> thanks stgraber
[19:24] <skaet> Riddell,  [15] is already under rebuild triggers,  why add it again in under consideration section on the pad?
[19:36] <iulian> highvoltage: zentyal: I'd appreciate it if you could provide something more useful than that, preferably some logs that show that it is indeed a low-risk update.
[19:37] <stgraber> kenvandine, skaet: accepted
[19:37] <skaet> thanks stgraber
[19:38]  * skaet sees that arm is now finished and published,  still waiting on powerpc for ubiquity :P
[19:38] <kenvandine> stgraber, thanks
[19:38] <Riddell> skaet: mm I don't remember adding it twice
[19:38] <Riddell> feel free to tidy up
[19:38] <skaet> Riddell,  ok.  thanks.
[19:39] <highvoltage> iulian: ok
[19:40] <iulian> highvoltage: If something goes wrong with zentyal, then I shall blame you. I don't usually accept FFes just because the package doesn't affect anything else.
[19:40] <iulian> highvoltage: If you have logs on the way, then please attach them to the report anyway.
[19:43] <highvoltage> iulian: I forwarded your message on to bencer. I don't like responsibility if I can avoid it so maybe I'll just delete my bug comment to be safe :) (before I have iulians chasing me in my dreams)
[19:43]  * skaet grumbles that universe ghc is building on powerpc, and still waiting for ubiquity to start.  :P
[19:44] <skaet> Daviey,  why is maas going into quantal-release/main with binaries right now?
[19:45] <iulian> highvoltage: I've told him earlier, see above. He didn't seem to do what I've told him to do. :(
[19:46] <iulian> Ahh, GHC! When did that get uploaded? \o/
[19:47] <iulian> skaet: It's not a very small package so it takes a bit of time to build. You might want to make sure that ubiquity is next in line.
[19:51] <iulian> highvoltage: Do you know if bencer has the packages ready for upload? If he does, then it's just a matter of clicking on a few things to attach the logs.
[19:52] <skaet> iulian, yeah,  ubiquity should have been before it.  Scores for ubiquity were bumped 1.5 hours ago, so must have just missed it.  ubiquity is next.   Any feel how long it will take?
[19:53] <skaet> s/it/ghc/
[19:53]  * iulian checks the build log.
[19:54] <iulian> skaet: It finished on powerpc. It's still building on arm*.
[19:55] <stgraber> slangasek, skaet: regarding the oversizedness warning on the tracker, my plan is to simply implement it in post-qa on nusakan and pass it in the note field. That way it'll show up in the e-mail sent out to testers and at the top of the build page on the tracker.
[19:55] <skaet> stgraber,  sounds good to me.
[19:56] <skaet> balloons, plars:  will the proposal above work for you?  ^
[19:56] <Daviey> skaet: hey.. it's an opportunity target now.
[19:57] <balloons> hmm.. will cdimage show a warning also?
[19:57] <skaet> balloons, cdimage page should be unchanged
[19:57] <stgraber> balloons: it always did
[19:58] <stgraber> I'm actually planning on checking the file generated on cdimage and use that to add a warning to the build (well, checking for the .OVERSIZED file on the fs)
[19:58] <plars> skaet, stgraber: sorry, not familiar with this. Is this concerning the bigger images in quantal? or are we adjusting the size check so that it now only does the OVERSIZED if >800MB?
[19:59] <skaet> plars,  just making it more visible on the iso tracker what should occur when OVERSIZED is triggered.
[19:59] <stgraber> plars: the limit was already changed by slangasek, we're just adding an extra warning on iso.qa.ubuntu.com if an image is oversized so we don't miss it like we did for 12.04.1
[19:59] <balloons> stgraber, right.. just double-checking..in other words, it will be more of a warning now :-)
[19:59] <stgraber> balloons: right
[20:01] <plars> sounds useful :)
[20:06] <iulian> skaet: It should be finishing on arm* in roughly 20 minutes by the looks of it.
[20:06]  * skaet happy that ubiquity now building on ross
[20:06] <skaet> thanks iulian,  its off powerpc now,  which was the blocker I was waiting to resolve.  :)
[20:07] <iulian> Great.
[20:08] <bencer> iulian: should be ready on my ppa, let me check
[20:10] <bencer> iulian: https://launchpad.net/~bencer/+archive/zentyal-2.3-p/+packages ready there
[20:11] <iulian> bencer: Brilliant.
[20:11]  * iulian looking.
[20:12] <highvoltage> iulian: what kind of logs do you mean? package update logs from apt?
[20:12] <iulian> bencer: What version do you want to get in? Those logs are from March.
[20:12] <iulian> highvoltage: And build.
[20:14] <iulian> bencer: 2.3.3 is already in quantal.
[20:18] <bencer> iulian: https://launchpad.net/~bencer/+archive/zentyal-2.3-p/+packages packages are ready there
[20:18] <bencer> pending to upload as commented in that ffe: zentyal-users, zentyal-squid, zentyal-samba
[20:20]  * iulian is confused.
[20:21] <highvoltage> bencer: hmm, those packages were all published in that ppa in march, are you sure that's the right link?
[20:22] <micahg> they're also all targetted at precise
[20:23] <bencer> sorry, wrong link
[20:23] <bencer> https://launchpad.net/~bencer/+archive/zentyal-2.3-q/+packages
[20:23] <bencer> with the q :)
[20:25] <iulian> bencer: So, 2.3.12 is the version you're planning to get in, correct?
[20:25] <iulian> I can't see that in the bug report.
[20:25] <bencer> iulian: yes, i didnt specify that on the bug report, right
[20:26] <bencer> we plan to upload final zentyal 3.0 packages before the final freeze
[20:26] <iulian> Could you please edit that bug report saying that because I'm getting quite confused here.
[20:26] <bencer> iulian: sure
[20:27] <bencer> iulian: basically, this new version contain all the important changes from the version in precise
[20:27] <highvoltage> bencer: ah, I thought your original plan was to upload an rc version of 3.0 and then when the final version is released upload that?
[20:27] <bencer> now zentyal is frozen, we are finish bugfixing, so if we upload newer pakcages later, before the final freeze, we will get more bugfixes
[20:28] <iulian> bencer: Whilst you're on it, please have a look at https://wiki.ubuntu.com/FreezeExceptionProcess.
[20:28] <bencer> highvoltage: right, our release is 13th september
[20:28] <bencer> iulian: yes, 13th september if before the final freeze
[20:28] <bencer> but i want to upload this now, so the new upload later on is smaller
[20:29] <bencer> iulian: do u want me to explain this on the ffe then?
[20:29] <iulian> bencer: I think it's better to just wait for the final one. If it's on the 13th, then it's all good.
[20:30] <bencer> iulian: i would prefer not... this is working now
[20:30] <bencer> dont know if will appear more bugfixes or not
[20:30] <iulian> bencer: Uploading this now and then the final one on the 13th makes no sense.
[20:30] <bencer> iulian: my point is if we upload the final on 13th, the diff between precise and that upload, will be bigger than if we upload now an already frozen and working version
[20:31] <bencer> and then just a small diff on top of that containing only bugfixes
[20:31] <iulian> bencer: Well, it's going to be the same thing, isn't it?
[20:31] <bencer> iulian: the new upload, if it happens, will only contain bugfixes
[20:31] <iulian> bencer: So, this version contains some new features and after that it's just bugfixes?
[20:31] <bencer> iulian: new features, that's why i dont want to wait more
[20:32] <bencer> samba4, kerberos
[20:32] <micahg> iulian: to be fair, AIUI, the earlier the better for FFes, right (assuming the rest is just bug fix)?
[20:33] <iulian> OK then. Please follow the instructions from that wiki page I've given you earlier and you can also paste this log in to the bug report. If everything's fine, then we shall get this version in and then the next one will just contain bugfixes which you can just upload without needing an FFe.
[20:33] <bencer> micahg: yup, that was my thought
[20:33] <tumbleweed> erm, what did I miss? nobody approved the maas FFe that I saw
[20:34] <bencer> iulian: the thing is the previous zentyal-samba was samba3 based, and this new one is samba4 based
[20:34] <bencer> and i'm afraid there is no migration path
[20:34] <iulian> micahg: Indeed.
[20:36] <iulian> bencer: OK, please give as much information as you can in the bug report and I shall go through it.
[20:37] <bencer> iulian: i've commented the lack of migration path, and why, going to add what we said about uploading later (eventually) a bugfixing only upload
[20:42] <iulian> bencer: If it's just a bug fix upload, then you don't have to talk to the release team about it. In the case that you're not certain whether it's a bug fix release or not, then the recommended way to solve this is to get in touch with -release.
[20:42] <bencer> iulian: ok, understood, but i need this ffe now as this new upload contains new features, right?
[20:44] <Laney> heya
[20:46] <iulian> bencer: Yes, it's new features all the way down which is why I hesitate in letting it in. Could you also mention the version you'd like to get in? There's an edit button so you don't have to comment every time you want to add something.
[20:47] <iulian> bencer: Have you seen that wiki page I've given you 20 minutes ago? That explains what you have to do.
[20:48] <bencer> iulian: yes, i know we are late, but we discussed about this in the uds, was within the edubuntu plans and we didnt upload before because was not finished upstream
[20:48] <bencer> and also leaving like it is now is not an option and current zentyal-samba version wont work with current zentyal-common and zentyal-core versions
[20:49] <tumbleweed> bencer: if you can't get an upload in before FF, you can file an FFe in advance
[20:49] <Laney> maas> indeed
[20:49] <Laney> was that discussed somewhere out of band?
[20:49] <tumbleweed> (and yes, that is preferable to intentionally landing a half-finished thing before FF)
[20:49] <tumbleweed> Laney: I commented on the bug
[20:49] <bencer> tumbleweed: yup, i realized this for the next time :)
[20:49] <Laney> tumbleweed: I don't see it
[20:50] <iulian> bencer: If I accept it now, do you have the packages ready for upload?
[20:50] <tumbleweed> Laney: e-mail probably still in flight
[20:50] <Laney> ah
[20:50] <iulian> bencer: Just to let you know, I'm still trying to gather more information about this. ;)
[20:51] <bencer> iulian: so let me clarify, missing stuff: information of version we want to upload, anything else?
[20:51] <iulian> If I'm being too picky here, then please jump in. tumbleweed, Laney. ^
[20:51] <iulian> bencer: See the wiki page.
[20:52] <Laney> I'm not following it iulian, sorry
[20:52] <iulian> bencer: That wiki page explains every step that you have to do.
[20:52] <bencer> iulian: yes, i know, but i agree some steps doesnt make sense on this case, because for example a debdiff would be huge containing all the new features
[20:57] <phillw> skaet: you have a reply. As I knew, Julien said okay.
[20:58] <skaet> phillw,  ok.
[21:01] <phillw> when do you expect the iso's to land? I know there is a large queue of builds.
[21:04] <skaet> phillw,  looks like those last bits have landed and published.   I'll be starting off the builds in the order on the pad.
[21:04] <tumbleweed> bencer: just because it's huge, doesn't mean you shouldn't attach it
[21:05] <tumbleweed> bencer: I've looked at your FFes once or twice, but there really isn't much there to go on. See the FFe page for a list of useful information to include
[21:06] <phillw> permission to let people know ARM will be arriving?
[21:08] <stgraber> skaet: http://iso.qa.dev.stgraber.org/qatracker/milestones/219/builds/16291/testcases <- is that visible enough?
[21:09] <skaet> phillw,  its not on the tracker yet.   But I'll finish sorting it as soon as I mark the others as rebuilding.
[21:09] <plars> stgraber: bold and/or red letters would probably be nice to make it really stand out
[21:09] <skaet> stgraber,  yup.   feel free to make it red too ;)
[21:09] <phillw> kk
[21:10] <plars> blink tags, popups, nyancat music... :)
[21:11] <stgraber> skaet: yeah, need to figure out how to make it red, pretty sure the current Drupal filter won't let me use style="color:red"
[21:13] <stgraber> skaet: well, I can do bold easily, will go with that for now ;)
[21:16] <stgraber> can someone from ubuntu-archive land: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/add-note-to-tracker/+merge/122761 ?
[21:17] <stgraber> this is required for my next change to nusakan
[21:22] <knome> xubuntu alternate updated?
[21:22] <knome> i thought those were dropped :)
[21:22] <slangasek> Ubuntu alternate is dropped; other flavors make their own decisions about which images to release
[21:22] <Laney> not according to the manifest
[21:22] <knome> slangasek, we did, and i sent that information to skaet
[21:22] <slangasek> ah
[21:23] <Laney> although that still also says ubuntu alternates on ppc :-)
[21:23] <knome> not pointing fingers, just wondering :)
[21:23] <stgraber> Daviey: looks like you manually commited something on nusakan (etc/notify-addresses) preventing pulling the new revisions of cdimage-deployment... I "fixed" it by uncommiting your change for now
[21:23] <stgraber> Daviey: looks like you may have commited directly to /srv/cdimage.ubuntu.com instead of pushing to cdimage-deployment, then doing "bzr pull" in /srv/cdimage.ubuntu.com
[21:24] <stgraber> skaet: landed the change manually on nusakan for now as I need to check that the path I'm checking is correct
[21:24] <Daviey> stgraber: oo,err
[21:24] <slangasek> knome: ok, doesn't seem to have percolated through the system yet.  But since you're listed on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest as the contact, I guess I can take your word for it and drop them now :)
[21:24] <stgraber> skaet: I'm not expecting anything that may affect the beta builds, worst case I'll just get a debug message in the log that I can use to fix my change
[21:24] <knome> slangasek, yep, sure you can. if you ask anybody else on our community, they will tell to ask me :P
[21:26] <tumbleweed> slangasek: oh, btw, re the zombie bug 990740 which you also replied to a bit. I suspect it's just collecting everyone who had a broken upgrade, as this failure is a symptom of their recovery attempt
[21:26] <ubot2`> Launchpad bug 990740 in python-defaults "upgrading from lucid to precise fails" [High,Confirmed] https://launchpad.net/bugs/990740
[21:26] <tumbleweed> one person replied to me privately, saying his system was so b0rked that apport wouldn't work. And it wouldn't suprise me if that was the case for most of them
[21:31] <dobey> anyone on here moderates ubuntu-translators@?
[21:31] <slangasek> tumbleweed: but there could be several reasons for apport not working... since python is implicated and apport is written in python
[21:32] <tumbleweed> yeah
[21:32] <knome> dobey, ubuntu-translators list run by david.planella at ubuntu.com
[21:32] <tumbleweed> I think I'll stick a big notice at the top of the bug asking people to create a new bug, and attach /var/log/update-manager, if apport odesn't work for them
[21:34] <dobey> ah
[21:34] <dobey> thanks knome
[21:34] <plars> so the status of alternate as "still being decided" on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest
[21:34] <knome> dobey, np. there might be other *moderators* though, but that's the best way to get a hold of them
[21:34] <plars> that is decided as no longer supported for quantal on all archs now?
[21:34] <plars> is that correct?
[21:35] <dobey> knome: right, but he's away for the evening i'm sure :)
[21:35] <plars> or is it happening?
[21:35] <slangasek> stgraber: branch landed
[21:35] <plars> I'm asking about Ubuntu specifically btw
[21:35] <plars> not k/l/x/etc
[21:35] <knome> dobey, dunno. :) doesn't seem to be on irc at least though, but i don't think he is always anyway
[21:36] <slangasek> plars: I only see that written for Kubuntu
[21:36] <slangasek> it has been decided for Ubuntu - alternates are being dropped
[21:36] <dobey> knome: right, and he's in europe. so it's almost wednesday for him now :)
[21:36] <knome> dobey, yup. :)
[21:36] <plars> slangasek: thanks, just verifying
[21:37] <stgraber> slangasek: thanks
[21:37] <dobey> knome: anyway, it's fine. just wanted to prod someone to get my mail through, so i can stick the URL on this FFe bug :)
[21:37] <knome> dobey, or you and register to the list and resend
[21:38] <dobey> knome: right; i'll just wait :)
[21:38] <knome> dobey, good luck in waiting :)
[21:44] <slangasek> knome: and xubuntu alternate is dropped dropped, right, not "we'll see if anyone complains after beta1" dropped?
[21:44] <knome> slangasek, hehe. thanks :)
[21:45] <cjwatson> stgraber: I didn't mention test_misc because it went with the parenthesisation fix - I don't believe in listing changes file by file in general in debian/changelog
[21:45] <cjwatson> stgraber,xnox: the way to avoid the tzsetup diff is to do debian/rules update (or equivalent) last, after any test runs
[21:46] <stgraber> cjwatson: ah, ok. Looking at the diff it didn't immediately strike me as related, that's why I mentioned it.
[21:47] <stgraber> cjwatson: good to know for tzsetup, will save me the extra bzr branch before building the source package
[21:49] <cjwatson> stgraber: one of these days I might fix the bug that causes it, but people only ever complain about it around milestone prep :)
[21:49] <stgraber> skaet, slangasek: tested the post-qa change as much as I can without actually getting an oversized image, so far it looks good. "Hopefully" we'll be getting an oversized image soon after the freeze so I can actually see it work :)
[21:50] <cjwatson> stgraber: test_misc was TDD and everything ... ;-)
[21:50] <stgraber> cjwatson: hehe, because apparently that's the only time people actually look at the diff... ;)
[21:50] <slangasek> stgraber: I suppose you could touch a .OVERSIZED file to test it by hand? :)
[21:50] <cjwatson> exactly
[21:51] <stgraber> slangasek: if we don't get any oversize in b1, I'll simply lower the limit for a product on Friday and trigger a rebuild to make sure everything works ;) just didn't want to give someone an heart attack by doing it today :)
[21:53] <stgraber> actually, looks like kubuntu and xubuntu have some oversized daily-live, that should do the trick ;)
[22:05] <cjwatson> balloons: well, basically it configures apt at a certain point during installation, and from that point on presence of network will mean that it'll try to get packages from the network; in some cases this can change behaviour a bit
[22:05] <cjwatson> balloons: there are other things such as geolocation, but apt configuration is the main thing that tends to permute presence of bugs
[22:06] <balloons> cjwatson, yes, I did a little testing after I found that funny behavoir. And it does indeed go after packages if it detects a working connection
[22:06] <cjwatson> balloons: this is after copying the squashfs - we're talking things like language packs, sometimes hardware-specific packages, etc.
[22:06] <balloons> I wasn't sure if there's a specific bug in here.. perhaps a wishlist or clarification.
[22:06] <cjwatson> balloons: in general we consider it a bug if it breaks either with or without, but it's not a bug that behaviour may differ
[22:07] <balloons> cjwatson, yes, in my case I'm wondering if it will ever continue on
[22:07] <balloons> aka, I have local network only, not external
[22:07] <cjwatson> if you don't have network, bits of the desktop may later report that you don't have full language support, for instance
[22:07] <cjwatson> sounds like you have a buggy firewall that drops packets rather than rejecting them
[22:07] <cjwatson> Don't Do That
[22:07] <balloons> silent dropping is fun :-)
[22:08] <balloons> but no, I don't think that's the case here.. it might be
[22:08] <cjwatson> if it rejects apt will move on as it's supposed to.  if it drops, apt can't tell the difference between crap firewall and just slow without a long timeout.
[22:08] <balloons> but it should eventually continue on by itself, yes.. it's all up to apt to finish
[22:08] <cjwatson> that of course assumes that it's stuck in apt
[22:08] <cjwatson> you should be able to tell from the tail of syslog
[22:09] <balloons> cjwatson, yes, it was stuck in apt
[22:09] <skaet> knome, ^ new images up now (no alternates)
[22:09] <stgraber> skaet, slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22538/testcases <- looks like the code is well working, that's the first detected oversized image
[22:09] <cjwatson> balloons: https://wiki.ubuntu.com/NetworklessInstallationFixes - historical context
[22:10] <cjwatson> AFAIK that was all implemented years ago but perhaps there's been a regression in some edge case
[22:10] <skaet> stgraber,  looks good.    lets see if knome wants to do something about it, or we release note Xubuntu desktop being oversized.
[22:11] <knome> skaet, i don't think there is anything for us to do now, so let's release note it being oversize
[22:11] <skaet> knome,  ok.
[22:11] <balloons> cjwatson, http://paste.ubuntu.com/1186023/
[22:12] <balloons> it *seems* like it hung for 10 mins? I can definitely re-test to check things out.. I will know that I have the full context and understanding of course
[22:12] <xnox> stgraber: CSS love =) warning should be *red* color
[22:12] <stgraber> xnox: yeah, as I said earlier, the Drupal filter used for this field doesn't really allow anything fancy
[22:13] <stgraber> xnox: though as it's an admin-only field, I may just switch it to full-html in the next release
[22:13] <Laney> the colour really interests people
[22:13] <balloons> in that log, I eventually noticed and hit skip.. it finished rather quickly after that
[22:14] <cjwatson> balloons: That does look rather like an apt regression - maybe it specifically fails to handle the case where packets are dropped on the way to your nameserver?  (speculation)
[22:14] <cjwatson> Well I mean it handles it but it doesn't do the multiple-consecutive-timeout avoidance thing
[22:14] <cjwatson> AFAICS
[22:14] <balloons> right.. ok. Well O
[22:15] <cjwatson> That really is a badly hosed network though :)
[22:15] <balloons> I'll play around a bit more and try and see if I can track down what exactly isn't being well handled.. I'll test some various network configs and see how apt does
[22:15] <balloons> and yes, it definitely is mangled :-)
[22:16] <cjwatson> Definitely something at name resolution time anyway
[22:16] <balloons> It's just interesting because I'm surprised it tried to hit the network.. in the beginning it wouldn't let me check the download updates (since there's no connectiity)
[22:16] <balloons> I get it now, your simply issuing an apt-get update, but it contains the full sources.list
[22:17] <cjwatson> Right, that's deliberate
[22:17] <cjwatson> We don't want to be in the situation where you never get updates because you weren't on the network when you installed
[22:17] <balloons> could you not disable it if no network is present?
[22:17] <cjwatson> Not a good idea
[22:17] <cjwatson> See above :)
[22:17] <cjwatson> apt is supposed to quickly continue
[22:17] <balloons> lol.. yes, I'm assuming it is your sources.list
[22:18] <balloons> you wouldn't want to enable the full list @ the end
[22:18] <cjwatson> The installer shouldn't attempt to work around it failing to do so - that creates other problems
[22:18] <cjwatson> We agreed this all years ago :)
[22:18] <balloons> fair enough..
[22:18] <cjwatson> "download updates" is a different thing
[22:18] <cjwatson> but usability means we aren't allowed to give a full explanation in the UI :P
[22:19] <balloons> cjwatson, what do you mean?
[22:19] <balloons> your prevented from giving technical details?
[22:21] <xnox> balloons: the fact that we are hitting the network and trying is "internal implementation detail"
[22:21] <xnox> balloons: usability is all about little white lies and cheats =)
[22:21] <xnox> balloons: for the sake of sanity
[22:21] <cjwatson> balloons: I'm being cynical for comic effect
[22:22] <balloons> xnox, haha.. well thank you cjwatson and xnox. I'll let that one lie for now ;-) I appreciate the insight and background on the networking stuff.. I'll let you know if anything comes of it
[22:23] <xnox> balloons: i am interested to know what is the User Experience like with Desktop CD, Networking Enabled, But proxy settings required. You may not use Live Session CD, only Install now mode.
[22:23] <balloons> xnox, sure I can test that.. proxy was on the list after today's experience :-)
[22:23] <xnox> balloons: and not transparent proxies something with username and password. Not sure if you can set that up.
[22:23] <cjwatson> balloons: But I think "Download upgraded versions of packages in the live filesystem, in order that they will immediately be ready to upgrade without further download time after installation; we don't install these upgrades immediately during installation because that would complicate an already delicate part of the installer and increase the chance of unrecoverable failures" would likely fail any reasonable usability test
[22:24] <xnox> balloons: because alternative CD throws a dialog in your face to setup proxy, but desktop cd might be more fun.... and if proxy is not setup at install time try to do it after the install is complete =)
[22:25] <cjwatson> In any event the installer used the network long before the "Download updates" feature was implemented
[22:25] <xnox> cjwatson: followed by "If and only if you like formal logic, you may submit a bug report with full apport attachments."
[22:25] <xnox> ;)
[22:25] <balloons> lolol
[22:26] <cjwatson> I still want to require a Nethack ascension before you can complete installation
[22:26] <cjwatson> It would cut down on those annoying bug reports
[22:27] <Laney> The Amulet of Shuttleworth
[22:27] <cjwatson> new player class: Developer
[22:27] <balloons> am I allowed to play in 3d, or do I have to play old-school inside a term window in the installer?
[22:28] <cjwatson> old-school ASCII is the one true way
[22:28] <Laney> telnet nethack.alt.org. no other way.
[22:28] <xnox> balloons: only if you have triple core cpu, llvmpipe works and you will see flickering at the most crucial points.
[22:28] <cjwatson> Meh, I would if my network was about 5x more reliable
[22:29] <balloons> skaet, notice what the release teams turns into while awaiting builds? :-)
[22:30] <skaet> balloons,  more likely a function of the time and that they're still awake...  ;)
[22:31] <balloons> as long as your not blaming me :-)
[22:34] <xnox> balloons: i like your spelling and grammar there =) keeps me on my toes guessing
[22:35]  * xnox ponders where my upload is
[22:35] <balloons> xnox, I have this horrible habit of typing 'your' instead of 'your are'.. I don't even notice anymore :-)
[22:35] <balloons> just enunciate it :-)
[22:36] <xnox> here it is =) (well the top one)
[22:45] <Laney> xnox: Is that diff right though?
[22:45] <Laney> That's an update for conjunction, but I'd think the test wants disjunction, no?
[22:46] <xnox> Laney: let me look at it again.
[22:50] <xnox> Laney: are you saying ORs are missing
[22:51] <Laney> for or you have to duplicate the <match> and change the test
[22:51] <Laney> I showed you a diff like that a while ago if you remember
[22:51] <xnox> vaguely yes.
[22:52] <Laney> see comment #23 in that bug
[22:54] <xnox> Laney: can you reject those two uploads then?
[22:55] <Laney> are you mailing him / commenting on the bug?
[22:55] <xnox> fonts-droid & fonts-unfonts-core
[22:55] <xnox> Laney: yes, I follow up since I started sponsoring it.
[22:55] <Laney> ok
[22:55] <Laney> make sure they're being forwarded upstream too please
[23:02] <xnox> Laney: he did file debian bugs.
[23:02] <xnox> Laney: with patches that will now need resending.....
[23:03] <Laney> maybe the fonts-droid one is right?
[23:04] <xnox> Laney: not the second chunk.
[23:04] <xnox> the first one is maybe ok.
[23:05] <Laney> ah, that one is eq, indeed
[23:05] <Laney> ok, uploads go bye bye
[23:06] <xnox> Laney: merci.
[23:06] <Laney> good job we had a freeze eh
[23:06] <xnox> I'm calling it a night =)
[23:06] <xnox> cause if I can't parse boolean logic..... it's really not the best time to code =)
[23:07] <slangasek> || 1
[23:08] <xnox> slangasek: hehe
[23:13] <NCommander> Daviey: did you approve the maas upload to the archive?
[23:14] <Laney> NCommander: roaksoax said so (https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1044367/comments/6)
[23:14] <ubot2`> Ubuntu bug 1044367 in maas "[FFe] Feature freeze exception for maas in Quantal" [Undecided,Fix released]
[23:15] <NCommander> Laney: yeah, I'm trying to figure out why. That's a massive upload during a period when we want the archive more or less in one piece. It doesn't seem like it was critical enough to warrent an exemption for beta freeze
[23:15] <Laney> I was under the impression that it was nacked for the beta earlier today actually
[23:16] <NCommander> Laney: well it introduced a new package so it went into the binNEW queue, so it can still be rejected
[23:16] <NCommander> I get really anstys on adding new packages to images when we are in bloody freeze
[23:22] <RAOF> Primary?
[23:23] <cjwatson> Archive, as opposed to partner.
[23:23] <RAOF> Ah.
[23:23] <Laney> that appears to be FFeless?
[23:24]  * Laney gives up and goes to bed
[23:24] <Laney> I just walked laptop-first into a doorframe
[23:24] <slangasek> NCommander: we certainly shouldn't be rejecting binaries from the NEW queue due to freezes, that just makes more work for people later
[23:27]  * xnox giggles at Laney 
[23:29] <NCommander> slangasek: I rather not give free pass to people violating freezes. Its safer to do a rollback upload especially since the new upload adds a package
[23:30] <slangasek> NCommander: if there's a rollback, then yeah, a reject would make sense.  However, you're saying Daviey approved the upload, so it doesn't sound like any freezes have been violated here.
[23:30] <NCommander> slangasek: I don't know if he did. There is a comment that he did, but there's no official ACK on the bug
[23:32] <skaet> slangasek,  yes, it suddenly appear, no FFE in place or referenced,  no risk assessment,  QA not lined up for retesting,  so a bit worrying all around.
[23:32] <slangasek> NCommander: well, someone also has to have accepted the package?
[23:32] <NCommander> slangasek: and given what the upload is, a NACK is more apprioate given its an entirely new version
[23:32] <cjwatson> Daviey didn't explicitly mention it on IRC, but talked about it in a way that indicated that he'd approved it.
[23:32] <cjwatson> s/it/an approval/
[23:33] <NCommander> I consider it very concerning that an upload is approved with a complete disregard to our normal FFE processes.
[23:33] <cjwatson> I haven't looked at the FFe so can't really speak to it; my only comment is that I don't remotely buy the "contains new binary packages => automatically requires freeze exception" line of argument
[23:34] <NCommander> cjwatson: that gives me pause. What concerns me is its not a minor fix, its an entirely new version of MAAS that was uploaded
[23:34] <cjwatson> Doesn't seem any more valid to me than the presumption that new upstream releases are automatically more problematic than new packaging revisions, which is a notion I think we disposed of a while back
[23:34] <cjwatson> Yeah, that part I can't speak to
[23:35] <xnox> IMHO cherry-picking is more problematic than taking new revisions/releases. As that really makes you run a forked code base, that nobody else is running.
[23:36] <NCommander> cjwatson: I mis-spoke. A new upstream version and/or new binary is not grounds for an auto-FFe REJECT, but I damn well want to see why it was done
[23:36] <NCommander> xnox: unless it was a soul-crushing critical bug (which this was marked as even though it doesn't seem to meet the criteria), it could have waited 'til friday
[23:36] <slangasek> wanting to see why it was done is an entirely different thing than proposing to roll it back after the release team member who approved it is EOD, which is what it sounds like to me
[23:37] <cjwatson> I certainly have no objection to a desire for transparency, indeed
[23:38] <NCommander> slangasek: because I rather want to avoid having to do respins of all the server images to pick up the new MAAS and invalidate all the testing. If it sits in the queue, and then approved on Wednesday, then we have to fracitically retest everything on Wednesday with no window to get bug fixes in
[23:38] <xnox> there was chatter about that upload on #ubuntu-server earlier today, but the scrollback is rather incomplete / missing full context about the upload.
[23:39] <NCommander> slangasek: and MAAS testing isn't trivial since you need to both test the client and server aspects of it and unless you are explicately setup for it, can be a damn well four letter word to do
[23:41] <NCommander> Now I advocate a binary reject, not because its the easy thing to do, or even the "right" thing to do, but it does avoid the MAAS retesting nightmare. Failing that, then reuploading the old revision and respinning with that (followed by copying the test results to the new images) is the next best course of action
[23:42]  * NCommander is fully aware rejected binaries go straight into /dev/null
[23:42] <slangasek> NCommander: and how is it better to reject a binary and force a re-upload, than to either a) hold the binaries in the queue until after beta, or b) accept the binaries without respinning anything?
[23:42] <slangasek> if there are *any* respins you have to retest anyway
[23:42] <slangasek> and there's nothing on the pad at http://pad.ubuntu.com/ubuntu-release suggesting maas was considered critical for a respin
[23:43]  * micahg also wonders why it wasn't uploaded to proposed
[23:43] <slangasek> I agree that we want more transparency here and that we should revisit why this was accepted when it was (since it doesn't sound like it's critical), but there's no reason to be punitive by rejecting binaries
[23:44] <slangasek> micahg: why should it have been?  it's arch: all so there's no installability issue
[23:44] <NCommander> slangasek: fair enough. if MAAS's binaries sit in the new queue until friday, thats satisifactory
[23:45] <slangasek> NCommander: well, I'm not promising that; we might find that Daviey really does consider this beta-critical.  I'm only saying that a binary reject doesn't make sense to me
[23:46] <micahg> slangasek: package that affects image that's marked as an opportunity target (last minute respin might not want to take it)
[23:46] <NCommander> slangasek: I don't want to have to scramble on Wednesday to retest everything
[23:46] <micahg> IMHO of course since I'm not a release team member
[23:48] <slangasek> micahg: a) that's not what -proposed is for, b) we already had the option to not take it from the unapproved queue and somebody exercised the option to take it
[23:51] <jbicha> slangasek: wasn't -proposed also supposed to be used for updates of seeded packages that aren't milestone blockers?
[23:51] <skaet> gilir, phillw, ogra_ - I've added lubuntu ac100+armhf image to the iso tracker.  Should show up when the next image finishes building.  Please doublecheck that the links are ok.  I went ahead and made the testcases the same as what was used for the ac100+armhf in Ubuntu.   Let me know if it should point to something else.
[23:52]  * skaet --> dinner and visit with friends,  will check in on the image rebuilds when return.
[23:52] <slangasek> jbicha: that was the case for alpha milestones with only a soft freeze on the archive... I don't think it was ever explicitly discussed for beta
[23:53] <micahg> it wasn't which puzzled me slightly
[23:55] <bkerensa> skaet: Is there a set date for when the ReleaseNotes wiki page is created for a release to begin populating information
[23:56] <skaet> bkerensa,  I've got most of the template in place already,  just need to clean up one thing for the 12.10 Release Notes.    For the 12.10 Beta 1 release,  use: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
[23:57] <bkerensa> Thanks