[04:43] <pitti> Good morning
[04:44] <Noskcaj> what do i need to do to package bug 1199017 ? the dsc, debian folder and tarball ar all provided?
[04:44] <Noskcaj> *are
[04:54] <ajmitch> Noskcaj: the bug is there so that a sponsor can look at it & upload it, there's nothing you need to do if you're not able to upload it
[04:54] <Noskcaj> ok
[06:36] <dholbach> good morning
[07:16] <mwhudson> pitti: hello
[07:16] <pitti> hello mwhudson
[07:17] <mwhudson> pitti: did you see https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1196440?  would you know anything about it?
[07:17] <mwhudson> (i found your fingers on dbgsym stuff :))
[07:19] <pitti> hmm, apache2's debian/control does have apache2-dbg; I wonder where it went
[07:19] <pitti> ooh
[07:19] <pitti> we explicitly don't build it on ubuntu
[07:19] <pitti> that delta can be dropped now
[07:21] <pitti> mwhudson: doing a test build now
[07:22] <mwhudson> pitti: ta
[07:23] <zyga_> pitti: hey
[07:29] <mwhudson> ... in the mean time, how do i lie to apt and pretend apache2-dbg is installed?
[07:31] <zyga> mwhudson: you want to build something that depends on the -dbg package?
[07:31] <pitti> hey zyga
[07:31] <zyga> pitti: hey, I've started looking at and experimenting with your dbusmock project
[07:32] <pitti> mwhudson: won't help you in this case, the -dbgsym is empty
[07:32] <zyga> pitti: I wanted to say *thank you* it's really awesome
[07:32] <mwhudson> pitti: oh ok
[07:32]  * mwhudson rummages around for his unstripped apache build
[07:33] <pitti> zyga: nice :)
[07:35] <zyga> pitti: I'm still in the early stages here, I wanted to ask if you think that dbusmock is applicable for testing server code somehow? like putting upower on a fake bus (and mocking stuff internally) to ensure that the actual implementation does what is expected
[07:35] <zyga> pitti: from what I read so far it seems to be more client focused, where you put a fake server on a spare bus and have real clients talk to it
[07:36] <ev> m4n1sh: apologies for not getting to that bug yesterday. Going to try to fit it in today
[07:37] <pitti> mwhudson: fix uploaded
[07:37] <mwhudson> pitti: :)
[07:37] <mwhudson> pitti: thanks
[07:37] <pitti> zyga: not quite, it's not meant for that; it's primary purpose is to test desktop-side/UI code
[07:37] <pitti> zyga: like, indicators or gnome-settings-daemon
[07:38] <pitti> zyga: for testing upower itself I use an umockdev approach, i. e. fake the sysfs/uevent side and test that upowerd reacts as intended
[07:38] <pitti> zyga: i. e. the intention is to have the mock mirror what the real daemon does, so it's rather pointless to test the other way round
[07:43]  * smb wonders whether there is a compelling reason to have "move workspace left+right" on ctrl+alt+<left/right> but "move workspace up+down" on super+<up/down>
[07:44] <zyga> pitti: I see, how do you test upower's dbus interface itself then?
[07:44] <smb> (actually super and page up/down
[07:45] <pitti> zyga: the test suite calls the "upower" CLI tool
[07:45] <pitti> zyga: but you can just talk to the d-bus interface directly in tests, of course
[07:45] <zyga> pitti: oh
[07:46] <zyga> pitti: do you put upower on a some kind of special, standalone, test bus/
[07:47] <pitti> zyga: yes, I do; otherwise you couldn't run the tests in "make check"/during package build
[07:48] <zyga> pitti: I need to look at upower then, I think the solution I'm after is just putting my code on a bus does not interfere with rest of the system and see what happens when I (really) call methods over dbus, that I can mock (the actions of) internally in the test code
[07:49] <pitti> zyga: you can do that with dbus-launch <program>, and setting DBUS_SYSTEM_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
[07:49] <pitti> zyga: (and then clean up the bus after you've done)
[07:49] <pitti> there are some convenience libraries around that, but that's the gist of it
[07:50] <zyga> pitti: my app runs on the session bus normally
[07:50] <zyga> pitti: is it appropriate to just use that during tests/
[07:50] <pitti> zyga: ah, then you only need the dbus-launch
[07:50] <zyga> ok
[07:51] <pitti> zyga: if your test suite is in Python, you can also use Gio.TestDBus, which is very convenient (and cleans up after itself)
[07:51] <zyga> pitti: indeed it is
[07:51] <pitti> zyga: yes, sure; tests shouldn't assume an existing session bus
[07:51] <zyga> pitti: thanks, I need to look stuff up then :)
[07:52] <pitti> zyga: http://cgit.freedesktop.org/upower/tree/src/linux/integration-test uses Gio.TestDBus
[07:53] <zyga> pitti: that looks like exactly what I wanted!
[07:53] <zyga> pitti: awesome, thanks
[07:58] <pitti> zyga: you wouldn't use lines 75 and 76 for a session bus
[07:58] <pitti> zyga: and of course Gio.BusType.SYSTEM → .SESSION
[08:02] <seb128> barry, slangasek: ubuntuone and software-center are broken in saucy for a week now due to the python-configglue update ... should we think about reverting the update?
[08:02] <seb128> it's getting really annoying for those of us that use u1...
[08:03] <pitti> seb128: is that the UnicodeDecodeError crash that pops up multiple times every day?
[08:03]  * pitti tried to report it, but had outdated packages
[08:03] <seb128> pitti, no, it's bug #1198480
[08:04] <pitti> ah, it just crashed again, reporting now
[08:04] <seb128> pitti, ubuntuone-syncdaemon doesn't start for me
[08:04] <seb128> pitti, does it work for you?
[08:04] <pitti> indeed not
[08:04] <pitti> 0:00 /usr/lib/x86_64-linux-gnu/indicator-sync/indicator-sync-service
[08:04] <pitti> unless this replaced it somehow
[08:04] <pitti> but no ubuntuone-syncdaemon process or similar
[08:05] <seb128> pitti, no, can you try running manually ubuntuone-syncdaemon ?
[08:05] <seb128> pitti, /usr/lib/ubuntuone-client/ubuntuone-syncdaemon
[08:05] <pitti> yep, AssertionError
[08:05] <seb128> righht
[08:05] <seb128> it's broken for a week, since barry updated python-configglue
[08:06] <seb128> what happened to the "revert broken updates in the day if we don't come with a fix"? ;-)
[08:07]  * pitti gets bug 1199659
[08:07] <pitti> seb128: well, we should
[08:08] <pitti> mwhudson: argh, my upload was rejected, there is a -2.4 stuck in -proposed
[08:08] <pitti> mwhudson: I'm afraid I can't fix this quickly then
[08:08] <seb128> pitti, Laney and dobey were discussing s-c but I don't know if that's this bug
[08:09] <Laney> no I was just fixing the tests
[08:10] <cjwatson> pitti: you could fix it in -proposed if the version there has the same problem
[08:10] <cjwatson> pitti: we're working on getting that transition landed
[08:11]  * pitti re-fixes his apt sources to add deb-src saucy-proposed again
[08:11] <cjwatson> pitti: pull-lp-source is your friend
[08:13] <pitti> cjwatson: ah, the -proposed version already drops teh ubuntu specific -dbg handling, so much the better
[08:13] <seb128> cjwatson, Laney, pitti: do you have any opinion on reverting the python-configglue update to fix u1? I'm pondering doing it ... or maybe I should just wait for barry to wake up to check with him first
[08:13] <pitti> +1 for reverting
[08:14] <cjwatson> seb128: I think by now it can wait for barry to wake up ...
[08:14] <Laney> I'm not massively up to speed with the problem, sorry
[08:14] <cjwatson> I don't have much of a personal opinion beyond observing that the update added python3 support (afaik) and thus reverting it at this late stage would require checking whether anything's been built on top of that since
[08:14] <seb128> right, I pinged him yesterday already but nothing happened
[08:14] <seb128> but yeah, it has been broken for a week, it can be broken for a few extra hours
[08:15] <pitti> seb128: hm, http://launchpadlibrarian.net/144486841/python-configglue_1.1.0-0ubuntu1_1.1.1-0ubuntu1.diff.gz doesn't seem to have ConfigParser changes?
[08:16] <pitti> seb128: ah, I guess it wasn't the latest upload, but 1.1.0-0ubuntu1 instead?
[08:16] <seb128> pitti, the issue started with 1.1.0 not 1.1.1
[08:16] <pitti> that looks harder to revert
[08:16] <seb128> yeah :/
[08:16] <pitti> python3-configglue has zero rdepends, tohugh
[08:18] <Laney> I think the problem is that the update brings in configparser which causes conflicts or something
[08:18] <Laney> https://code.launchpad.net/~ricardokirkner/configglue/from-future-remove-configparser/+merge/173806 was posted yesterday
[09:03] <infinity> @pilot in
[09:21]  * dholbach hugs infinity
[09:21] <caribou> I'm working on a patch that requires a modification to configure.ac that comes from upstream
[09:22] <infinity> caribou: Nothing wrong with that.
[09:22] <caribou> I suppose that this means that debian/rules needs to run autoreconf but for some reason, it fails on me
[09:22] <caribou> infinity: well, just changing configure.ac breaks the build :-/
[09:22] <caribou> infinity: let me paste the error...
[09:22] <infinity> caribou: One can either use one of the dh autoreconf thingees to sort that out, or your patch can hit configure.ac, configure.in, and configure all at once.
[09:23] <caribou> infinity: http://paste.ubuntu.com/5861074/
[09:23] <caribou> infinity: that's what I did : I added an override to dh_auto_configure to run autoreconf before continueing
[09:23] <infinity> That's not really a helpful error without knowing what it's complainign about, or what your patch is.
[09:24] <caribou> infinity: just adding /bin/*/libc.so.* to a subshell search with 'ls'
[09:24] <seb128> caribou, you should better use dh-autoreconf and --with autoreconf
[09:24] <seb128> caribou, rather overwriting
[09:24] <seb128> rather *than* overwriting
[09:25] <infinity> caribou: s/bin/lib/ I assume, though any autoconf check for libc is probably broken by design.
[09:25] <seb128> (though that will probably not fix your issue if autoreconf fails there)
[09:25] <infinity> caribou: As seb says, dh_autoreconf is the way to do this, but I'm curious as to what your patch is and why it's needed in the first place.
[09:26] <caribou> oh, btw if I rm acinclude.m4 & rerun autoreconf --force --install in the schroot it works
[09:26] <caribou> infinity: let me paste it...
[09:27] <caribou> infinity: http://paste.ubuntu.com/5861086/
[09:27] <caribou> seb128: ok, I'll do that
[09:27] <infinity> caribou: I think what I was driving at is *why* does it do that?  Nothing should need to know the path to libc.
[09:28] <cjwatson> Yeah, dh-autoreconf is the way, the truth, and the life
[09:28] <seb128> caribou, hum, for that patch you might want to try to make the change the configure manually as well and avoid autoreconfing at all
[09:29] <caribou> infinity: well danted fails to start because it cannot find the lib. I'm just following pitti's advice on the bug; let me dig it
[09:29] <cjwatson> seb128: ugh
[09:29] <cjwatson> patching autogenerated files is a timebomb
[09:29] <caribou> 557918
[09:30] <infinity> caribou: I don't doubt that the patch is necessary in the current incarnation of whatever crazy thing the package is doing, I'm just arguing that fixing it to DTRT is better than perpetuating hacks, especially if it's going to be upstreamed.
[09:30] <seb128> cjwatson, well, patching both configure.ac and configure should be fine ... but yeah, better to autoreconf when you can
[09:30] <infinity> cjwatson: I do it all the time (patching the source *and* the generated file, never just the latter)
[09:30] <seb128> cjwatson, sometime you can get away with patching the autogenerated ones though
[09:30] <cjwatson> sounds like you need to find the bug in acinclude.m4 and patch that so that autoreconf works
[09:30] <cjwatson> infinity: For "timebomb", I meant just the latter.  But the more I work with dh-autoreconf the more I find it night-and-day from previous "patch both files" approaches.
[09:31] <caribou> infinity: here's the bug : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/1124048
[09:32] <caribou> sorry I pasted the Dupe : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
[09:34] <caribou> btw, I had the same build failure before adding the autoreconf bit
[09:34] <caribou> well, this was last night, need to test it again
[09:35] <infinity> dlopening libc makes me a sad panda.  But fixing that looks like it would be a massive patch.
[09:37] <infinity> caribou: You could just add --with-libc=libc.so.6 to configure.
[09:38] <caribou> infinity: isn't that hardcoding the version ? not that it should change much
[09:38] <infinity> caribou: It is, and it's wrong for Debian (since it's not always 6)
[09:38] <infinity> caribou: Meh, I guess fixing their weird search works.
[09:39] <infinity> Fixing their dlopens would be better, but that looks painful.
[09:39] <caribou> ok FYI, just patching configure.ac & rebuilding w/o autoreconf yield to the same error
[09:40] <caribou> full build error : http://paste.ubuntu.com/5861110/
[09:41] <caribou> well doesn't look like there is an easy answer to that; sorry to bring that noise
[09:41]  * Laney hears Public Enemy
[09:43] <infinity> caribou: That just looks like a missing build-dep.
[09:44]  * infinity tests here.
[09:44] <cjwatson> patching configure.ac and rebuilding without autoreconf is always wrong
[09:44] <caribou> infinity: I added automake1.9 but it didn't change a thing
[09:45] <cjwatson> and the failure is strictly less interesting than what you get from autoreconf
[09:45] <caribou> cjwatson: yeah, I know I figured out the autoreconf afterward (I'm an autotool noob)
[09:45] <cjwatson> don't add automake1.9, that entire path is unreliable and not worth debugging
[09:45] <caribou> cjwatson: but I seem to get the same failure with & without the autoreconf
[09:45] <infinity> I wish I hadn't read that debian/rules.
[09:46] <cjwatson> caribou: that's as may be, but without autoreconf you get a weirder set of failures appended that you really do not want to debug
[09:46] <cjwatson> take my word for that :)
[09:53] <cjwatson> that's one reason I prefer the dh-autoreconf approach, because it makes us make things easier for other people modifying the source
[09:54] <caribou> cjwatson: I can add that in my patch, since it won't build without. Or a separate quilt patch ?
[09:54] <infinity> Yeah, I wouldn't argue against the m4 being fixed regardless.
[09:54] <cjwatson> i.e. if somebody had converted this to dh-autoreconf before, then we'd have seen this as a build failure at the very least and you wouldn't have been dragged into this
[09:54] <cjwatson> caribou: I'd do it in a separate patch but I don't think it's that important
[09:54] <cjwatson> however:
[09:54] <cjwatson> once you patch a .m4 file, you'll probably find that the maintainer-mode rules evidently in use here will try to rebuild Makefile.in files and such
[09:54] <infinity> Besides, my patch could get you into timestamp skews and force and autoreconf which would hit build failures anyway. :P
[09:55] <cjwatson> so I don't think fixing acinclude.m4 is compatible with infinity's patch-the-generated-file-as-well approach
[09:55] <infinity> s/and/an/
[09:55] <infinity> caribou: Just fix it all and autoreconf.  Being in maintainer-mode makes this a bit of a nondeterministic rabbit hole if you don't.
[09:56] <cjwatson> so I would: (a) add a patch adding a blank line to the end of acinclude.m4 (b) add a patch for the configure.ac fix you were trying to apply in the first place (c) make the package b-d on dh-autoreconf and use it
[09:56] <cjwatson> should be safest all round
[09:57] <caribou> cjwatson: ok, will do that & let you know that comes out
[09:57] <caribou> it will have to be sponsored anyway
[09:57] <caribou> cjwatson: infinity thanks for the valuable help & learning experience :)
[09:59] <zyga> pitti: quick question, your upower test code uses Gio.DBuxProxy, is there any advantage over using python-dbus proxy objects?
[10:00] <pitti> zyga: not much except avoiding yet another dependency
[10:00] <pitti> I already need GI there anyway, so I'm using the GI bindings instead of python-dbus
[10:00] <zyga> ok, thanks for the explanation
[10:00] <pitti> zyga: but they are both roughly equivalent in terms of comfort and functinoality
[10:01] <zyga> I was just looking for hidden dependencies
[10:17] <ev> pitti: do you have any time today to discuss whether https://code.launchpad.net/~ev/apport/automatic-reporting/+merge/173553 is the correct approach?
[10:17] <pitti> hey ev
[10:17] <pitti> ev: still catchign up with stuff after my short holidays; I haven't yet looked at it, but will do this afternoon
[10:17] <ev> pitti: awesome, thank you. And welcome back :)
[10:36] <pitti> ev: reviewed, I left some commentary in the MP
[10:37] <ev> pitti: thanks!
[10:53] <apachelogger> cjwatson, Riddell: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1199731
[10:56] <ev> manish: also, I'm going to split the dbus service out of activity-log-manager as I need it available for the mobile platform settings
[10:57] <ev> the WhoopsiePreferences service, that is
[11:01] <cjwatson> apachelogger: thanks, fixed in Debian bzr now: http://paste.ubuntu.com/5861279/
[11:02] <apachelogger> weeh
[11:02] <apachelogger> cjwatson: will that land in saucy?
[11:02] <cjwatson> Yeah
[11:03] <cjwatson> I'll probably roll up an unstable upload this weekend, and merge it
[11:03] <cjwatson> if that's OK
[11:03] <apachelogger> cjwatson: awesome :)
[11:04] <apachelogger> Riddell: ^ we'll have plymouth again ;)
[11:05] <Riddell> apachelogger: ooh exciting
[11:23] <mlankhorst> sforshee: bisected
[11:23] <mlankhorst> I hate guessing correctly
[11:23] <mlankhorst> 1acba98f810a14b1255e34bc620594f83de37e36
[11:23] <mlankhorst> breaks my macbook efi boot
[11:47] <mdeslaur> cjwatson: did rbasak get back to you regarding the php5 merge?
[11:50] <cjwatson> mdeslaur: Not as yet
[11:56] <zyga> pitti: I cannot import Gio.TestDBus, is that available on precise?
[12:14] <halfie> during the process of building packages, is accessing internet OK or is it forbidden?
[12:15] <ogra_> forbidden ...
[12:18] <cjwatson> accessing internet resources other than the archive itself (for build-deps and the like) is a recipe for unreliability anyway
[12:20] <pitti> zyga: ah, it was added in glib 2.33, so no
[12:21] <pitti> zyga: OOI, why do you need this on precise?
[12:21] <halfie> cjwatson, agreed. I was wondering how you guys are able to build scala without internet access
[12:21] <halfie> while building scala, ant does some dependency resolution and downloading
[12:23] <zyga> pitti: welcome to the PES area, everything we do needs to be on precise
[12:24] <zyga> pitti: I started running precise not to get used to all the shiny good stuff added later
[12:24] <pitti> well, that's why we call it a development release :)
[12:24] <zyga> pitti: can I somehow spawn dbus as non-root and use it to register my service there
[12:24] <zyga> pitti: well, 12.04 is quite older than 12.10 and 13.04
[12:24] <pitti> zyga: so you won't have umockdev either; if you need this, I'll need to jump through some hoops
[12:25] <zyga> pitti: it's not about saucy sadly :/
[12:25] <pitti> zyga: sure, all of this (like upower's test suite) runs as normal user
[12:25] <zyga> ok
[12:25] <zyga> thanks!
[12:25]  * ogra_ hopes pitti at least takes a video for us when doing that :)
[12:25] <pitti> zyga: dbus-launch just starts a session bus
[12:25] <pitti> ogra_: tried, but broke the camera during jumping!
[12:26] <ogra_> haha
[12:42] <caribou> infinity: cjwatson: Does that look like a decent use of dh_autoreconf : http://paste.ubuntu.com/5861491/
[12:42] <caribou> I patched acinclude.m4 so I no longer have the aclocal failure
[12:43] <caribou> but it now fails at compilation :-/
[12:47]  * caribou is wondering if those kind of questions would be better suited for  #ubuntu-app-devel
[12:59] <smoser> not a big deal, and i'm just going to not upgrade right now
[12:59] <smoser> but
[12:59] <smoser> http://paste.ubuntu.com/5861525/
[12:59] <roaksoax> smoser: don't dist-upgrade :)
[12:59] <smoser> (alpine and firefox are specifrically held) but the xserver stuff is odd and rmoving ubuntu-desktop didn't seem right.
[13:00] <smoser> specifrically .
[13:00] <roaksoax> smoser: yeah someone reported something similar over the the ML
[13:00] <roaksoax> smoser: but i have the latest upgrades and have not seen any issues
[13:00] <smoser> odd.
[13:00] <roaksoax> but better to hold off
[13:00] <roaksoax> smoser: do you have -proposed enabled? maybe that's it?
[13:01] <smoser> doesn't look like it.
[13:07] <rbasak> cjwatson, mdeslaur: sorry, I'm working on it (php merge)
[13:07] <mdeslaur> rbasak: thanks
[13:10] <dobey> if i add autopkgtest support to a package, and upload it, how long before i see those tests happening on jenkins?
[13:20] <jibel> dobey, when binaries are in -proposed
[13:21] <dobey> jibel: and if i don't see the tests on jenkins, even after the binaries are in release?
[13:21] <jibel> dobey, which package?
[13:22] <dobey> jibel: dirspec
[13:23]  * jibel looks
[13:45] <rbasak_> Is there any need to prefer libpng12-dev when a package in main depends on libpng-dev, and the only thing that provides libpng-dev is libpng12-dev in main?
[13:46] <rbasak_> I presume not, unless we do something to avoid future breakage or something. But if the buildd doesn't include universe, I don't see that it would break.
[13:47] <dobey> jibel: i take it you didn't find it either? :)
[13:47] <jibel> dobey, still looking, but right I didn't find why yet
[13:48] <jibel> cjwatson, I cannot see why dirspec tests have not been requested, would you know? I can see it for the first time in 2013-07-09/22:09:33.log but there has never been any test request
[13:59] <cjwatson> halfie: I don't know specifically about scala.  Usually Java packages build-depend on packaged versions of the things they need and I think there's some scheme to stop ant going off to the network
[13:59] <cjwatson> caribou: Fine as far as it goes, but you need to call dh_autoreconf_clean immediately before dh_clean too
[13:59] <caribou> cjwatson: ok, will  do that. unfortunately, right now, this breaks compilation later on
[13:59] <cjwatson> rbasak_: You need to explicitly prefer libpng12-dev so that germinate knows which to prefer
[14:00] <rbasak_> OK, thanks
[14:00] <cjwatson> rbasak_: However, are there any other providers of libpng-dev in universe, even?
[14:00] <rbasak_> cjwatson: not that I can see
[14:00] <cjwatson> rbasak_: I don't see any - which means it's unambiguous and you can just Build-Depends: libpng-dev
[14:00] <rbasak_> OK
[14:01] <cjwatson> rbasak_: It's just that "only one in main" isn't enough
[14:01] <rbasak_> Right. Useful to know - thanks.
[14:02] <rbasak_> Two more issues. Is there a standard answer for a build depends on "locales-all | language-pack-de"? I don't see any locales-all package.
[14:02] <cjwatson> jibel: Unfortunately I don't have any more data than what's in that log :(
[14:02] <cjwatson> rbasak_: locales-all is in Debian
[14:03] <rbasak_> And there's a Suggests on php5-json, which we don't seem to have imported. I could drop that entirely, but I wonder why we're not importing it at least into universe?
[14:03] <cjwatson> rbasak_: So that looks like a build-depends constructed to do the right thing on both distros
[14:03] <rbasak_> s/Suggests/Recommends
[14:03] <rbasak_> OK - great.
[14:05] <cjwatson> rbasak_: php-json has source in the archive but is waiting for a json-c merge before it can build.  https://launchpad.net/ubuntu/+source/php-json/0~git~1+c05ebf+dfsg-2/+build/4638791
[14:06] <cjwatson> Which should be on jodh`'s list by default, I believe, since he touched it last
[14:06] <cjwatson> rbasak_: You should leave the Recommends in place anyway, IMO
[14:06] <cjwatson> Unsatisfied Recommends are maybe unsightly but don't cause a problem, and in this sort of case where they're expected to turn up eventually, better to leave them there
[14:08] <rbasak_> I'm a bit confused. In Debian, php5-json's source package is php5-json, which is why I couldn't find it in Debian. You've pointed me to php-json, whose source is in saucy-proposed but the source is in universe.
[14:08] <rbasak_> why I couldn't find it in Ubuntu
[14:11] <rbasak_> OK, it looks like my chdist cache was out of date. But if I keep php5-json, I still need to drop it to a Suggests since php5-json wont be in main when it's built, right?
[14:12] <cjwatson> Well, it's arguable; perhaps it should be promoted?  I don't know, up to you
[14:12] <cjwatson> rbasak_: And no, in Debian, php5-json's source package is still php-json.
[14:13] <rbasak_> OK, got it. Thanks for going through this with me.
[14:16] <ev> anyone know how we're handling policykit on mobile?
[14:19] <cjwatson> jibel: It kind of looks as though adt-jenkins didn't think it had an XS-Autopkgtest header at the time p-m was processing it, but it's meant to be looking at guaranteed up-to-date Sources files ...
[14:19] <jibel> cjwatson, it seems that test requests are submitted only on dependency change but not the first time a package is uploaded.
[14:19] <jibel> for example plv8 yesterday
[14:20] <cjwatson> jibel: Hmm, it shouldn't make any difference to the code on my side
[14:20] <jibel> there test as been submitted only when libgcc1 has been uploaded
[14:20] <dobey> cjwatson: isn't the header XS-Testsuite: ?
[14:20] <cjwatson> dobey: Sorry, yeah
[14:20] <cjwatson> Braino
[14:21] <jibel> dobey, the header is okay, it is a bug in the interface, I'm trying to find where
[14:21] <jibel> dobey, here you go https://jenkins.qa.ubuntu.com/job/saucy-adt-dirspec/1 and it broke adt-run BTW :/
[14:25] <dobey> jibel: adt-run was already broken :)
[14:32] <caribou> cjwatson: any reason why the dh_autoreconf would create a configure script that is sensibly smaller than the one in the tarball ?
[14:33] <cjwatson> caribou: IIRC autoconf started making use of shell functions to make things more compact
[14:34] <caribou> cjwatson: it also comes up with many more warnings like "configure: WARNING: unknown option 'enable_dependency_tracking', ignoring ..."
[14:35] <caribou> cjwatson: ok, I suspected that the newly created configure script was wrong
[14:38] <cjwatson> caribou: I wouldn't recommend this line of investigation; the odds of success are slim
[14:39] <cjwatson> caribou: Investigate the compilation failure directly instead.  If it leads you to a bug in the generated configure script, fine
[14:39] <cjwatson> caribou: The warning you quote is entirely harmless
[14:39] <caribou> cjwatson: good advice,thanks
[14:40] <unixabg_> cjwatson: greetings, I have persued the boot iso from hard drive a bit and I would like to ask your thoughts on adding a
[14:40] <unixabg_> persistent option which could be used as a read only stack against defalut iso images?
[14:41] <unixabg_> I have read throught the casper code and not sure it is the best thing to offer. But I am not sure how to inject changes
[14:41] <cjwatson> unixabg_: Sorry, I don't think I can help
[14:41] <unixabg_> against defalut iso images. Oh ok.
[14:41] <cjwatson> I only work on casper when I need to fix something specific
[14:42] <cjwatson> Feel free to send a patch - in this case I suspect you'll have difficulty getting design advice in advance, though, sorry
[14:42] <unixabg_> Is there a way to inject on boot changes like knoppix or live-boot does with hooks?
[14:43] <cjwatson> I normally just extract the image by hand and repack
[14:43] <cjwatson> Or, for small things, break=top and edit it on the fly (although tools are limited)
[14:44] <unixabg_> Ok I appreciate your assistance and dialog.
[14:45] <infinity> rbasak: locales-all is a Debian thing, though we may grow it here after I have a talk with pitti.
[14:59] <jibel> pitti, could you review https://code.launchpad.net/~jibel/ubuntu/saucy/autopkgtest/fix_atmostone/+merge/173965 when you have a second.
[15:00] <jibel> pitti, do I need to forward it to Debian too or you can fix it in git directly?
[15:06] <pitti> jibel: I can apply it directly in Debian
[15:06] <pitti> jibel: is there some existing bug associated with this? (doesn't need one, just checking)
[15:14] <dobey> barry: can you please review pindonga's configglue branch asap?
[15:15] <barry> dobey: yes, although right now i'm in a meeting and then i have two other high priority bug fixes to land.  i will definitely get to configglue today
[15:16] <dobey> barry: ok. i need to make a release of ubuntuone-client, and this is blocking it, as almost all the tests fail as a result :)
[15:17] <barry> dobey: :(  it's definitely the third top thing on my list ;)
[15:26] <Sarvatt> barry: updated your bug if you wouldn't mind giving the x-x-v-vmware update a shot, it should fix it and i'll try to get it sponsored if so
[15:27] <barry> Sarvatt: fantastic, thanks.  it will be a little while before i can test this, but hopefully today if nothing else comes up ;)
[15:39] <seb128> barry, hey, did you see my ping earlier about reverting python-configglue to unbreak u1?
[15:40] <barry> seb128: sorry, i did not.  but pindonga has a new version in mp that eliminates the dep.  i plan to review it as soon as my other two higher priority bug fixes have landed ;)
[15:40] <seb128> barry, just curious, what is higher priority than unbreaking u1 not working at all?
[15:41] <barry> seb128: phone stuff i have to land
[15:41] <seb128> barry, hum, k, good luck, I hope you get to the u1 fix today
[15:41] <barry> seb128: and the meeting i'm in right now ;)
[15:41] <barry> seb128: i shall not sleep or eat until then :)
[15:52] <jdstrand> tedg: responding to your email here-- are you implementing the "simple change"?
[15:52] <jdstrand> tedg: and hi! :)
[15:53] <tedg> jdstrand, Uhm, sure.  It should be easy.
[15:53] <tedg> mdeslaur, Did you change it so that the apparmor line in the upstart job can be the null string?
[15:53] <jdstrand> tedg: well, I wasn't sure what you had in mind
[15:54] <tedg> jdstrand, I'd like to start using libupstart there, but we can put a quick hack in to call initctl
[15:55] <jdstrand> tedg: so, short term, what I said, slightly longer term, libupstart?
[15:55] <tvoss_> slangasek, ping
[15:55] <tedg> jdstrand, Yeah, I was hoping that we could use the apparmor line in the upstart job instead of calling aa-exec
[15:55] <tedg> jdstrand, But that doesn't mater too much.
[15:56] <jdstrand> tedg: right, we will soon, but can't today
[15:56] <jdstrand> tedg: we still need to know the profile name though and export that as an env var, right?
[15:57] <tedg> jdstrand, Yup
[15:57] <jdstrand> tedg: ok, so that part was what I thought you were saying was the simple change, and I was curious how you were going to do it without calling desktop-exec twice
[15:57] <jibel> pitti, there is no bug associated with this.
[15:58] <tedg> jdstrand, Flip it so that desktop-exec calls initctl directly.
[15:59] <jdstrand> ah yes
[15:59] <jdstrand> tedg: fyi, once that kernel bug is fixed, we can simply do:
[15:59] <jdstrand> apparmor switch $APP_EXEC_POLICY
[15:59] <jdstrand> exec $APP_EXEC
[16:00] <jdstrand> assuming apparmor switch won't barf if APP_EXEC_POLICY is not defined
[16:00] <jdstrand> mdeslaur: ^
[16:01] <jdstrand> I wonder if we could do:
[16:01] <jdstrand> script
[16:01] <jdstrand>   if [ -n "$APP_EXEC_POLICY" ]; then
[16:01] <jdstrand>     apparmor switch $APP_EXEC_POLICY
[16:01] <jdstrand>   fi
[16:01] <jdstrand>   exec $APP_EXEC
[16:01] <jdstrand> end script
[16:02] <jdstrand> I don't know how 'script' works in upstart jobs though...
[16:04] <tedg> jdstrand, I think that could work, but I thought there was a profile command in the upstart job syntax that mdeslaur added.  We should probably just use that.
[16:04] <jdstrand> tedg: 'apparmor switch' is the profile command
[16:04] <jdstrand> tedg: 'man 5 init'
[16:05] <slangasek> tvoss_: hi
[16:05] <tedg> jdstrand, Ah, I see.  I don't think that can be used in the script area.  I think that's in the body of the job.
[16:06] <jdstrand> that is what I kinda figured. so:
[16:06] <jdstrand> apparmor switch $APP_EXEC_POLICY
[16:06] <jdstrand> exec $APP_EXEC
[16:07] <jdstrand> is what we would want, assuming upstart can handle that when $APP_EXEC_POLICY is not defined
[16:11] <cjwatson> jdstrand: I'm not convinced it will, from the code ...
[16:13] <jdstrand> well, we can fix that
[16:18] <tedg> It's just a simple mater of programing.  :-)
[16:24] <pedronis> Sarvatt: hi, barry pointed me to you about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1199403, I tried the ppa, it fixed the broken vm I had around, X starts, get greeter, dash looks working
[16:24] <Sarvatt> pedronis: thanks a ton, finding a sponsor now :)
[16:26] <Sarvatt> going to just do a version update instead since we needed to and it was only 2 commits (both of which would be backported..), just waiting on test builds of http://sarvatt.com/downloads/merges/vmware-saucy/
[16:28] <seb128> Cimi, ^ is that the issue you are having?
[16:29] <Cimi> seb128, could be
[16:29] <Cimi> seb128, you know how I stop the greeter to respawn?
[16:29] <Cimi> seb128, I can't switch TTY cause it gets back
[16:30] <seb128> Cimi, boot in recovery mode?
[16:31] <Cimi> can't
[16:31] <Cimi> I don't have grub options here :-\
[16:31] <seb128> Cimi, it's in the grub menu
[16:31] <seb128> that should give you a text console
[16:31] <mdeslaur> jdstrand, tedg: that's not what we decided on
[16:31] <tedg> mdeslaur, For click, yes.  This would be for legacy.
[16:32] <mdeslaur> jdstrand, tedg: we decided that since desktop-exec needs to spawn a new upstart job anyway, we'd have two different upstart jobs, one for legacy, and one of click
[16:32] <cjwatson> debs aren't legacy, they're just a different audience
[16:32] <mdeslaur> ok, wrong terminology
[16:32] <tedg> I think for user-facing applications they are, no?
[16:33] <cjwatson> Depends how simple the application is.
[16:33] <cjwatson> click is quite deliberately not trying to solve all problems.
[16:34] <mdeslaur> jdstrand, tedg: since desktop-exec knows if a job is click w/apparmor, or a regular app, it simply uses the appropriate upstart job
[16:34] <tedg> Certainly.  But I can't think of a user application that has those problems.  Almost all are leafs even in a deb repo.
[16:35] <mdeslaur> jdstrand, tedg: we really shouldn't be running a zillion processes each time a user wants to start something
[16:35] <tedg> mdeslaur, Yes, the question is about if the non-click application defines an app-armor profile in it's desktop file.
[16:35] <mdeslaur> tedg: we don't support that
[16:35] <cjwatson> Plenty of user applications don't fall within the limited set of frameworks permissible in click packages, or have non-trivial additional dependencies.
[16:36] <cjwatson> They're just not the sort of thing you'd generally run on a phone.
[16:36] <mdeslaur> tedg: they can use path based attachment for that
[16:37] <jdstrand> mdeslaur: well, why can't we support it?
[16:37] <tedg> Apps packaged with Click aren't only for phones.  And I may also use my phone connected to a monitor and keyboard.
[16:37] <Cimi> Sarvatt, works for me too with vmware ^^
[16:38] <jdstrand> mdeslaur: it is already implemented in upstart-app-launch
[16:38] <mdeslaur> jdstrand: because we don't care?
[16:38] <Sarvatt> its uploaded so that nightmare will be over soon :)
[16:38] <jdstrand> sure we do
[16:38] <mdeslaur> jdstrand: of course not
[16:38] <jdstrand> traditional packaging isn't going to magically disappear
[16:39] <tedg> mdeslaur, I think we care as a migration strategy.
[16:39] <jdstrand> it isn't difficult, ted already implemented it
[16:39] <mdeslaur> ok, so implement a third upstart job for regular apps that specify an apparmor profile
[16:39] <mdeslaur> no biggie
[16:39]  * jdstrand -> phone
[16:39] <mdeslaur> but much better than spawning a zillion processes and mangling environment variables
[16:40] <mdeslaur> tedg: where's the upstream tree reside now?
[16:40] <tedg> mdeslaur, We only increase the number of processes by one if they've defined a profile, otherwise it's a wash.
[16:40] <tedg> jdstrand, Can you try: lp:~ted/upstart-app-launch/split-profile
[16:40] <tedg> mdeslaur, lp:upstart-app-launch
[16:43] <mdeslaur> tedg: ok, now I fail to understand all the stuff that's in upstart-app-launch
[16:44] <jdstrand> mdeslaur: to echo tedg's comment, it is very lightweight right now
[16:44] <mdeslaur> jdstrand: I disagree...we're spawning helpers, shells, etc.
[16:44] <mdeslaur> far from lightweight if you ask me
[16:45] <jdstrand> its one process
[16:45] <jdstrand> desktop-exec
[16:45] <mdeslaur> jdstrand: but you've got "script" stanzas all over
[16:46] <mdeslaur> jdstrand: which spawns shells
[16:46] <jdstrand> it is launched for click, we can also launch it for legacy/traditional
[16:46] <jdstrand> aiui, that isn't for the apparmor bits, that is for application lifecycle tracking
[16:46] <jdstrand> (the post ones that is, the pre is the one I am referring to
[16:46] <jdstrand> )
[16:47] <mdeslaur> jdstrand, tedg: ok, I'm going to leave you two figure it out, as I'm getting dizzy just thinking of how complex this has gotten
[16:47]  * jdstrand doesn't see how it is so complex
[16:48] <jdstrand> it is an upstart job that calls desktop-exec to in a pre-script to set two env vars
[16:48] <jdstrand> (well, atm it is just one, but we want two)
[16:48] <jdstrand> desktop-exec is needed to handle parsing the manifest file
[16:48] <jdstrand> tedg just made it able to parse a desktop file too
[16:49] <jdstrand> (and honor XCanonicalAppArmorProfile=<profile> if it is set)
[16:50] <jdstrand> people can of course continue to use path-based attachment, but that doesn't always work fantastic with interpreted programs, like we've seen with qmlssene
[16:52] <mdeslaur> so you have 1- an upstart job, which spawns 2- a shell, which spawns 3- another upstart job, which spawns 4- another shell, which spawns 5- desktop-exec, which opens 6- the manifest file, and opens 7- the desktop file, which spawns initctl to set the variable and then finally spawns the calculator
[16:52] <cjwatson> tedg: And click isn't for all apps, just the common case that is sufficiently simple.
[16:52] <cjwatson> tedg: I have absolutely no intention of perpetrating second-system-effect by making the mistake of scoping them too widely.
[16:56] <jdstrand> note, I was speaking only of application-legacy.conf, not the whole scheme of determining if something is legacy or not
[17:00] <tedg> mdeslaur, If we could have the apparmor switch command handle the NULL case we could probably just drop the sub jobs.
[17:02] <jdstrand> tedg: is your thinking that desktop-exec would look at the manifest, then if it didn't exist, look at the desktop file?
[17:02] <tedg> jdstrand, Uhm, not sure exactly what would do it.  But something like that.
[17:02]  * jdstrand nods
[17:02] <tedg> I don't think it could be called "desktop-exec" anymore :-)
[17:02] <jdstrand> heh, yeah
[17:03] <tedg> I think we could have one *something* in pre-start and that would set the vars for the job.
[17:03] <jdstrand> tedg: yep
[17:09] <mdeslaur> tedg, jdstrand: ok, if that will simplify it, let me fix upstart to skip stanzas that are null
[17:09] <mdeslaur> s/stanzas/switch stanzas/
[17:17] <mdeslaur> tedg: what uses lsapp?
[17:17] <tedg> mdeslaur, Nothing, just me to debug
[17:18] <tedg> mdeslaur, Doesn't work with the split right now though.  Should work if we can reunify.
[17:18] <mdeslaur> tedg: is that the code that will send a message if the app is already running?
[17:19] <tedg> mdeslaur, I haven't written that code yet.
[17:19] <tedg> mdeslaur, It's just a utility to list instances in a sane way.
[17:19] <mdeslaur> oh! my mistake
[17:19] <mdeslaur> tedg: so how is the message code going to be run?
[17:20] <mdeslaur> tedg: I think we need to start a diagram or something :P
[17:21] <tedg> mdeslaur, Hmm, good point.  I was going to do that in the application job.  Still might have to have two layers.
[17:21] <tedg> mdeslaur, initctl2dot  ;-)
[17:22] <mdeslaur> oh. wow. :)
[17:23] <infinity> tedg: I thought you were joking.  initctl2dot(1) convinced me otherwise.
[17:24] <tedg> Ha, I never joke about visualizations :-)
[17:47] <mdeslaur> tedg: got a few minutes to mumble/hangout?
[17:47] <mdeslaur> tedg: I have a few random thoughts to throw at you
[18:28] <tedg> mdeslaur, Back from lunch, anytime.
[18:31] <mdeslaur> tedg: want to start a hangout?
[18:31] <tedg> mdeslaur, Uhm, no, you start it.  /me can never figure it out :-)
[18:32] <mdeslaur> tedg: https://plus.google.com/hangouts/_/62f0f0f42b1b8fc854906922474629e2c7556059?authuser=1&hl=en
[18:32] <mdeslaur> wow, I can't believe I managed
[20:34] <xnox> interesting on doing android build I'm getting zero ccache hits
[21:54] <cjwatson> tjaalton: reminder to fakesync/merge (as appropriate) libapache2-mod-nss ...