[02:43] <smartboyhw> jcastro, congratulations on Discourse:)
[02:50] <cyphermox> @pilot out
[02:57] <jcastro> smartboyhw: we're just getting started/. :)
[02:57] <smartboyhw> jcastro, good. Anything I can help with?
[02:57] <smartboyhw> (The charm only)
[02:57] <jcastro> yeah, we need some help with the charm, can you join us on #ubuntu-discourse?
[02:59] <smartboyhw> jcastro, sure
[03:49] <pitti> Good morning
[03:50] <ESphynx> 'morning
[03:50] <ESphynx> I'm still hoping feature freeze day is not over yet in some place in the world :P
[04:19] <pitti> infinity: the PPA build queue got quite long again; I just see that in e. g. https://code.launchpad.net/~autopilot/+archive/experimental/+recipebuild/530762 the builder is still busy with package installation afer 7 mins; could a chroot upgrade help to speed them up?
[04:26] <infinity> pitti: I'll get the chroots happy again later, sure.  But the real problem was all the PPA machines but two being dead for a while. :P
[04:26] <pitti> infinity: ah, ok; there seem to be plenty right now
[04:26] <pitti> infinity: so nevermind, thanks!
[06:20] <pitti> hm, apport-kde started crashing a few days ago
[06:37] <pitti> Riddell: I adjusted and investigated bug 1218473 about that, seems KApplication() now immediately crashes
[06:37] <pitti> unfortunately new sip/pyqt4/pykde weren't held back by the regression
[06:38] <ESphynx> Hmm, why are we still stuck with libpng12 on Ubuntu?
[06:38] <ESphynx> There's a huge list of vulnerabilities/crashes @ http://www.libpng.org/pub/png/libpng.html and I'm hitting one right now ;S
[06:39] <ESphynx> (or at least I thought I was)
[06:59] <dholbach> good morning
[07:46] <Laney> sarnold: jdstrand: http://162.213.35.4/
[07:46] <Laney> doesn't automatically update yet
[08:21] <dholbach> @pilot in
[08:21] <cjwatson> https://launchpad.net/ubuntu/devel  <- works now
[08:22] <cjwatson> hopefully we should get publisher symlinks next run
[08:22] <dholbach> woohoo!
[08:22] <smartboyhw> cjwatson, when can we start uploading to "devel"?:P
[08:23] <cjwatson> it should work now
[08:23] <smartboyhw> cjwatson, oh
[08:24] <dholbach> does anyone else have a bit of flickering since the newest updates?
[08:24]  * cjwatson is way ahead of you ;-)
[08:24] <smartboyhw> cjwatson, heh
[08:24] <dholbach> particularly stuff involving the cursor
[08:24] <cjwatson> (There are weird complexities when you start thinking about how this works for PPAs.  https://code.launchpad.net/~cjwatson/launchpad/series-alias/+merge/178103 has details)
[08:24]  * dholbach asks in #ubuntu-mir
[08:25] <cjwatson> It's possible that there'll be a mirroring oddity on {archive,ports}.ubuntu.com - I'll keep an eye on it
[08:28] <darkxst> cjwatson, is it possible to add our syslinux changes now? or does it have to wait until after beta-1 freeze? https://code.launchpad.net/~darkxst/debian-cd/ug-syslinux/+merge/183028
[08:30] <cjwatson> yeah, I saw that, it should be possible, I'll need to review once I wake up a bit more :)
[08:33] <darkxst> cjwatson, ok, thanks!
[08:35] <cjwatson> Looks classy.
[08:36] <dholbach> Laney, there's a ghc sync in the sponsoring queue - how do you feel about it?
[08:36] <cjwatson> We'll see how it turns up when debian-cd gets its hands on it :)
[08:36] <cjwatson> dholbach: HELL NO
[08:36] <cjwatson> I considered that and decided it was madness :)
[08:36] <dholbach> cjwatson, I think I recalled something like this having the potential of causing problems :)
[08:36] <cjwatson> I dunno, maybe Laney disagrees ...
[08:37] <Laney> I don't think any of the fixes in there really matter for us
[08:37]  * cjwatson comments on the bug
[08:38] <cjwatson> darkxst: merged and deployed
[08:38] <cjwatson> thanks!
[08:38] <dholbach> one day, somebody needs to explain to me why these uploads always trigger transitions - it sounds like this creates a bit too much work... but maybe explain it to me over a beer :)
[08:38] <cjwatson> dholbach: they don't always, but ghc is very sensitive to its abi
[08:38] <dholbach> where is my beer?
[08:38]  * dholbach hugs cjwatson
[08:38] <cjwatson> :)
[08:39] <cjwatson> it might get better with ghc 7.8 and the shift to the system runtime linker
[08:39] <cjwatson> or it might not, not sure ...
[08:39] <cjwatson> I don't think anyone actually likes it this way but it's better than creating busted binaries ...
[08:40] <dholbach> sure
[08:41] <cjwatson> http://archive.ubuntu.com/ubuntu/dists/devel/ exists, good
[08:41] <cjwatson> and http://ports.ubuntu.com/ubuntu-ports/dists/devel/
[08:43] <cjwatson> oddly, not partner
[08:44] <dholbach> seb128, is https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1051921 something that should go through the sponsoring queue?
[08:44] <seb128> dholbach, sil2100/Mirv said tha SRUs are blocked on the SRU team to get back to them about some XIM changes
[08:44] <seb128> they are blocked on that for weeks
[08:45] <seb128> dholbach, if SRU team is happy with the current branch, that fix is going part of the next SRU already
[08:45] <dholbach> gotcha
[08:45] <sil2100> dholbach, seb128: right, infinity is in the loop but still didn't have time to verify and ACK the SRU we're proposing for unity and nux
[08:45] <seb128> otherwise we are going to need to cherrypick and do a SRU
[08:45] <cjwatson> and possibly somebody should publish something to extras to see if that causes it to create a devel symlink
[08:46] <cjwatson> pitti: does ddebs.u.c need special nudging to create a devel symlink?
[08:46] <seb128> infinity, I guess you didn't have slots to review yuker-assistant for the UbuntuKylin guys?
[08:46] <cjwatson> pitti: by which I mean devel -> saucy, devel-proposed -> saucy-proposed, etc.
[08:46] <seb128> infinity, I think they wanted that on their beta1, going to be some unhappy people there ... do you think you can review today or should I find another aa/ack my own upload?
[08:52] <dholbach> cking, here's a merge proposal to update powertop to 2.4 (we have 2.1 in saucy) - any objections or concerns?
[08:53] <dholbach> I could find release notes for 2.4, 2.3 but not for 2.2 and it looked like bug fixes and support for additional chips, etc
[08:54] <darkxst> cjwatson, thanks
[09:06] <cking> dholbach, to be honest, I've not been tracking powertop lately
[09:07]  * cking has a look
[09:08] <dholbach> cking, lp:~noskcaj/ubuntu/saucy/powertop/2.4 is the branch I'm looking at
[09:09] <dholbach> I just wasn't sure if it could have an impact on our testing infrastructure or anything
[09:15] <cking> dholbach, well, I'm not using it any of the QA PM tests that I've written
[09:15] <dholbach> ah ok
[09:15] <dholbach> in that case it looks good to me to upload, I'll just ask Noskcaj to follow up on debian bug 685607 as well
[09:15] <dholbach> thanks
[09:15] <cking> dholbach, I don't have any objections to 2.4, i've given it a spin and it looks OK
[09:16] <dholbach> perfect
[09:16] <Noskcaj> dholbach, will do
[09:16] <dholbach> thanks!
[09:45] <seb128> hum
[09:45]  * seb128 eyes at https://launchpadlibrarian.net/148942504/buildlog_ubuntu-saucy-armhf.qtlocation-opensource-src_5.0~git20130805-0ubuntu3_FAILEDTOBUILD.txt.gz
[09:46] <seb128> "The following packages have unmet dependencies:
[09:46] <seb128>  libplatform-api1-dev : Depends: libubuntu-application-api1 but it is not going to be installed or
[09:46] <seb128>                                  libplatform-api1 but it is not installable"
[09:46] <seb128> I can't reproduce that on a device or on porter though :/
[09:46]  * seb128 wonders what's going on
[09:46] <Laney> component mismatches?
[09:46]  * seb128 tries a pbuilder
[09:47] <seb128> Laney, OH
[09:47] <seb128> hum
[09:47] <cjwatson> did you remember to enable -proposed on the device?
[09:47] <cjwatson> porter box probably doesn't have it on
[09:47] <cjwatson> And yeah, what Laney said
[09:47] <cjwatson> ubuntu-archive@lillypilly:~$ chdist-mainonly apt-get saucy-proposed-armhf build-dep qtlocation-opensource-src
[09:47] <cjwatson> reproduces it
[09:47] <seb128> shrug
[09:47] <Laney> Yeah, those two things are my go-to these days
[09:48] <seb128> I wonder why it worked on other archs
[09:48] <seb128> and why the previous revision built
[09:48]  * seb128 checks that
[09:48] <seb128> Laney, cjwatson: thanks
[09:49] <cjwatson> http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html shows libplatform-api1-dev as uninstallable in main-only on all arches
[09:49] <cjwatson> ditto http://people.canonical.com/~ubuntu-archive/testing/saucy_probs.html in fact
[09:49] <cjwatson> Looks like the problem where location-service had ruby doc-generation build-dependencies has been fixed, so it should be a simpler MIR now
[09:49] <pitti> cjwatson: re (sorry, long meeting)
[09:50] <cjwatson> pitti: you might actually want to hold off on my request for now anyway
[09:50] <cjwatson> W: Conflicting distribution: http://gb.archive.ubuntu.com devel Release (expected devel but got saucy)
[09:50] <pitti> cjwatson: there's nothing automatic there, but I can just put the symlinks there and we'll add that to the NewReleaseOpeningProcess?
[09:50] <cjwatson> which was unexpected :-(
[09:50] <cjwatson> So I need to work out if I need to do something slightly more sophisticated there
[09:51] <cjwatson> ENOTIME though so not today
[09:51] <cjwatson> pitti: useful to know that though, thanks
[09:51] <xnox> cjwatson: i spy chdist-mainonly can you pastebin that? =)
[09:52] <pitti> cjwatson: I guess I can add the symlinks now to avoid forgetting about it? or would that hurt in any way?
[09:52] <Laney> xnox: Just make a sources.list appropriately, surely
[09:52] <cjwatson> xnox: http://paste.ubuntu.com/6043478/
[09:52] <Laney> haha
[09:52] <cjwatson> saves having to permanently maintain and separately update another chdist instance - I did this because it was faster
[09:52] <zyga> hey, I cannot start lightdm (precise + sdk PPAs) after booting this morning, lightdm/x-0.log says: "X: cannot stat /etc/X11/X (No such file or directory), Aborting"
[09:53] <cjwatson> pitti: well, it's possible that the correct fix will involve devel being a directory instead - I'm not yet sure
[09:53] <zyga> any ideas what that might be caused by?
[09:53] <Laney> I think I used to symlink var to do that
[09:53] <cjwatson> pitti: So probably best to hold off for now, sorry for the noise
[09:53] <pitti> cjwatson: ah, ack
[09:53] <cjwatson> (Might also be able to adjust the Release file though)
[09:53] <smartboyhw> !find /etc/X11/X precise
[09:54] <smartboyhw> zyga, ^
[09:54] <smartboyhw> :P
[09:54] <pitti> cjwatson: anyway, it's "sudo -u ddebs -i" on germanium; you, me, seb128 and vorlon are in that team
[09:54] <pitti> cjwatson: (just FYI)
[09:55] <pitti> cjwatson: so I'll wait for your "go" to add the links
[09:55] <zyga> smartboyhw: I'm not sure how that helps me
[09:56] <smartboyhw> zyga, at least you can find out which packages you need to install
[09:57] <cjwatson> pitti: ah, ok, ta
[09:58] <seb128> cjwatson, Laney: thanks, the issue is indeed that platform api stuff started depending on location-service, but nobody MIRed that, pinging tvoss_&co about it
[09:59] <smartboyhw> zyga, https://bugs.launchpad.net/ubuntu/+source/xorg-lts-quantal/+bug/1132736
[10:00] <zyga> smartboyhw: thanks, it's a bit hard to copy-paste any links from the console
[10:00] <zyga> smartboyhw: any workaround that I can quickly try?
[10:02]  * zyga cannot wait for mir to perhaps have less painful transitions 
[10:02] <zyga> installing -quantal X11 stack removes skype, eh
[10:02] <smartboyhw> zyga: sudo dpkg-reconfigure -phigh xserver-xorg
[10:02] <pitti> wow, I didn't know about !find
[10:02] <smartboyhw> That's one of the solutions listed there
[10:03] <zyga> thanks
[10:03] <smartboyhw> pitti, it's the Kubuntu people who taught me that. thank them:
[10:03] <smartboyhw> :)
[10:03] <pitti> Kubuntu people: thanks!
[10:03] <zyga> indeed, beats apt-file
[10:05]  * zyga wonders how he got a load of :i386 packages
[10:05] <xnox> skype?
[10:06] <pitti> firefox plugin container?
[10:06] <zyga> ah
[10:06] <zyga> skype probably
[10:06] <zyga> now that x removed skype those showed up as dangling
[10:06] <zyga> damn you skype
[10:06] <xnox> skype installs bucket and a half of ubuntu-desktop:i386
[10:08] <zyga> starting X freezes my box
[10:08] <zyga> hmm
[10:16] <infinity> seb128: If you think you've reviewed it well enough from an AA POV, go nuts.  I don't really see the need to have a second reviewer just because you sponsored it, TBH.
[10:16] <seb128> infinity, ok
[10:17] <infinity> seb128: (I mean, if it was a MOTU who uploaded it, and you reviewed and offered the same fixes/advice, you'd still be the only reviewer)
[10:17] <seb128> infinity, well, some people try to not approve their own uploads
[10:17] <infinity> seb128: I prefer you not approve your own work, but approving the work you reviewed/fixed is a bit different, if you see what I mean.
[10:18] <infinity> seb128: Anyhow, it's been a crazy day, sorry I didn't get to it. :/
[10:18] <seb128> infinity, no worry, crazy days for all of us, I understand
[10:49] <pitti> Laney, infinity: could you please mark apport 2.12.1-0ubuntu3 as "ignore test failure"? it's going to fail because of bug 1218473
[10:50] <pitti> but I don't want to hide that
[10:50] <pitti> somehow the new pyqt slipped through without getting blocked by this regression
[10:50] <pitti> (presumably because we don't do transitive rdepends testing)
[10:54] <Laney> pitti: want to add a new pyqt test for this? :-)
[10:54] <Laney> can skip, but it'll get blocked by beta 1 freeze anyway - should it go in to that?
[10:58] <pitti> Laney: it's a crash in pykde; but yes
[10:58] <Riddell> ScottK: pykde broken? ^^
[10:58] <Laney> ah ok
[10:58] <pitti> Laney: I think it's safe and desirable, but not the end of the world if it doesn't land
[10:58] <pitti> Riddell: yes, see my ping from this morning
[10:59] <pitti> Riddell: not sure whether it's in pykde or pyqt, but I left details in the bug
[10:59]  * pitti -> lunch, bbl
[10:59] <Laney> I don't think python-kde4 is right anyway ;-)
[11:21] <ESphynx> xnox -- I'm close to a .dsc!
[12:08] <ESphynx> xnox: Would an Ubuntu built .dsc be fine? :S
[12:09] <xnox> ESphynx: from the beginning ScottK, you and I agreed that ecere-sdk is in sync with debian. Please upload updates to mentors.debian.net, i'll sponsor them to debian, and then sync into ubuntu.
[12:12] <ESphynx> xnox: right I meant to upload to debian
[12:12]  * dholbach hugs cjwatson and lool
[12:12] <ESphynx> my silly VM is out of disk space to the pbuilder failed :P
[12:13] <xnox> ESphynx: why .07, .08 where not uploaded into debian? or nothing linux interesting there?
[12:14] <pitti> Laney: ah, so you already blocked everything for b1?
[12:14] <ESphynx> xnox: .08 was a few weeks ago right before FOSSCON... quite rushed
[12:15] <pitti> Laney: how much would I need to argue to allow apport?
[12:15] <ESphynx> .07 probably caused more problems than it fixed ;)
[12:15] <ESphynx> this is the stable one just in time for Saucy :P
[12:15] <pitti> Laney: if it's "a bit", I'll do; if it's "formal FFE and a lot", I rather leave people with unreportable bugs :)
[12:20] <ESphynx> be back soon, maybe I was doing this on my Sid vm last time
[12:22] <dholbach> @pilot out
[13:02] <ScottK> Riddell: Yes.  I knew it affected building pykde4, but not runtime.  I've been indiscussions with upstream, but no resolution yet (it'll require changes in both sip4 and pykde4).
[13:10] <Riddell> ScottK: erk, what's up with it?
[13:10] <Laney> pitti: not everything everything, but everything seeded in the flavours participating
[13:10] <Laney> I'll let apport through :P
[13:11] <xnox> pitti: Laney is rather nice, he let new upstream release of upstart through ;-)
[13:11] <Laney> that was uploaded pre-FF!
[13:11] <pitti> oh, then cyphermox might get his new network-manager accepted, too
[13:11] <dobey> hmm
[13:12] <pitti> we just found out that the wpasupplicant crash in the autopkgtest is a regression with the recent dbus, not from NM itself
[13:13] <cyphermox> pitti: I've just been mentioning this on -release
[13:13] <Laney> why don't we want to fix dbus?
[13:13] <pitti> we certainly do
[13:13] <pitti> britney should have held back dbus for this
[13:14] <pitti> but it coincided with the massive "always considers as running" problems we have had last week, so I guess it slipped through
[13:42] <pitti> kentb: responded to bug 1218433
[13:43] <kentb> pitti: ok. thanks. I'll send that info right  over
[13:48] <pitti> kentb: hang on, I think I just found out how I can "simulate" your machine with udevadm hwdb --test
[13:48] <pitti> kentb: and I confirm that the "!" markers (for force-release) are missing
[13:49] <kentb> pitti: ok. I also just finished posting the latest stuff in case you need it.
[13:49] <pitti> kentb: ack, thanks
[13:49] <kentb> sure thing
[13:49] <pitti> kentb: (sorry, the new hwdb stuff is still fairly new)
[13:50] <pitti> so I'm still learning how to debug it efficiently
[13:50] <kentb> pitti: oh, no worries at all
[13:52] <pitti> kentb: updated file attached
[13:52] <ScottK> Riddell: Typical sort of fixed something in sip4 and pykde4 had been relying on broken assumptions.  It's probably best to upload a really~lastrversion of  sip4, pyqt4, and pyqt5 if it's causing problems as I don't know when it'll be resolved.
[13:53] <ScottK> I'll poke upstream again.
[13:53] <kentb> pitti: ok. thank you. I should have results in just a couple minutes
[13:53] <jdstrand> pitti: you are able to reproduce the wpasupplicant issue locally?
[13:54] <pitti> kentb: that pointed out an interesting problem, I need to discuss that with upstream; but this should work for you
[13:54] <pitti> jdstrand: "run-adt-test network-manager" reproduces it fine, yes
[13:54] <pitti> jdstrand: and I confirm that downgrading dbus fixes it
[13:54] <ScottK> Riddell: http://lists.kde.org/?l=kde-bindings&m=137759567504203&w=2
[13:54] <pitti> jdstrand: I haven't yet tried running the test on my production machine; can do, but I need to go offline for that (shut down NM)
[13:55] <jdstrand> pitti: are you able to make a change to the apparmor configuration and the run-adt-test? (using the new dbus)
[13:55] <pitti> jdstrand: can do; let me set up the VM
[13:56] <kentb> pitti: I think we have a winner :)  Touchpad hotkey working again on Latitude 6430u.  I have an Inspiron in the lab that I'll test sometime later today, but, I expect it'll be OK.  I'll update the bug if it isn't.
[13:57] <kentb> pitti: thanks, again, for your help
[13:57] <jdstrand> pitti: thanks. what you'll want to do is adjust /etc/apparmor.d/sbin.dhclient to add "dbus bus=session," to the profile for /usr/lib/NetworkManager/nm-dhcp-client.action
[13:57] <pitti> kentb: thanks! could you please attach the "for e in /sys/class/input/event*; do udevadm test-builtin keyboard $e; done" with the working file?
[13:57] <kentb> pitti: will do
[13:57] <pitti> kentb: I'm interested in how that looks like (the difference with the ! flag)
[13:57] <pitti> kentb: many thanks for your patience :)
[13:57] <jdstrand> pitti: this 'sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient' before running the test
[13:58] <kentb> pitti: no problem at all.
[13:58] <ESphynx> Unity is bugged beyond all salvation, I give up!!!
[13:59] <pitti> jdstrand: at a new line at the top or bottom of the block?
[14:00] <jdstrand> pitti: anywhere in the /usr/lib/NetworkManager/nm-dhcp-client.action { } stanza
[14:03] <tyhicks> jdstrand: thanks for handling the dbus issue while I was gone
[14:03] <jdstrand> np
[14:03] <tyhicks> I agree that nm-dhcp-client.action need session bus access based on the denial
[14:04] <jdstrand> the question is why is it accessing the session bus, and it that makes wpasupplicant work again
[14:05] <pitti> jdstrand: running
[14:05] <pitti> jdstrand: OOI, what does bus=session mean?
[14:06] <pitti> jdstrand: the session D-BUS? (wpa_supplicant uses the system bus)
[14:06] <jdstrand> pitti: yes, that is the mystery
[14:06] <jdstrand> but look at this denial in the jenkins syslog:
[14:06] <jdstrand> Aug 29 18:17:54 autopkgtest dbus[8876]: apparmor="DENIED" operation="dbus_method_call"  bus="session" name="org.freedesktop.DBus" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" pid=9018 profile="/usr/lib/NetworkManager/nm-dhcp-client.action" peer_profile="unconfined"
[14:06] <pitti> I saw one denial for some GetProperties, but I think that has always been there
[14:07] <pitti> ah
[14:07] <pitti> that's more interesting
[14:07] <jdstrand> bus="session"
[14:07] <jdstrand> we already have sub="system" via the dbus abstraction in the profile. but session is weird
[14:08] <jdstrand> there are a couple of references to DBUS_BUS_SESSION in network-manager source
[14:08] <tyhicks> the apparmor code added to dbus that generates that denial message takes the bus type right off of the message
[14:08] <pitti> cyphermox, jdstrand: indeed that fixes it
[14:08] <jdstrand> but not nm-dhcp-client.action specifically (according to cyphermox)
[14:08] <jdstrand> man, that is weird
[14:09] <jdstrand> pitti: are you doing any deep magic to make the tests not use the system bus or something?
[14:09] <pitti> jdstrand: well, it uses dbus-launch to launch a private bus to do the testing on
[14:10] <pitti> and pretends it was the system bus
[14:10] <jdstrand> tyhicks: ah, that would do it I bet
[14:10] <pitti> so that could be it
[14:10] <tyhicks> yes, definitely
[14:10] <tyhicks> dbus-launch launches a session bus
[14:10] <cyphermox> jdstrand: pitti: I'm absolutely convinced nm-dhcp-client.action doesn't ever use the session bus.. though happy to be proven wrong
[14:10] <cyphermox> gah
[14:10] <pitti> cyphermox: well, it does in these tests
[14:10] <cyphermox> yeah, I guess
[14:10] <cyphermox> it's still a mystery why this affects wpasupplicant in any way
[14:10] <pitti> export DBUS_SYSTEM_BUS_ADDRESS=`dbus-launch` (not literally, but in spirit)
[14:10] <jdstrand> pitti: do you have the ability to update the apparmor profile via the autopkgtests?
[14:10] <pitti> because everything happens on that bus
[14:11] <cyphermox> but it seems to me like the wpasupplicant issue is just a coincidence
[14:11] <pitti> jdstrand: yes, this runs as root, so it can do everything it wants to
[14:11] <tyhicks> well you can feed a bus config file to dbus-launch
[14:11] <pitti> jdstrand: can I do that in a separate file somehow, or apply seddery to that profile?
[14:11] <tyhicks> I wonder what would happen if you gave it a system bus config file
[14:12] <jdstrand> pitti: you could append "bus=session," to abstractions/dbus
[14:13] <jdstrand> pitti: but tyhicks suggestion might be more interesting and real world
[14:13] <pitti> tyhicks: I guess that would be most elegant; not sure whether one can do that as user, but I'll try
[14:13] <pitti> (that's done by python-dbusmock)
[14:13] <tyhicks> ah
[14:14] <jdstrand> cyphermox: it is interesting that wpasupplicant is the grumpy one when nm-dhcp-client.action gets the denial, isn't it?
[14:15] <jdstrand> pitti: so, at this point is the ball in your court?
[14:15] <pitti> jdstrand: yes; I'll try tyhicks' suggestion with passing a config to dbus-launch, and if that doesn't work do the profile seddery
[14:15] <cyphermox> jdstrand: quite
[14:15] <jdstrand> pitti: cool, thanks! :)
[14:15] <pitti> tyhicks, jdstrand: thanks for pointing this out! that was quite surprising
[14:15] <tyhicks> thanks pitti - ping me if you need anything
[14:16] <cyphermox> especially for some piece of code that shouldn't ever ever be touched, since it's support for new stuff we don't test yet, and almost nobody has support for
[14:16] <jdstrand> cyphermox: I'll leave that to your curiosity then :)
[14:16] <cyphermox> jdstrand: heh, I'll debug this on monday
[14:16] <cyphermox> we're probably just unlucky there, or lucky that it's showing a real bug we'd eventually hit
[14:17] <pitti> kentb: "keyboard: updating force-release list with '140,158,369-370,140,158'
[14:17] <pitti> kentb: ah, that's what I was expecting, thanks
[14:20] <kentb> pitti: ok. cool. I saw that myself.  Glad it helped you out!
[14:28] <pitti> tyhicks: how does it decide whether it's the system or session bus? does it ask the process "what are you", or does it check uid, etc?
[14:29] <tyhicks> pitti: what do you mean by "it"? dbus-launch or the apparmor mediation code that I added to dbus?
[14:32] <diwic> from apt-get:
[14:32] <diwic>     gstreamer1.0-plugins-good:amd64 conflicts with gstreamer1.0-plugins-bad:amd64
[14:32] <diwic>     gstreamer1.0-plugins-bad:amd64 conflicts with gstreamer1.0-plugins-good:amd64
[14:32] <diwic> the eternal fight between good and bad it seems like!
[14:33] <pitti> tyhicks: nevermind; specifying a config file with  <type>system</type> works fine
[14:34] <tyhicks> ah, yeah - that's all there is to it
[14:34] <pitti> tyhicks: splendid, I'll fix that in python-dbusmock and try to squeeze it through the freeze (it's not seeded, so should be fine)
[14:34] <tyhicks> thanks pitti :)
[14:34] <pitti> tyhicks: thanks to you, too
[14:44] <dobey> can anyone reject/delete/whatever ubuntuone-credentials-13.07-0ubuntu1 from the saucy NEW upload queue?
[14:48] <seb128> dobey, done
[14:49] <dobey> thanks
[14:49] <dobey> doh
[14:49] <dobey> seb128: you rejected the 13.08 upload, not 13.07 :-/
[14:50] <seb128> dobey, crap
[14:50] <seb128> dobey, let me fix that
[14:50] <Laney> now he gets to review from rejected ;-)
[14:50] <dobey> heh
[14:50] <Laney> (you can accept from rejected)
[14:50] <seb128> Laney, yeah :/
[14:51] <pitti> yeah, just not put back into NEW :/
[14:51] <Laney> seb128: or get the uploader to reupload :P
[14:51] <seb128> Laney, that's ok, I just need to find a nitpick to justify the reject
[14:51] <dobey> what? the package is *perfect* :)
[14:51] <pitti> "badly worded package description"
[14:52] <dobey> "package description not in french"
[14:52] <pitti> tyhicks, jdstrand, cyphermox: ok, new python-dbusmock uploaded with the "pretend harder to be a system bus"; that's certainly the least place I would have expected a dbusmock bug to live :)
[14:53] <jdstrand> hehe, thanks! :)
[14:53] <dobey> seb128: do i need to re-upload?
[14:53] <pitti> "Jenkins Fixed - saucy-adt-mysql-5.5" -- OH MY OH MY OH MY!
[14:53] <dobey> or you can just accept it :)
[14:53] <seb128> dobey, Package: qtdeclarative5-ubuntuone-credentials-plugin ... please rename "Package: qtdeclarative5-ubuntuone1.0"
[14:53]  * pitti hugs jamespage
[14:54] <jamespage> pitti, just doing my QA catchup
[14:54] <pitti> jamespage: so you managed to fixed that one in two gazillion tests that was always failing?
[14:54] <jamespage> pitti, yep
[14:54] <seb128> dobey, current convention (from kenvandine) is qtdeclarative5-<importname><version> ... it makes different versions co-installable
[14:54] <dobey> seb128: is that new? i named it based on what existing plugins were named
[14:54] <jamespage> the test executor was being called with a trailing / on one of the parameters
[14:54] <pitti> jamespage: OOI, for legitimate stderr (if that cannot be sensibly suppressed), there is now "Restrictions: allow-stderr"
[14:54] <seb128> dobey, relatively new yes, the recent packages use that
[14:54] <jamespage> pitti, yeah - I spotted that
[14:55] <dobey> seb128: but existing ones haven't been updated?
[14:56] <seb128> dobey, no, we decided it wasn't worth transitioning all the existing one, we try to respect the new convention for new packages though
[14:56] <seb128> dobey, also copyright
[14:56] <seb128> "Files: music-login/*
[14:56] <seb128> Copyright: 2013 Canonical Ltd.
[14:56] <seb128> License: GPL-3 with OpenSSL Exception"
[14:56] <seb128> but
[14:56] <seb128> ./online-accounts-provider/NewAccount.qml: GPL (v3)
[14:56] <seb128> ./online-accounts-provider/ExistingAccount.qml: GPL (v3)
[14:56] <seb128> ./online-accounts-provider/Main.qml: GPL (v3)
[14:56] <seb128> dobey, ^ need to add those to the GPL3 list
[14:58] <seb128> dobey, out of those, it's fine, if you fix them I and reupload, I can approve
[14:59] <smoser> can i get an archive admin to nack my upload to precise-proposed of ubuntu-cloudimage-keyring_2013.08.23~12.04.1.dsc
[14:59] <smoser> the changelog didn't hvae a bug reference.
[14:59] <seb128> dobey, it's a bit suboptimal that you have /usr/share files in the lib binary as well, it means that if the soname change the versions are not going to be co-installable
[15:00] <dobey> seb128: infinity was insistent on a security review, that sarnold i think is going to do, as well. i don't know if we want to block on putting it in universe for that or just block having it on the touch image
[15:00] <seb128> dobey, security reviews don't happen in NEW usually
[15:00] <seb128> rather before MIR/seeding
[15:00] <stgraber> smoser: which one?
[15:00] <seb128> we have plenty of code with unsecure code in the archive I'm sure
[15:01] <dobey> seb128: yeah, but this was being seeded to touch from universe so infinity thought we should get it done now
[15:01] <dobey> also since the previous upload had been sitting there for a month with not being accepted into the archive :-/
[15:01] <seb128> dobey, ok, then just fix the stuff I reupload and we can wait for the security review to happen
[15:01] <smoser> stgraber, the precise one without a bug in the chagnelog
[15:01] <stgraber> smoser: done
[15:01] <smoser> if you want you just delete both precise-prposed and i re-upload the righ tone.
[15:02] <seb128> dobey, but I'm happy to accept it as well
[15:02] <smoser> thanks. so there should be one there, right?
[15:02] <smoser> thanks stgraber
[15:02] <stgraber> smoser: yep, I kept the one with the bug reference
[15:03] <dobey> seb128: might be better to just accept it into universe too. i'll be on holiday all next week, and we need to get this into the touch image asap
[15:04] <seb128> dobey, wfm, let me know when you reupload
[15:05] <chiluk> dholbach, kenvandine rsalveti can you guys approve the already sponsored uploads for curl and apt in the precise, quantal,raring queues?  also be careful because the change to apt adds a builddep to the newly uploaded version of curl
[15:06] <dholbach> chiluk, no, not within my powers I'm afraid
[15:06] <kenvandine> chiluk, me either
[15:06] <chiluk> both of you are listed on the patch pilot calendar...
[15:06] <chiluk> what patch piloting are you able to do?
[15:07] <smartboyhw> chiluk, patch pilots only upload fixes
[15:07] <kenvandine> that needs to be someone from the sru team
[15:07] <smartboyhw> For approving queues, that goes to SRU team:)
[15:07] <chiluk> alright...
[15:07] <kenvandine> sorry
[15:07] <chiluk> thanks guys..
[15:08] <chiluk> nope.. the process here is not always the most straightforward.
[15:08] <chiluk> I'm still getting used to it.
[15:08] <chiluk> I thought I had it figured out.
[15:12] <xnox> cjwatson: doko: any idea why apt-get install libgles2-mesa-dev:armhf fails? http://paste.ubuntu.com/6044494/
[15:13] <arges> dholbach: kenvandine smartboyhw : btw who is patch piloting now? i have a patch(es) that may need some piloting.
[15:13] <smartboyhw> arges, nobody
[15:13] <smartboyhw> ?
[15:13] <smartboyhw> Oh NO
[15:13] <arges> heh
[15:13]  * smartboyhw hates this channel:p
[15:13] <smartboyhw> Phew:P
[15:14] <smartboyhw> Someone lock topic for this channel plz...
[15:14] <ogra_> just dont edit it :)
[15:14] <chiluk> infinity, RAOF, SpamapS, cjwatson, slangasek, Daviey, can one of you approve the upload for curl and then later apt *(apt gets a builddep on the new version of curl) that's sitting in the upload queues for p,q,r ? related bug = pad.lv/1179781
[15:14] <kenvandine> damn... i hadn't noticed i was scheduled for piloting today...
[15:14] <kenvandine> dholbach, sorry :/
[15:15] <smartboyhw> ogra_, I was saying that "/topic shows who is"
[15:15] <smartboyhw> And uh hum, that happened
[15:15] <smartboyhw> SORRY
[15:15] <smoser> slangasek, since its your day for SRU, and you're probably not doing anything important at all.... https://bugs.launchpad.net/ubuntu/+source/ubuntu-cloudimage-keyring/+bug/1218963 would be appreciated. it seems particularly low regression potential to me.
[15:15] <ogra_> smoser, no worries, you restored it :)
[15:15] <smartboyhw> ogra_, you pinged the wrong guy:P
[15:16] <ogra_> heh
[15:16] <arges> kenvandine: when you pilot-in, can you check out bug 1160490. I've got debdiffs ready and packaged tested for an SRU. thanks
[15:16] <ogra_> happens :)
[15:18] <kenvandine> arges, that's why i was saying sorry... i really can't do it today... :/
[15:19] <arges> ok..
[15:19] <kenvandine> arges, sorry :(
[15:19] <doko> xnox, not immediately
[15:20] <xnox> doko: in minimal chroot, it's even more fun. apt-get install libgles2-mesa-dev:armhf decides: build-essential cpp cpp-4.8 dh-autoreconf g++ g++-4.8 gcc gcc-4.8 libtool sbuild-build-depends-core-dummy
[15:20] <xnox> should be removed.
[15:21]  * xnox installs cross-build essential first.
[15:23] <xnox> works in a chroot.
[15:23] <xnox> so dunno....
[15:30] <dobey> seb128: uploaded
[15:33] <seb128> dobey, NEWed
[15:34] <dobey> thanks
[15:35] <arges> Hi. Can anybody with some extra time take a look at bug 1160490, its in need of sponsoring. Thanks
[16:03] <danjared> xnox: I thought we were still undecided about combining suspend and hibernate into one
[16:08] <slangasek> danjared: towards the end of the session, I think we had good consensus that we wouldn't expose hibernate as a separate UI option, it should be handled transparently underneath
[16:08] <xnox> danjared: well the design from 2007 for ubuntu, finally have the technology to implement it =) and since then people were towards the idea of a single button "suspend" which will "hibernate" after a timeout, which one can twiddle in settings - zero timeout, X minutes, hours, never.
[16:09] <danjared> slangasek: I'll have to rewatch the session, but I certainly wasn't of that opinion :)
[16:09] <xnox> danjared: so everyone has suspend, and those with rapid start can have suspend+timeout->hibernate.
[16:10] <xnox> danjared: our usability tests in the past showed that people have no idea what the difference between the two is =)
[16:10] <danjared> I think there's still value in being able to put your system into a ~0 power state immediately without having to shutdown (and therefore lose state)
[16:10] <xnox> danjared: what's your preffered default timout? as per intel 1h, or instant?
[16:11] <danjared> (alternatively, having to go temporarily change settings)
[16:11] <xnox> danjared: in practice how much power is used to do 1h of sleep?
[16:11] <slangasek> danjared: does the firmware even *let* us initiate an irst hibernate from the OS?
[16:12] <slangasek> and yeah, what xnox said re: usability
[16:13] <xnox> slangasek: no, you can set timout to zero & sleep. Such that on boot/resume we need to reset the timer back to the default value as far as I can tell from the specs and Windows UI to control this.
[16:14] <slangasek> ah
[16:15] <danjared> xnox: unsure, but it lets me do things like hibernate immediately and swap out my battery without plugging in
[16:15] <xnox> cool.
[16:16] <danjared> slangasek: right, you get to set the timer to zero but leave iRST on, so right when the system goes into S3, the firmware wakes it back up and hibernates
[16:16] <xnox> danjared: i wasn't sure how to prevent iRST despite having the partition and et al. The guide suggested to format / remove the iRST partition =/
[16:17] <xnox> unless I missed that somehow.
[16:17] <danjared> xnox: I .... actually did a more extreme version of that a couple days ago where I went into iRST hibernate then disassembled my laptop to replace the keyboard (which I had spilled something on and rendered some keys non-functional). once it was back in one piece, I reassembled, thawed, and continued on
[16:18] <xnox> .................. danjared i'm not sure we user test that scenario, most of the people we get for user-testing do not bring spare keyboards and toolkits to perform laptop surgeries =)
[16:19] <danjared> xnox: sure, I'm just giving an anecdote there. the "swap out battery" case is the more salient one :)
[16:19] <xnox> danjared: at one point we had a design where the shutdown dialog has options drop-down to e.g. bypass UEFI fastpath, and that could have had "hibernate" instantly.
[16:20] <xnox> danjared: i'm still testing normal hibernate here locally & will be formatting my new laptop with iRST partition in a moment. But if it's quick enough, I'd be inclined to have the default timeout zero.
[16:20] <xnox> danjared: would that be better?
[16:20] <danjared> xnox: if you want to temporarily disable iRST, you set the first bit of SFFS to 0: http://mjg59.dreamwidth.org/26022.html
[16:21] <xnox> danjared: =) i wonder if I should package mjg59 blog as manpages.
[16:22] <danjared> xnox: a drop-down dialog that lets you hibernate immediately seems fine to me.
[16:22] <danjared> xnox: you could always ask him :)
[16:24] <danjared> if the difference between sleep and hibernate is confusing, maybe hibernate could be renamed to "power off (save session)" or something similar
[16:25] <xnox> danjared: i googled for SFFS and google offered me some intel confidential driver specs =)
[16:25] <xnox> \o/
[16:25] <danjared> yeah, I noticed that many of their intentionally public documents still say that
[16:26] <xnox> danjared: no, we removed it =) we have: <list of users to switch to>, log out,  suspend, restart, shut down.
[16:27] <xnox> and it would not be compelling to re-introduce hibernate, as it was very very unreliable, failed to resume, was confusing with suspend.
[16:27] <danjared> right, I meant if you are adding a down-down
[16:27] <xnox> "drop down"
[16:27] <danjared> that too. it's still early for me :)
[16:27] <xnox> yeah, that drop down existed before unity OSD type shutdown.
[16:28] <danjared> so, I thought "hibernate" is still an option for OEM systems
[16:28] <danjared> (we'd like to keep that)
[16:28] <xnox> danjared: http://askubuntu.com/questions/94754/how-to-enable-hibernation
[16:29] <xnox> danjared: so default policikit file in Ubuntu disables hibernate, users can enable it. And/or OEMs may do that as well, if they wish.
[16:29] <danjared> right, sorry, I should have been clear that I am thinking in the context of OEM installs where we've tested hibernate enough to back using it
[16:29] <xnox> danjared: once enabled, the UI magically offers hybernate.
[16:30] <danjared> I mean that, when the hibernate option is made available, it should default to using iRST to immediately hibernate a system instead of using Linux's software hibernate
[16:31] <xnox> danjared: no, as Linux's software hibernate works with full disk encryption using LUKS, and iRST doesn't.
[16:31] <danjared> xnox: and you can work around that by reverting to Linux's hibernate if software disk encryption is used
[16:32] <xnox> danjared: and we care about user privacy & security, especially when they went to lengths to enable full disk LUKS encryption (a single checkbox)
[16:34] <xnox> danjared: i'm un convinced, but then again I don't drive, ubuntu system user design either. mpt, what do you think - should hibernate option be exposed to the users, if we can guarantee that it's reliable?
[16:36] <xnox> danjared: Linux's software hibernation will not be exposed as "hibernation" by default (but one can twiddle policy kit to enable it). Exposing zero timout iRST as hibernate is an option which could go in.
[16:36] <danjared> I mean, you're using disk encryption as a criterium for whether iRST is enabled anyway, and hibernate is exposed to users buying from an OEM
[16:37] <xnox> danjared: and at oem-config first screen they can tick "encrypt my home directory" on OEM preinstalled machine.
[16:38] <danjared> correct. if they do that, iRST can be disabled
[16:40] <xnox> it would be sad, UI wise, that enabling encryption makes hibernate button disappear, unless of course OEM provided big enough swap and validated / enabled Linux's hibernation as well.
[16:40] <xnox> (with and without user home directory encryption, which does LUKS encryption of swap upon activation)
[16:41] <danjared> we currently validate Linux's hibernation. it's part of the certification, IIRC
[16:41] <xnox> danjared: as OEM you certainly have enough toggles to enable everything =) and it would be hard to remove toggles.
[16:42] <danjared> okay, sure. as long as the toggles are there still
[16:42] <mpt> xnox, the menu I showed you this morning was like danjared is describing: "Immediately" was sleep=hibernate, "Never" was don't hibernate.
[16:43] <xnox> mpt: sure, but danjared implies that as a user i want to have: sleep (eventually hibernate) button and hibernate-now button (i want to unplug my lapto battery). Directly in the UI, without changing the default.
[16:43] <mpt> xnox, but I like the idea that if encryption is on then you get the software hibernate instead.
[16:44] <xnox> mpt: i doubt we will enable back software hibernation by default across the board, it was disabled because OEMs validated it to be unreliable and not meeting expectations.
[16:45] <xnox> mpt: but it looks like on danjared's laptops it will be wonderful =)
[16:45] <mpt> What proportion of OEM installs have working hibernate? 10%? 20%? 80%?
[16:46] <danjared> kentb: double-checking, we test hibernate as part of OEM validation, right?
[16:50] <xnox> danjared: http://www.ubuntu.com/certification/hardware/201202-10556/ "Hibernate may not function on this system"
[16:51] <mpt> So we have {iRSTable, software-hibernatable, software-unhibernatable, software-mysterious} × {encrypted, unencrypted with the necessary partition, unencrypted without the necessary partition}?
[16:51] <mpt> That's 12 combinations
[16:52] <danjared> xnox: that certification isn't for a factory install. the factory install certifications are a bit different and have a different logo there
[16:52] <mpt> though probably several of them can be combined
[16:52] <xnox> danjared: correct.
[16:53] <danjared> xnox: here's a weird one that demonstrates that: http://www.ubuntu.com/certification/hardware/201208-11536/
[16:53] <mpt> xnox, could you make a table along those lines, with approximate percentages of each if you know them? That way we'll have a better idea what we're designing for.
[16:53] <mpt> Then I can come back next week and knock out designs for them.
[16:54] <xnox> mpt: in practice thought the second portion is {software encryption used, software encryption is not used}.
[16:54] <mpt> xnox, by "the necessary partition" I meant the necessary partition for either iRST or software hibernation. (They both need an extra partition, right?)
[16:56] <xnox> mpt: sure, but your way some combinations are impossible combinations. =)
[16:56] <mpt> good
[17:01] <sarnold> dobey,seb128, I've started reviewing the 13.08-0ubuntu1 version of ubuntuone-credentials; I'm liking what I'm seeing, I expect to finish it quickly.
[17:02] <dobey> sarnold: great. thanks!
[17:02] <sarnold> Laney: ooh cool :)
[17:06] <kentb> danjared: yes. we do.  It is turned on on the OEM images
[17:07] <kentb> danjared: not a certification blocker but it is tested and noted in the certification if there are issues with it.
[17:10] <Whoopie> debfx: yeah, saw it. Thanks a lot!
[17:11] <Whoopie> debfx: to be honest, the vnc extension is not very stable. but it's good to get more feedback.
[17:23] <pitti> cyphermox, jdstrand: aah, love green! https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-network-manager/
[17:23] <jdstrand> \o/
[17:25]  * pitti waves good night, enjoy the weekend
[17:26] <jdstrand> pitti: you too :)
[17:46] <dobey> kenvandine: ping
[17:46] <kenvandine> dobey, pong
[17:46] <dobey> kenvandine: i presume it's possible to use online-accounts from vala right? is there a good example of it anywhere?
[17:47] <kenvandine> yeah, look at unity-lens-friends
[17:48] <dobey> cool, thanks
[17:48] <kenvandine> np
[18:10]  * xnox is not quite sure what's broken
[18:16] <infinity> tjaalton: Why do my drm lockups not produce crash reports anymore?
[18:17] <infinity> tjaalton: Did you decide you didn't want all my i915 bugs? :P
[18:23] <tjaalton> infinity: heh, when was the last time they produced lockups?
[18:24] <infinity> tjaalton: Today and yesterday.
[18:24] <tjaalton> erm I mean crash reports
[18:25] <infinity> tjaalton: Err, not sure.  Back when I had those frequent hangs in... Q?  R? ... I used to reboot and have a ton of apport popups to cope with.
[18:25] <tjaalton> ah, could be a change in xdiagnose then
[18:25] <infinity> tjaalton: Not having those is certainly more friendly, but not having anything reported is a bit less handy. :)
[18:25] <infinity> tjaalton: Anyhow, drm on my sandybridge sucks again.  I blame you.
[18:25] <tjaalton> well it might just be the same bug all the time
[18:26] <tjaalton> yeah, upstream was hopeful of a patch fixing it, and it worked for some but then upstream reproduced it again..
[18:26] <infinity> At least it's different from the Q/R issues I had. :)
[18:27] <infinity> tjaalton: I assume you're talking about these: http://paste.ubuntu.com/6045137/
[18:27] <infinity> tjaalton: (Which sometimes recover, like above, and sometimes hard lock and force me to reboot... I assume it's the same bug either way, but a bit hard to tell for sure the cause of the reboot ones)
[18:28] <tjaalton> the one with i915.semaphores=0 workaround
[18:28] <tjaalton> but sounds like your bug could be in mesa instead
[18:28] <infinity> tjaalton: Well, if the one you're talking about is the Q/R lockups, this is definitely different.  And very new.
[18:29] <infinity> I've never seen this before yesterday.
[18:29] <infinity> Could be mesa9.2's fault.
[18:29] <tjaalton> file a new bug against x-x-v-intel and attach i915_error_state
[18:29] <tjaalton> yeah
[18:29] <tjaalton> it's been happy on my lappy for a week
[18:29] <tjaalton> snb
[18:30] <infinity> My reproduction method has, so far, been to play video in mplayer with the -vo gl renderer.
[18:30] <tjaalton>   * debian/xdiagnose.udev: Disable gpu apport hook for raring release
[18:30] <infinity> Haven't tried xv yet.
[18:30] <tjaalton> so you could hack that to report crashes again
[18:30] <infinity> It soft locked about 4 times in the course of a 2h movie last night, and had locked once.
[18:31] <infinity> s/had/hard/
[18:31] <tjaalton> hmm this is why we haven't been getting any bugs during saucy :P
[18:31] <tjaalton> other than the usual xserver crashes
[18:32] <tjaalton> xdiagnose is basically orphaned since bryce left
[18:32] <tjaalton> mlankhorst: ^ maybe you should adopt that one too ;)
[18:33] <mlankhorst> tjaalton: ah :P
[18:33] <tjaalton> maybe enable it until release-ish
[18:33] <mlankhorst> tjaalton: bit late in the cycle for that, though..
[18:33] <tjaalton> well, now is the time when people start upgrading en masse
[18:34] <tjaalton> or after beta
[18:34] <tjaalton> still nearly two months until release
[18:34] <mlankhorst> tjaalton: I won't be able to look at it until monday, but I'll add it to my list
[18:34] <tjaalton> sure, no rush
[18:38] <slangasek> chiluk: curl accepted.  Now, what happens if someone happens to pull the new version of apt from -updates without explicitly pulling in the new version of curl?  Will that regress existing uses of apt-transport-https?
[18:39] <slangasek> chiluk: if so, it seems to me that apt should have a hard-coded versioned runtime dependency on the fixed libcurl; and the build-dependency actually looks superfluous to me
[18:39] <chiluk> slangasek, it will be fine because apt statically links with the curl libs.
[18:39] <infinity> slangasek: I would hope there's a binary dependency.
[18:39] <chiluk> afaik
[18:39] <infinity> Err, it does what now?
[18:40] <slangasek> chiluk: it does not
[18:40] <infinity> (base)adconrad@cthulhu:~$ ldd /usr/lib/apt/methods/https | grep curl
[18:40] <infinity> 	libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f46995e9000)
[18:40] <slangasek> infinity: there's a binary dependency on libcurl; but not on the new SRUed version of curl, which doesn't change abi and therefore doesn't change shlibs
[18:40] <chiluk> nuts.. i stand corrected
[18:40] <infinity> slangasek: Did this introduce a header change?  If not, the build-dep is indeed pointless.
[18:41] <slangasek> infinity: nopers
[18:41] <infinity> Yeah, so the build-dep should be a binary dep.
[18:41] <chiluk> i assumed that since I only found a build-dep that's all that needed updating.
[18:41] <chiluk> i stand ashamed.
[18:41] <infinity> Or that curl should have a shlibs bump.
[18:42] <slangasek> chiluk: so I think these apt uploads in the queue should be rejected, I'll do that now.  Do you understand what you need to change for the reupload?
[18:42] <chiluk> yeah... add a depends on the new version of curl for apt.
[18:42] <chiluk> not a builddep
[18:42] <chiluk> I'll revert the builddep line back to the previous version
[18:43] <slangasek> for apt-transport-https, specifically (which is probably what you meant, but just to be explicit)
[18:43] <chiluk> yeah.
[18:44] <slangasek> chiluk: and the binary package to depend on appears to be libcurl3-gnutls, which the version set to the SRU version of curl in the corresponding pocket - so different for each
[18:44] <infinity> apt-transport-https is just pulling its curl dep from shlibs currently.
[18:44] <slangasek> yes
[18:44] <slangasek> so we want to hard-code an override for that in debian/control
[18:44] <chiluk> slangasek, right.
[18:44] <infinity> So, why not just fix this in curl's shlibs?
[18:44] <slangasek> because it's not a shlib issue
[18:45] <slangasek> it's an "apt will do broken things if running with a version of curl that has this particular bug" issue
[18:45] <dobey> i take it a build in -proposed being in depwait on powerpc will block the package being migrated to release?
[18:45] <infinity> dobey: It will if the binary previously existed on PPC.  Which package?
[18:45] <dobey> infinity: ubuntuone-credentials
[18:45] <infinity> Then no.  That's a new package.
[18:45] <chiluk> I agree that the dependency should be explicit in apt-transport-https and not shlibs... because this is exacerbated by apt
[18:46] <infinity> dobey: It just needs someone to process the other three arches from binary NEW.  I'll look at 'em now.
[18:46] <dobey> ubuntu-ui-toolkit isn't built on powerpc, and ubuntuone-credentials has a build-dep on a package from ubuntu-ui-toolkit, so it won't build on powerpc. but i don't see why a) ubuntu-ui-toolkit isn't builting on powerpc or b) why ubuntuone-crednetials is trying to
[18:46] <dobey> ah ok
[18:46] <dobey> thanks
[18:47] <cjwatson> not building on an architecture is only a problem for proposed-migration if there are currently binaries for that architecture in the release pocket.
[18:47] <infinity> dobey: ubuntu-ui-toolkit probably isn't building on PPC cause it needs qt5declarative, which needs v8, which isn't ported to anything other than x86 and ARM.
[18:47] <infinity> Because Google are muppets.
[18:47] <infinity> And Qt upstream are even bigger muppets for choosing a JS engine that only exists on 1.5 architectures. :P
[18:47] <slangasek> infinity: you coulda had a V8
[18:48]  * sarnold smacks forehead
[18:48] <slangasek> infinity: alas, this means that quantal still doesn't have the backported fix for auto-cleaning of stale kernels... so maybe you want to sponsor chiluk's next apt? :)
[18:49] <infinity> slangasek: I thought we'd decided to only bother backporting that to the LTS.
[18:49] <infinity> slangasek: But we can certainly do Q too.
[18:50] <chiluk> man, I didn't expect apt to build into separate binaries like that.... sorry bout that guys... I still think it's retarded instead of linking to libs..
[18:51] <slangasek> infinity: well, apparently you uploaded 0.9.7.5ubuntu5.3 in January or something to fix it in Q, then it was superseded by a security upload, then bdmurray included the change in his latest sponsored upload
[18:51] <infinity> slangasek: Oh, hrm.  Sure.  I'll take your word for it.  That was another lifetime ago. :)
[18:51] <slangasek> chiluk: apt is a low level component of the system, apt-transport-https is an optional component with significant added dependencies; the binary split is necessary to avoid a) bloating the system, b) breaking bootstrapping
[18:52] <infinity> dobey: Accepted.
[18:52] <chiluk> slangasek, ah.. thanks.... sometimes knowing the reason makes things less insane.
[18:54] <chiluk> slangasek infinity does order matter on the Depends: line for precedence ?
[18:54] <slangasek> nope
[18:54] <dobey> infinity: thanks again
[18:54] <slangasek> chiluk: not unless it's an ORed dependency
[18:54] <slangasek> (which should not be the case here)
[18:55] <infinity> dpkg-gencontrol should be smart enough to collapse the dep from dpkg-shlibdeps and the manual dep from debian/control into the single higher one anyway.
[18:56] <slangasek> it is
[18:56] <infinity> (But even if it's not, you just have two harmless deps that say "foo (>= 1), foo (>= 2)", which obviously reduces to "you need higher than 2")
[18:56] <slangasek> at least for the releases we're talking about
[19:04] <slangasek> smoser: bug #1218963> I don't see any packages in the queue for this?
[19:04] <slangasek> oh, they're in NEW
[19:04] <slangasek> ok
[19:05] <arges> slangasek: hiya. could you sponsor an SRU for bug 1160490? thanks
[19:06] <slangasek> arges: maybe it would be better to have stgraber do the sponsoring?
[19:06] <slangasek> (though before we do any of that, we ought to get bug #1217263 fixed in saucy :P)
[19:06] <arges> slangasek: sure. I saw your name all over the changelog, and figured it may be too late for him
[19:07] <slangasek> arges: he's only eastern time :)
[19:07] <slangasek> (now)
[19:07] <arges> ah
[19:09] <arges> slangasek: why does bug 1217362 need to get fixed first?
[19:09] <infinity> arges: Because you're dyslexic.
[19:09] <arges> hah
[19:09] <arges> bug 1217263
[19:09] <arges> there we go
[19:09] <slangasek> arges: because a) bugs should be fixed in the devel series before being SRUed, b) conffile handling bugs should be fixed ASAP because they get harder to fix properly with each subsequent upload
[19:14] <chiluk> slangasek, infinity... done... debdiffs attached here  .   https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1179781
[19:20] <ESphynx> xnox: Uploading on debian.mentors.net ...
[19:20] <ESphynx> there is still a bug with this Unity stuff, but I am very late on my weekend vacation schedule :S
[19:20] <ESphynx> So I will try to fix that when I come back and submit a patch
[19:51] <ESphynx> xnox: http://mentors.debian.net/package/ecere-sdk
[19:52] <ESphynx> Sorry to submit it so late, I was really hoping to fix these Unity woes which apparently are not fixed yet
[19:52] <ESphynx> So either redj this weekend or me when I come back on Monday evening are going to try to resolve that properly and submit a patch...
[21:09] <Noskcaj> kirkland, what's your reasoning for keeping parallels in testdrive?
[21:28] <dobey> sarnold: hi. did you finish up the ubuntuone-credentials review already?
[21:56] <sarnold> dobey: not yet, but please feel free to treat it as an ACK
[21:58] <dobey> sarnold: ok. thanks!
[22:42] <smoser> slangasek, is there anything i need different since they're new?
[22:51] <infinity> dobey: Just make a mental note that that review's already been done when MIR time comes. :)