[17:48] <tumbleweed> bdrung: just got around to looking at udt logging
[17:48] <tumbleweed> I agree, python logging isn't a sensible thing to use here
[17:48] <tumbleweed> we should just bundle a copy of devscripts.logger again, I think
[18:13] <bdrung> tumbleweed: okay, bundling our logger to udt sounds like the better than any other solution i came up with
[19:53] <achiang> when using schroot, and issuing say, "sudo sbuild -j 4  -A --arch armhf -d precise foo*.dsc", does that unpack the sources every time?
[23:36] <vagrantc> anyone know the next steps for the SRU for: https://bugs.launchpad.net/pithos/+bug/988395
[23:45] <RAOF> vagrantc: The SRU team will get to pithos in the unapproved queue, then someone needs to test it from proposed.
[23:46] <vagrantc> ok, thanks.


[06:59] <RAOF> infinity: Hey, you around for a little impromptu mentoring? :)
[07:12] <Mirv> it seems Oxide didn't get forward during US Friday - if there's a coredev to ack https://launchpadlibrarian.net/191910301/debdiff_4_6.txt it'd hopefully help unblocking the various things stuck in -proposed because of autopkgtests failing to install packages as described in bug #1399597
[07:12] <ubot2> bug 1399597 in oxide-qt (Ubuntu) "The last oxide upload breaks autopkgtests with a package installation failure" [Undecided,New] https://launchpad.net/bugs/1399597
[07:14] <Mirv> (the package is built in landing-003 since Friday)
[07:14] <RAOF> Mirv: That's a somewhat odd change?
[07:15] <RAOF> Mirv: More specifically, that looks like a fix in the wrong place.
[07:15] <RAOF> Mirv: I take it that oxideqt-codecs-extra conflicts with oxideqt-codecs?
[07:16] <Mirv> RAOF: right, that was the thing discussed. the problem is as seen in the bug that among else the touch image has a hard dependency on the extra codecs package, while oxide itself has this preferral of the non-extra package. somehow this leads to the autopkgtest failure when it first installs Oxide's preferred package and then notices the extra is required.
[07:16] <Mirv> RAOF: yes, they conflict
[07:17] <Mirv> RAOF: and the problem appeared when the conflicts were made arch specific which possibly increased apt complexity too much. this was needed so that even though they conflict, cross compilation chroot needs to be able to install them..
[07:17] <Mirv> RAOF: the problem appeared with this https://code.launchpad.net/~bzoltan/oxide/packaging.vivid-improved-conflicts/+merge/243515
[07:17] <Mirv> which was not wanted to be reverted since then SDK vivid Click cross-compilation would start to fail again
[07:20] <RAOF> Hm, odd. I suppose that also arch-specifying the Replaces: was tried?
[07:21] <RAOF> Anyway, ack. The change is odd, not wrong.
[07:22] <Mirv> RAOF: the arch-specific replaces was not tried. we also couldn't reproduce the autopkgtest machines' problem locally (well, sure we should with proper adt usage).
[07:26] <Mirv> added a note in case arch-specific replaces would be wanted to be experimented with
[08:27] <infinity> RAOF: Not in this timezone, I'm not.  Just heading off to bed.
[10:11] <RAOF> infinity: Well, that's lucky, as I'm EOD anyway :)
[14:58] <mlankhorst> who's doing the 14.04.2 release?
[17:42] <Laney> Are the autopkgtest runners down?
[21:48] <sil2100> infinity: hey! Are you around to upload a quick revert-package for me? :)
[21:49] <sil2100> infinity: there was some trouble with one of the things we released through a silo, but it's in main so I can't upload this revert directly
[21:49] <sil2100> It's a standard revert as per our revert script for CI Train released packages
[21:52] <sil2100> infinity: nevermind my earlier request, but I have another one: once you find a free moment, I would also appreciate if you (or any other archive admin) could drop upower and ubuntu-system-settings from 14.09-proposed in ubuntu-rtm
[21:53] <sil2100> infinity: those are b0rken and need to be uploaded
[21:53] <sil2100> Thanks in advance!
[21:54] <infinity> ... and he didn't stick around for questions.
[23:25] <ScottK> infinity: You mean because CI Train isn't an adequate answer to all teh questions.
[23:26] <infinity> ScottK: It's more of a question for all the answers.
[23:26] <ScottK> There is that.
[23:27] <infinity> When one of your thumbs is twice the size of the other, and moving it makes you want to stab puppies, that's a bad sign, right?
[23:27]  * infinity really has no idea what he did to this thumb...
[23:28] <ScottK> Depends on your perspective on puppies, but I guess it's generally bad.
[23:28] <infinity> ScottK: I'm not a dog person.  Stabbing puppies is still wrong. :P
[23:29] <ScottK> Are they not delicious?  (dunno myself)


[07:19] <skrp> i run an nfs server on freebsd. i can mount it on my other freebsd box but when i try to mount on ubuntu i get " Access denied by server
[07:51] <lordievader> Good morning.
[09:36] <jdv> oooook. What could cause APFs deny_hosts.rules to flush out rules I add?
[09:36] <jdv> there is no cron
[18:17] <bithon> Hello
[18:18] <bithon> Is anyone here in a mood to help another fellow newbie in need of help :D
[18:18] <bithon> in mood*
[18:18] <bithon> Ill state my problem anyway so if anyone's in mood to help I'd appreciate it
[18:19] <bithon> So I'm trying to configure a web server in VirtualBox and so far I've been quite succesful
[18:19] <bithon> the only problem that I face right now is permissions and such
[18:19] <bithon> You see, I use this VM as my dev box. I ssh to it and write code directly from it in vim
[18:19] <bithon> so I setup a wordpress blog and I wish to modify some code but
[18:20] <bithon> I constantly have to switch file permissions of my virtualhost's folder
[18:20] <bithon> from www-data to my account's group
[18:20] <bithon> and it's annoying
[18:20] <bithon> does anyone know a way to bypass this
[18:20] <bithon> ?
[18:21] <bithon> so that wordpress's happy and is able to modify whatever it pleases dynamically without me interfering and at the same time allow me to modify code with my own account
[18:21] <lordievader> bithon: Acl's or a shared group.
[18:22] <bithon> Oh
[18:22] <bithon> I tried placing my account (bithon) to www-data group
[18:22] <bithon> but that doesn't work :S
[18:22] <lordievader> Does the group have rw access?
[18:22] <bithon> yeah
[18:22] <bithon>  -rwxrwxr-x
[18:23] <lordievader> Then it should work.
[18:23] <bithon> There are the permissions
[18:23] <bithon> These*
[18:24] <bithon> I don't like using chmod 775
[18:24] <bithon> Is there a way around it ?
[18:24] <bithon> oh and I'm running apache 2.4 if anyone's wondering
[18:24] <lordievader> bithon: See what I said above.
[18:24] <bithon> Okay I'll look into it and get back to you in a bit. Thanks
[18:38] <bithon> Hmm ACL seems overly complicated
[18:38] <bithon> on Arch Linux wiki it states that I have to mount my partition with ACL
[18:38] <bithon> which complicates a really simple thing that I'm trying to accomplish
[20:43] <andrewjs18> hi all, any iptables gurus in here?
[20:59] <teward> andrewjs18: depends on what you define as a 'guru' and what you want to achieve :P
[21:00] <andrewjs18> teward, I'm still a newb, so I'm sure anyone better than me will suffice.
[21:00] <andrewjs18> anyways, I'm trying to block China through iptables but I'm getting some errors, and I'm not sure why
[21:00] <andrewjs18> I'm using this guide: https://mattwilcox.net/web-development/unexpected-ddos-blocking-china-with-ipset-and-iptables
[21:00] <teward> blocking countries by iptables is incredibly difficult
[21:01] <andrewjs18> I'm using ipset to do it
[21:01] <andrewjs18> let me test something real fast though
[21:02] <andrewjs18> adding this bit of code to the file I load for my iptables rules is causing it to fail: -A INPUT -p tcp -m set --match-set china src -j DROP
[21:02] <andrewjs18> if I comment it out and then load the rules, no issues.
[21:23] <Sling> andrewjs18: what kind of requests do you want to block? remember that if you put all of this in iptables, it will need to be parsed for every incoming packet on every port/protocol
[21:23] <Sling> for a lot of subnets (think thousands or more) this might cost valuable CPU%


