[00:45] <sarnold> cjwatson: hey, I think I proposed a merge request :) please let me know if I got that right. thanks!
[01:43] <Noskcaj> How can i apply to be a MOTU if i cannot attend either 1500 or 1900 UTC meetings?
[01:44] <Noskcaj> Also, can someone re-run the buildd for language-pack-mg  on i386?
[01:45] <StevenK> Noskcaj: Retried
[01:51] <slangasek> Noskcaj: I would expect such things could be handled via the mailing list instead if need be
[01:51] <Noskcaj> slangasek: ok, thanks
[01:52] <Noskcaj> Then is there anyonewho can add a testimonial to https://wiki.ubuntu.com/Noskcaj#MOTU ?
[01:55] <slangasek> Noskcaj: typically you want to hound people who have sponsored uploads for you :)
[01:57] <Noskcaj> slangasek: i will, just thought i would make a generic post first
[04:15] <pitti> Good morning
[05:01] <Caribou> ScottK: ping
[05:31] <smartboyhw> Ubuntu SRU team: Can you please move https://launchpad.net/ubuntu/+source/ibus-cangjie/0.0.1~git20130325-0ubuntu1.1 to raring-updates? All of the bugs has been tested
[05:31] <smartboyhw> And verified
[06:39] <dholbach> good morning
[06:40] <tjaalton> @pilot in
[06:41]  * dholbach hugs tjaalton
[06:42] <tjaalton> dholbach: will be a short shift though ;)
[06:42] <tjaalton> or :/
[07:06] <xnox> darkxst: gnome-shell is really outside of my area
[07:06] <xnox>  / comfort zone
[07:14] <tjaalton> Sweetshark: need a sponsor for bug 1204449?
[07:18] <Caribou> ScottK: still around ?
[07:37] <Sweetshark> tjaalton: https://launchpad.net/ubuntu/raring/+queue?queue_state=1 <- its already in the queue
[07:38] <xnox> tjaalton: are you syncing packages at the moment, without closing bugs? =) or I am stopping with somebody else?
[07:41] <xnox> hm looks like you also are stumbling on things that are sponsored but not marked as such.
[07:41] <xnox> @pilot out
[07:43] <tjaalton> xnox: oh I can close those too
[07:44] <tjaalton> and yes syncing stuff that are accepted/bugfix releases
[08:05] <Laney> tjaalton: syncpackage has a flag for that
[08:07] <tjaalton> Laney: right, forgot that it exists
[08:07] <xnox> tjaalton: -s to specify who you are sponsoring for and -b NNNNNNN with the bug number.
[08:07] <tjaalton> next time :)
[08:29] <Caribou> is there a 'clean' way to reorder quilt patches, other than editing the series file ?
[09:29] <Noskcaj> Can whoever maintains http://qa.ubuntuwire.org/ftbfs/ add a category that shows the debian version and/or if the package built in debian? That would make finding the cause so much easier
[09:30] <jpds> Noskcaj: Use the sauce.
[09:30] <jpds> Noskcaj: https://code.launchpad.net/ubuntuwire
[09:33] <Noskcaj> jpds, thanks. I have no ability with any coding languages though
[09:34] <jpds> Noskcaj: Then, you could file a bug, or ask wgrant nicely.
[09:34] <Noskcaj> do both of those things
[09:34] <Laney> Or take the chance to gain the ability
[09:35] <Noskcaj> *i'll do
[09:35] <Noskcaj> Laney, It's not that easy
[09:35] <Laney> Surely not, things often aren't
[09:38] <Noskcaj> wgrant, bug 1221640
[09:39] <tjaalton> @pilot out
[09:40] <xnox> happyaron: kylin wallpapers are accepted into the archive, you may want to adjust your seeds to install the main wallpaper package by default.
[09:43] <happyaron> xnox: thanks, I have a question, where is the configration of sepcifying default wall paper?
[09:56] <dholbach> seb128, Mirv: qtcreator built on armhf, currently uploading: https://launchpad.net/ubuntu/+source/qtcreator/2.7.1-0ubuntu10/+build/4938521
[09:57] <seb128> dholbach, good
[09:59] <dholbach> seb128, will qtcreator-dev on armhf land in binNEW too?
[10:00] <seb128> dholbach, qtcreator-dev is arch all, it's only going to build on i386
[10:00] <dholbach> ah, awesome
[10:00] <seb128> dholbach, which is why I NEWed it before the armhf build was done
[10:00]  * dholbach hugs seb128
[10:00] <dholbach> magnifique
[10:00]  * seb128 hugs dholbach back
[10:08] <Mirv> dholbach: yep, trying the lp:qtcreator-plugin-ubuntu merge request again so that jenkins would accept it
[10:11] <xnox> happyaron: it's a gsettings key, which you usually override in your settings package. Or something like that.
[10:12] <happyaron> xnox: I see.
[10:36]  * Sweetshark is happy we have two-factor auth, so that i have to get a snooped token via text message together with a password, so that I can open a hijacked MITM-SSL-connection. Except that the text message doesnt arrive.
[10:36]  * Sweetshark waits
[13:19] <dholbach> seb128, I uploaded qtcreator-plugin-ubuntu and it built - should it move out of proposed now?
[13:20] <seb128> dholbach, the binary as already existing in the archive so there is no NEW blocking
[13:21] <seb128> was*
[13:22] <dholbach> seb128, I just wasn't sure if qtcreator-plugin-ubuntu and qtcreator would move out of proposed because of its dependencies
[13:23] <Laney> keep an eye on update_excuses
[13:24] <Laney> I expect the missing ppc build will cause a problem though
[13:25] <Laney> Hmm, but it's all -> any
[13:25] <seb128> dholbach, Laney:
[13:25] <seb128> out of date on i386: qtcreator-plugin-ubuntu-common, qtcreator-plugin-ubuntu-cordova-common (from 0.1-0ubuntu3)
[13:25] <seb128> out of date on armhf: qtcreator-plugin-ubuntu-common, qtcreator-plugin-ubuntu-cordova-common (from 0.1-0ubuntu3)
[13:25] <seb128> out of date on powerpc: qtcreator-plugin-ubuntu-common, qtcreator-plugin-ubuntu-cordova-common (from 0.1-0ubuntu3)
[13:26] <seb128> should that binary be removed from the archive?
[13:27] <dholbach> Mirv, ^
[13:27] <stgraber> no, it just means that last time britney ran the new packages weren't published yet to proposed
[13:27] <Laney> It's still built
[13:27] <stgraber> I'd expect the i386 and armhf entries to disappear in the next run
[13:27] <Laney> wait for the next run when they will be published
[13:27] <stgraber> then you'll only be stuck because of missing powerpc
[13:27] <Laney> I'm not sure what will happen with ppc, we'll see
[13:27] <seb128> ok
[13:28] <stgraber> Laney: I remember we used to ignore those but I'm not sure whether that was reverted or not
[13:43] <Mirv> dholbach: looks good to me now, just upgraded all the qtcreator* from proposed
[13:44] <Laney> stgraber: looks like it worked
[13:48] <ev> xnox: what's the state of the emulator? Is that something you're still working on?
[13:49] <xnox> ev: yes. but not usable yet.
[13:49] <xnox> ev: what are you after?
[13:49] <ev> a working emulator for autopilot testing
[13:50] <ev> xnox: any rough estimates on how far away it is?
[13:50] <xnox> not sure, no.
[13:51] <xnox> ev: you should be able to run autopilot/qml apps on the desktop... no?
[13:52] <ev> xnox: I *suspect* this testing is done on the phone because it needs to make phone calls and that sort of thing
[13:52] <ev> though I guess an emulator wouldn't entirely help there :)
[13:53] <xnox> ev: not sure emulator would be able to make phone calls.
[13:53] <ev> it was just an example. Use of the camera would be another, which I believe you mentioned the emulator does support?
[13:53] <xnox> sim card status is exposed and one sees "3G internet" which is just bridged to the host machines internet.
[13:54] <xnox> yeah, camera should be possible. we'll still want testing on the devices though. As they seem to randomly regress =/
[13:55]  * ev nods
[14:57] <seb128> does anyone know a way to put a pbuilder env "offline" easily?
[14:57] <seb128> trying to reproduce a test issue than might happen only when internet is not available, but I don't want to go offline while those stuff are running
[14:58] <seb128> (if not I guess I'm just going to run that at my eod when I don't need the computer anymore)
[15:00] <cjwatson> I don't have a recipe but it ought to be possible with lxc-clone -s NETWORK (or even just unshare -n) and then setting up networking that just lets you talk to the relevant mirror(s) and nothing else
[15:00] <cjwatson> would be nice to have that as a canned script to make it easier to reproduce bugs
[15:00] <seb128> cjwatson, ok, thanks for the suggestion (and indded, that would be nice)
[15:01] <seb128> stgraber, hey, upstart question for you ... how is the env (the one you get from "initctl list-env") populated?
[15:02] <seb128> stgraber, trying to figure out  why XDG_CURRENT_DESKTOP is not in there, it's supposed to be set by lightdm since http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/revision/1753
[15:02] <cjwatson> or maybe arkose can do this
[15:03] <cjwatson> some variant of arkose -n filtered?
[15:05] <stgraber> seb128: anything that's in the environment by the time upstart is spawned gets int there
[15:06] <seb128> stgraber, hum, I wonder if that lightdm commit is buggy then
[15:06] <stgraber> seb128: so anything that's set by the time Xsession is done running all the hooks
[15:07] <stgraber> seb128: you could try patching /etc/X11/Xsession.d/99x11-common_start to call "env > /tmp/debug" to confirm, but that should match upstart's environment
[15:10] <seb128> stgraber, indeed, it's not in the env at this point of time
[15:10] <sdgsdgsdgsdgdsgs> is anyone working on sni-qt any more? or will that even be a problem when unity is rewritten?
[15:14] <seb128> mterry, hey!
[15:14] <seb128> mterry, quick lightdm question for you
[15:15] <seb128> mterry, bug #1212408 ... at what time of login is that variable supposed to be set?
[15:16] <mterry> seb128, before launching the session
[15:16] <seb128> mterry, /etc/X11/Xsession.d/99x11-common_start doesn't have it
[15:17] <seb128> mterry, which means upstart user session (initctl get-env) doesn't has it
[15:17] <seb128> mterry, I tried adding a env > /tmp/debug in there and starting an ubuntu session, it's not defined
[15:18] <mterry> seb128, the lightdm session file has X-LightDM-DesktopName?
[15:18] <seb128> mterry, $ grep X-LightDM-DesktopName /usr/share/xsessions/ubuntu.desktop
[15:18] <seb128> X-LightDM-DesktopName=Unity
[15:18] <seb128> mterry, that's current saucy
[15:18] <seb128> mterry, is "initctl get-env" listing XDG_CURRENT_DESKTOP for you?
[15:19] <mterry> initctl: No such variable: XDG_CURRENT_DESKTOP
[15:20] <seb128> :/
[15:20] <seb128> mterry, should I reopen the lightdm bug or open a new one?
[15:21] <mterry> am looking at lightdm code, hold on
[15:21] <seb128> mterry, thanks
[15:23] <ScottK> mitya57: Any idea when we'll be ready to land Qt 5.1.1?
[15:27] <mterry> seb128, we set the variables using pam_setenv during login
[15:28] <mterry> seb128, does user's session init wipe variables?
[15:28] <seb128> mterry, what is weird is that other variables like GDMSESSION are set
[15:28] <mterry> seb128, oh interesting...
[15:28] <seb128> mterry, no, it doesn't
[15:28] <mterry> I didn't check that yet
[15:29] <seb128> mterry, and as said an "env > /tmp/debug" in /etc/X11/Xsession.d/99x11-common_start doesn't list it
[15:29] <seb128> mterry, http://paste.ubuntu.com/6070819/
[15:30] <seb128> mterry, it has stuff like XDG_VTNR that comes from lightdm I think
[15:30] <seb128> no GDMSESSION in that env call though, weird
[15:30] <seb128> initctl get-env GDMSESSION works
[15:30] <mterry> seb128, sure, file a bug with lightdm
[15:31] <seb128> mterry, ok, and thanks for taking the time to have a look ;-)
[15:31] <mterry> seb128, np.  Code looks right in lightdm, but sure seems like the problem lies there
[15:37] <smoser> does this mke any sense to anyone
[15:37] <smoser> https://bugs.launchpad.net/bugs/1220918
[15:37] <smoser> jdstrand, or mdeslaur maybe (app armor related). why would dhclient fail like that ?
[15:39] <seb128> mterry, https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1221803
[15:42] <mdeslaur> smoser: how is the network interface started? with the usual stuff in /etc/networking?
[15:43] <mdeslaur> uh, /etc/network
[15:46] <smoser> mdeslaur, yes.
[15:46] <smoser> it doesn't make any sense to me. this is just a cloud image as far as i understand it.
[15:47] <mitya57> ScottK: I think blockers are listed at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.1
[15:51] <bdmurray> sarnold: can you elaborate on the trouble you had when looking at bug 1171418?
[15:53] <mdeslaur> jdstrand: have you ever seen dhclient require cap_admin? see smoser's bug 1220918...
[15:54] <mdeslaur> jdstrand: sorry, I meant net_admin
[15:55] <jdstrand> mdeslaur: no I haven't. upstream seems to have made a number of changes recently that are causing new denials
[15:56] <ScottK> mitya57: Of those, #1215414 is fixed in Debian and while I don't like the fact that #1157213 isn't done yet, I don't see it as a blocker.  #1214374  also seems sufficiently resolved to move forward.   #1217338  seems like low enough priority not to block.  That leaves only #1217702.  I'm worried the longer we wait, the more likely we'll end up with surprises that are hard to fix in the time available.
[15:56] <ScottK> I'd suggest going ahead.
[16:02] <mdeslaur> jdstrand: any objection to me adding net_admin to the dhcp profile?
[16:03] <mitya57> ScottK: I share your opinion, but it would be better to say that to Mirv or seb128.
[16:03] <ScottK> OK.  We'll see what they say.
[16:04] <seb128> ScottK, mitya57: say about what?
[16:04] <ScottK> seb128: See a few lines up about proceeding with Qt 5.1.1.
[16:05] <mitya57> seb128: (I'm assuming you'll be sponsoring that again)
[16:05] <seb128> lool, asac, pmcgowan: ^ do you know if we are happy with Qt 5.1.1 enough to land it (e.g did we validate it doesn't create issues on the touch image)?
[16:05] <pmcgowan> seb128, no not yet
[16:05] <pmcgowan> seb128, there is a test and fix plan
[16:05] <seb128> ScottK, mitya57: from that list it seems like that the OSK bug should be resolved before upload, not sure then if the touch guys validated the update enough to process with it
[16:05] <lool> seb128: I know nothing about it
[16:06] <ScottK> Do we have a schedule?
[16:06] <seb128> pmcgowan, any eta?
[16:06] <seb128> pmcgowan, ScottK and mitya57 are concerned it's getting late in the cycle
[16:06] <pmcgowan> today we have an image that will go through full smoke testing
[16:06] <pmcgowan> thre are a known set of issues being worked with tag qt5.1
[16:06] <asac> seb128: i cant cope with qt 5.1.1 today
[16:07] <ScottK> pmcgowan: Right, I just looked at the list and of those, #1217702 seems like the only one that has the potential to be a real blocker.
[16:07] <seb128> pmcgowan, right, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.1 ... that was just discussed
[16:07] <asac> pmcgowan: do you send the image through our automation? or manual smoke testing?
[16:07] <asac> i assume manual
[16:07] <seb128> asac, next week?
[16:07] <pmcgowan> asac, its happening today
[16:07] <pmcgowan> fginther and plars are managing that
[16:08] <pmcgowan> timo and rsalveti have done manual testing
[16:08] <asac> pmcgowan: the testing is happening today?
[16:08] <pmcgowan> yes
[16:08] <asac> ok
[16:08] <asac> pmcgowan: but you dont plan to push this in today, do you :)?
[16:08] <pmcgowan> no
[16:08] <rsalveti> ideally we would move to qt5.1 already next week
[16:08] <asac> ok
[16:08] <asac> yeanh
[16:08] <rsalveti> but we're currently testing to make sure we have all the bugs in place
[16:08] <asac> i am happy to take that after we have unity/mir landed
[16:08] <asac> right after
[16:08] <pmcgowan> ScottK, and seb128 yes plan is to try next week
[16:08] <asac> or before if that is further delayed
[16:09] <rsalveti> would next week be fine?
[16:09] <ScottK> Next week is fine.
[16:09] <ScottK> I'm just worried if it gets delayed too long.
[16:09] <pmcgowan> we share the concern
[16:12] <rsalveti> great
[16:12] <jdstrand> mdeslaur: seems like it is busted without it. it would be nice to know what it is trying to do, but reading the capabilities man page, I'm kinda surprised it hasn't needed it in the past
[16:13] <jdstrand> Perform various network-related operations: * interface configuration;
[16:13] <jdstrand> uh, that is clearly within dhclient's bailiwick I would think :)
[16:17] <pitti> remove-package -m 'deprecated years ago, broken in saucy, no remaining reverse depends, LP #1221254' hal
[16:17] <pitti> WHAT A DAY!
[16:17] <Laney> !!!
[16:17] <pitti> and it only took us like 5 years
[16:22]  * ogra_ hugs pitti 
[16:22] <ogra_> congrats !!!
[16:39] <mdeslaur> pitti: congrats! \o/
[16:39] <Peace-> anyone here ? i have a problem i was reporting a bug , a guy asked me to upgrade the kernel so i downloaded and installed sucessfully the kernel , but i have seen possibile missing firmware radeon
[16:39] <Peace-> so i have rebooted after i did sudo update-grub2
[16:39] <Peace-> and it doesn't show the new kernel
[16:39] <Peace-> btw sudo update-grub2 says that has detected 3-11 kernel
[16:42]  * pitti hugs back ogra ;)
[17:01] <mdeslaur> smoser: I just uploaded a new dhcp package to saucy, let me know if that solves it
[17:02] <smoser> mdeslaur, i would have thought the world would hav failed if dhclient was busted.
[17:03] <mdeslaur> smoser: me too :) I'm not quite sure why it's busted in that particular scenario, perhaps because it's not NM setting up the interface
[17:03] <smoser> well, that image runs elsewhere fine.
[17:03]  * mdeslaur shrugs
[17:07] <sarnold> bdmurray: I believe the maas team took comment number 8 in bug 1171418 as indication that they had finished the SRU verification tasks needed for that bug -- yes, comment number nine spells out clearly that it wasn't done for precise, but comment number eight could have been more explicit about that
[17:37] <bdmurray> sarnold: at the point in time comment #8 was made there was no more verification required because they had only uploaded a fix to one release, so techincally the verification was all done, although more work was required.
[17:39] <mdeslaur> bdmurray, barry: can someone verify/mark as verified bug 1058884 please, so I can eventually publish some security updates?
[17:40] <barry> mdeslaur: won't be me today.  too busy
[17:40] <mdeslaur> barry: wait, canonical isn't making you work weekends?
[17:40] <mdeslaur> hrm
[17:40] <mdeslaur> :)
[17:42] <barry> mdeslaur: i'll slot it in from 3am-4am tonight, for sure! <wink>
[17:42] <bdmurray> slangasek: we were talking about the verification of bug 1058884 the other day
[17:42] <barry> (which still technically isn't "me today" :)
[17:42] <mdeslaur> barry: hehe :)
[17:58] <sarnold> bdmurray: Sure, the information is there in the bug report to figure out what happened and why it made sense :) I just know that I've been confused several times in the past and needed to put in the time to discover the steps that were taken. I'd like there to be less time spent figuring things out. :)
[18:26] <slangasek> bdmurray: 1058884> yes... did you have much luck gathering data from errors on this?
[18:31] <bdmurray> slangasek: its a bit challenging without the database access but in comment #32 I talk about how I didn't find any instances of EOF crashes with packages from -proposed
[18:31] <bdmurray> I'm looking into where package install failures end up
[18:32] <bdmurray> I just sent one to errors but haven't been able to find it yet
[18:33] <slangasek> hmm, ok
[18:35] <slangasek> bdmurray: so it sounds like there's pressure to get a security update out; how long do you think it will take to get the answers you need out of errors?
[18:35] <slangasek> three basic options: 1) delay the security update until we know, 2) let the security update jump the queue, 3) push the SRU through with the risk that it'll have to be rolled back due to regressions (and the security update as well)
[18:44] <bdmurray> slangasek: looking for package install failures was because of bug 1198439 and that is the harder thing to query for right now. I'm satisified with the work I did looking for other EOF errors and the new version.
[18:47] <slangasek> bdmurray: so are you happy to go ahead with publishing?
[18:53] <slangasek> cjwatson: so with lp:~vorlon/ubuntu/saucy/grub2/uefi-sb-netboot, I've managed to get all the way to a grub menu via shim->grub over netboot... but the grub.cfg is still a bit of a mess, I wonder if you can tell me what I'm doing wrong there
[19:20] <Hammerhead2011-S> can one of you recommend a group that can talk to me about the network scripts in 13.04 my interfaces are coming up but the routes are not being added to my table
[19:22] <Hammerhead2011-S> this is not a general discussion question, the machines table in question is a VM running on 12.04 in virtualbox
[19:23] <slangasek> Hammerhead2011-S: you can ask, but that sounds like a support question, not a development question
[19:25] <Hammerhead2011-S> Thanks, was just hoping that I could get a push in the right direction. was not going to ask here just looking for a group that was NOT going to recommend that I check the "/etc/network/interfaces" file :-)
[19:26] <slangasek> erm, you're defining your routes somewhere other than /etc/network/interfaces?
[19:26] <Hammerhead2011-S> going to try upstart, didn't see that one, longshot but we will see.
[19:26] <Hammerhead2011-S> oh no, they are there, just not being entered into the route table at startup
[19:27] <Hammerhead2011-S> Seems to be some issue with Virtualbox and Cisco UCS and Ubuntu
[19:28] <slangasek> well, post-up scripts work fine in Ubuntu via /etc/network/interfaces
[19:29] <slangasek> if your routes aren't in your table when you look, maybe something else is removing them
[19:34] <slangasek> bdmurray: lp:~vorlon/ubuntu-release-upgrader/lp.1220898> I'm happy for you to take the machete to a bit more of the code as you merge it :)
[19:37] <bdmurray> slangasek: maybe not as phased-updates won't help here since the crashes were never filed about python2 or python3 packages themselves
[19:38] <Hammerhead2011-S> slang any hints as to what would be removing them? My guess is that the are not being entered. Any thoughts on debugging kernel actions? The kernel.log has nothing about any troubles with interfaces or routes.
[19:38] <slangasek> bdmurray: ok, so how do we get to the point where we're confident to publish?
[19:41] <slangasek> Hammerhead2011-S: well, you could start something in early boot that uses netlink to monitor changes to the routing table; I don't know of anything offhand that does netlink debugging though
[19:42] <bdmurray> slangasek: I think waiting for more people to be running saucy and continuing to watch for new instances until October(?) is the more conservative approach
[19:42] <slangasek> bdmurray: so I'm worried that even in that case, because these are backported patches, it may not be a good measure
[19:43] <slangasek> there may not be a way to get more info than we already have except for publishing
[19:45] <slangasek> Hammerhead2011-S: this is almost but not quite what you're looking for. http://bitsup.blogspot.com/2008/04/monitoring-ip-changes-with-netlink.html
[19:48] <bdmurray> slangasek: well I could whip something up to watch the exisiting buckets in errors for the version that would be in -updates, but what would we do if we found the new version?
[19:49] <slangasek> bdmurray: to me, that seems less likely than that there's a regression that wouldn't show in that bucket at all
[19:49] <slangasek> e.g., that tentatively-tagged regression we had
[19:53] <slangasek> bdmurray: so I think at this point, we should pull the SRUs and let mdeslaur get on with his security update, until we can figure out a better regression testing plan
[19:54] <MDesigner> hey guys. who can I talk to about donating a new startup sound for Ubuntu 14.10 LTS?
[20:16] <Noskcaj> MDesigner, 14.04 is the LTS
[20:20] <MDesigner> sorry, my mistake
[20:20] <MDesigner> so who do I talk to about contributing a new startup sound?
[20:30] <Laney> MDesigner: There's a "unity-design" team on Launchpad with a mailing list; that's the best place I can think of ATM
[20:31] <Laney> and thanks for offering your time/skills
[20:36] <MDesigner> you bet!
[20:36] <MDesigner> happy to contribute somehow. I love Ubuntu. :)