=== Fudgey is now known as Fudge === Noskcaj10 is now known as Noskcaj === _salem is now known as salem_ === cmagina is now known as cmagina-away === salem_ is now known as _salem === asac` is now known as asac === iulian is now known as Guest40084 [04:43] Good morning [04:44] what do i need to do to package bug 1199017 ? the dsc, debian folder and tarball ar all provided? [04:44] bug 1199017 in Ubuntu "[needs-packaging] ubuntuone-credentials" [Wishlist,New] https://launchpad.net/bugs/1199017 [04:44] *are [04:54] 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] ok [06:36] good morning === Guest40084 is now known as iulian [07:16] pitti: hello [07:16] hello mwhudson [07:17] pitti: did you see https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1196440? would you know anything about it? [07:17] Launchpad bug 1196440 in apache2 (Ubuntu) "apache2-mpm-worker-dbgsym is uninstallable" [Undecided,New] [07:17] (i found your fingers on dbgsym stuff :)) [07:19] hmm, apache2's debian/control does have apache2-dbg; I wonder where it went [07:19] ooh [07:19] we explicitly don't build it on ubuntu [07:19] that delta can be dropped now [07:21] mwhudson: doing a test build now [07:22] pitti: ta [07:23] pitti: hey [07:29] ... in the mean time, how do i lie to apt and pretend apache2-dbg is installed? [07:31] mwhudson: you want to build something that depends on the -dbg package? [07:31] hey zyga [07:31] pitti: hey, I've started looking at and experimenting with your dbusmock project [07:32] mwhudson: won't help you in this case, the -dbgsym is empty [07:32] pitti: I wanted to say *thank you* it's really awesome [07:32] pitti: oh ok [07:32] * mwhudson rummages around for his unstripped apache build [07:33] zyga: nice :) === smb` is now known as smb [07:35] 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] 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] m4n1sh: apologies for not getting to that bug yesterday. Going to try to fit it in today [07:37] mwhudson: fix uploaded [07:37] pitti: :) [07:37] pitti: thanks [07:37] zyga: not quite, it's not meant for that; it's primary purpose is to test desktop-side/UI code [07:37] zyga: like, indicators or gnome-settings-daemon [07:38] 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] 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+ but "move workspace up+down" on super+ [07:44] pitti: I see, how do you test upower's dbus interface itself then? [07:44] (actually super and page up/down [07:45] zyga: the test suite calls the "upower" CLI tool [07:45] zyga: but you can just talk to the d-bus interface directly in tests, of course [07:45] pitti: oh [07:46] pitti: do you put upower on a some kind of special, standalone, test bus/ [07:47] zyga: yes, I do; otherwise you couldn't run the tests in "make check"/during package build [07:48] 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] zyga: you can do that with dbus-launch , and setting DBUS_SYSTEM_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS [07:49] zyga: (and then clean up the bus after you've done) [07:49] there are some convenience libraries around that, but that's the gist of it [07:50] pitti: my app runs on the session bus normally [07:50] pitti: is it appropriate to just use that during tests/ [07:50] zyga: ah, then you only need the dbus-launch [07:50] ok [07:51] 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] pitti: indeed it is [07:51] zyga: yes, sure; tests shouldn't assume an existing session bus [07:51] pitti: thanks, I need to look stuff up then :) === tkamppeter_ is now known as tkamppeter [07:52] zyga: http://cgit.freedesktop.org/upower/tree/src/linux/integration-test uses Gio.TestDBus [07:53] pitti: that looks like exactly what I wanted! [07:53] pitti: awesome, thanks [07:58] zyga: you wouldn't use lines 75 and 76 for a session bus === FourDoll1rs is now known as FourDollars [07:58] zyga: and of course Gio.BusType.SYSTEM → .SESSION [08:02] 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] it's getting really annoying for those of us that use u1... [08:03] 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] pitti, no, it's bug #1198480 [08:03] bug 1198480 in ubuntuone-client (Ubuntu) "ubuntuone-syncdaemon crashed with AssertionError in expand_user()" [Undecided,Confirmed] https://launchpad.net/bugs/1198480 [08:04] ah, it just crashed again, reporting now [08:04] pitti, ubuntuone-syncdaemon doesn't start for me [08:04] pitti, does it work for you? [08:04] indeed not [08:04] 0:00 /usr/lib/x86_64-linux-gnu/indicator-sync/indicator-sync-service [08:04] unless this replaced it somehow [08:04] but no ubuntuone-syncdaemon process or similar [08:05] pitti, no, can you try running manually ubuntuone-syncdaemon ? [08:05] pitti, /usr/lib/ubuntuone-client/ubuntuone-syncdaemon [08:05] yep, AssertionError [08:05] righht [08:05] it's broken for a week, since barry updated python-configglue [08:06] 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] bug 1199659 in software-center (Ubuntu) "software-center-dbus crashed with UnicodeDecodeError in parse_applications_menu(): 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/1199659 [08:07] seb128: well, we should [08:08] mwhudson: argh, my upload was rejected, there is a -2.4 stuck in -proposed [08:08] mwhudson: I'm afraid I can't fix this quickly then [08:08] pitti, Laney and dobey were discussing s-c but I don't know if that's this bug [08:09] no I was just fixing the tests [08:10] pitti: you could fix it in -proposed if the version there has the same problem [08:10] 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] pitti: pull-lp-source is your friend [08:13] cjwatson: ah, the -proposed version already drops teh ubuntu specific -dbg handling, so much the better [08:13] 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] +1 for reverting [08:14] seb128: I think by now it can wait for barry to wake up ... [08:14] I'm not massively up to speed with the problem, sorry [08:14] 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] right, I pinged him yesterday already but nothing happened [08:14] but yeah, it has been broken for a week, it can be broken for a few extra hours [08:15] 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] seb128: ah, I guess it wasn't the latest upload, but 1.1.0-0ubuntu1 instead? [08:16] pitti, the issue started with 1.1.0 not 1.1.1 [08:16] that looks harder to revert [08:16] yeah :/ [08:16] python3-configglue has zero rdepends, tohugh [08:18] I think the problem is that the update brings in configparser which causes conflicts or something [08:18] https://code.launchpad.net/~ricardokirkner/configglue/from-future-remove-configparser/+merge/173806 was posted yesterday [09:03] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity [09:21] * dholbach hugs infinity [09:21] I'm working on a patch that requires a modification to configure.ac that comes from upstream [09:22] caribou: Nothing wrong with that. [09:22] I suppose that this means that debian/rules needs to run autoreconf but for some reason, it fails on me [09:22] infinity: well, just changing configure.ac breaks the build :-/ [09:22] infinity: let me paste the error... [09:22] 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] infinity: http://paste.ubuntu.com/5861074/ [09:23] infinity: that's what I did : I added an override to dh_auto_configure to run autoreconf before continueing [09:23] That's not really a helpful error without knowing what it's complainign about, or what your patch is. [09:24] infinity: just adding /bin/*/libc.so.* to a subshell search with 'ls' [09:24] caribou, you should better use dh-autoreconf and --with autoreconf [09:24] caribou, rather overwriting [09:24] rather *than* overwriting [09:25] caribou: s/bin/lib/ I assume, though any autoconf check for libc is probably broken by design. [09:25] (though that will probably not fix your issue if autoreconf fails there) [09:25] 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] oh, btw if I rm acinclude.m4 & rerun autoreconf --force --install in the schroot it works [09:26] infinity: let me paste it... [09:27] infinity: http://paste.ubuntu.com/5861086/ [09:27] seb128: ok, I'll do that [09:27] 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] Yeah, dh-autoreconf is the way, the truth, and the life [09:28] 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] 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] seb128: ugh [09:29] patching autogenerated files is a timebomb [09:29] 557918 [09:30] 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] cjwatson, well, patching both configure.ac and configure should be fine ... but yeah, better to autoreconf when you can [09:30] cjwatson: I do it all the time (patching the source *and* the generated file, never just the latter) [09:30] cjwatson, sometime you can get away with patching the autogenerated ones though [09:30] sounds like you need to find the bug in acinclude.m4 and patch that so that autoreconf works [09:30] 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] infinity: here's the bug : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/1124048 [09:31] Launchpad bug 816153 in dante (Ubuntu Precise) "duplicate for #1124048 dante-server using the wrong libc.so" [Medium,Triaged] [09:32] sorry I pasted the Dupe : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153 [09:32] Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,Triaged] [09:34] btw, I had the same build failure before adding the autoreconf bit [09:34] well, this was last night, need to test it again [09:35] dlopening libc makes me a sad panda. But fixing that looks like it would be a massive patch. [09:37] caribou: You could just add --with-libc=libc.so.6 to configure. [09:38] infinity: isn't that hardcoding the version ? not that it should change much [09:38] caribou: It is, and it's wrong for Debian (since it's not always 6) [09:38] caribou: Meh, I guess fixing their weird search works. [09:39] Fixing their dlopens would be better, but that looks painful. [09:39] ok FYI, just patching configure.ac & rebuilding w/o autoreconf yield to the same error [09:40] full build error : http://paste.ubuntu.com/5861110/ [09:41] 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] caribou: That just looks like a missing build-dep. [09:44] * infinity tests here. [09:44] patching configure.ac and rebuilding without autoreconf is always wrong [09:44] infinity: I added automake1.9 but it didn't change a thing [09:45] and the failure is strictly less interesting than what you get from autoreconf [09:45] cjwatson: yeah, I know I figured out the autoreconf afterward (I'm an autotool noob) [09:45] don't add automake1.9, that entire path is unreliable and not worth debugging [09:45] cjwatson: but I seem to get the same failure with & without the autoreconf [09:45] I wish I hadn't read that debian/rules. [09:46] 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] take my word for that :) [09:53] 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] cjwatson: I can add that in my patch, since it won't build without. Or a separate quilt patch ? [09:54] Yeah, I wouldn't argue against the m4 being fixed regardless. [09:54] 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] caribou: I'd do it in a separate patch but I don't think it's that important [09:54] however: [09:54] 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] Besides, my patch could get you into timestamp skews and force and autoreconf which would hit build failures anyway. :P [09:55] so I don't think fixing acinclude.m4 is compatible with infinity's patch-the-generated-file-as-well approach [09:55] s/and/an/ === Guest71585 is now known as Zic [09:55] 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] 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] should be safest all round [09:57] cjwatson: ok, will do that & let you know that comes out [09:57] it will have to be sponsored anyway [09:57] cjwatson: infinity thanks for the valuable help & learning experience :) === vanhoof_ is now known as vanhoof === ev_ is now known as ev === balloons_ is now known as balloons [09:59] pitti: quick question, your upower test code uses Gio.DBuxProxy, is there any advantage over using python-dbus proxy objects? [10:00] zyga: not much except avoiding yet another dependency [10:00] I already need GI there anyway, so I'm using the GI bindings instead of python-dbus [10:00] ok, thanks for the explanation [10:00] zyga: but they are both roughly equivalent in terms of comfort and functinoality [10:01] I was just looking for hidden dependencies [10:17] 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] hey ev [10:17] ev: still catchign up with stuff after my short holidays; I haven't yet looked at it, but will do this afternoon [10:17] pitti: awesome, thank you. And welcome back :) [10:36] ev: reviewed, I left some commentary in the MP [10:37] pitti: thanks! [10:53] cjwatson, Riddell: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1199731 [10:53] Launchpad bug 1199731 in grub2 (Ubuntu) "config script thinks grub.d contains all variables" [Low,Triaged] === 6JTAA2M02 is now known as tvoss [10:56] 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] the WhoopsiePreferences service, that is === MacSlow is now known as MacSlow|lunch [11:01] apachelogger: thanks, fixed in Debian bzr now: http://paste.ubuntu.com/5861279/ [11:02] weeh === jpds is now known as Guest46086 [11:02] cjwatson: will that land in saucy? [11:02] Yeah [11:03] I'll probably roll up an unstable upload this weekend, and merge it [11:03] if that's OK [11:03] cjwatson: awesome :) [11:04] Riddell: ^ we'll have plymouth again ;) [11:05] apachelogger: ooh exciting [11:23] sforshee: bisected [11:23] I hate guessing correctly [11:23] 1acba98f810a14b1255e34bc620594f83de37e36 [11:23] breaks my macbook efi boot [11:47] cjwatson: did rbasak get back to you regarding the php5 merge? === victorp_ is now known as victorp [11:50] mdeslaur: Not as yet [11:56] pitti: I cannot import Gio.TestDBus, is that available on precise? === MacSlow|lunch is now known as MacSlow [12:14] during the process of building packages, is accessing internet OK or is it forbidden? [12:15] forbidden ... [12:18] accessing internet resources other than the archive itself (for build-deps and the like) is a recipe for unreliability anyway === greyback is now known as greyback|lunch [12:20] zyga: ah, it was added in glib 2.33, so no [12:21] zyga: OOI, why do you need this on precise? [12:21] cjwatson, agreed. I was wondering how you guys are able to build scala without internet access [12:21] while building scala, ant does some dependency resolution and downloading [12:23] pitti: welcome to the PES area, everything we do needs to be on precise [12:24] pitti: I started running precise not to get used to all the shiny good stuff added later [12:24] well, that's why we call it a development release :) [12:24] pitti: can I somehow spawn dbus as non-root and use it to register my service there [12:24] pitti: well, 12.04 is quite older than 12.10 and 13.04 [12:24] zyga: so you won't have umockdev either; if you need this, I'll need to jump through some hoops [12:25] pitti: it's not about saucy sadly :/ [12:25] zyga: sure, all of this (like upower's test suite) runs as normal user [12:25] ok [12:25] thanks! [12:25] * ogra_ hopes pitti at least takes a video for us when doing that :) [12:25] zyga: dbus-launch just starts a session bus [12:25] ogra_: tried, but broke the camera during jumping! [12:26] haha === pete-woods is now known as pete-woods-away === pete-woods-away is now known as pete-woods [12:42] infinity: cjwatson: Does that look like a decent use of dh_autoreconf : http://paste.ubuntu.com/5861491/ [12:42] I patched acinclude.m4 so I no longer have the aclocal failure [12:43] but it now fails at compilation :-/ [12:47] * caribou is wondering if those kind of questions would be better suited for #ubuntu-app-devel === cmagina-away is now known as cmagina [12:59] not a big deal, and i'm just going to not upgrade right now [12:59] but [12:59] http://paste.ubuntu.com/5861525/ [12:59] smoser: don't dist-upgrade :) [12:59] (alpine and firefox are specifrically held) but the xserver stuff is odd and rmoving ubuntu-desktop didn't seem right. [13:00] specifrically . [13:00] smoser: yeah someone reported something similar over the the ML [13:00] smoser: but i have the latest upgrades and have not seen any issues [13:00] odd. [13:00] but better to hold off [13:00] smoser: do you have -proposed enabled? maybe that's it? [13:01] doesn't look like it. === Quintasan_ is now known as Quintasan === greyback|lunch is now known as greyback [13:07] cjwatson, mdeslaur: sorry, I'm working on it (php merge) [13:07] rbasak: thanks [13:10] if i add autopkgtest support to a package, and upload it, how long before i see those tests happening on jenkins? [13:20] dobey, when binaries are in -proposed [13:21] jibel: and if i don't see the tests on jenkins, even after the binaries are in release? [13:21] dobey, which package? [13:22] jibel: dirspec [13:23] * jibel looks === zoktar_ is now known as zoktar === broder_ is now known as broder === dendroba` is now known as dendrobates === Nigel_ is now known as G === ssweeny` is now known as ssweeny === debfx_ is now known as debfx === pete-woods is now known as pete-woods-lunch === Riddelll is now known as Riddell [13:45] 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] 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] jibel: i take it you didn't find it either? :) [13:47] dobey, still looking, but right I didn't find why yet [13:48] 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 === Ursinha_ is now known as Ursinha === henrix_ is now known as henrix === balloons_ is now known as balloons === lilstevie_ is now known as lilstevie [13:59] 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] caribou: Fine as far as it goes, but you need to call dh_autoreconf_clean immediately before dh_clean too === NishanthMenon__ is now known as NishanthMenon [13:59] cjwatson: ok, will do that. unfortunately, right now, this breaks compilation later on [13:59] rbasak_: You need to explicitly prefer libpng12-dev so that germinate knows which to prefer [14:00] OK, thanks [14:00] rbasak_: However, are there any other providers of libpng-dev in universe, even? [14:00] cjwatson: not that I can see [14:00] rbasak_: I don't see any - which means it's unambiguous and you can just Build-Depends: libpng-dev [14:00] OK [14:01] rbasak_: It's just that "only one in main" isn't enough [14:01] Right. Useful to know - thanks. [14:02] 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] jibel: Unfortunately I don't have any more data than what's in that log :( [14:02] rbasak_: locales-all is in Debian [14:03] 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] rbasak_: So that looks like a build-depends constructed to do the right thing on both distros [14:03] s/Suggests/Recommends [14:03] OK - great. [14:05] 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] Which should be on jodh`'s list by default, I believe, since he touched it last [14:06] rbasak_: You should leave the Recommends in place anyway, IMO === bdrung_ is now known as bdrung [14:06] 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] 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. === pete-woods-lunch is now known as pete-woods [14:08] why I couldn't find it in Ubuntu [14:11] 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] Well, it's arguable; perhaps it should be promoted? I don't know, up to you [14:12] rbasak_: And no, in Debian, php5-json's source package is still php-json. [14:13] OK, got it. Thanks for going through this with me. === rbasak_ is now known as rbasak === lynxman_ is now known as lynxman === zoktar_ is now known as zoktar [14:16] anyone know how we're handling policykit on mobile? === Cimi_ is now known as Cimi [14:19] 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] cjwatson, it seems that test requests are submitted only on dependency change but not the first time a package is uploaded. [14:19] for example plv8 yesterday [14:20] jibel: Hmm, it shouldn't make any difference to the code on my side [14:20] there test as been submitted only when libgcc1 has been uploaded [14:20] cjwatson: isn't the header XS-Testsuite: ? [14:20] dobey: Sorry, yeah [14:20] Braino [14:21] dobey, the header is okay, it is a bug in the interface, I'm trying to find where [14:21] dobey, here you go https://jenkins.qa.ubuntu.com/job/saucy-adt-dirspec/1 and it broke adt-run BTW :/ === psivaa-afk is now known as psivaa [14:25] jibel: adt-run was already broken :) === popey_ is now known as popey === geser_ is now known as geser === cmagina is now known as cmagina-away [14:32] cjwatson: any reason why the dh_autoreconf would create a configure script that is sensibly smaller than the one in the tarball ? [14:33] caribou: IIRC autoconf started making use of shell functions to make things more compact [14:34] cjwatson: it also comes up with many more warnings like "configure: WARNING: unknown option 'enable_dependency_tracking', ignoring ..." === shadeslayer_ is now known as shadeslayer [14:35] cjwatson: ok, I suspected that the newly created configure script was wrong === mzanetti_ is now known as mzanetti_sa [14:38] caribou: I wouldn't recommend this line of investigation; the odds of success are slim === mzanetti_sa is now known as mzanetti [14:39] caribou: Investigate the compilation failure directly instead. If it leads you to a bug in the generated configure script, fine [14:39] caribou: The warning you quote is entirely harmless [14:39] cjwatson: good advice,thanks [14:40] 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] persistent option which could be used as a read only stack against defalut iso images? === cmagina-away is now known as cmagina === manjo` is now known as manjo [14:41] 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] unixabg_: Sorry, I don't think I can help [14:41] against defalut iso images. Oh ok. [14:41] I only work on casper when I need to fix something specific [14:42] Feel free to send a patch - in this case I suspect you'll have difficulty getting design advice in advance, though, sorry [14:42] Is there a way to inject on boot changes like knoppix or live-boot does with hooks? [14:43] I normally just extract the image by hand and repack [14:43] Or, for small things, break=top and edit it on the fly (although tools are limited) [14:44] Ok I appreciate your assistance and dialog. [14:45] rbasak: locales-all is a Debian thing, though we may grow it here after I have a talk with pitti. === cmagina is now known as cmagina-away [14:59] pitti, could you review https://code.launchpad.net/~jibel/ubuntu/saucy/autopkgtest/fix_atmostone/+merge/173965 when you have a second. [15:00] pitti, do I need to forward it to Debian too or you can fix it in git directly? === enrico__ is now known as enrico === shadeslayer is now known as Guest33135 === charles_ is now known as Guest68669 === yofel_ is now known as Guest48668 === Lutin is now known as Guest145 === Nigel_ is now known as Guest37357 === christoffer is now known as Guest17196 === ffio is now known as Guest47909 === jbicha is now known as Guest68084 [15:06] jibel: I can apply it directly in Debian [15:06] jibel: is there some existing bug associated with this? (doesn't need one, just checking) === Guest33135 is now known as shadeslayer === Guest68084 is now known as jbicha [15:14] barry: can you please review pindonga's configglue branch asap? [15:15] 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] 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] dobey: :( it's definitely the third top thing on my list ;) === masACC is now known as maswan [15:26] 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] Sarvatt: fantastic, thanks. it will be a little while before i can test this, but hopefully today if nothing else comes up ;) [15:39] barry, hey, did you see my ping earlier about reverting python-configglue to unbreak u1? [15:40] 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] barry, just curious, what is higher priority than unbreaking u1 not working at all? [15:41] seb128: phone stuff i have to land [15:41] barry, hum, k, good luck, I hope you get to the u1 fix today [15:41] seb128: and the meeting i'm in right now ;) [15:41] seb128: i shall not sleep or eat until then :) [15:52] tedg: responding to your email here-- are you implementing the "simple change"? [15:52] tedg: and hi! :) [15:53] jdstrand, Uhm, sure. It should be easy. [15:53] mdeslaur, Did you change it so that the apparmor line in the upstart job can be the null string? [15:53] tedg: well, I wasn't sure what you had in mind [15:54] jdstrand, I'd like to start using libupstart there, but we can put a quick hack in to call initctl [15:55] tedg: so, short term, what I said, slightly longer term, libupstart? [15:55] slangasek, ping [15:55] jdstrand, Yeah, I was hoping that we could use the apparmor line in the upstart job instead of calling aa-exec [15:55] jdstrand, But that doesn't mater too much. [15:56] tedg: right, we will soon, but can't today [15:56] tedg: we still need to know the profile name though and export that as an env var, right? [15:57] jdstrand, Yup [15:57] 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] pitti, there is no bug associated with this. [15:58] jdstrand, Flip it so that desktop-exec calls initctl directly. [15:59] ah yes [15:59] tedg: fyi, once that kernel bug is fixed, we can simply do: [15:59] apparmor switch $APP_EXEC_POLICY [15:59] exec $APP_EXEC [16:00] assuming apparmor switch won't barf if APP_EXEC_POLICY is not defined [16:00] mdeslaur: ^ [16:01] I wonder if we could do: [16:01] script [16:01] if [ -n "$APP_EXEC_POLICY" ]; then [16:01] apparmor switch $APP_EXEC_POLICY [16:01] fi [16:01] exec $APP_EXEC [16:01] end script [16:02] I don't know how 'script' works in upstart jobs though... [16:04] 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] tedg: 'apparmor switch' is the profile command [16:04] tedg: 'man 5 init' [16:05] tvoss_: hi [16:05] 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] that is what I kinda figured. so: [16:06] apparmor switch $APP_EXEC_POLICY [16:06] exec $APP_EXEC [16:07] is what we would want, assuming upstart can handle that when $APP_EXEC_POLICY is not defined [16:11] jdstrand: I'm not convinced it will, from the code ... [16:13] well, we can fix that [16:18] It's just a simple mater of programing. :-) === Guest48668 is now known as yofel [16:24] 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] Launchpad bug 1199403 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [Critical,Triaged] [16:24] pedronis: thanks a ton, finding a sponsor now :) [16:26] 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] Cimi, ^ is that the issue you are having? [16:29] seb128, could be [16:29] seb128, you know how I stop the greeter to respawn? [16:29] seb128, I can't switch TTY cause it gets back [16:30] Cimi, boot in recovery mode? [16:31] can't [16:31] I don't have grub options here :-\ [16:31] Cimi, it's in the grub menu [16:31] that should give you a text console [16:31] jdstrand, tedg: that's not what we decided on [16:31] mdeslaur, For click, yes. This would be for legacy. [16:32] 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] debs aren't legacy, they're just a different audience [16:32] ok, wrong terminology [16:32] I think for user-facing applications they are, no? [16:33] Depends how simple the application is. [16:33]