[00:06] <phillw> skaet: do you have a few minutes to spare?
[01:28] <Daviey> slangasek: Sorry, i've been afk.  It's a well tested upload, that isn't *entirely* beta critical.. as in, does not warrant a respin.  It is an opportunistic include, which cannot impact other testcases.
[01:29] <slangasek> NCommander: ^^
[01:30] <slangasek> Daviey: it sounds to me like NCommander's biggest concern was that even taking it opportunistically would be a problem for him on ARM maas validation for beta-2
[01:31] <Daviey> slangasek: considering the current version in the archive is known not to work, i can't see why it would upset NCommander
[01:31] <Daviey> note, that rbasak as purely been working on arm support for that upload for the last 2 weeks.
[01:32] <Daviey> So this one, has a higher chance of some success.. compared to known suckage
[01:32] <slangasek> ah, well, then I don't know
[02:20] <NCommander> Daviey: the lack of documentation upsets me. Nowhere at a quick glance can I see that MAAS as it was in the archive was totally broken.
[02:21]  * NCommander was at dinner
[02:21] <NCommander> (well, I knew it didn't work on ARM, but I didn't know it was totally foobar'ed
[02:21] <NCommander> )
[04:17] <skaet> all builds finished,  lubuntu ac100+armhf image now accessible from tracker.
[04:17]  * skaet --> zzz
[07:45] <Daviey> NCommander: The fact that you had no idea it was broken, troubles me more TBH.
[09:04] <knome> there somebody who could help or point to somebody could help with problems during ubiquity?
[09:05] <knome> xubuntu is affeted by both bug #924909 and bug #101087 and we think this has something to do with the ubiquity config
[09:05] <ubot2> Launchpad bug 924909 in xfwm4 "Windows have grey traces in Ubiquity" [Medium,Confirmed] https://launchpad.net/bugs/924909
[09:05] <ubot2> Launchpad bug 101087 in silva "request for get_ordered_ids()" [Wishlist,Won't fix] https://launchpad.net/bugs/101087
[09:09] <Laney> knome: you probably meant something else for the second one?
[09:09] <knome> yes...
[09:09] <knome> bug #1010487
[09:10] <ubot2> Launchpad bug 1010487 in ubiquity "Xubuntu - black windows" [High,Confirmed] https://launchpad.net/bugs/1010487
[09:10] <knome> is there some settings how ubiquity/xfce is run or similar we could look at?
[09:12] <xnox> knome: #924909 is funny. There is an upstart job which launches ubiquity in the greeter mode. But it looks like the background is not repainted, maybe something needs to be done there to ask thunar to repaint itself?
[09:12] <cjwatson> bin/ubiquity-dm in the ubiquity source might be worth looking at, assuming this is in the "Install Xubuntu" mode and not "Try Xubuntu without installing"
[09:13] <cjwatson> You can generally tell whether something's a ubiquity-dm bug by seeing if behaviour in those two modes differs
[09:13] <cjwatson> (significantly)
[09:13] <xnox> knome: cjwatson reply is better =)
[09:13] <cjwatson> We might quite plausibly not be launching some bit of your desktop infrastructure
[09:13] <Laney> the bugs both confirm that
[09:13] <cjwatson> I didn't look :-)
[09:13] <knome> cjwatson, yeah, the grey bits is only in "install" mode
[09:14] <knome> and probably the other bug as well..
[09:14] <knome> though somebody reported to have it on "live", but not when running "install" from live
[09:14] <knome> cjwatson, bin/ubiquity-dm where? :)
[09:15] <cjwatson> As I said, in the ubiquity source
[09:15] <cjwatson> bzr branch lp:ubiquity
[09:15] <knome> oh, right. just woken up.. sorry! :)
[09:16] <cjwatson> have it on "live", but not when running "install" from live> that sounds confused as ubiquity doesn't run in "live" mode unless you run install ... I suspect they meant "install" mode for the formere
[09:16] <cjwatson> *former
[09:16] <knome> yeah.
[09:16] <knome> probably
[09:16] <xnox> knome: the second one might be a dupe of bug 744283 but I am not entirely sure. There are changes to two files in that branch (gtk_ui.py & ubiquity.ui you could replace them in place and see if helps, replace on the tty1 and do $ sudo restart lightdm to retest the "greeter" mode)
[09:16] <ubot2> Launchpad bug 744283 in ubiquity "Steps "Preparing to install" and "Erase disk" are unreadable with high-contrast theme enabled" [Medium,In progress] https://launchpad.net/bugs/744283
[09:17] <knome> :o
[09:17] <xnox> we do need consistent terms for "greeter", "try ubuntu" & "install ubuntu". Cause live/alternate are the traditional counter parts =)
[09:18] <cjwatson> desktop/alternate are the traditional counterparts
[09:18] <cjwatson> live -> desktop and install -> alternate were simultaneous changes
[09:19] <cjwatson> I sometimes call them "live session" and "only-ubiquity" modes
[09:19] <xnox> ok.
[09:19] <cjwatson> bit jargonish which is why I tend to use the boot menu names when talking to non-ubiquity-developers
[09:20] <cjwatson> And of course only-ubiquity and maybe-ubiquity are not quite identical.  Terrible naming there
[09:20] <cjwatson> maybe-ubiquity is the greeter mode (i.e. what you get if you let an Ubuntu desktop image boot without touching it)
[09:20] <xnox> cjwatson: which are not visible by default & no logo either. See the video from the 924909. Why is there no isolinux ubuntu logo shown?! only unless you click Esc...
[09:21] <xnox> gray logic ftw =)
[09:21] <knome> heh
[09:22] <cjwatson> That video shows the "press key for options" rebus icon
[09:22] <cjwatson> Which is as expected
[09:22] <cjwatson> If you don't press a key there, you get maybe-ubiquity mode
[09:22] <cjwatson> Which I think is what you're calling "greeter"
[09:23] <xnox> yeah.
[09:23] <cjwatson> It's sort of an uneasy compromise
[09:23] <xnox> I think it would be nice to show ubuntu logo & the rebus. But I am sure there are reasons for it =) e.g. wrong resolution, low color depth, etc....
[09:23] <cjwatson> Design didn't want to show the boot menu by default; I wasn't happy with showing text before we know the user's language
[09:24] <cjwatson> And yes, the Ubuntu logo is kind of a no-go there because the aspect ratio is very likely to be wrong
[09:24] <cjwatson> And syslinux is a bit too primitive to be able to do much about that
[09:24] <cjwatson> At least not while preserving my sanity
[09:26] <xnox> well remaining sanity bits, need preserving =))))))) totally agree with you there!
[09:26] <knome> anyway, thanks for the help
[09:26] <knome> we'll look at this and hopefully fix it soon!
[09:30]  * iulian is not getting any mails from Launchpad when he comments in bugs where ubuntu-release is subscribed.
[09:31] <iulian> Any idea why?
[09:32] <xnox> iulian: what's your bug mail preferences? you can choose not to receive spam about your own updates =)
[09:32] <iulian> xnox: I've no idea what my bug mail preferences are. :)
[09:32] <iulian> Where do I check that?
[09:32] <iulian> It used to work before.
[09:32] <xnox> iulian: it's somewhere on your personal page http://pad.lv/~iulian ?
[09:33] <xnox> iulian: also #launchpad support on #launchpad? =)))))))))))) ;-)
[09:34] <smartboyhw> iulian: Follow xnox's advice and go to #launchpad for Launchpad Mail help:)
[09:34] <Laney> you don't get your own comments back
[09:34] <xnox> you can =)
[09:34] <xnox> I do =)
[09:34] <iulian> Laney: We used to get them. What happened?
[09:35] <Laney> eww
[09:35] <xnox> 1046206 dupe of 1010487 ? I am suspecting a thunar change
[09:35] <Laney> I see a somewhat relevant sounding setting on http://launchpad.net/~/+edit
[09:35] <iulian> I cannot remember each bug I commented on and it makes reviewing things a bit harder. :(
[09:35] <iulian> OK, let's see.
[09:36] <iulian> I've got the "Send me bug notifications..." ticked already.
[09:37]  * iulian sighs.
[09:37]  * iulian goes to #launchpad.
[11:15] <xnox> jibel: bug 1046175 debdiff attached, fixed in lp:ubiquity . Tested locally created 4 primary, delete 4th primary, create 3 logical.... the partition type is now shown in the create dialog.
[11:15] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
[11:16] <xnox> release team please see bug 1046175 and check if you want to: release note it, respin opportunity or trigger.
[11:17] <xnox> the manual partitioner currently creates only primary partitions. so you are limited to create maximum 4 partitions when starting from scratch. If starting from existing system you can only create (4 - # of existing primary partitions)
[11:22] <cjwatson> I think that's at least worth uploading so that we can take the decision about whether to respin for it (potentially) in your absence
[11:22] <cjwatson> Worth noting that many systems have three primary partitions from the factory so it can be very difficult to install at all without using logical partitions
[11:23] <xnox> ok.
[11:23] <xnox> in the mean time I will continue on implementing manual lvm controls.
[11:23] <cjwatson> xnox: Have you tested the behaviour when editing an existing partition as well?
[11:30] <xnox> cjwatson: yes.
[11:30] <xnox> although I do not understand why partman decides to check for bad blocks while doing edit =/ remove+add are instant, yet edit are not.
[11:31] <cjwatson> I wouldn't expect bad blocks checks until you commit
[11:33] <xnox> edit decided that "previous changes need to be committed", although there were no previous changes (just restarted ubiquity).
[11:33] <xnox> change 3 partitions / repartitioned.
[11:33] <xnox> and the primary/logical options are not shown on edits.
[11:41]  * ogra_ wonders whats the reason that http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22564/testcases/1167/results tells him the last update was on may 9th
[11:41] <ogra_> :P
[11:41] <ogra_> (read: cant we use sane date strings ?)
[11:42] <Daviey> +1
[11:43] <xnox> ogra_: drupal has no clue about browser locales =)
[11:43] <Laney> heh
[11:43]  * xnox +1 for ISO dates 2012-09-05
[11:44] <ogra_> xnox, well, i dont need a date in my personal locale necessarily ... a more international way would already suffice
[11:44] <ogra_> and yeah, ISO would be good
[11:44] <xnox> ogra_: you made a slight assumption there that american is not internation way ;-)
[11:45] <ogra_> no, i made a hard claim ;)
[11:48] <cjwatson> Yeah, no real excuse for not using ISO dates in an international project
[12:11] <iulian> Yummy.
[12:12] <Laney> I'd have thought -dpkg needed re-merging or syncing
[12:12] <Laney> (the interface changed)
[12:14] <iulian> Right, should we reject this one and sync it instead?
[12:14] <Laney> think so
[12:15] <Laney> test build the debian version and see
[12:16] <iulian> Already started building it.
[12:24] <skaet> good morning
[12:25] <iulian> Laney: Status: successful. I'm rejecting the one in the queue right now and sync it.
[12:25] <iulian> Morning skaet.
[12:25] <skaet> good afternoon iulian :)
[12:26] <skaet> Laney, cjwatson - pad looks quiet.    Any concerns emerging from latest set of images?
[12:27] <skaet> Riddell,  has anyone been able to duplicate https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1046244?
[12:27] <ubot2> Launchpad bug 1046244 in casper "plasma-desktop crashes with SIGFAULT on boot" [Undecided,New]
[12:28] <cjwatson> skaet: bug 1046175
[12:28] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
[12:28] <cjwatson> xnox: ^- still awaiting an upload for that, I think ...
[12:28] <xnox> ok.
[12:34] <Riddell> skaet: no I couldn't recreate that plasma crash but I'm asking for more testers
[12:35] <skaet> Riddell,  thanks.
[12:47] <Laney> iulian: please take a look at silently and ghc-syb-utils (my uploads, so I can't do them myself)
[12:52] <iulian> Laney: Done.
[12:52] <iulian> I reckon that ghc.html page will look nicer. :)
[12:56] <Laney> cheers
[12:58] <iulian> queuebot is on holiday again.
[12:58] <Laney> Daviey: go!
[12:59] <iulian> Is he bringing a new robot from the clouds?
[13:00] <skaet> Daviey, can you provide more background on the MAAS upload on the pad, and a bit more background?
[13:01] <skaet> in general - ie. what are the implications if we don't respin, and just make it available as SRU?
[13:02] <Laney> SRU?
[13:02]  * skaet needs more coffee
[13:03] <skaet> first update after we put out beta 1.    Had concept of 0-day SRU in my head,  where 0-day was for Beta 1,  but term SRU is inappropriate.   Development Update?  DU
[13:03]  * xnox 's machine locked up. On reboot I have 15 apport windows..... *sigh* I am submitting them all!
[13:05] <cjwatson> just "update" is fine
[13:07] <skaet> fair 'nuf ;)
[13:11] <skaet> bug 1046228
[13:11] <ubot2> Launchpad bug 1046228 in ubiquity "Quantal Desktop AMD64 installation failed with: ubiquity.install_misc.InstallStepError: Plugin console_setup failed with code 1" [Undecided,Confirmed] https://launchpad.net/bugs/1046228
[13:13] <skaet> cjwatson, xnox - is one of you looking at this as well?
[13:13]  * skaet --> vet,  back in 2 hours.
[13:13] <xnox> not yet. needs follow up as nobody else is reproducing this yet.
[13:13] <xnox> maybe the reported did something non-standard to get that.
[13:14] <xnox> but then again. I am not that good with console-setup
[13:16] <psivaa> xnox, i reported the bug, but did not do anything non standard,
[13:17] <psivaa> xnox, let me try a coupld more times to see if i could nail the steps to reproduce
[13:17] <cjwatson> I'll have a look once I get some I/O back from this GRUB build
[13:17] <cjwatson> But the move to 3D unity only means I'm kind of hamstrung in terms of doing much in the way of installer debugging in kvm
[13:18] <cjwatson> psivaa: If you're running it again, please add the "debug-ubiquity" boot parameter
[13:18] <cjwatson> That will produce more helpful logs
[13:18] <cjwatson> psivaa: You also didn't say which language, location, and keyboard layout/variant you selected
[13:19] <cjwatson> Actually, never mind, those bits are in the log
[13:20] <psivaa> cjwatson, i could add the debug-ubiquity but i need to look up how to do that
[13:20] <cjwatson> f6 at boot menu
[13:20] <psivaa> cjwatson, thats good enough thanks v much
[13:20] <Daviey> skaet: i'm not sure it requires more content.. it's an opportunity include.
[13:20] <cjwatson> probably best to add  maybe-ubiquity debug-ubiquity  to make it as similar as possible to the previous scenario
[13:37] <jibel> xnox, skaet , I filed bug 1046323, which I think should be marked in red in the release notes if not fixed.
[13:37] <ubot2> Launchpad bug 1046323 in ubiquity "Ubuntu installs on first drive without asking when 'Encrypt disk' is selected on a dual drive system " [Undecided,New] https://launchpad.net/bugs/1046323
[13:37] <xnox> jibel: are both disks same size?
[13:37] <xnox> jibel: or one bigger than the other.
[13:38] <jibel> xnox, yes, same disks
[13:38] <xnox> jibel: then does it matter which one to install onto? since we can't install on to both.
[13:39] <xnox> jibel: if they are different size, maybe it does matter.
[13:39] <jibel> xnox, what if there is an existing system on sda and want to install to sdb ? the content of sda is lost
[13:39] <xnox> jibel: if existing OS are detected, it's a different code path and you should always see selection.
[13:40] <jibel> xnox, if the user doesn't select to encrypt the drive, there is an additional page to select the target drive
[13:40] <xnox> jibel: plus you would be choosing side-by-side install, which is differe from wipe disk and install.
[13:40] <xnox> jibel: no, there isn't. It became optional, if there are no choices for the users to make.
[13:40] <xnox> jibel: as per design spec.
[13:41] <xnox> I recently commented on the armhf bug that testcases need adjustment.
[13:41] <jibel> xnox, I have the choice, there are 2 disk drives on the system
[13:42] <xnox> both are empty, both are the same size, and can be enumerated in random order. so you don't know which is sda and which is sdb => you have no choice =)
[13:42] <xnox> I am not sure if selection should be presented.
[13:43] <jibel> xnox, hm install precise on disk1, precise on disk 2, then quantal with entire drive + luks
[13:43] <jibel> don't tell me it selects to wipe a random disk
[13:43] <xnox> jibel: is that what you did?
[13:43] <jibel> xnox, it was not precise but pretty much
[13:44] <xnox> jibel: cause the entire drive becomes => "delete $existingos and do clean install"
[13:44] <xnox> jibel: if you have existing system and you want to preserve it, you should select "install side-by-side"
[13:44] <xnox> then you should be able to choose which drive to install onto.
[13:45] <jibel> xnox, ok, let me try again
[13:45] <xnox> and by the way you can currently only use "lvm & crypt" options on "wipe & install"
[13:45] <xnox> it should not offer those on dual boot options
[13:45] <xnox> they will be gray.
[13:46] <xnox> the reason it's ambigious where to do the dual boot at: disk level, crypt level or lvm level.
[13:48] <xnox> jibel: please take screenshots / read carefully (prefferably in english, If you want to file bugs about it. Maybe there is something lost in translation?!)
[13:48] <xnox> or both locales....
[13:49] <jibel> xnox, I'm reinstalling lucid on sda, precise on sdb and will tell you what happens with no lvm, lvm only, lvm+luks.
[13:50] <xnox> jibel: using automatic installer?
[13:50] <xnox> jibel: hmmmm =/ i expect something ugly will happen.
[13:51] <xnox> cjwatson: skaet ^^^ upload for bug 1046175
[13:51] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
[13:51] <jibel> xnox, I expect it too, and why I think it should be documented
[13:52] <jibel> I could have windows on my first drive, and want to try new shiny features of Quantal on an additional drive.
[13:53] <xnox> jibel: it's different code paths if it is existing $windows + $ubuntu vs ($windows + $other_linux or 3+ OS)
[13:55] <xnox> jibel: if you have lucid/sda and precise/sdb. You should see "You have multiple OS installed, what do you want to do?". The option that will offer crypt or lvm, should have a Red Warning label saying everything will be destroyed.
[13:55] <xnox> not sure about exact text of that option.
[13:56] <xnox> psivaa: any more luck reproducing your console-setup crash?
[13:57] <psivaa> xnox, not yet, but trying
[13:58] <jibel> xnox, ok, I'll try with windows too
[14:00] <cjwatson> plars: So, skaet's away for a bit, but she asked me to talk to you about bug 1046175
[14:00] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
[14:01] <xnox> psivaa: i wonder if something went very wrong in that install.... see my last comment on your bug. That's from ubiquity syslog
[14:01] <cjwatson> plars: This is a pretty nasty bug that I reckon renders the installer unusable for a number of classes of users, and is certainly deeply confusing
[14:01] <plars> cjwatson: I'm looking at that one right now and talking to jibel about it
[14:01] <cjwatson> plars: I can't personally speak to its testing, but xnox has tested his own fix
[14:01] <cjwatson> plars: What do you think about the chances of a respin?
[14:01] <cjwatson> 'cos I know QA love that
[14:01] <phillw> lol
[14:02] <plars> cjwatson: heh, well... if we kick off a respin now, we are looking at late night for most of the team but me by the time it's ready
[14:02] <cjwatson> Yeah, and we need to accept the new ubiquity and get it built and published
[14:02] <cjwatson> It's not ideal
[14:02] <plars> cjwatson: yeah, I know
[14:03] <psivaa> xnox, yes i saw that, but this is a vm install so not sure what exactly might have gone wrong there
[14:03]  * xnox doesn't consider bug 1046175 respin worthy. maybe opportunity candidate. I'm not  in release team or anything like that.
[14:03] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Confirmed] https://launchpad.net/bugs/1046175
[14:03] <cjwatson> Perhaps I should get it built and published anyway?  At the very least, we aren't going to build images without this fix
[14:03] <cjwatson> Yeah, I think I'll do that
[14:04] <xnox> psivaa: anything can happen, I had virt-manager loosing track of it's storage pools and producing very interesting virtualisations of hardware failures ;-)
[14:04] <plars> I was actually about to talk to jibel to see if we have any standard criteria for respinning at milestones that differ from release.  Certainly for release we would need to respin, but for beta, in my thinking, is there a big difference between release noting something like this and telling people that if this is a big deal for you, you should pick up tomorrow's daily build instead for testing?
[14:04] <stgraber> having it in the archive as an opportunity target sounds good
[14:04] <plars> indeed
[14:04] <cjwatson> plars: Depends how many support mails we want to answer :-)
[14:04] <cjwatson> The day after a milestone, daily builds are often broken, of course
[14:04] <cjwatson> But we'll see ...
[14:10] <psivaa> xnox, hmm ok, could not reproduce it yet, the vm installation on that particular system is very slow though
[14:11] <xnox> psivaa: most of my testing is in kvm, and I didn't see that one yet.  That certainly explains why I'm not getting any X session...
[14:12] <highvoltage> stgraber: yeah I noticed that yesterday too and wondered what was going on
[14:12] <highvoltage> (I assumed it was a global ubuntu problem, is it not?)
[14:13] <stgraber> I don't think so or we'd have a lot more people panicing ;)
[14:13] <stgraber> xserver-xorg-video-all seems to be missing, trying to figure out why
[14:14] <psivaa> xnox, hmm possibly, let me try if that wind is persistent :) but owing to its lack of frequency, i dont think its very important for today
[14:15] <stgraber> highvoltage: hmm, might be because we're shipping arkose which ships xpra which depends on xfvb which depends on xserver-xorg-video-dummy
[14:15] <stgraber> highvoltage: xserver-xorg-video-dummy meets the "xorg-driver-video" criteria part of xserver-xorg so xserver-xorg-video-all never gets installed
[14:16] <highvoltage> ah, weird that we didn't run into it before.
[14:17] <highvoltage> I guess the dependencies/recommends got updated with the new X stack that got uploaded.
[14:17] <stgraber> something must have changed recently, either xvfb/xpra using xserver-xorg-video-dummy or some change on xserver-xorg-video-dummy so it now provides xorg-driver-video...
[14:19] <stgraber> trying to figure out what the right fix is... I can see why someone would wnat to install xserver-xorg with only xserver-xorg-video-dummy as I'm actually doing that for some containers/auto-upgrade-testing... I'll just add xserver-xorg-video-all to edubuntu-desktop for now
[14:28] <stgraber> Laney, skaet, cjwatson: I'm going to push a new edubuntu-meta to fix that missing X driver issue we're having (seed change pushed already), then will respin with whatever other fixes will have landed by then
[14:30] <Laney> are we expecing a new ubiquity?
[14:30] <Laney> you might want to wait for that if so
[14:30] <cjwatson> stgraber: Let's wait until ubiquity has published
[14:30] <cjwatson> Laney: It's building or publishing or something
[14:30] <cjwatson> stgraber: But yes, makes sense to upload edubuntu-meta in the meantime
[14:31] <stgraber> cjwatson: ok, will add the ubiquity fix as rebuild trigger for Edubuntu then
[14:31] <Laney> ah, it's being release noted for everything else?
[14:32] <cjwatson> I don't think we've decided
[14:32] <Laney> just going by the pad
[14:36] <stgraber> ^ can someone please review edubuntu-meta? (diff should be tomboy replacing gnote and xserver-xorg-video-all added)
[14:36] <Laney> doing
[14:37] <stgraber> the gnote -> tomboy part is bug 1046345 which I mentioned in the seed commit but forgot in the upload
[14:37] <ubot2> Launchpad bug 1046345 in edubuntu-meta "[ffe] Change from gnote to tomboy in Edubuntu" [Medium,Confirmed] https://launchpad.net/bugs/1046345
[14:37] <Laney> (yay tomboy)
[14:38] <Laney> done
[14:38] <stgraber> Laney: thanks
[14:43] <phillw> could someone spare a bit of time to look at the powerpc builds for lubuntu? Both are 'fail', two different bugs.
[14:43] <phillw> bug http://launchpad.net/bugs/1041625
[14:43] <ubot2> Launchpad bug 1041625 in openchrome "X not starting after install [openchrome]" [Critical,Confirmed]
[14:43] <phillw> bug http://launchpad.net/bugs/1040544
[14:43] <ubot2> Launchpad bug 1040544 in ubiquity "Installer dialog does not come up" [Undecided,New]
[14:51] <phillw> ahh, there has been a comment on the X bug :)
[15:01] <tumbleweed> grumble, ppc buildd has been hit with lots of PPA builds today
[15:09] <phillw> tumbleweed: sorry... I know ppc can be a pain in the neck.
[15:15] <skaet> plars, cjwatson, Laney - looks like we'll be getting in a security fix as well.
[15:16] <Laney> for what?
[15:16] <tumbleweed> phillw: not your fault. I just don't want to accept too many unseeded things until the backlog has cleared
[15:22] <plars> skaet: which packages are affected? we have the fix already?
[15:23] <cjwatson> Is it a security fix that *has* to be on the live session rather than being upgraded latere?
[15:23] <cjwatson> *later
[15:23] <xnox> isn't it kernel?!
[15:23] <jdstrand> which package is it?
[15:23] <cjwatson> Well, I don't know, I haven't been told
[15:24] <jdstrand> we've been uploading userpace things to quantal-proposed. they don't need to be on the CD unless someone explicitly asks for it
[15:25] <utlemming> stgraber: can you add http://cloud-images.ubuntu.com/quantal/20120905/ to the tracker for B1?
[15:25] <stgraber> utlemming: sure
[15:25] <utlemming> stgraber: thank you kindly :)
[15:26] <stgraber> Can't find: us-west-2-amd64-hvm
[15:26] <stgraber> utlemming: is that something new? ^
[15:27] <utlemming> stgraber: yes, that's new. It came online the day of A3
[15:27] <skaet> jdstrand,  openjdk6 and openjdk7
[15:27] <jdstrand> those are probably coming from doko
[15:27] <skaet> yes,  jamespage has been working with him on testing.
[15:27] <cjwatson> skaet: Why do those need to be updated on the images?  12.04 is vulnerable too, surely
[15:27] <stgraber> utlemming: ok, I'll need a bit more time for that one then
[15:27] <doko> skaet, yes, as mentioned earlier
[15:28] <jdstrand> but I don't see why they need to be on the image per se-- but the server team might want it...
[15:28] <cjwatson> If it's vital that it be in 12.10 beta 1 for some reason, I'm not sure why logically we aren't scrambling to do a snap 12.04 point release
[15:29] <skaet> cjwatson,  I believe that's in progress as well.
[15:29] <doko> cjwatson, 12.04 has the openjdk security updates
[15:29] <cjwatson> doko: In the 12.04.1 images?
[15:29] <cjwatson> skaet: A snap point release?
[15:29] <cjwatson> That's kind of a big deal, surely we need to talk about that
[15:30] <cjwatson> We didn't even do that for the OpenSSL vulnerability of death
[15:30] <skaet> cjwatson, agreed.    No discussion of a snap point release for 12.04 yet.
[15:30] <doko> sorry, didn't get this with the point release
[15:30] <iulian> There's a sync (octave) sitting in the queue. It takes more than 1 hour to build on amd64/i386 and roughly 4 hours on arm* and ppc. If you need the buildds to be free, then let it stay in the queue.
[15:30] <cjwatson> I understand that the Java plugin has serious vulnerabilities, but web stacks have vulnerabilities all the time - we generally just let people upgrade afterwards and move on
[15:31] <micahg> The java browser plugin wasn't shipped in 12.04.1 anyways and isn't on any media for quantal
[15:32] <stgraber> utlemming: there you go ^
[15:33] <cjwatson> Yeah, indeed - so at least the Java vulnerabilities I've heard about don't seem urgent for images
[15:33] <utlemming> stgraber: most appreciated :)
[15:33] <cjwatson> Well, icedtea-6-plugin is on the Kubuntu DVD actually
[15:33] <cjwatson> Ah, but we've stopped building that by the looks of things
[15:34] <skaet> server and edubuntu?
[15:34] <cjwatson> AIUI the vulnerabilities are only critical for things that ship icedtea*-plugin
[15:34] <cjwatson> i.e. Java on the security boundary rather than YA language interpreter
[15:34] <stgraber> can someone from ubuntu-archive please merge: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/ami-add-us-west-2-amd64-hvm/+merge/122903 ?
[15:42] <doko> cjwatson, hmm, no, the ones from last week are in the jdk
[15:43] <cjwatson> doko: Please expand
[15:43] <cjwatson> doko: Are they attacks by malicious applications on the language runtime/VM?  That's what I understood
[15:43] <doko> http://lwn.net/Articles/514274/
[15:43] <cjwatson> doko: In that case they only matter if the application comes from a different security context
[15:44] <cjwatson> We don't care about the possibility that a local application might exploit a local VM to do something malicious with its own user privileges
[15:44] <cjwatson> Only things on security boundaries matter, such as the web plugin
[15:44] <doko> well, ok
[15:52] <stgraber> Laney, cjwatson, skaet: edubuntu-artwork and ubiquity are published on all architectures, can we respin Edubuntu now?
[15:53] <skaet> stgraber,  ok for respinning Edubuntu
[15:53] <skaet> Laney,  will you trigger it, or do you want me to?
[15:57] <cjwatson> plars: so I gather there's some debate about whether to respin desktop, and we should talk about it here
[15:57] <cjwatson> we let in the ubiquity fix kind of as an opportunity target, or at least because there was no reason not to
[15:58] <cjwatson> I understand QA time is tight but I think it's very bad to release with a broken manual partitioner
[15:58] <plars> cjwatson: I had just been reading the backscroll, it sounded like most here were in agreement that it should be updated, but no respin?
[15:58] <cjwatson> prepared to be overruled, but we shouldn't all assume we agree without clear discussion :)
[15:58] <plars> oh, I thought you meant about the java bug
[15:58] <stgraber> skaet, Laney: as neither of you seems to have done it yet, I'm triggering the rebuild
[15:58] <skaet> stgraber,  ack.
[15:58] <cjwatson> I don't think the Java bug needs a respin, no, but the ubiquity issue remains
[15:59] <plars> cjwatson: which ubiquity bug specifically? do you mean https://launchpad.net/bugs/1046175
[15:59] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Fix released]
[15:59] <cjwatson> Yes
[15:59] <plars> or https://launchpad.net/bugs/1046167
[15:59] <ubot2> Launchpad bug 1046167 in ubiquity "Cannot use manual partitioner if an LVM partition already exists (dup-of: 1042647)" [Undecided,New]
[15:59] <ubot2> Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,Confirmed]
[15:59] <cjwatson> No, 1046175
[15:59] <cjwatson> The only image for which that's relevant that also contains OpenJDK is the Edubuntu DVD, BTW
[16:00] <stgraber> skaet, Laney: doh... I forgot to set ARCHES... so looks like we'll get an armhf build for Edubuntu (not published though), sorry for the extra time it'll take to build that one for nothing...
[16:00] <plars> I've been trying to reproduce 1046175 and so far, not able to
[16:00] <cjwatson> xnox: ^-
[16:00] <plars> maybe because I was testing it on mac?
[16:00] <cjwatson> Yes
[16:00] <cjwatson> Macs use GPT which does not have a primary/logical distinction
[16:00] <cjwatson> Testing that bug on Macs is a waste of time :)
[16:01] <plars> ah, ok I had wondered if there was a diff there.. (I just got this mac from jibel, never used one before)
[16:01] <highvoltage> I wish people would stop doing silly things like buying Macs.
[16:01]  * xnox if only everyone used GPT like I also do.....
[16:01] <cjwatson> Oh don't get me wrong it's a much better partition table format
[16:01] <cjwatson> But
[16:01] <plars> cjwatson: there's another one to be aware of too...
[16:02] <plars> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1046323
[16:02] <ubot2> Launchpad bug 1046323 in ubiquity "Ubuntu installs on first drive without asking when 'Encrypt disk' is selected on a dual drive system " [High,Confirmed]
[16:02] <cjwatson> jibel and xnox were going round on that; I didn't keep up
[16:02] <xnox> this is IMHO expected behaviour. But I still need to review jibel's screenshots.
[16:03] <cjwatson> I'm not sure I agree, but I'm not sure now is the time for that debate either :-)
[16:03] <xnox> I only offer lvm/crypt on clean installs, not dual boot configs / reinstall / upgrades etc.
[16:03] <plars> xnox: my understanding was that if you have two disks, and you are trying to install on the second drive with encrypted disk, you're first drive is going to get wiped instead
[16:03] <cjwatson> It seems to lack defence in depth against data loss
[16:03] <xnox> i need to review jibel's pdf before doing any fixes.
[16:04] <xnox> plars: ubiquity partitioning does not currently offer automatic option "install on the second drive with encryption".
[16:04] <plars> ok, so it's back to just bug 1046175 then
[16:04] <ubot2> Launchpad bug 1046175 in ubiquity "[regression] Manual partitioner only creates primary partitions" [High,Fix released] https://launchpad.net/bugs/1046175
[16:04] <xnox> that one is uploaded.
[16:05] <plars> didn't there used to be an option to get the latest ubiquity before starting the install?
[16:05] <plars> or is that gone now
[16:05] <xnox> if there was, it was way before my time.
[16:06] <cjwatson> There is, but it relies on a remote trigger to activate
[16:06] <cjwatson> xnox: ubiquity/auto_update.py
[16:06] <xnox> ok.
[16:08] <plars> cjwatson: I think this would surely be critical if it were final release, but for beta1, would we have normally done a respin in the past with <24 hours for something like this?
[16:08]  * plars just started on the team this week, so I don't yet have a good feel for the history of things like this
[16:08] <cjwatson> certainly have in the past
[16:09] <cjwatson> depends how far in the past you mean I suppose, I only have records in wetware memory
[16:09] <plars> cjwatson: my concern is that there may not be enough time to rerun all the tests
[16:09] <cjwatson> well, I don't know, as I say I'm prepared to be overruled if you think there isn't enough time
[16:10] <cjwatson> although I think it is a process failing if there isn't enough time, because we've certainly done shorter-notice respins than this in the past, and we've cut down on our image sets so that QA would be quicker
[16:10] <plars> skaet: what time do we actually release tomorrow?
[16:10] <plars> cjwatson: what do you mean by "cut down our image sets"?
[16:10] <cjwatson> I mean if we stop shipping alternates and QA takes twice as long, that seems kind of odd
[16:11] <plars> cjwatson: could be ok, as I said, just started, don't have a good sense of time on this yet
[16:11] <skaet> plars, its variable,  we certainly have time for a round of testing from europe in the morning, as well as the rest of the afternoon here.
[16:12] <Laney> stgraber: OK. I was never going to do it because you said you would. ;-)
[16:12] <plars> skaet: ok, sounds good then... it's just desktop respin right?
[16:12] <cjwatson> I don't want to steamroller this through by force of personality or whatnot; if other people don't think it's desperately important I'll step back
[16:12] <cjwatson> xnox said he didn't feel it was respin-worthy
[16:12] <cjwatson> Anyone else?
[16:12] <skaet> cjwatson,  I'd rather it get fixed and out there as well,   and since there is still time to retest, that's my preference
[16:13] <skaet> plars, yes, just desktop respin.
[16:13] <skaet> for Ubuntu.
[16:13] <plars> +1 then
[16:13] <xnox> well it affects all images that use gtk-ubiquity so: ubuntu desktop, lubuntu desktop, xubuntu desktop, ubuntu studio desktop, edubuntu (is already respinning)
[16:13] <skaet> Riddell, gilir, knome - do you want respins to pick this up for yours?
[16:13]  * skaet snaps with xnox
[16:14] <xnox> does not affect Kubuntu
[16:14] <cjwatson> Yeah, doesn't appear to affect Kubuntu
[16:14]  * xnox snap
[16:14] <skaet> xnox,  cjwatson,  ack.  Riddell - relax ;)
[16:14]  * Riddell relaxes
[16:14] <phillw> skaet: the lubuntu testers will dive back in if warned.
[16:15] <xnox> well the question is whether you care about setting primary & logical partitions in manual partitioning.....
[16:15] <skaet> phillw,  yours and gilir's call.    How critical is this case to your userbase?
[16:15] <skaet> scott-work,  do you want ubuntu-studio respun?
[16:16] <phillw> lubuntu users tend to be adventurous, so the lack of using extended partitions could well cause problems.
[16:16] <skaet> xnox,  does this affect the alternates?
[16:16] <knome> skaet, when was the testing deadline again and will this affect all builds?
[16:17] <cjwatson> skaet: no
[16:17] <cjwatson> it's purely at the ubiquity UI level
[16:17] <skaet> knome, ^ per cjwatson,  just desktop.
[16:17] <knome> skaet, i meant i386/amd64, but that probably affects both ;)
[16:17] <knome> skaet, please respin for xubuntu
[16:18] <skaet> knome, testing deadline is by 1200 UTC
[16:18] <skaet> knome,  ok.
[16:18] <phillw> skaet: when will the iso's land?
[16:18] <utlemming> skaet: it looks like we're going to rebuild our cloud images in light of LP: #1046115
[16:19] <cjwatson> I'll start off respins nowish
[16:19] <scott-work> skaet: ubuntu studio will not ask for a respin
[16:19] <skaet> scott-work,  ok
[16:19] <skaet> utlemming,  ack
[16:19] <cjwatson> It is *so annoying* that etherpad reconnection doesn't work
[16:19] <phillw> cjwatson: indeed!
[16:19] <utlemming> skaet: I'll let you know ASAP on that
[16:19] <cjwatson> so Ubuntu Lubuntu Xubuntu then?  I suspect that Xubuntu and Lubuntu users are pretty similar in adventurousness
[16:20] <knome> cjwatson, i already confirmed xubuntu wants a respin :)
[16:20] <phillw> I'm happy for a lubuntu respin
[16:20] <cjwatson> Oh I missed that, sorry
[16:20] <skaet> phillw,  marked it.
[16:20] <knome> np
[16:21] <Laney> you guys don't want to change your seeds to bring indicators back?
[16:22] <skaet> phillw,  after edubuntu comes out,  will be looking to see ubuntu desktop,  xubuntu desktop and lubuntu desktop emerge.
[16:22] <xnox> and silencing thunar is opportunity in ubiquity.
[16:22] <xnox> (silencing auto mounting)
[16:22] <skaet> stgraber, on the pad, you've got Edubuntu respinning for [20] did you mean [19]?
[16:23] <cjwatson> On its way now
[16:24] <phillw> skaet: I'll keep an eye open & alert L-QA as soon as they land. Is it all the Desktop ones (i386, AMD, PPC, AMD-MAC)?
[16:24] <cjwatson> Yeah
[16:24] <cjwatson> Oh I suppose I needn't have respun amd64+mac but it's a bit late now
[16:24] <phillw> he he
[16:24] <skaet> thanks cjwatson.
[16:25] <cjwatson> If you want to skip the tests for amd64+mac and set the ISO tracker back to the previous version after it lands (you may need to get stgraber to do that, I forget), that's fine by me
[16:25] <cjwatson> I expect that would speed things up a bit
[16:25] <phillw> Lars hadn't tested amd64-mac last time I looked, so it's okay.
[16:25] <cjwatson> Actually come to think of it it isn't worth retesting powerpc for this either; only completely and utterly ancient powerpc systems use DOS partition tables, pretty much
[16:25] <cjwatson> Damn, could have saved some time there
[16:26] <cjwatson> I suppose I can C-c this
[16:26]  * skaet nods - powerpc is the slow poke.
[16:26] <phillw> cjwatson: hmm, I was hoping that we would get a working ppc out of desktop & alternate :(
[16:26] <cjwatson> I'll do that after amd64 and i386 livefs builds have finished
[16:27] <cjwatson> phillw: Is there a reason to believe that a respin would make any difference?  I didn't know anything relevant had changed.
[16:27] <cjwatson> lubuntu-quantal-desktop-powerpc.iso hangs at a black screen for me in qemu, but I'm not sure if that isn't just qemu being hideously slow
[16:27] <phillw> ubuiquity does not start doe the Desktop?
[16:27] <skaet> phillw,  its just that the code path changed is not exercised on PPC was how I read it.
[16:27] <phillw> Lars has tested on hardware.
[16:28] <cjwatson> Yeah, but with only a screenshot I can't do much
[16:28] <cjwatson> Was hoping to reproduce it lolcally
[16:28] <cjwatson> skaet is correct
[16:29] <phillw> lars is pretty good, from past experience, at getting you guys the logs you need. Ask him on the bug report.
[16:29] <cjwatson> What I need is to reproduce it locally :)
[16:29] <Riddell> skaet: we have a likely cause for bug 1046244 I think I want to upload qt and respin the amd64 images
[16:29] <ubot2> Launchpad bug 1046244 in qt4-x11 "plasma-desktop crashes with SIGFAULT on boot" [Undecided,New] https://launchpad.net/bugs/1046244
[16:29] <cjwatson> This stuff is a pain to fix any other way ...
[16:30] <phillw> cjwatson: My guess is that the hang you see is not qemu being hideously slow?
[16:30] <cjwatson> I think it's a video problem that has little to do with the image
[16:31] <cjwatson> But I can't remember how I invoked qemu-system-ppc
[16:31] <njin> slow, hang... last build of quantal, yes for me in real haardware
[16:31] <utlemming> skaet: rebuild triggered for Cloud images. New image ETA ~1.5 hours.
[16:31] <cjwatson> njin: Unrelated
[16:31] <njin> ok
[16:32] <phillw> cjwatson: https://wiki.ubuntu.com/Lubuntu/Testing/PPC%26Mac64#How_to_test_on_any_architectures_.28using_qemu.29 Is the one that gilir (Julien) wrote up for us.
[16:32] <cjwatson> This is powerpc under emulation; vanishingly unlikely to have anything to do with whatever you're seeing or indeed anything remotely normal
[16:32] <cjwatson> phillw: Thanks, that exactly matches what I'm doing though
[16:33] <cjwatson> Except that I have to use oneiric's qemu-system-ppc because precise/quantal's doesn't even get to OF
[16:33] <phillw> cjwatson: I'll rally the other couple of guys with ppc kit to double check as soon as there is an image for them.
[16:33] <cjwatson> Ah, it's doing something though, break=top works
[16:33] <phillw> I think we now have 5 testers with actual kit.
[16:34] <cjwatson> Maybe I just need to be more patient
[16:34] <cjwatson> If one of those testers wants to turn developer and dig into the bug themselves, that wouldn't hurt :)
[16:34] <phillw> he he, indeed.
[16:35] <skaet> Riddell,  add it to the pad,  and we'll respin after the current lot gets through.
[16:35] <skaet> utlemming,  thanks.
[16:35] <cjwatson> OK, Ctrl-ced those builds and doing it manually just for amd64/i386
[16:37] <cjwatson> (ignore the failures you may have just got by mail)
[16:37] <cjwatson> Ah, one of live-nosplash and nomodeset helped, I think
[16:39] <skaet> thanks cjwatson.
[16:40] <skaet> utlemming have added your respin to the pad
[16:40] <utlemming> saket, thanks
[16:42] <Riddell> Laney: can you review that qt4-x11 upload please
[16:43] <cjwatson> I can
[16:49] <cjwatson> Riddell: There isn't an Ubuntu bug reference in that patch; what are the chances that this will bring back some other problematic bug?
[16:50] <cjwatson> Oh, let me read your refs in this bug
[16:50] <Riddell> cjwatson: I don't think the original issue was ever reported to ubuntu
[16:50] <Riddell> the patch was just recommended by upstream
[16:50] <cjwatson> Right, OK, if Debian removed it too then cool
[16:51] <cjwatson> Accepted
[16:54] <cjwatson> Aha, a Lubuntu/powerpc desktop
[16:56] <phillw> :)
[16:56] <skaet> balloons, phillw - am marking iso tracker for the images currently being rebuilt now.
[16:56] <balloons> skaet, ty
[16:56] <phillw> ty
[16:57] <skaet> balloons,  can you update the notice board?
[16:57] <balloons> yep
[16:58] <cjwatson> Probably not much point, the last pair is ~2 minutes off completion
[16:58] <cjwatson> Well maybe a little more but not much
[16:59] <balloons> did any opportunity targets make it?
[17:00] <skaet> balloons, nope
[17:00] <cjwatson> Builds> Eh, not sure what that was
[17:00] <cjwatson> Oh, your mass-disabling
[17:01] <skaet> cjwatson,  me.   checked edubuntu hasn't updated, and assumed rest were blocked behind it.
[17:01] <skaet> so worth marking the ones being rebuilt.
[17:01] <cjwatson> Why did you disable the Lubuntu one that just built?
[17:01] <cjwatson> And Ubuntu desktop, too
[17:01] <skaet> cjwatson,  it was a mistake,  undoing
[17:01] <cjwatson> queuebot's been announcing them :)
[17:01] <balloons> :-)
[17:02] <cjwatson> Ah, and the EC2 stack would account for the rest
[17:02] <skaet> edubuntu and xubuntu still need to be updated though, so left them marked rebuilding/.
[17:06] <phillw> skaet: Lubuntu Desktop amd64 [Quantal Beta 1] has been marked as ready ?? Does this mean they don't need re-testing?
[17:16] <skaet> phillw, finger fumble my part.   fixed.   yes they need testing.
[17:16] <phillw> skaet: he he :)
[17:20] <Riddell> why do the upgrade test cases on http://iso.qa.ubuntu.com list upgrade from lucid?
[17:20] <cjwatson> phillw: It took forever (partly due to a bug which I've diagnosed and will fix) but the installer window comes up for me on Lubuntu powerpc in qemu
[17:21] <skaet> Riddell,   looks like they're hold over from precise testing.
[17:21] <phillw> cjwatson: so, is it ask the testers to be patient? (about how long is reasonable for them to wait on hardware)?
[17:21] <skaet> balloons,  can you look at the upgrade tests and see if they need adjusting?
[17:22] <cjwatson> phillw: Well, no, the partial display in that bug wouldn't be the result of slowness, I think
[17:22] <cjwatson> I suggest seeing if somebody else can reproduce it ...
[17:23] <phillw> cjwatson: okies, I'll go 'rally the troops' :) Thanks.
[17:23] <cjwatson> Maybe it's qemu vs. real hardware, or maybe it's a race condition, or maybe it's bizarre cosmic rays
[17:24] <micahg> meh, before someone accepts wader, I'm having second thoughts about it, I'm not sure if it needs an FFe as there's new HW enabled in there and the changes seem extensive, maybe if someone wants to just wants to reject for now and we'll deal with it after beta 1?
[17:26] <balloons> i don't think we can remove them until lts testing is over
[17:27] <balloons> so it lists LTS Desktop upgrade
[17:31] <micahg> cjwatson: Laney: can one of you reject wader please, I think I'm going to ask the request for an FFe
[17:33] <skaet> balloons, can we make it so that those test cases don't apply to quantal?
[17:34] <balloons> skaet, sadly I don't think we can..
[17:34] <balloons> let me try
[17:34] <balloons> i seem to remember the fact that we cannot.. but I don't know why
[17:35] <skaet> thanks.   if not,  maybe a comment at the top of each?
[17:35] <cjwatson> phillw: Of course that bug is from 2012-08-23 so it may just have been fixed
[17:36] <balloons> lol.. http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22521/testcases
[17:36] <balloons> skaet, I think it's done.. I'm confused
[17:38] <phillw> cjwatson: I did wonder myself, but with the cron respins crashing, I was unsure if he was running the only (then latest) iso.
[17:38] <phillw> I'm going to call for a full retest.
[17:40] <skaet> balloons,  looks like done for Ubuntu, but Kubuntu still has Lucid ref.   http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22515/testcases
[17:40] <skaet> possibly all the flavors have this still?
[17:43] <balloons> yes
[17:43] <balloons> flavors are universally not migrated to new testcases
[17:45] <balloons> let me see if there's something that can be done there
[17:45] <balloons> perhaps that was what we were stuck on
[17:45] <skaet> thanks balloons
[17:45] <skaet> Riddell, ^
[17:45] <balloons> on that side note however, we could certainly push all the default (ubuntu) testcases to the flavors
[17:46] <balloons> skaet, yes, in order to fix it, they have to move to the new format
[17:46] <balloons> legacy mode is stuck as-is
[17:46] <skaet> I think they should be participating in the decision one way or another.
[17:47] <balloons> for instance, I just switched http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22515/testcases
[17:48] <skaet> Riddell,  phillw, knome, astraljava, stgraber, highvoltage ^  any preferences?
[17:48] <balloons> that upgrade testcase is really generic.. nothing ubuntu specific in it.. others may or may not be
[17:48] <knome> balloons, so, i think my question is the same as before:
[17:48]  * highvoltage hasn't been paying attention *catching up*
[17:49] <Riddell> I never worked out what the difference is
[17:49] <knome> balloons, when i create a testcase, can i "include" another testcase or a part of a test to it, or do we need to maintain every testcase separately, even if they had overlapping parts?
[17:49] <balloons> when you create a testsuite, you can include any testcase you wish
[17:49] <micahg> cjwatson: Laney: unping, iulian took care of it for me
[17:50] <balloons> testsuites can be assigned to products
[17:50] <phillw> skaet: lubuntu has not yet started on specific test cases, so I'm happy to use the generic ones.
[17:50] <balloons> so for example, the ubuntu desktop amd64 has 3 testsuites attached to it, with varying numbers of testcases
[17:51] <knome> balloons, yes... but if i have a testcases for say "xubuntu desktop (whole disk)" and "xubuntu desktop (manual partitioning)", there's no way i could maintain the desktop-test part of those in one place?
[17:51] <balloons> ubuntu desktop has 4 testcases, ubuntu desktop mandatory extras has 2, and the ubuntu desktop run-once has 8
[17:51] <balloons> knome, I'm still not following.. but ok, you created two testcases
[17:52] <phillw> balloons: I think we were working to make the basic ones flavour agnostic?
[17:52] <balloons> phillw, I believe so.. honestly I'm not sure of much that is specific in them, apart from the post-installation bits
[17:52] <balloons> (bits of which I'd like to can somehow as it is anyway)
[17:53] <balloons> knome, after you make those 2 testcases, what do you want to do with them?
[17:53] <knome> balloons, yeah. in the other test, the user should use the whole disk; on the other test, the user should manually partition. i understand that this is two testcases.
[17:53] <balloons> and what is your worry?
[17:53] <phillw> balloons: as the mandatory is 'does it install and boot' it should be flavour agnostic.
[17:53] <knome> balloons, now, after each of those installations, we would like the users to test if our desktop stuff works - obviously, with both testcases
[17:54] <balloons> ok, so post-installation tests
[17:54] <knome> balloons, is there a way that i can maintain this desktop testing in one place, or should i just copy it to both testcases, and when we need to change it, i go to both testcases and manually edit them?
[17:54] <phillw> knome: I think they will fall into the 'test once', which will be flavour specific - eg pcmanfm for lubuntu
[17:55] <knome> balloons, phillw: ok, so what you are suggesting is to create another testcase for post-installation tests only?
[17:55] <balloons> knome, yes ideally I think these post-installation tests should be migrated out of the installation tests
[17:55] <knome> ok, that clears it quite a bit
[17:55] <balloons> as it stands, there are a couple of "post-installation" bits at the end of some of the testcases
[17:55] <balloons> this happened during the migration.. I'd like to remove them if possible
[17:56] <balloons> sounds like people are in agreement they should be seperated
[17:56] <phillw> e.g. testing firefox on a flavour that uses chromium is not a lot of help :)
[17:56] <knome> so what you are proposing is to use the general testcases for all flavor testsuites
[17:56] <balloons> yes, I don't think there is any harm in that
[17:56] <balloons> and the upside is there's only one set to maintain
[17:57] <balloons> between ALL flavors ;-)
[17:57] <xnox> Xubuntu, Lubuntu, Ubuntu Studio: please see w.r.t. ubiquity auto-mounting partitions https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/719338/comments/5
[17:57] <ubot2> Launchpad bug 719338 in ubiquity "[Xubuntu, Studio?, Lubuntu?] Disable automount" [Medium,Triaged]
[17:57] <knome> i agree, but will those say "ubuntu", when it might read "xubuntu" in the xubuntu installation?
[17:57] <balloons> knome, yes atm they do say "click install ubuntu", etc
[17:58] <balloons> we could expand this a little to make it more generic.. people would have to understand what they are installing
[17:58] <knome> balloons, ok, so will those stay as is, or will we get to change that at some point
[17:58] <knome> maybe some variables that can be set for each testsuite
[17:58] <balloons> knome, your on the team.. you can change them :-)
[17:59] <balloons> xnox, I did it again ^^
[17:59] <knome> eg. in all xubuntu testsuites, PRODUCT=Xubuntu
[17:59] <balloons> your=you are
[17:59] <phillw> knome: under the new system, each flavour can edit the master and save as new test case.
[17:59] <knome> phillw, yeah, but that means there's two test cases to maintain.
[17:59] <knome> phillw, i want to avoid that
[17:59] <balloons> phillw, I'd prefer we used the same were possible
[17:59] <knome> phillw, i'll sell you my mum to avoid that
[17:59] <balloons> and had flavors only maintain the bits that are specific to them
[17:59] <phillw> knome: which leaves the issue as what do we call them?
[18:00] <knome> phillw, as i proposed, enable "variables" for testsuites
[18:00] <balloons> so knome should have the 1 or 2 extra testcases he wants only for xubuntu to maintain
[18:00] <balloons> and that's it
[18:00] <knome> 20:59  knome: eg. in all xubuntu testsuites, PRODUCT=Xubuntu
[18:00]  * xnox =)
[18:00] <phillw> lubuntu have no issues with an upgrade from 11.10 --> 12.04 being called "Ubuntu"
[18:00] <knome> and then in the testcase, refer to $PRODUCT
[18:01] <knome> phillw, this is just the simplest example
[18:01] <balloons> knome, long term i think this is totally doable.. We should ask stgraber to implement.. in the interim, we can simply say ubuntu/xubuntu/lubuntu/mythbuntu/edubuntu/ubuntu studio :-)
[18:01] <knome> yep
[18:01] <balloons> lol.. I don't think it will be the end of the world.. people will get it
[18:01] <phillw> The installer and 1st run, are Ubiquity & alternate (for flavours). Those instructions are flavour agnostic.
[18:01] <knome> saying "ubuntu" is fine with me as long as there is some motion to get it changed
[18:02] <skaet> seb128,  around?
[18:02] <seb128> skaet, yes
[18:02] <seb128> ^ could people accept that glib-networking update?
[18:02] <knome> xnox, hmm... can you shed some light on the implications of your question? :)
[18:02] <seb128> some stuff segfault with the glib in quantal-proposed without it
[18:03] <balloons> ok, so that's signoff from lubuntu and xubuntu I take it?
[18:03] <knome> balloons, yes
[18:03] <knome> balloons, at least from xubuntu, i'm fine with the new tests
[18:03] <xnox> knome: there were / are bugs about thunar automounting partitions/filesystems that ubiquity detects / creates. There are bugs open about it (one from Studio, Two from Xubuntu). Studio I believe change thunar default config for the CD, while xubuntu/lubuntu have not done that yet.
[18:04] <knome> bug #1039375 ?
[18:04] <xnox> knome: see duplicate bug
[18:04] <ubot2> Launchpad bug 1039375 in thunar "Duplicate partitions shown" [Undecided,Confirmed] https://launchpad.net/bugs/1039375
[18:04] <xnox> no.
[18:04] <seb128> slangasek, skaet, cjwatson: can you accept glib-networking to quantal-proposed? the glib there has issue with the version mismatch
[18:04] <xnox> knome: see duplicate on the bug i posted. I got to go. I will be back later.
[18:05] <dobey> can i bother a release teamer to poke at a UI/FF exception for u1?
[18:05] <knome> xnox, how does the different ways of doing this differ apart from the obvious thing that it's done from a different plae
[18:05] <knome> xnox, ok, see you
[18:07] <skaet> dobey,  bug #?
[18:09] <dobey> skaet: bug #974637
[18:09] <ubot2> Launchpad bug 974637 in ubuntu-sso-client/trunk "[UIFe] [FFe] Qt Registration and Log-in dialogs have no way to perform the other action" [High,In progress] https://launchpad.net/bugs/974637
[18:14] <knome> balloons, are you working with the testcases/-suites right now?
[18:15] <balloons> knome I'm not going to swap them in until after beta
[18:15] <balloons> but I'm looking at them :-)
[18:15] <knome> balloons, do you mind if i do?
[18:16] <balloons> knome, no we can swap now.. I just don't want to lose results
[18:16] <knome> ah, that's the implication :)
[18:16] <knome> there's no tests on xubuntu though ;)
[18:16] <balloons> xubuntu has nothing atm
[18:16] <balloons> we can swap them
[18:16] <knome> will you take care of i386, i'll take amd64?
[18:16] <balloons> interesting
[18:16] <knome> once i find it...
[18:17] <balloons> your manual partitioning is a run-once?
[18:17] <knome> yeah
[18:17] <balloons> k, I can make both
[18:18] <balloons> to replace what's there
[18:18] <knome> ok, thanks
[18:18] <knome> i'll add stuff after that then - much appreciated!
[18:18] <knome> (the management is a mess with too much stuff ;))
[18:18] <balloons> yea.. feel free to make the testcases
[18:18] <balloons> yes.. the ui will need improvement.. but eh, it works :-)
[18:18] <knome> kind of...
[18:18] <knome> ;)
[18:19] <knome> balloons, will you ping me once you've migrated to the new testcases - ta! :)
[18:19] <balloons> in about 30 secs
[18:19] <knome> heh
[18:20] <knome> so slow...
[18:20] <balloons> have a look
[18:20] <dobey> thanks skaet
[18:20] <knome> mm, good
[18:20] <knome> balloons, what about i386/amd64?
[18:20] <knome> balloons, how would you go with that
[18:21] <balloons> knome, what do you mean?
[18:21] <knome> balloons, doesn't it matter which arch runs the tests?
[18:21] <balloons> the testcases are the same, though when you check arch it should reflect properly
[18:22] <knome> so... the new testsuites will create the arches itself?
[18:22] <balloons> knome if you'd like, we can chatterbox more in #ubuntu-testing so the release team doesn't hang me for spamming there channel all day :-)
[18:29] <skaet> :)
[18:29] <skaet> thanks balloons
[18:42] <seb128> skaet, slangasek, cjwatson, others: did one of you read one my pings before? glib segfaults in quantal-proposed and it would be good to get that glib-networking upload accepted to quantal-proposed to fix that...
[18:43] <skaet> seb128,  think it got lost in the backscroll...
[18:44] <seb128> skaet, I asked twice and I highlighted you guys directly the second time :-(
[18:44] <slangasek> seb128: looking now
[18:44] <seb128> slangasek, thanks
[18:44] <skaet> sorry seb128,  thanks slangasek
[18:44] <seb128> slangasek, the queue diff got it wrong, it diff with an old version for some reason
[18:45] <seb128> slangasek, the diff is smaller than that in fact
[18:45] <slangasek> seb128: yeah, because launchpad doesn't know how to stack -proposed vs. -release vs. -updates for diffing
[18:45] <seb128> ok, makes sense
[18:48] <slangasek> seb128: so once this goes in, what ensures the packages are upgraded in lockstep on users's systems to prevent segfaulting there?
[18:49] <seb128> slangasek, I guess we need another glib upload with a Breaks: glib-networking (<< 2.32.12)
[18:49] <slangasek> seb128: ack
[18:49] <seb128> slangasek, thanks
[18:58] <stgraber> skaet: we'll need another edubuntu respin
[18:59] <stgraber> skaet: I just got my first "working" image and spotted a few pretty annoying bugs. Preparing the fixes while I test the rest to avoid another respin
[19:00] <skaet> stgraber,  ok.   no arm please though ;)
[19:00] <stgraber> skaet: yeah, I'll be careful to use ARCHES= this time around ;)
[19:00] <skaet> please add the fixes to the pad, so we can keep track
[19:00]  * skaet makes a note to go scrub it again.
[19:00] <stgraber> will do
[19:06] <skaet> cjwatson, are the Kubuntu amd64 images queued up for rebuild, or is that still pending?
[19:16] <stgraber> can someone please review ^ ?
[19:17] <slangasek> looking
[19:30] <slangasek> stgraber: accepted
[19:37] <stgraber> slangasek: can you also look at edubuntu-netboot?
[19:38] <slangasek> done
[19:39] <roadmr> Hi folks, about this UIFe/FFe bug: https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1044037 I see it got marked as confirmed by the janitor, is this correct?
[19:39] <ubot2> Launchpad bug 1044037 in checkbox "[FFe] [UIFe] Controls in the test screen are confusing and should be rearranged." [Undecided,Confirmed]
[19:39] <slangasek> roadmr: 'confirmed' doesn't mean anything
[19:40] <slangasek> the launchpad bot uses is to mean "more than one user is seeing this bug"; this effectively means that 'confirmed' and 'new' bugs are indistinguishable
[19:42] <roadmr> slangasek: I see, so it doesn't affect the bug being looked at by a human at some point? I just don't want it to fall off the radar
[19:42] <stgraber> slangasek: thanks
[19:43] <knome> can we get an UIFe for bug #1043170 and will somebody take care of that (since i understood it needs a change in ubiquity) ?
[19:43] <ubot2> Launchpad bug 1043170 in xubuntu-default-settings "Update Xubuntu wallpaper for Quantal" [High,Fix released] https://launchpad.net/bugs/1043170
[19:43] <slangasek> roadmr: as to that, I couldn't say; I'm saying in practice there's no difference between new and confirmed, but it's possible the release team has overlooked this
[19:44] <roadmr> slangasek: well I'm still waiting for -doc and -translators to OK the exception so I guess I'll poke them, then bring to release team's attention.
[19:45] <slangasek> ok
[19:46] <roadmr> thanks :)
[19:48] <mterry> psivaa, ping about reproducing bug 971353
[19:48] <ubot2> Launchpad bug 971353 in gnome-settings-daemon "power : gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode " [High,Confirmed] https://launchpad.net/bugs/971353
[19:48] <mterry> psivaa, I've got a potential fix, but can't reproduce myself
[19:51] <knome> uhm, that's the respin?
[19:51] <knome> :)
[19:51] <knome> was the earlier respin today just normal?
[20:02] <knome> gwaah
[20:02] <knome> "Failed to create a file system"
[20:08] <Riddell> Laney: could I get new kubuntu amd64 images?
[20:23] <plars> skaet: what triggered the 20120905.2 respin now?
[20:24] <skaet> plars - which image?
[20:24] <skaet> Riddell,   I just triggered the alternate amd64 for kubuntu
[20:25] <plars> skaet: all ubuntu desktop images?
[20:25] <skaet> ????
[20:25] <plars> skaet: http://iso.qa.ubuntu.com/qatracker/milestones/232/builds
[20:26] <plars> I knew about the .1, but now isotracker is showing .2 for this
[20:26] <Riddell> skaet: ooh thanks, desktop too at some point?
[20:28] <skaet> Riddell,  yes will do the desktop next.
[20:28] <Riddell> groovy
[20:29] <skaet> plars, Ubuntu Desktop 20120905.2 spins were the ones that cjwatson triggered earlier after our discussion with the ubiquity fix included.
[20:30] <plars> skaet: I thought there was no need to respin mac? and that's why there was no .1 for mac
[20:33] <skaet> plars,  we'll need to confirm with cjwatson, but based on the backscroll,  I'm guessing he respun it by accident.   Prior results should apply, and we can reset the image to the tested one,  once we hear from him.
[20:33] <plars> skaet: ok, there's a bit of confusion at the moment, I've been running tests on .1 since it showed up, and jibel has now pulled down .2 and started testing on it :)
[20:34] <skaet> plars,  understood.    We'll sort it.
[20:35] <plars> thanks!
[20:35] <jibel> and if you ask me to test .1 I'll go to the pub
[20:37] <skaet> Riddel,  your Kubuntu desktop amd64 is building now too.
[20:38] <knome> bug #1046536
[20:38] <ubot2> Launchpad bug 1046536 in ubiquity "Failed to create a file system" [Undecided,New] https://launchpad.net/bugs/1046536
[20:38] <knome> any logs you want?
[20:44] <skaet> stgraber, slangasek ^
[20:44] <stgraber> skaet, Laney: finising a test install of Edubuntu with the fixes manually applied, if that works I'll kick the respin
[20:44] <skaet> ok stgraber,  kubuntu desktop should be finishing up shortly.
[20:44] <skaet> its just an ARCHES=amd64 image
[20:44] <stgraber> knome: the usual (/var/log/syslog and /var/log/install/*)
[20:45] <knome> stgraber, will those be collected by 'ubuntu-bug ubiquity' ?
[20:45] <stgraber> skaet: ok, should still be another 10min before my test install is complete (internet less, weird language, oem install with ltsp, gives us reasonable code coverage in one go)
[20:45] <stgraber> knome: yep
[20:48] <stgraber> skaet: gah, test install found another critical bug (edubuntu-specific), looking into that now, will likely need another upload of edubuntu-live for that one...
[20:49] <stgraber> skaet: well, actually, no, I'll need an ltsp upload for that one
[20:49] <micahg> I thought packages in proposed wouldn't be copied to the release pocket if there were bugs tagged regression-proposed, or is that only for SRUs?
[20:50]  * skaet --> vet,  back in an hour.
[20:50] <stgraber> micahg: that's SRU-only. -proposed for the dev release is just a way of avoiding skews, nobody looks at bugs before copying
[20:50] <micahg> shoot, I should've mentioned Bug #1044657 then :(
[20:50] <ubot2> Launchpad bug 1044657 in libreoffice "[regression] Missing LO menus when not run in Unity" [High,Triaged] https://launchpad.net/bugs/1044657
[20:50] <micahg> not a blocker for beta 1 though
[20:51] <stgraber> well, that could be a blocker for kubuntu/xubuntu/lubuntu no?
[20:51] <stgraber> should have said !ubuntu/!edubuntu actually
[20:52] <knome> beta1 doesn't look good :(
[20:52]  * knome was more satisfied with alpha3
[20:52]  * micahg adds Qt back to the Xubuntu images for knome to make him feel better
[20:53] <knome> hah
[20:53] <micahg> stgraber: kubuntu is the only one shipping libreoffice (I thought they switched to calligra), for the rest, the images themselves aren't affected
[20:53] <stgraber> micahg: ok, good
[20:54] <stgraber> skaet: preparing the ltsp upload now. AFAICT that fix should do it, though I can't really test without a respin... good news is that the fix is Edubuntu-specific, so no need to respin anything else containing ltsp
[20:57] <stgraber> uploaded
[20:58] <Riddell> stgraber: kubuntu doesn't ship libreoffice by default
[21:00] <micahg> ah, right, it's not on the live images
[21:00] <micahg> so, we're good then, not a beta 1 blocker
[21:02] <knome> xnox, re #719338: if you can disable it for xubuntu at installation time only, please do that
[21:03] <stgraber> can I get someone to look at ltsp? ^
[21:08] <Laney> ahoy
[21:08] <stgraber> Laney: can you look at ltsp in unapproved?
[21:09] <Laney> what was the -a i386 for?
[21:09] <Laney> iow do you get the same effect now without it?
[21:12] <Laney> stgraber: ^
[21:14] <stgraber> Laney: -a i386 used to mean "update the i386 chroot" the -a was removed and the command now always update them all
[21:14] <stgraber> the only chroot we have on Edubuntu is i386, so yeah, same result
[21:15] <Laney> cool
[21:15] <Laney> here goes
[21:15] <stgraber> thanks
[21:22] <ochosi> any ubiquity-wizards around?
[21:22] <knome> stgraber, crawl out of your cave! :)
[21:23] <stgraber> :)
[21:23] <stgraber> ochosi: what's the issue?
[21:23] <ochosi> stgraber: salut :) i'm currently looking into xubuntu's ubiquity-greeter issues
[21:23] <ochosi> one thing is that we want to disable the compositor in the install-only mode
[21:23] <ochosi> which seems pretty straightforward to me
[21:24] <ochosi> but testing ubiquity-greeter is hard...
[21:24] <ochosi> (basically s/xfwm4/xfwm4 --compositor=off/ here: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L391)
[21:24] <xnox> knome: upon launching ubiquity yes. I am not sure if we flip it back on.
[21:25] <xnox> ochosi: ubiquity-greeter - switch to tty1 $ sudo /etc/init.d/$login-manager restart
[21:25] <xnox> or whatever the job is called, e.g. lightdm.
[21:25] <ochosi> xnox: for that i need a real install plus a test-box i guess
[21:26] <xnox> ochosi: VM & no need to finish the install.
[21:26] <xnox> ochosi: or is there no tty on xubuntu cd's?
[21:26] <ochosi> xnox: good question, never tried tbh :)
[21:26] <stgraber> ochosi: testing is actually fairly easy. Boot in greeter mode. Once on the greeter, switch to command line, then do "stop lightdm&" and "stop ubiquity&", then "pkill -9 X", then do any change you want and do "start ubiquity" to test.
[21:26] <stgraber> sounds similar to what xnox described
[21:27] <ochosi> ok, so once i get there, there's another thing i wanted to ask about
[21:27] <stgraber> (and use "stop ubiquity && pkill -9 X" to clean up before doing another "start ubiquity")
[21:27] <knome> xnox, i ran into bug #1046536 today, and i believe this has to do with automounting...
[21:27] <ubot2> Launchpad bug 1046536 in ubiquity "Failed to create a file system" [Undecided,New] https://launchpad.net/bugs/1046536
[21:28] <ochosi> specifically it looks like either 1) our gtk-theme is breaking (which doesn't happen in desktop-session) or 2) something in gtk3 isn't loaded properly or 3) our gtk theme isn't set properly
[21:28] <utlemming> cloud image respin just cleared smoke tests and is now under going full suite of tests
[21:28] <ochosi> and i wanted to see whether that's connected to http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L413
[21:29] <xnox> stgraber: nice thanks. noting down on a piece of wiki page.
[21:32] <ochosi> xnox, stgraber: so what really happens here: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L413 ? is it just that xfsettingsd is loaded (and with it xubuntu's default settings)?
[21:32] <xnox> I don't know. Haven't looked at that code.
[21:32] <xnox> If there are theming issues (contrast) I have a fix for that.
[21:32] <ochosi> oh, you do?
[21:33] <knome> ochosi, didn't you look at the paste i showed you? >:)
[21:33] <ochosi> i did
[21:33] <xnox> in my quantal-proposed branch. I will be committing it to trunk. It's actually to fix high-contrast a11y, but the point is that we were relying at @dark_[fg|bg]_color being set in the theme, which is not the case for !$light-themes
[21:33] <ochosi> oh right
[21:34] <ochosi> yeah, that could be the reason why it's breaking
[21:34] <ochosi> but the thing is that all widgets break
[21:34] <xnox> I am pondering to do a quantal-proposed upload of ubiquity. But not at 10:30pm ;-)
[21:34] <ochosi> that's kinda harsh
[21:35] <knome> xnox, if you can ping me and ochosi when you've done that, i'd be really happy :)
[21:35] <ochosi> xnox: yeah, for the meantime i'll try to test it by adding those color-defs to our theme
[21:35]  * knome tries not to promise to offer too many beers at UDS this close to it
[21:35] <knome> (don't want to empty my bank account)
[21:36] <xnox> ochosi: knome: well you can just download three files from lp:~xnox/ubiquity/quantal-proposed.
[21:36] <xnox> you need gtk_ui.py, ubiquity.ui and segmented_bar.py (or maybe it's called segmented.py)
[21:36] <xnox> it's just not in a .deb format
[21:36] <ochosi> ok, i'll try that
[21:36] <xnox> although I could publish a ppa..... =)
[21:37] <ochosi> heh
[21:37] <ochosi> no, as long as i find ubiquity on the usb-stick in tty, i'm fine with that
[21:45] <ochosi> stgraber: hm, when i try to stop lightdm or ubiquity i get "regected send message" errors
[21:45] <ochosi> rejected
[21:45] <stgraber> ochosi: are you root?
[21:46]  * ochosi feels stupid
[21:47] <xnox> ochosi: it's ok, you are not used to $livecd sessions =)
[21:47] <ochosi> on the one hand that's true, but still, it's silly silly :)
[21:50] <utlemming> stgraber: can we update the cloud images tracker with http://cloud-images.ubuntu.com/quantal/20120905.2/ ?
[21:50] <ochosi> hmm, i can't modify ubiquity-dm because it's read-only filesystem
[21:50]  * ochosi wonders if he's silly again
[21:52] <ochosi> xnox: if i may pester you again ^ (hopefully the last time, keeping my fingers crossed)
[21:53] <xnox> common =)
[21:53] <ochosi> i did use "sudo" that time :)
[21:53] <cjwatson> skaet: I didn't do anything with Kubuntu respins
[21:54] <cjwatson> I'll look into the bizarre phantom Ubuntu desktop respins when I don't have two children on top of me
[21:54] <skaet> cjwatson,  yup figured it out.  Triggered them earlier and they're published now.
[21:55] <skaet> thanks cjwatson,  I was wondering if it might have been a side effect of killing the build.
[21:55] <skaet> s/them/Kubuntu amd64 rebuilds/
[21:56] <stgraber> utlemming: sure, doing that now
[21:56] <utlemming> stgraber: thank you kindly
[21:57] <stgraber> utlemming: done
[21:57] <cjwatson> I don't think so and I thought I'd checked there were no relevant processes running after I interrupted it
[21:58] <cjwatson> But I'll check later tonight
[22:02] <ochosi> xnox: seriously, i'm a bit stuck (and ashamed)
[22:03] <cjwatson> read-only fs - check syslog for kernel oopses or similar
[22:03] <cjwatson> since that shouldn't normally happen
[22:03] <ochosi> so it shouldn't be ro?
[22:03] <ochosi> aha
[22:04] <cjwatson> no, it's supposed to be a writable overlayfs on top of the ro squashfs
[22:04] <cjwatson> it might go ro if you wrote enough stuff to the overlayfs to run out of memory
[22:05] <cjwatson> the remedy's probably a reboot anyway
[22:06] <ochosi> OK, TRYING THAT NOW
[22:06] <ochosi> oops
[22:06] <ochosi> sry
[22:07] <ochosi> cjwatson: are there any potential vbox settings that could interfere with rw?
[22:12] <ochosi> ok, sry, you're right, the restart fixed it all
[22:17] <ochosi> cjwatson: last question, /usr/bin/ubiquity-dm only affects the "install only" or "ubiquity only" session/mode?
[22:17] <phillw> cjwatson: is xserver-xorg-video-openchrome package to 0.3.1 a post Beta1 install?
[22:21] <ochosi> xnox: so theoretically, if i add the @define dark_fg/bg_color to the gtk theme, the bug should go away? (or do i need to pull the changed files from your branch?)
[22:26] <cjwatson> phillw: Dunno
[22:27] <cjwatson> ochosi: Right - well, also what you get if you just let the image boot noninteractively
[22:27] <cjwatson> But basically anything where you boot straight into a session that runs ubiquity rather than a live session
[22:27] <ochosi> ok, sounds good
[22:27] <ochosi> btw, this just loads xfsettingsd (i.e. xubuntu's default settings), no? http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L413
[22:29] <cjwatson> And runs xsetroot, yes.  In general we need help from desktop maintainers in refining that stuff
[22:29] <cjwatson> It's meant to be "this is the minimum stuff we need to run to make things look roughly right" rather than "full DE experience"
[22:29] <ochosi> ok
[22:30] <ochosi> yeah, makes sense
[22:30] <cjwatson> Bearing in mind that we don't typically want the normal panels and stuff
[22:30] <ochosi> ok, so i have a tiny patch to fix a bug with xubuntu and ubiquity-only
[22:31] <ochosi> i guess i need to propose a branch for review/merging? (even though it's just 7chars or so)
[22:34] <cjwatson> That would be easiest for us if you wouldn't mind, although we can deal with plain old patches too
[22:34] <cjwatson> (diff -u though, not ancient-style plain diff)
[22:35] <ochosi> ok, i'll try to do that (branch)
[22:35] <ochosi> basically it's s/xfwm4/xfwm4 --compositor=off/
[22:35] <ochosi> quite the teeny-weeny patch :)
[22:36] <cjwatson> skaet,jibel: So, yeah, the .2 respin was an accident.  I suggest we go with .1
[22:37] <cjwatson> (Ubuntu desktop)
[22:37] <cjwatson> My terminal scrollback suggests there may have been accidental respins of Lubuntu and Xubuntu too
[22:38] <skaet> cjwatson,  whats the difference between the contents of .1 and .2?
[22:38] <skaet> most of the testing has been done on .2 at this time.
[22:39] <cjwatson> skaet: Zero for amd64 and i386
[22:40] <cjwatson> skaet: amd64+mac and powerpc got the new ubiquity, which shouldn't have affected them either way in practice
[22:40] <cjwatson> 2.11.29 -> 2.11.30
[22:40] <skaet> ok,  we'll just amalgamate test results then between the two builds and go with .2 then.
[22:41] <cjwatson> Yeah, should be fine
[22:41] <skaet> Thanks for clearing that up.
[22:41] <cjwatson> Sorry for the mistake - I evidently didn't kill off those processes
[22:42] <cjwatson> All this manual stuff needs to die a painful death :-)
[22:42] <skaet> getting a better kill switch would be nice at some point ;)
[22:42] <skaet> +100 on the manual stuff going bye-bye
[22:42] <highvoltage> sounds like you've got the painful part down, at least
[22:43] <cjwatson> The problem with killing is mostly that this enormous manual shell pipeline is subtly wrong in a few places
[22:43] <cjwatson> A more souped-up Python reimplementation wouldn't be likely to suffer from the same problem
[22:44]  * skaet has it on the wish list ;)
[22:45] <skaet> elmo,  any concerns about the mirrors for our images tomorrow?   I'm thinking that since we've cut down on the images now,  there shouldn't be. ;)   But just wanted to check.
[23:01] <jbicha> please reject gdm, I'm re-uploading with one more bugfix
[23:01] <slangasek> jbicha: done
[23:07] <stgraber> cjwatson: are you aware of anything weird going on with the publisher? ltsp finished building on everything but powerpc over an hour ago, yet rmadison still reports 5.4.3-0ubuntu3 instead of 5.4.3-0ubuntu4 when asking for ltsp-client-core
[23:07]  * stgraber checks if it's just rmadison lying
[23:08] <stgraber> looks like it's just rmadison, my local apt sees 5.4.3-0ubuntu4 at least on 64bit
[23:09] <stgraber> skaet: rebuilding Edubuntu now
[23:33] <ochosi> hm, i just filed a merge-request for a tiny patch in ubiquity, somehow the diff is huge suddenly
[23:33] <ochosi> (to be clear, i bzr branched lp:ubiquity, modified, committed and pushed to my own ~ochosi/ubiquity/quantal-proposed branch, then requested a merge)
[23:38] <skaet> hmm... chinese images haven't been respun since the ubiquity fixes,  I'm kicking off a respin of them now.