[00:00] <infinity> jtaylor: To be fair, the s390x ABI break (and a SuperH ABI break I need to commit) was widely discussed, and everyone went into it with eyes wide open.
[00:00] <infinity> jtaylor: It would never happen on x86, because there's zero chance of getting everyone to recompile everything.
[00:00] <Bluefoxicy> that's the best way t oget a gnat in your eye
[00:00] <jtaylor> yeah, I guess if debian wouldn't test s390x no one would have noticed
[00:00] <jtaylor> or cared
[00:00] <Bluefoxicy> yeah but debian is insane
[00:00] <Bluefoxicy> they even have an x86-freebsd distro now
[00:01] <Bluefoxicy> I often think Debian builds for architectures just for the hell of it
[00:01] <jtaylor> this topic is somewhat offtopic for this channel though
[00:02] <Bluefoxicy> yeah I was just trying to probe a simple question
[00:03] <Bluefoxicy> it always turns into a huge philosophical debate when I do that
[00:18] <infinity> hallyn_: I'm no expert, but I expect that adding a patch to debian/patches/README instead of debian/patches/series probably won't apply it?
[00:20] <infinity> hallyn_: Oh, nevermind, it's simple-patchsys.  Ew.
[01:33] <hallyn_> infinity: :)
[05:10] <Mirv> dobey: I'd say MIR, not a high maintenance package with purely language pack like content
[06:00] <pitti> Good morning
[06:01] <Unit193> Howdy.
[06:02] <pitti> hey Unit193, how are you? thanks for confirming
[06:03] <Unit193> pitti: Sure.  Only seen the random "session out of sync" issue (can't reboot, suspend, poweroff, etc.) and some strange bug on upgrade that unmutes and sets the volume to 90%, but otherwise smooth sailing.
[06:11] <pitti> Unit193: but the logind one should be fixed now, right?
[06:11] <pitti> volume> that's nothing that the init systemd touches, I'm afraid
[06:13] <Unit193> Haven't seen it within the past week or two.  And figured it might be systemd/logind as it seemed to hit only with systemd upgrades, but no matter.
[06:39] <pitti> smoser, utlemming: oh, cloud images switched to systemd already? there are some "unable to connect to upstart" messages, and they hang now; is that from https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1072-0ubuntu1 or was the init system changed in the image build process?
[06:40] <pitti> ah, they are timing out trying to talk to <IP_ADDRESS>
[06:41] <pitti> hm, odd, http://cloud-images.ubuntu.com/vivid/current/vivid-server-cloudimg-amd64.manifest shows that it has upstart, and no systemd-sysv; but the output is definitively systemd
[06:42] <pitti> ah, init=/lib/systemd/systemd
[06:52] <pitti> filed bug 1427999 to track this
[07:02] <tmpRAOF> Hey, anyone feel like giving a second-opinion on https://code.launchpad.net/~afrantzis/mir/automate-package-abi-versioning/+merge/251442 ?
[07:03] <tmpRAOF> I'm uncomfortable with the extent of debian/control generation, and it's location, but maybe other people are more sanguine :)
[07:47] <dholbach> good morning
[08:27] <pitti> cjwatson: could I pick your brain about seed handling? (bug 1428026)
[08:33] <pitti> cjwatson: i. e. do I need to copy required (for keeping upstart) and minimal (no actual change) to ubuntu-touch.vivid as {required,minimal}-touch, and adjust STRUCTURE accordingly, or is there an easier way?
[08:33] <pitti> also, I'm not sure whether we shoudl actually build an ubuntu-minimal-touch package; we could just fold everything into ubuntu-sdk and ubuntu-touch, as on touch you can't individually uninstall/upgrade them anyway
[08:34] <pitti> ogra_: ^ do you have an opinion on this? or "I don't care"?
[08:40] <ogra_> pitti, as long as we dont regress in any way and as long as the new way is slightly documented (with a mail or so) i'm in the "don't care" dept.
[08:41] <ogra_> it is not like minimal changes a lot
[08:41] <pitti> ogra_: ack, thanks; I'm leaning towards the "put all dependendies into ubuntu-touch", I don't see much value in having an ubuntu-touch-minimal binary metapackage
[08:42] <pitti> (as soon as I figure out how to do either solution.. :) )
[08:42] <ogra_> right, just make it a clear section in the seed file
[08:43] <ogra_> you might want to check with the SDK guys, not sure if they need minimal in their builder chroots (i dont know how the SDK creates them)
[08:43] <pitti> ogra_: how do you mean? add a comment to it that says that the only difference should be upstart vs. systemd-sysv?
[08:43] <pitti> ack
[08:43] <ogra_> pitti, no add a caption at the bottom "minimal" or some such ...
[08:44] <pitti> ogra_, cjwatsonL
[08:44] <pitti> erk
[08:44] <pitti> ogra_, cjwatson: http://paste.ubuntu.com/10524629/ is my first attempt, but that's apparently not sufficient yet
[08:44] <ogra_> and add them below ... i.e. dont merge them alphabetically in the other sections in the touch seed or some such :)
[08:45] <pitti> ogra_: oh, I didn't move them around (see pastebin); I don't know whether the order matters, but I'm fine with reordering them
[08:46] <pitti> (I just don't understand what you mean)
[08:46]  * pitti <- seed n00b
[08:46] <ogra_> pitti, ah, i thought you would just add them to the "touch" file
[08:47] <pitti> ogra_: hm, wouldn't that make them harder to maintain? I thought in STRUCTURE I could just add the "dependency"
[08:47] <ogra_> though i see that would break sdk-libs
[08:47] <pitti> and I don't wnat to copy them into both sdk-libs and touch
[08:47] <ogra_> yeah, i didnt know there were other "required" deps
[09:11] <doko> jamespage, zul:  libvirt-daemon isn't packaged in libvirt. looks like the package was never merged
[09:20] <doko> tjaalton, you synced freeipa, now ftbfs on powerpc and ppc64el, stuck in -proposed
[09:20] <Odd_Bloke> pitti: Where/how are you booting those cloud images?
[09:21] <pitti> Odd_Bloke: locally in QEMU (adt-buildvm-ubuntu-cloud)
[09:21] <pitti> Odd_Bloke: i. e. with a local seed .iso image
[09:22] <tjaalton> doko: ok, I'll have a look
[09:24] <pitti> cjwatson: my current progress is in https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1428026/comments/1 but I'm afraid now I really need your help
[09:32] <doko> tbb: you synced tbb, now ftbfs on arm64, powerpc, ppc64el
[09:35] <doko> Logan: you synced tbb, now ftbfs on arm64, powerpc, ppc64el
[09:36] <cjwatson> pitti: Aren't we going to have terrible problems getting debootstrap to do the right thing during image builds?
[09:36] <pitti> cjwatson: yeah, that would have been my next question -- how does ubunut-minimal actually land on images, given that it's not a dependency of anything
[09:37] <pitti> debootstrap doesn't install ubuntu-minimal, or does it? it's priority: important, not required
[09:37] <cjwatson> debootstrap installs Priority: important stuff, unless you take special measures to tell it not to.
[09:37] <pitti> I would have assumed that ubuntu-minimal is hardcoded somewhere in the touch image build process, and it would need to change to ubuntu-minimal-touch
[09:37] <pitti> ah, so that's how it gets there
[09:37] <cjwatson> Avoiding ubuntu-minimal is Really Hard.
[09:38] <cjwatson> I mean, as it happens, the touch build process does hardcode ubuntu-minimal (in livecd-rootfs)
[09:38] <cjwatson> But I'm fairly sure it's there already by the time that takes effect ... would have to check build logs
[09:42] <pitti> cjwatson: aye, confirmed that debootstrap pulls in ubuntu-minimal
[09:43] <pitti> cjwatson: that might explain why "init" is required/essential in Debian, but systemd-sysv or sysvinit-core aren't
[09:44] <cjwatson> pitti: I will have to think about this; how to express it in the seeds is a secondary concern
[09:44] <pitti> cjwatson: do alternatives work in seeds, i. e. could we change ubuntu-minimal to "systemd-sysv | upstart" and explicitly seed upstart in ubunut-touch?
[09:44] <cjwatson> pitti: Well, Essential isn't transitive, but required is
[09:44] <cjwatson> pitti: No
[09:45] <cjwatson> pitti: We could manually hack the ubuntu-meta source package to express that, but I'd prefer to explore other options first
[09:45] <pitti> then as a third option we could replace upstart with "init" in ubuntu-minimal, and seed upstart in touch?
[09:45] <pitti> and promote init to main and to required
[09:45] <cjwatson> pitti: That might work, but will still require the build process to remove systemd-sysv when installing upstart, which it may not be willing to do
[09:46] <cjwatson> pitti: systemd-sysv is functionally Priority: required in Debian according to debootstrap, even if the overrides don't say that
[09:46] <pitti> *nod*
[09:47] <cjwatson> That's just a lazy ftpmaster bug :)
[09:47] <caribou> I'm fixing a Universe package that is synced from debian. Should I remove debian's Uploader: field in the control file and only leave the XSBC-Original-Maintainer ?
[09:47] <cjwatson> caribou: Just run update-maintainer
[09:47] <cjwatson> (which leaves Uploaders alone)
[09:47] <caribou> cjwatson: hmm thanks; didn't know about this one
[09:48] <darkxst> didrocks, doko, grilo-plugins-extra should stay in universe, just -base is getting promoted to main
[09:48] <cjwatson> pitti: The third option will potentially leave germinate a bit confused, but it *might* not matter
[09:49]  * pitti sends a summary to the bug
[09:50] <pitti> cjwatson: so it seems the main thing to test is whether the image build process gets along with replacing systemd-sysv with upstart; can this be tested locally somehow?
[09:53] <cjwatson> pitti: It can with some effort, but I'm still caffeinating and thinking about this
[09:54] <pitti> cjwatson: woudl it help if I put the ubuntu-minimal upstart->init and adding "upstart" to ubuntu-touch changes in a PPA?
[09:55] <pitti> (we also need to seed systemd-sysv on ubuntu-standard then, so that we actually get this on upgrades; but I'll test that myself)
[09:55] <cjwatson> pitti: Not really
[09:55] <cjwatson> Too many variables confounding the test when PPAs are involved
[09:55] <cjwatson> (At least at that level)
[09:59] <infinity> pitti: Did you decide against using the "init" package to mirror the Debian setup?
[10:00] <pitti> infinity: we haven't really done any decision wrt. "init"; just mostly ignored it so far
[10:00] <cjwatson> I think, at least, having ubuntu-minimal depend on init is a good idea at minimum for this, because it will mean we don't have to remove ubuntu-minimal to make ubuntu-touch work.
[10:00] <infinity> Oh, I see, the touch/non-touch split makes it a Very Bad Idea to make anything Essential.
[10:01] <cjwatson> init doesn't have to be Essential, just used as indirection from ubuntu-minimal.
[10:01] <pitti> infinity: we merely updated its dependencies to reflect ubuntu's init systems (no sysvinit, upstart the defualt), but even the package description is still wrong :)
[10:01] <cjwatson> Although it wouldn't hurt *this* part of it if it were.
[10:01] <infinity> cjwatson: Well, init as Essential (which it is in Debian), and then dropping all but the systemd dep seemed like a simple way to force the issue on upgrade.  But that's not what touch wants, so that wouldn't work.
[10:01] <cjwatson> Both touch and non-touch would have init, just its dependencies satisfied in a different way.
[10:01] <pitti> at least it needs to be in main, and at the same time we coudl also fix its priority?
[10:02] <cjwatson> Its priority will be (semi-)magically fixed after it's seeded in the place we want.
[10:02] <pitti> infinity: right, hence my other idea of adding systemd-sysv to ubuntu-standard
[10:02] <pitti> (standard isn't on touch)
[10:02] <infinity> pitti: I guess if we take the view that any system without standard installed isn't ubuntu proper, and thus we don't care if upgrades do the switch...\
[10:02] <pitti> I tested upgrade with upstart -> systemd in ubuntu-minimal (in a PPA); I expect it to work the same way with init+systemd-sysv in standard, but of course I'll test that again
[10:03] <cjwatson> standard is an option, but I'm a bit wary of having to chase up other debootstrapped environments that historically expect an init.
[10:03] <infinity> cjwatson: init as Essential fixes debootstrap.
[10:03] <infinity> cjwatson: The standard dep is just how pitti proposes forcing the switch.
[10:03] <cjwatson> infinity: Sure, in which case it would also be in ubuntu-minimal.
[10:03] <pitti> yeah, with "init" it would have some init
[10:03] <cjwatson> infinity: Oh, umm, pretty sure germinate-update-metapackage would filter that
[10:04] <cjwatson> It'd have to be written manually in ubuntu-meta/debian/control
[10:04] <infinity> That's not rocket surgery.
[10:04] <pitti> so ubuntu-minimal is on touch+desktop+server and has "init", ubuntu-standard is not on touch and has systemd-sysv, ubuntu-touch has upstart
[10:04] <infinity> And could be dropped post-16.04
[10:04] <pitti> cjwatson: you mean it would filter out an explicit upstart or sytemd-sysv seed?
[10:05] <cjwatson> Yeah, because it won't include stuff that's already effectively in inner seeds
[10:05] <cjwatson> But as I say it can be written by hand
[10:05] <pitti> ah, so that wouldn't affect -touch, but -standard, I see
[10:05] <cjwatson> Probably both actually
[10:05] <cjwatson> pitti: So as I read it that leaves two questions: (1) is that enough to fix upgrades, (2) will the touch build process work with this scheme
[10:06] <pitti> as upstart isn't in the "inner seed"
[10:06] <cjwatson> Er, yeah, you're right
[10:06] <pitti> cjwatson: right; I'm happy to test (1), that's easy; I'm not sure how to test  (2) without actually having it in the archive
[10:06] <pitti> for (1) I'm going to prepare a PPA, but you said that doesn't help with (2)
[10:06] <cjwatson> I can test (2)
[10:06] <cjwatson> It only needs testing that the relevant apt-get line DTRT
[10:06] <pitti> we need to promote init to main for that, right?
[10:07] <cjwatson> I can set it up by hand
[10:07] <cjwatson> But for actually implementing this, yeah
[10:07]  * pitti promotes it, should be harmless
[10:07] <infinity> ... he says, before triggering an apt bug.
[10:07] <pitti> at worst the next archive admin will demote it again in a few days, if we don't update the seeds by then?
[10:07] <infinity> mvo_: Did we ever hunt down that weird apt bug that seemed to cause a massive sad on upgrades when the required/essential sets changed?
[10:08] <pitti> infinity: is that just your usual optimistic self, or do you actually know an apt bug that gets triggered by thaht?
[10:08] <pitti> eek
[10:08] <pitti> well, promoting to main doesn't change hte optional priority yet, that'll just appear in priority-mismatches.txt
[10:14] <mvo_> infinity: I'm not sure, do you have a example issue? if so I can have a look
[10:16] <infinity> mvo_: We had examples long ago.  Remember it happened when I made util-linux depend on initscripts to force initscripts into the Essential set, and the world exploded?
[10:17] <infinity> mvo_: And we had to back that out a day or two before release.
[10:18] <infinity> mvo_: I think you set up reproduction environments at the time and such, but then probably got sidetracked with Other Things and stopped being my whipping boy. :P
[10:19] <pitti> tseliot: good morning!
[10:19] <tseliot> pitti: good morning to you
[10:19] <pitti> tseliot: FYI, the nvidia-304 regression with the new kernel is tracked in bug 1427924 now
[10:19] <infinity> mvo_: Annoyingly, it didn't break on small-scale upgrades (like buildd chroots or minimal schroots), but apt shot itself in the head doing desktop upgrades after the Essential set changed.
[10:20] <tseliot> pitti: good, as I'm going to fix it today
[10:20] <mvo_> infinity: I think that particular one got fixed, but I need to dig into the logs, there was one issue right before 14.04 that sounds a lot like this
[10:20] <pitti> tseliot: I'm not sure whether we should drop the tests from u-d-common, given that they are useful to spot these (I do agree they run at the wrong time)
[10:20] <infinity> mvo_: But maaaaybe this was actually a weird side-effect of the "command line too short, breaking loop detection" bug, which you fixed, right?
[10:21] <tseliot> pitti: I think we should keep them. As - somehow - I didn't catch the failure in my chroot
[10:21] <infinity> mvo_: Seems plausible, given that small upgrades worked, but large ones broke.
[10:21] <tseliot> pitti: I've just read slangasek's comment though
[10:24] <cjwatson> pitti: OK, I can't be absolutely certain as there's some probably-unrelated confusion here with packagekit, but it looks OK to me, once I hit it only slightly harder it's happy to remove systemd-sysv
[10:24] <pitti> cjwatson, infinity: https://launchpad.net/~pitti/+archive/ubuntu/systemd has the above changes now (seeding init in minimal, adding systemd-sysv to ubuntu-standard, adding upstart to ubuntu-touch)
[10:24] <cjwatson> let's try your PPA to see
[10:24]  * pitti tests upgrades from trusty and utopic now
[10:25] <mvo_> infinity: I think 2f58969150b0daec1de407f61385ccf5b2065aa3 was a fix for the preconfigure issue, the ordering code was buggy, I'm not sure if I ever tried this with the old bug we had back in the day
[10:25] <cjwatson> pitti: Hmm, I still seem to have to say "apt-get install ubuntu-touch upstart packagekit"
[10:26] <cjwatson> It's not happy with just ubuntu-touch on its own
[10:26] <cjwatson> http://paste.ubuntu.com/10525402/
[10:26] <pitti> cjwatson: that's in which environment now?
[10:26] <cjwatson> debootstrap
[10:27] <infinity> mvo_: Am I just dreaming, or didn't you also crank up DPkg::Max{Bytes,Args} too, to fix some "upgrading lots of packages causes bad breaks in loops" issues?
[10:27] <pitti> ah; my last test just directly changed the ubuntu-minimal dep, and apt was happy enough to replace the package (after fixing ureadahead)
[10:27] <cjwatson> debootstrap vivid, install systemd-sysv, then upgrade to your PPA and put ubuntu-minimal back, then try to install ubuntu-touch
[10:27] <cjwatson> However, the worst case from this is that we have to hack livecd-rootfs a little bit, it isn't actually awful
[10:27] <pitti> cjwatson: that's not just because init is still in universe?
[10:27] <cjwatson> pitti: No I forced that
[10:27] <tseliot> pitti: the reverse dependencies test makes a lot of sense to me
[10:27] <cjwatson> installed init
[10:28] <cjwatson> pitti: Still, I think this plan is the closest we're likely to get to a right answer, and it's mostly trivial to implement in seeds
[10:28] <infinity> cjwatson: "apt-get install ubuntu-touch systemd-sysv-" would probably be more elegant, to preserve apt's manual/auto ideas.
[10:28] <cjwatson> infinity: Yeah, true
[10:28] <cjwatson> infinity: Still something odd with packagekit, I don't understand that
[10:28] <pitti> I get http://paste.ubuntu.com/10525435/ on apt-get dist-upgrade from trusty and utopic, to vivid+PPA; looks okay
[10:30] <infinity> pitti: Note that do-release-upgrade isn't apt-get dist-upgrade, so might behave slightly differently.
[10:30] <pitti> infinity: yeah, I'll check that next; but plain dist-upgrade also ought to work
[10:30] <infinity> But given that it tries hard to make sure metapackages stay installed, it's likely going to get the right result.
[10:31] <infinity> pitti: I agree, dist-upgrade should work.
[10:32] <pitti> ok, so I debootstapped vivid, added universe and PPA, upgraded (installed init and new ubuntu-minimal)
[10:32] <pitti> indeed apt-get install ubuntu-touch now fails on packagekit
[10:33] <infinity> pitti: And "apt-get install ubuntu-touch systemd-sysv-"?
[10:33] <cjwatson> Yeah same
[10:33] <cjwatson> http://paste.ubuntu.com/10525468/  from earlier
[10:33] <cjwatson> (ok, upstart vs. systemd-sysv-, but should be the same for this purpose)
[10:34] <cousteau> https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972 -- seems fixed, when will it make it into libexo-helpers on the repos?
[10:34] <infinity> cjwatson: Not necessarily.
[10:34] <cousteau> also, will it be on Precise as well?
[10:34] <pitti> I get some more issues with other packages, but likely just follow-ups of upstart: http://paste.ubuntu.com/10525469/
[10:34] <cjwatson> infinity: it had the same end effect.  I'll get problem resolver output once I've rebootstrapped
[10:35] <cjwatson> pitti: Yeah those are all consequences
[10:35] <cjwatson> pitti: Add systemd-sysv- and then it works
[10:35] <pitti> confirmed
[10:35] <pitti> so we need another package to depend on upstart, to bump its scores, or so?
[10:36] <cjwatson> pitti: 10:27 <cjwatson> However, the worst case from this is that we have to hack livecd-rootfs a little bit, it isn't actually awful
[10:36] <pitti> yeah, I saw that, I was just wondering if there's a better way
[10:36] <cjwatson> I would actively prefer that over fragile score guesswork
[10:37] <pitti> ah, initramfs-tools-ubuntu-touch and others also depend on upstart, so it should already have plenty of dependencies
[10:38] <cjwatson> So http://paste.ubuntu.com/10525503/
[10:38] <pitti> cjwatson: but all in all this looks more promising than trying to split ubuntu-minimal{,-touch}, WDYT?
[10:38] <cjwatson> I completely agree
[10:39] <cjwatson> These are comparatively minor issues
[10:40] <pitti> ok, so AFAICS we can add the upstart seed to -touch and change the minimal seed to "init" right now, and they should be no-ops (except for getting the additional empty "init" metapackage)
[10:40] <cjwatson> Yeah
[10:40] <pitti> and the live-build change too, as long as systemd-sysv isn't actually installed
[10:40] <pitti> then the flip woudl just be to upload init with switched dependencies, and add it to ubuntu-standard
[10:41] <pitti> and -touch would be prepared to keep upstart
[10:41] <cjwatson> livecd-rootfs but yes
[10:41] <cjwatson> Yep
[10:41] <pitti> agreed, sounds like a plan
[10:42] <pitti> cjwatson, infinity: many thanks for your help!
[10:44] <pitti> cjwatson: OOI, is there a syntax for purge? with - it'll get removed, but not purged, right?
[10:46] <pitti> mvo_: ^
[10:46] <pitti> mvo_: i. e. "apt-get install foo-" removes foo, is there a "purge foo"?
[10:46] <cjwatson> pitti: Not AFAIK, but doesn't matter in this case since systemd-sysv has no postrm.
[10:46] <cjwatson> So remove == purge
[10:46] <pitti> ok
[10:46] <cjwatson> Though apt-get --purge install foo- works
[10:47] <cjwatson> But passing that through live-build is probably a pain
[10:47] <pitti> it's no big deal anyway, I just wondered
[10:51] <mvo_> pitti: what cjwatson said, if you need a real purge via "pkgname-" I can do that too
[10:52] <mvo_> pitti: but early lunch first :)
[10:52] <pitti> mvo_: ack, thanks
[10:52] <pitti> mvo_: nah, not a biggie; --purge is fine
[10:56]  * sil2100 silently pokes didrocks regarding a certain endorsement request
[10:56] <sil2100> ;)
[10:56] <didrocks> apw: hey, I have some questions on name_to_handle_at vs overlayfs. I see that it's supposed to be supported (from http://goo.gl/OJoowv), but when I'm using a simple example (like the one on the manpage) on our livecd, I'm getting errno == EOVERFLOW, any idea?
[10:57] <didrocks> sil2100: oh, mind if that waits on Friday? Sorry about the delay
[10:57] <ogra_> sil2100, you mean he's as bad a slacker as i am ?
[10:57] <ogra_> that cant be !
[10:57] <sil2100> didrocks: no worries, any time in the nearest few weeks is fine
[10:57] <didrocks> good :)
[10:57] <sil2100> ;)
[10:57] <sil2100> ogra_: uh oh!
[10:57] <sil2100> I'm just kindly poking, no haste ;)
[10:58] <ogra_> heh
[10:59] <davmor2> ogra_: no one is as bad a slacker as you dude ;)
[10:59] <ogra_> hmm, probably true :)
[11:00] <pitti> cjwatson: ./update says "? Unknown required package: init" (http://paste.ubuntu.com/10525662/), seems we need to adjust the priority beforehand?
[11:00] <apw> didrocks, what code is using that call, as i expect it to be handled by the underlying fs
[11:00] <davmor2> ogra_: if it isn't a device you don't care about it.  Maybe if they made it snappy, you'd write his review to test that the snap worked, maybe that is the way round it ;)
[11:00] <pitti> cjwatson: ah no, perhaps the mirror is just slightly out of date wrt. the promotion to main; http://archive.ubuntu.com/ubuntu/pool/main/i/init-system-helpers/ is fine, but I'll try a bit later
[11:00] <ogra_> davmor2, lol
[11:01] <cjwatson> pitti: Yeah, that's about presence not priority
[11:01] <didrocks> apw: I just tried t_name_to_handle_at.c from man name_to_handle_at
[11:02] <didrocks> apw: context is, tracking a systemd issue when it detects all individual files as mount point in systemd code when used over overlayfs, I'm using that code as the source of this issue ^
[11:06] <apw> didrocks, it seems to be returning ENOSUPP for me
[11:06] <apw> didrocks, on overlayfs, not EOVERFLOW
[11:07] <didrocks> apw: sorry, you're right, it's just that it returns -1 as expected
[11:07] <apw> didrocks, well it failed, as expected
[11:08] <didrocks> apw: so, I guess this is expected that overlayfs doesn't support it
[11:08] <didrocks> hum, I wonder how I can detect if a file is a mount point (meaning, I guess, in that context, being overridden)
[11:08] <didrocks> apw: the systemd logic is to test a path, test the parent path, and check mount_id
[11:09] <didrocks> the fallback is using stat()
[11:09] <didrocks> and comparing st_dev
[11:10] <apw> which sounds ok ?
[11:10] <apw> oh perhaps not if the path is a file and the parent a directory
[11:11] <didrocks> apw: yeah, that exactly what happens here, path is file, parent a dir
[11:11] <apw> its not clear that name_to_handle_at would work any better if it did work of course
[11:11] <apw> this seems like an odd way to work out what is a mountpoint to me, then again it is systemd
[11:12] <didrocks> apw: I'm not debating how it is working ;) but yeah, tracking down a crash due to this
[11:13] <doko> ScottK, Riddell: https://projects.kde.org/projects/playground/libs/libqinfinity/repository libqinfinity needs an update for the new libinfinity in proposed. are there official tarballs available, or should a snapshot be packaged?
[11:15] <pitti> xnox: ah, apparenlty we have some hardcoded dbus-daemon paths (http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-notify-osd/38/ARCH=amd64,label=adt/console), I'll look
[11:15] <apw> didrocks, i am unsure if we have any good way to detect this right now ?
[11:16] <caribou> I would need a sponsor for openafs-modules-dkms on Trusty : it no longer build following a kernel struct change
[11:16] <xnox> pitti: i know, uploaded at-spi2-core
[11:16] <xnox> pitti: once that's rebuild, notify-osd test will need a rerun.
[11:16] <caribou> the bug seems to be impacting many people
[11:16] <pitti> xnox: ah, yay you
[11:17] <didrocks> apw: just run a test, and I confirm that st_dev is different if path == file from parent == dir.
[11:18] <didrocks> apw: hum, yeah, seems tricky to even think of a workaround…
[11:18] <didrocks> the easiest way would be to take another file (if any) into the same dir, but doesn't seem efficient…
[11:18] <Riddell> doko: what's the new version of libinfinity it needs to work with?
[11:19] <doko> Riddell, 0.6.5
[11:19] <didrocks> apw: the fact that major = 0 will only be return by dirs on overlays or am I on crack?
[11:20] <didrocks> no, tmpfs would as well…
[11:20] <pitti> slangasek: hm, you test-forced http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-libtest-requiresinternet-perl/ although the history makes it pretty clear that this is not just a random failure
[11:20] <caribou> apw: maybe the openafs sponsoring should be looked at by someone from the kernel team; it's a dkms build failure
[11:21] <pitti> the uninstallables caused by the perl upgrade still hold it in -proposed, but otherwise it would go in
[11:21] <caribou> .
[11:21] <apw> caribou, oh goody
[11:22] <caribou> apw: https://bugs.launchpad.net/bugs/1423151
[11:22] <caribou> apw: main part of the patch is one single commit, but I had to bring in two #defines so it would build
[11:23] <Riddell> doko: there's no new releases, do you know if it compiles with git snapshot? why is this being updated after FF? it's only used by an experimental plugin so qinfinity can be removed if it has to be
[11:23] <xnox> pitti: see the commit message in hints https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu
[11:24] <xnox> 910. By Steve Langasek 6 hours ago
[11:24] <xnox> Override failures from libtest-requiresinternet-perl; discovering that you
[11:24] <xnox> have no Internet is a perfectly valid test result from a module whose
[11:24] <xnox> purpose is *to detect whether or not you have Internet*.
[11:24] <xnox> pitti: i'm subscribed to that branch =) very useful stuff to get notified about.
[11:25] <pitti> xnox, slangasek: well, something is still wrong; the same package/test succeeds for me locally on vivid (in teh schroot runner), and fails on vivid-proposed
[11:25] <Riddell> doko: upstream says.. 11:25 < scummos> Riddell: it has been a while but I think I ported it to 0.6, but did not release it yet
[11:25] <Riddell> 11:25 < scummos> libqinfinity-0.5 does not work with 0.6.5
[11:26] <doko> Riddell, it was uploaded on 2015-01-22, way before feature freeze. I can't help if you guys don't address things in -proposed ...
[11:26] <pitti> xnox, slangasek: sorry, it fails in both, but it both cases the test does have internet..
[11:27] <Riddell> doko: I asked about a git snapshot 11:26 < scummos> Riddell: if that is possible for you, yes, and I will try to get a release for 0.6 some day
[11:27] <pitti> xnox: I'll ignore the upstart failure for dbus; that's not the new dbus' fault
[11:30] <pitti> cjwatson: oh, is this alright? minimal/i386: Skipping package init (package not in debootstrap)
[11:31] <xnox> pitti: at-spi2-core seems to be in, can you re-queue notify-osd test (unless you already have, I only see "public" jenkins)
[11:31] <pitti> cjwatson: the pacakge is clearly there now (wget -qO- http://archive.ubuntu.com/ubuntu/dists/vivid/main/binary-i386/Packages.bz2| bzcat -cd |grep '^Package: init$')
[11:31] <pitti> xnox: done 2 mins ago
[11:31] <xnox> pitti: tah.
[11:31] <didrocks> apw: do you think I should just return False or bail out if the system is overlayfs?
[11:32] <apw> didrocks, well not knowing why systemd cares to know, it is hard to say
[11:33] <pitti> xnox: ah, I got upstart to succeed again after 6 retries..
[11:34] <didrocks> apw: this is a common functionality for some units to have a ConditionIsMountPoint=<path>. We are using it as /etc/machine-id is not writable if empty at systemd startup (due to our ro mount, contrary to fedora and others), so systemd will overmount it as tmpfs. Then, we detect in a service (triggered by that ismountpoint condition) and do the swapping to a committed rw version to persist across reboots
[11:34] <didrocks> for snappy
[11:34] <didrocks> apw: but basically, this is just one example, maybe we will have other services using ConditionIsMountPoint=
[11:35] <cjwatson> pitti: Ah, *now* it needs to have its priority promoted first
[11:35] <pitti> ah, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt :)
[11:35] <pitti> cjwatson: ack
[11:35] <didrocks> I'm fine to bail out in that specific case, but that wouldn't fix for other services if they expects mount points to perform their operations
[11:35] <cjwatson> pitti: Go ahead and do that, wait a publisher run, retry
[11:35] <pitti> cjwatson: *nod*, thanks
[11:37] <pitti> xnox: notify-osd success, so dbus should go in now
[11:39] <ogra_> pitti, hmm
[11:39] <pitti> ogra_: I'm scared if you say "hmm"!
[11:39]  * pitti hugs ogra
[11:39] <ogra_> pitti, i'm not sure you should add upstart to the desktop file in the touch seed
[11:40] <ogra_> this is the base of desktop-next
[11:40] <pitti> ogra_: that's for desktop-next, isn't it? aren't these system images?
[11:40] <ogra_> no, isos afaik ...
[11:40] <pitti> ogra_: I seede it to touch-core
[11:40] <ogra_> Laney, seb128 ^^^^
[11:40] <ogra_>   * Added upstart to desktop, touch. This ensures that we keep upstart on
[11:40] <ogra_>     Touch even when we switch Ubuntu to systemd. (LP: #1428026)
[11:41] <pitti> ogra_: so at most it's over-cautious, but I'm not sure anyone ever tested desktop-next with systemd yet
[11:41] <ogra_> i was just commenting to your chanelog entry
[11:41] <ogra_> definitely nobody i think
[11:41] <ogra_> but i also think it wants to use the standard core system
[11:41] <ogra_> tricky one :)
[11:42] <Laney> If the jobs left to port are phone/android/whatever specific then it's probably fine
[11:42] <pitti> ogra_: right, so we'd move upstart from touch-core to touch
[11:42] <Laney> but someone should check before we do the switch there I guess
[11:42] <pitti> for now I thought we'd rather switch stuff step by step
[11:42] <ogra_> Laney, right, i thinnk there will be some that arent ported even for the non phone specific stuff
[11:43] <pitti> a few more stuff has direct upstart dependencies, like initramfs-tools-ubuntu-touch (but that's in touch-android, so we're fine)
[11:43] <pitti> ogra_: yes, for sure
[11:43] <ogra_> right
[11:43] <pitti> although, xnox' property watcher fixes are for android only
[11:44] <pitti> anyway, not too many fronts at once, please :)
[11:44] <ogra_> i dont think -next uses properties
[11:44] <ScottK> doko: I don't see any commits in the repository newer than the current release (about 6 months ago)
[11:44] <pitti> ogra_: right, no android container I presume
[11:44] <ogra_> misses the android backend :)
[11:44] <pitti> ogra_: but thanks for bringing it up; it seems to me that moving touch-core is a nice intermediate step
[11:44] <xnox> pitti: hm, i don't like that at-spi2-core is valid candidate, yet dbus is not. the two should go in together.....
[11:45] <pitti> ogra_: argh, of coruse I mean s/touch-core/desktop-next/
[11:45] <ogra_> pitti, ok
[11:45] <pitti> xnox: ah, no versioned deps/breaks?
[11:45] <xnox> pitti: nah, no change rebuild =)))))
[11:45]  * xnox is good like that
[11:51] <ogra_> pitti, i assume you want a test image build once everything landed ?
[11:52] <pitti> ogra_: it's still a no-op, so not that interesting; but can't hurt indeed
[11:53] <ogra_> well, i guess you want to at least make sure that trying to remove systemd-sysv doesnt make the build fall over if it isnt installed
[11:53] <pitti> ogra_: right; unlikely, but good to verify
[11:53] <cjwatson> I'm pretty confident in that, but indeed, good to verify
[11:54] <cjwatson> http://paste.ubuntu.com/10526088/
[11:54] <pitti> xnox: btw, dependencies did save you somehow :) (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
[11:54] <ogra_> looks good
[11:55] <pitti> xnox: i. e. now it's accepting both in the same run, before that at-spi2-core was held back due to uninstallability
[11:55] <ogra_> interesting that you had to add packagekit ...
[11:55] <cjwatson> I don't understand that bit, but it wasn't worth a lot of time investigating
[11:55] <cjwatson> If mvo_ gets round to finishing the native-dbus work in click then packagekit goes away anyway
[11:55] <cjwatson> (Which probably has to happen for desktop-next?)
[11:56] <cjwatson> And we have to finish the native-dbus work before packagekit is upgraded under our feet to a version that no longer supports plugins
[11:56] <ogra_> right, i just dont get why it is explicitly needed, it is seeded in touch-core
[11:57] <xnox> cjwatson: re:native-dbus work in click -> what's that about?
[11:57]  * xnox is happy to do dbus work.
[11:57] <cjwatson> Well, that makes it a dependency of ubuntu-touch, but apt probably hasn't worked that out yet :)
[11:57] <ogra_> ah
[11:57] <cjwatson> xnox: https://code.launchpad.net/~cjwatson/click/native-dbus but mvo_ had something on top of that
[11:58] <cjwatson> I don't think it needs significant extra code at this point IIRC, but I also don't know exactly where it's sitting
[11:58] <cjwatson> https://code.launchpad.net/~mvo/click/native-dbus
[11:58] <cjwatson> mvo_ probably got eaten by snappy before remembering to finish it :)
[11:59] <ogra_> haha
[11:59] <ogra_> now i finally get the namin scheme
[11:59] <cjwatson> the point was to stop relying on packagekit's dbus interface, which click only ever used in the first place because it was expedient
[11:59] <ogra_> +g
[11:59] <cjwatson> but it's a bit awkward for various reasons, it means people have to remember to use pkcon and "click install" doesn't just DTRT internally
[12:00] <cjwatson> and it's unsustainable because packagekit has removed the "plugin" facility in newer upstream versions, which the current design utterly relies upon
[12:00] <cjwatson> so if we give click its own dbus service, then we can ditch the dependency on packagekit entirely and simplify the dependency structure, so we no longer have the awkward conflict with aptdaemon
[12:02] <cjwatson> however it's a three-step thing: first we add the native dbus service to click, then we whack-a-mole all the stuff that's using pkcon or possibly even packagekit's dbus service directly to interact with click packages, then we remove the packagekit plugin from click
[12:02] <cjwatson> I planned this all out towards the end of last year, but then got burned out and moved to LP
[12:08] <apw> didrocks, yes, i can see it is an issue not being able to implement that check, i just right now don't have any answers
[12:11] <didrocks> apw: ok, I'll get the workaround in for now for that specific case, keep me posted if you can think of anything
[12:19] <pitti> Odd_Bloke, smoser, utlemming: I updated bug 1427999, it's much less severe than I thought
[12:20] <Odd_Bloke> pitti: Good to know, thanks.
[12:20] <Odd_Bloke> pitti: The impression I have is that cloud-init is systemd-ready, but smoser and utlemming would know better.
[12:21] <pitti> Odd_Bloke: I continue to investigate this; the failed initctl is probably/hopefully just harmless noise
[12:31] <pitti> ok, mystery solved
[12:40] <doko> zul:
[12:40] <doko> python-glance-store (0.1.10-0ubuntu2 to 0.1.11-0ubuntu1)
[12:40] <doko> Maintainer: Ubuntu Developers
[12:40] <doko> 0 days old
[12:40] <doko> python-glance-store/amd64 unsatisfiable Depends: ython-jsonschema (>= 2.0.0)
[12:43] <xnox> doko: ython -> Object Oriented high-level language generated on the fly entirely with yacc =)
[12:43] <mvo_> cjwatson: haha, I think its ready to land, just needs a review, maybe barry can help with that? but I will double check
[12:44] <mvo_> cjwatson: and yes, I got eaten by snappy :)
[12:44] <cjwatson> Cool, thanks :)
[12:46] <mvo_> xnox: feel free to look at the branch if you want to do a bit of dbus hacking :) iirc it worked but tests were missing
[12:46] <mvo_> (or incomplete)
[13:21] <smoser> pitti, thanks.
[13:22] <smoser> pitti, i hope to get that fixed "righ tnow"
[13:22] <smoser> as was hoping to get the versio nof cloud-init in archive sufficient to work with snappy, and i did a quick hack in the snappy version (config change) to do that. but for archive we'll have to do something smarter...
[13:23] <smoser> pitti, with reguard to purging cloud-init from user-data, i dont know that i care too much.. at least not without thinking about it more.
[13:31] <pitti> smoser: "that" == the initctl message? are there any consumers of that? these will need to get fixed, right? or ist that just some internal communication?
[13:32] <smoser> theres probably nto consumers of initctl message at this point.
[13:33] <smoser> it was basically offered as a event that you could have upstart jobs on
[13:33] <smoser> that would guarantee that cloud-config was available
[13:33] <pitti> ah, ok
[13:33] <smoser> and i dont think that functionality is a bad thing...
[13:33] <smoser> but i dont think a lot of things used it. and it clearly has to have *some* change for systemd :)
[13:35] <xnox> smoser: but before emitting things for upstart, one should check that one is running with upstart e.g. initctl --system version >/dev/null 2>&1
[13:37] <smoser> xnox, thanks.
[13:37] <smoser> i will use that.
[13:37] <xnox> smoser: there are some versions of upstart that didn't support --system. one sec.
[13:37] <smoser> i probably dont care aobut them :)
[13:38] <pitti> smoser: a unit which wants to start on cloud-init can do that without extra measures from cloud-init itself, so I think we are good there
[13:39] <xnox> smoser: unset UPSTART_SESSION; initctl version >/dev/null 2>&1 is better. or like otherwise make sure user session variable is not set to check that PID1 is upstart.
[13:41] <smoser> xnox, k. thanks.
[13:52] <doko> siretart, looking at the x264 ftbfs on arm64, the upstream support seems to be non-functional, afaics. are there newer snapshots with better support?
[14:21] <smoser> xnox, to be clear...
[14:21] <smoser> initctl version
[14:21] <smoser> on a non-upstart-pid-1 system will return non-zero
[14:21] <smoser> right ?
[14:21] <xnox> yes.
[14:22] <xnox> initctl version -> tries to connect to a private socket exported by upstart, query the daemon's version, and return it.
[14:22] <pitti> not true
[14:22] <pitti> $ initctl version; echo $?
[14:22] <pitti> upstart 1.13.2
[14:22] <pitti> 0
[14:22] <xnox> it's equivalent of the sd_booted test -> [ -d /run/systemd/system ]
[14:22] <xnox> pitti: note the unset UPSTART_SESSION; from prior discussion.
[14:22] <pitti> sorry, that was session upstart
[14:22] <pitti> ignore me :)
[14:22] <smoser> ignored
[14:22] <smoser> :)
[14:22] <pitti> yes, returns 1 here
[14:23] <smoser> thank you pitti
[14:23] <xnox> smoser: yeah but do unexport UPSTART_SESSION -> as then session upstart daemon is queried, rather than the system one.
[14:24] <pitti> just that in cloud-init case there's no session
[14:25] <xnox> pitti: yeah, most of the time it's fine. but that's the only safe way to guarantee that really the system one is being checked.
[14:25] <xnox> initctl --system version -> is another way, but pre-user-session upstarts do not know about --system / --user flags.
[14:25] <xnox> thus unexporting variable is the backwards compatible way from forever to check the system init.
[14:36] <dobey> Mirv: huh? :)
[14:37] <Mirv> dobey: I meant in the morning, that translations are welcome in Ubuntu and MIRing the package is not a big one of a MIR
[14:38] <Mirv> so it'd make sense to have it available in main
[14:38] <Mirv> dobey: oh, right wrong [tab]
[14:38] <Mirv> doko: so yes, MIR:ing qttranslations ok
[14:39] <doko> Mirv, bug report?
[14:39] <smoser> xnox, pitti http://paste.ubuntu.com/10527499/
[14:39] <Mirv> doko: I'll have it still today
[14:39] <smoser> that is what i'm going with.
[14:39] <dobey> Mirv: ah ok. :)
[14:40] <smoser> cloudinit util.subp captures and returns (stderr, stdout) by default.
[14:40] <smoser> the onequestion, i'm guessing i can assume 'upstart' in the output.
[14:40] <xnox> smoser: yes.
[14:41] <pitti> smoser: ah, you don't think it's safer to just check the exit code?
[14:41] <pitti> $ sudo LANG= initctl version; echo $?
[14:41] <pitti> initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
[14:41] <pitti> 1
[14:41] <pitti> the error message has "upstart" in it too :)
[14:41] <xnox> pitti: that's in stderr
[14:41] <xnox> pitti: not in out
[14:42]  * xnox ponders how to check for @/com/ubuntu/upstart socket direct
[14:42] <smoser> pitti, i checked only because its possible i have a program that is not upstart named 'initctl'
[14:42] <xnox> as that would be the quickest imho.
[14:42] <smoser> the fork is fine. it happens once.
[14:42] <pitti> xnox: nc -U @/com/ubuntu/upstart ?
[14:42] <pitti> (needs checking on an upstart system)
[14:43] <pitti> but let's not overdo it
[14:43] <Mirv> doko: bug #1427677
[14:43] <pitti> and check internal implementation details
[14:43] <Mirv> doko: sorry, not that one
[14:43] <Mirv> doko: this one bug #1428162
[14:56] <flexiondotorg> I'm trying to remove some config files with dpkg-maintscript-helper rm_conffile
[14:56] <flexiondotorg> Here is my postinst script
[14:56] <flexiondotorg> http://paste.ubuntu.com/10527664/
[14:57] <flexiondotorg> The files are not being removed. Could someone point me in the right direction please?
[15:00] <pitti> flexiondotorg: you need to specify the version that removes it, as it's only done once
[15:01] <pitti> flexiondotorg: see man dpkg-maintscript-helper
[15:01] <pitti> flexiondotorg: not sure what the $@ is
[15:01] <pitti> flexiondotorg: but usually you just put these commands into debian/pkgname.maintscripts, and dh_installdeb DTRT
[15:01] <flexiondotorg> pitti, DTRT?
[15:01] <pitti> "do the right thing"
[15:02] <flexiondotorg> pitti. Thanks. That give me something to go on.
[15:06] <flexiondotorg> pitti, Should the version be 0.4.2ubuntu1 or 0.4.2?
[15:08] <pitti> flexiondotorg: I don't know -- whichever version removes the file, with ~ appended
[15:10] <cjwatson> ScottK: You synced python-astropy from experimental, which causes astroquery to FTBFS.  I think syncing python-astropy-helpers from experimental as well will fix this; was there a special reason you didn't, or was it just an oversight?
[15:13] <flexiondotorg> pitti, Thanks. Working now :)
[15:19] <cjwatson> ScottK: I've gone ahead and synced that; it looked likely and only has one reverse-(build-)dep.
[15:55] <pitti> wgrant: so I just moved python-dbusmock from gitorious to github; https://code.launchpad.net/~pitti/python-dbusmock/trunk is an automatic import of that, how can I change that to the new git location?
[15:55] <pitti> wgrant: editing the branch doesn't have an origin URL, and I can't delete and re-create as it complains about having associated branches
[15:58] <cjwatson> pitti: Do you not have an "Edit import source or review import" link?
[15:58] <pitti> cjwatson: no, I don't; that probably requires extra Launchpad fu
[15:58] <cjwatson> pitti: What's the GitHub URL?
[15:58] <pitti> cjwatson: https://github.com/martinpitt/python-dbusmock
[16:03] <cjwatson> pitti: Updated
[16:03] <cjwatson> wgrant: ^-
[16:03] <pitti> cjwatson: cheers!
[16:05] <cjwatson> Yeah, only ~vcs-imports and ~admins can use that interface, now that I look at it.
[16:07] <pitti> cjwatson: nice, I even got an automatic mail from LP about it
[16:11] <slangasek> cyphermox: I see console-setup still hasn't gone through because of console-setup-mini uninstallability on amd64
[16:12] <pitti> slangasek: yep, cyphermox and I talked about that this moring
[16:12] <pitti> morning, too
[16:12] <slangasek> ok
[16:12] <pitti> (most probably just a missing alternative dep in kbd, but I haven't checked very deeply)
[16:14] <cjwatson> yes that's the diagnosis I gave cyphermox too
[16:31] <Chipaca> could somebody confirm that, in bash on vivid, “( read -p "ok? " -n1 -e -t2 && echo "R: $REPLY" ); echo” leaves the terminal with no echo if you don't reply?
[16:47] <flexiondotorg> pitti, Where is your systemd FFE?
[16:47] <pitti> flexiondotorg: bug 1427654
[16:47] <flexiondotorg> pitti ty
[16:56] <flexiondotorg> pitti, I just dist-upgrade my vm. So, it has happened right? :)
[16:56] <pitti> flexiondotorg: no, not yet
[16:56] <pitti> flexiondotorg: still waiting on the FFE and NFS to land
[16:57] <pitti> flexiondotorg: today I just did some preparatory things to make ubuntu touch continue to use upstart
[16:58] <flexiondotorg> pitti, I got a new `init` package when I dist upgraded.
[16:58] <pitti> flexiondotorg: right; that's a meta-package which depends on upstart | systemd-sysv
[16:58] <pitti> flexiondotorg: and we'll flip that around (hopefully) soon
[16:59] <flexiondotorg> pitti, OK.
[17:00] <flexiondotorg> pitti, Before Beta 2?
[17:03] <pitti> flexiondotorg: hopefully this week :)
[17:03] <flexiondotorg> pitti, Ace!
[17:04] <flexiondotorg> pitti, You realise that the Internet will have an aneurysm when it is announced? ;)
[17:04] <pitti> yes, everybody will hate me, and I earn everyone's boot bugs :)
[17:05] <didrocks> well, people will just blame fsckd as it seems to be a thing… :p
[17:06] <flexiondotorg> pitti, No, everyone will not hate.
[17:06] <flexiondotorg> pitti, Only the trolls and the ignorant will ;)
[17:07] <flexiondotorg> pitti, Love you for it.
[17:07] <flexiondotorg> pitti, Seriously considering hanging up my Arch dev boots because of this.
[17:08] <didrocks> flexiondotorg: tell that on LAS! :)
[17:09] <flexiondotorg> didrocks, ;) You listen then?
[17:09] <flexiondotorg> didrocks, Do you hear last nights/
[17:09] <didrocks> flexiondotorg: when exercising… But I generally lag on LAS/Unplug by 2 weeks, so not yet :)
[17:10] <flexiondotorg> didrocks, Fair enough. Ubuntu MATE featured a good last night :)
[17:10] <flexiondotorg> didrocks, I mentioned systemd enablement.
[17:11] <didrocks> flexiondotorg: nice! I will listen then this time to not only check popey doesn't tell wrong things :)
[17:11] <popey> I have no idea what you mean :)
[17:11] <didrocks> heh
[17:12] <flexiondotorg> didrocks, popey Was very wrong last night. Fortnately I was there to straighten him out.
[17:12] <flexiondotorg> Oh, Hi popey ;)
[17:29] <pitti> roaksoax: so in http://paste.ubuntu.com/10529094/
[17:29] <pitti> roaksoax: +ConditionPathExists=|/var/lib/maas/secret
[17:30] <pitti> roadmr: what do you mean with the | there? a single | is a no-op; it only really makes sense if you have more than one OR-ed condition
[17:30] <pitti> roadmr: sorry, I meant roaksoax
[17:31] <roadmr> :D
[17:32] <roaksoax> pitti: ah i see
[17:32] <roaksoax> pitti: so then no need for that then
[17:32] <pitti> roaksoax: in http://paste.ubuntu.com/10528917/ the last unit, does sourcing maas-proxy-common.sh actually do anything, i. e. have some side effect?
[17:32] <roaksoax> at all
[17:32] <pitti> roaksoax: otherwise you probably mean EnvironmentFile=/usr/share/maas/maas-proxy-common.sh if that's supposed to apply to the squid call?
[17:33] <roaksoax> pitti just ensures permissions are correct. Similar to what squid-deb-proxy does
[17:33] <pitti> roaksoax: the other two look ok (they could probably get some cleanup, but nevermind)
[17:33] <pitti> roaksoax: ah, and it's not executable?
[17:34] <pitti> roaksoax: i. e. you want the unit to fail if maas-proxy-common.sh fails, but it's not exporting env vars for squid? that's fine then
[17:34] <pitti> roaksoax: although it'd be easier to just call it then, to avoid another shell
[17:34] <pitti> roaksoax: ExecStartPre=/usr/share/maas/maas-proxy-common.sh
[17:34] <roaksoax> pitti ok cool
[17:34] <pitti> roaksoax: or, if it's not executable, ExecStartPre=/bin/sh /usr/share/maas/maas-proxy-common.sh
[17:35] <pitti> (looks a bit simpler)
[17:35] <roaksoax> pitti: yeah that should work better
[17:36] <roaksoax> pitti: awesome then! I'll get this tested
[17:36] <roaksoax> pitti: and let you know how it goes
[17:36] <roaksoax> pitti: thanks for the feedback
[17:37] <pitti> utlemming, Odd_Bloke: oh, with the cloud images being switched to systemd some tests might now behave differently; I guess that deserves some announcement, I'll send an u-d-a@ post
[17:43] <pitti> jamespage: FYI, https://jenkins.qa.ubuntu.com/job/vivid-adt-heat/? started failing, some problem with the systemd units? (see the u-d-a@ mail I just sent)
[17:43] <pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-neutron/63/ARCH=amd64,label=adt/console too, although i386 succeeded
[17:44] <jamespage> hmm
[17:44] <jamespage> pitti, ok - we'll take a look
[17:45] <pitti> cheers
[19:37] <doko> pitti, zul: systemd fall-out: https://launchpad.net/ubuntu/+archive/test-rebuild-20150202/+build/6775834
[19:51] <doko> ScottK, you are clamav uploader. why is llvm not enabled on all architectures?
[20:50] <doko> kenvandine, ping on lp:#1428299 and lp:#1428314
[20:51] <kenvandine> doko, i haven't even looked at those in ages :)
[20:51] <doko> kenvandine, the version numbers look phonish ;-P
[20:52] <kenvandine> bregma, ^^
[20:52] <kenvandine> are you tending to geis and dee these days?
[20:52] <kenvandine> doko, i'm happy to patch them, but let me check first
[20:53] <doko> kenvandine, sure, would appreciate it if you could get these in. maybe more will follow, if you look at the list of GCC 5 ftbfs
[20:53] <kenvandine> doko, good times :)
[20:54] <kenvandine> doko, i'll go ahead and prepare branches to land while waiting for a reply
[20:56] <bregma> my first reaction is to run like the dickens when those names come up, but I can take a lok
[20:56] <kenvandine> bregma, are we landing those with the train?
[20:57] <kenvandine> i'm happy to prepare bzr branches for you guys to review
[20:57] <bregma> I believe I have landed those under ci-train in the past, yes
[20:58] <doko> let me know, I could upload directly to the archive too. these are no code changes
[21:00] <bregma> they're definitely ci-train projects, should be branched properly before landing
[21:00] <kenvandine> doko, we'll let you know, it might be less work for us to land it as opposed to pulling the patches back down
[21:00] <doko> ok
[21:01] <kenvandine> bregma, https://code.launchpad.net/~ken-vandine/dee/lp1428299/+merge/251827
[21:04] <kenvandine> https://code.launchpad.net/~ken-vandine/geis/lp1428314/+merge/251828
[21:05] <kenvandine> bregma, ^^
[21:05] <bregma> thanks
[21:05] <kenvandine> np
[21:10] <doko> kenvandine, bregma: I would appreciate it, if you could scan http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-gcc5-vivid.html  for other phonish packages.  you can find the compiler in the ubuntu-toolchain-r/test PPA. getting these addressed would be appreciated
[21:10]  * bregma adds to the work queue
[21:11] <kenvandine> doko, will do
[21:11] <doko> cool, then I'll skip these for now. just ping here when you address one of those
[21:12] <kenvandine> doko, libdbusmenu and unity-webapps-qml
[21:13] <kenvandine> there are 2 other unity related packages there, but i think those are only used in unity7
[21:13] <doko> anyway, these should be fixed, or demoted ...
[21:13] <kenvandine> yeah
[21:13] <kenvandine> none of these are particularly phoneish, a couple have libs that are installed on the phone
[21:15] <kenvandine> tedg, dbusmenu ftbfs with gcc5
[21:15] <tedg> gcc5 is a 15.10 thing, no?
[21:15] <kenvandine> doko, ^^ ?
[21:16] <kenvandine> i suspect so, not 15.04
[21:18] <tedg> How weird, seems one of the test is hanging. Wouldn't have expected that to be the issue.
[21:19] <tedg> In the GTK2 version even.
[21:20] <tedg> Vim is failing! We need a bug status above Critical!
[21:23] <Unit193> tedg: Oh, I don't suppose bug 1270486 will be fixed for release?
[21:24] <bregma> emacs does not get installed on the phone by default?  How does it even?
[21:24] <tedg> Unit193, Not sure if I'll get to it, or not. It's not a high priority for me right now.
[21:25] <Unit193> Dang, that stinks.  Right now I'm looking at a program with two quit options, but one is "and shutdown daemon" and I'm not sure which..
[21:26] <ochosi> +1
[21:44] <sbeattie> pitti: https://jenkins.qa.ubuntu.com/job/vivid-adt-ubuntu-system-settings-online-accounts/137/ARCH=amd64,label=adt/console looks to be a problem with powerd setup?
[21:51] <bdmurray> roaksoax: Is the verification of bug 1383727 still good?
[22:00] <roaksoax> bdmurray: from my perspective, yes, we have tested this in various different types of hardware in OIL and others
[22:00] <bdmurray> roaksoax: Do you know what comment #23 might mean?
[22:10] <bdmurray> bluesabre: Did you upload sponsor the fixes for bug 1425972? If so release tasks weren't opened, an SRU test case is missing and ubuntu-sponsors is still subscribed.
[22:16] <sbeattie> pitti: sorry, I was confusing powerd with upower. Do you have any idea why systemd is failing its adt tests? I can't see anything obvious in the logs in https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/109/?
[22:23] <doko> tedg, kenvandine: yes, 15.10, but things will be "interesting", so I'd like to fix as many things as possible proactively, so that we don't run into issues during the w-series cycle
[22:36] <bdmurray> For some reason w seems closer to the end of the alphabet than v
[22:37] <tedg> bdmurray, It is exactly one letter closer.
[22:39] <bdmurray> tedg: I think its because I remember the last letters of the alphabet in a block of 4 starting with W
[23:35] <bluesabre> bdmurray: Yes, updating the bug now and replacing the debdiff for trusty. I'll unsub sponsors and upload trusty to -proposed
[23:36] <bluesabre> sorry for the unnecessary noise
[23:36] <bluesabre> er, everything except unsubbing sponsors, can't do that
[23:44] <flexiondotorg> cyphermox, Are you able to do you package sponsoring today?
[23:49] <bdmurray> bluesabre: great, thanks