[00:54] <rlaager> Okay, so I rebuilt my backport of libgadu against libgnutls26. Now, I definitely get "Unable to locate package libmessaging-menu-dev" on Trusty: https://launchpadlibrarian.net/194579012/buildlog_ubuntu-precise-amd64.pidgin_1%3A2.10.11-1ubuntu0%2Bpidgin4.12.04_MANUALDEPWAIT.txt.gz
[00:55] <rlaager> err, that's precise, nevermind
[01:00] <rlaager> Okay, so now trusty says, "libgadu-dev : Depends: libgnutls26-dev but it is not installable".
[06:14] <pitti> Good morning
[06:15] <pitti> hallyn: cgmanager startup behaviour> ah great, then all is well AFAICS?
[06:15] <darkxst> morning pitti
[06:15] <pitti> hey darkxst
[06:16] <darkxst> pitti, is there some way to override make check in cdbs (for xvfb-run)?
[06:16] <pitti> darkxst: yes, there is; /me needs to look, it's been a few years
[06:17] <pitti> there's DEB_MAKE_CHECK_TARGET, but that's not sufficient
[06:18] <darkxst> nope, best I could find was DEB_MAKE_INVOKE, but that runs the entire build through xvfb
[06:20] <pitti> darkxst: perhaps just don't define DEB_MAKE_CHECK_TARGET and run the checks in common-post-build-arch::?
[06:20] <darkxst> I did try something like that, but tests (for gjs) still seem to run
[06:21] <darkxst> I suppose I could make the DEB_MAKE_CHECK_TARGET non fatal though, then it would work
[06:22] <darkxst> or just completely ignore build tests, since we have autopkgtests also?
[06:24] <darkxst> does that seem reasonable? pretty sure its exactly the same test suite
[06:27] <pitti> jamespage: thanks for starting the init migration on nova! FTR, it's stuck in -proposed as nova-objectstore doesn't seem to start automatically (https://jenkins.qa.ubuntu.com/job/vivid-adt-nova/47/ARCH=amd64,label=adt/console)
[06:27] <pitti> darkxst: setting DEB_MAKE_CHECK_TARGET to "check || true" would run everything twice
[06:29] <pitti> darkxst: build tests are still nice as they run on all the arches
[06:30] <pitti> darkxst: I still don't understand -- AFAICS cdbs does not run "make check" automatically
[06:30] <pitti> darkxst: are you sure you don't have anything in your rules which invokes the tests automatically? perhaps it even happens through normal "make" in the upstream build system?
[06:33] <darkxst> pitti, when I removed DEB_MAKE_CHECK_TARGET I still had two sets of tests running, one for the override
[06:34] <darkxst> though gjs doesnt seem to run make check atleast in jhbuild
[07:31] <dholbach> good morning
[07:49] <pitti> didrocks: argh, floodlight holding up sysvinit again :/
[07:50] <pitti> Laney, infinity: could either of you please force-badtest floodlight?
[07:50] <didrocks> pitti: it's a different test failing than last time?
[07:50] <pitti> didrocks: no, exactly the same
[07:50] <pitti> (three)
[07:51] <didrocks> ah :(
[07:52] <didrocks> pitti: so, systemd hackfest this week it seems? I planned to do some dev story stuff, but will see if I can join
[07:52] <pitti> didrocks: yes; we should wait for slangasek's definitive answer, but I think Thu/Fri
[07:53] <slangasek> yes Thu-Fri
[07:53] <didrocks> ok, let's see if I can join (I did some transitions last week)
[07:55] <pitti> oh, hey slangasek -- unsual hour :)
[07:56] <pitti> slangasek: so, I updated https://wiki.ubuntu.com/SystemdForUpstartUsers, will create a pad for coordination with links and lists of packages to convert grouped by openstack/desktop/juju/etc.
[07:56] <pitti> slangasek, didrocks: as for IRC, I think just #u-devel should be fine, WDYT?
[07:56] <slangasek> yes, that's my preference
[07:57] <didrocks> pitti: yeah, sounds good to me
[07:57] <pitti> and then we can have hangouts as necessary, but having it on all the time is too distracting IMHO
[07:57] <didrocks> agreed
[07:57]  * pitti yays https://launchpad.net/ubuntu/+source/keystone/1:2015.1~b1-0ubuntu2 and smells another MIR coming for didrocks  :)
[07:58] <slangasek> ok; I'd like to at least have a daily hangout at the start of the overlap between US and EU
[07:58] <pitti> that sounds good
[07:59] <didrocks> pitti: it's MIR-day anyway, 11 packages now (fctix, second edition) :p
[07:59] <didrocks> pitti: I'm a little bit afraid about that autogenerated systemd units btw
[07:59]  * pitti creates http://pad.ubuntu.com/systemd-porting-sprint
[07:59] <pitti> didrocks: I haven't looked at it at all yet TBH
[07:59] <didrocks> seems like it will just "have everything started on runlevel 5 equivalent"
[07:59] <didrocks> instead of seeing relations between services
[07:59] <pitti> didrocks: the current upstart jobs aren't really much different either AFAIR
[07:59] <didrocks> right
[07:59] <didrocks> it was just the opportunity to get it right :)
[08:00] <didrocks> but having a tool doing that genericness… meh
[08:00] <jamespage> pitti, will look this morning
[08:03] <pitti> didrocks, jamespage: yeah, .init.in also sounds a lot like it should just use /lib/init/init-d-script
[08:04] <didrocks> yeah, as I did for whoopsie IIRC
[08:05] <jamespage> pitti, hmm - maybe - currently the openstack-pkg-tools helper produces one that has some systemd specific actions as well
[08:05] <jamespage> pitti, I think we'll run with that for this cycle at least as it brings us a bit closer to Debian as well
[08:06] <pitti> jamespage: sounds good; merging/getting closer with Debian makes stuff easier in its own right, too
[08:16] <jamespage> pitti, oops - missed the init.in for objectstore - fixing now
[08:17] <pitti> jamespage: thanks! (and yay tests!)
[08:34] <pitti> slangasek: I prepared http://pad.ubuntu.com/systemd-porting-sprint
[08:34] <pitti> I think jamespage could already grab some of the OpenStack ones which he already started
[08:35] <didrocks> pitti: I'm unsure how often the file system update on the server, but some are already transitionned from Friday
[08:35] <pitti> didrocks: yeah, it's lagging several days behind for some reason
[08:35] <pitti> didrocks: I also transitioned two (apport-noui and mythtv)
[08:35] <pitti> didrocks: but so far it has always updated eventually
[08:36] <didrocks> yeah, it will just need some refresh then or should I remove those already done?
[08:37] <pitti> didrocks: just remove them from the pad, please
[08:38] <didrocks> doing
[08:39] <jamespage> pitti, canonical server team will deal with the openstack ones
[08:39] <jamespage> pitti, I have a few to review from coreycb last week
[08:40] <didrocks> jamespage: will you handle the server ones as well?
[08:40] <jamespage> didrocks, sure
[08:40] <pitti> jamespage: ack; I kept them separate in the categorization as I figured converting those might be a bit special (upstream coordination, and they are all relatively similar, etc.)
[08:40] <jamespage> didrocks, rbasak will help out there as well
[08:40] <didrocks> great ;)
[08:41] <pitti> jamespage: (no need to add "TODO" -- perhaps instead say "jamespage"
[08:44] <pitti> jamespage: I updated the status of keystone
[08:44] <jamespage> pitti, ah - right - yes - indeed - its stuck in proposed
[08:46] <pitti> slangasek: should I send the u-d-a@ announcement now, or is there something further to be done?
[08:46] <pitti> slangasek: ah, I have an XX:XX for the hangout time, but we can update the pad later
[09:09] <jamespage> pitti, when's the planned switch to systemd happening? I'll poke the juju dev team to deal with the autogenerated upstart jobs
[09:09] <pitti> jamespage: "we release when it's ready" by and large, but we do aim for 15.04, i. e. vivid
[09:09] <pitti> we shouldn't drag it for too long
[09:09] <pitti> jamespage: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration has the remaining work aside from porting the jobs
[09:10] <jamespage> pitti, oh I agree - but do we have a target for the swithover?
[09:10] <pitti> jamespage: I figure by feature freeze?
[09:10] <pitti> (no particular date)
[09:10] <jamespage> pitti, sounds reasonable
[09:10] <jamespage> pitti, I know that the juju team will prioritize the work accordingly - all of our vivid openstack testing will break on switchover unless we have the new juju bits
[09:11] <pitti> jamespage: so end of January would be nice, so that we still have enough time to fix the rough edges
[09:11] <jamespage> +1 ack
[09:11] <pitti> jamespage: cool, thanks for coordinating that!
[09:14] <jamespage> pitti, I've raised a bug for juju-core, linked it to the blueprint and pinged the ta and engineering manager for juju-core
[09:15] <jamespage> hopefully that should get some attention post haste
[09:15] <pitti> thanks; tagged and subscribed
[09:16] <pitti> jamespage: and replaced the textual WI with the bug
[09:16] <jamespage> pitti, ack
[09:16] <jamespage> rbasak, ^^ fyi - I know you are point on juju-core crossteam activities
[09:26] <cjwatson> rlaager: There's no such package libgnutls26-dev in trusty; it was called libgnutls-dev
[09:26] <cjwatson> rlaager: Generally I'd advise using chdist from devscripts to reproduce this kind of thing; that way you can have an isolated apt-get environment (that can't actually install packages, but it can tell you whether it would be able to resolve dependencies) that only considers trusty plus the PPA in question
[09:27] <rlaager> cjwatson: Thanks. I wasn't aware of that tool.
[09:46] <pitti> stgraber: oh, I see -- /lib/udev/bridge-network-interface is one of the udev-y things which would bring up bridges refering to a recently up'ed physical interface
[09:46] <pitti> (40-bridge-network-interface.rules)
[10:11] <pitti> didrocks: erk -- check /usr/sbin/invoke-rc.d line 577
[10:11] <pitti> didrocks: I just got an error message "op: not found" due to the extra line break
[10:12] <pitti> from http://launchpadlibrarian.net/194237210/sysvinit_2.88dsf-53.2ubuntu3_2.88dsf-53.2ubuntu4.diff.gz
[10:12] <pitti> didrocks: want to upload a fix, or want me to if you don't have time?
[10:13] <cjwatson> that was already fixed
[10:13] <cjwatson> http://launchpadlibrarian.net/194242250/sysvinit_2.88dsf-53.2ubuntu4_2.88dsf-53.2ubuntu5.diff.gz
[10:14] <pitti> cjwatson: no, it wasn't -- the error above is the line immediately below that
[10:14] <cjwatson> oh yeah, good point
[10:14] <pitti> i. e. the printerror
[10:14] <cjwatson> misread, sorry
[10:14] <pitti> well, *shrug*, I'll just upload it
[10:16] <pitti> cjwatson, didrocks: ^ uploaded (2.88dsf-53.2ubuntu6)
[10:17] <pitti> jamespage: nova test succeeds again, cheers!
[10:17] <jamespage> pitti, np
[10:17] <cjwatson> there was already an ubuntu6 ...
[10:18] <cjwatson> pitti: you'll need to rebase on https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-53.2ubuntu6
[10:18] <pitti> argh, sorry about that
[10:18]  * pitti says "Use pull-lp-source, Luke!" a hundred times
[10:19] <pitti> ubuntu7 is the charm! uploaded
[10:22] <highvoltage> heh :)
[11:33] <didrocks> pitti: sorry, was out for some exercise
[11:35] <pitti> didrocks: no worries
[11:36] <didrocks> pitti: I really wonder what I did with my vim snippet in that upload to get the 2 breaks…
[11:36] <pitti> tseliot: I updated bug 1312255 with some info and a question, but by and large translating this into a unit looks reasonably straightforward; let me know if you have questions
[11:36] <pitti> didrocks: forgot to hit the pastetoggle key? :-)
[11:36] <didrocks> pitti: probably :p
[11:37] <tseliot> pitti: I'll have a look at it, thanks
[11:44]  * xnox has an evil plan for upstart-local-bridge
[11:44] <didrocks> xnox: based on generators, from what I see :)
[11:45] <xnox> didrocks: yeah, but with full compat for system-systemd, session-systemd, session-upstart without system-upstart.
[11:45]  * xnox should post an email about it.
[11:46] <didrocks> nice ;) yeah, please do
[12:10] <LocutusOfBorg1> pitti, thanks for the answers, I don't know the best solution, feel free to do what you think is best
[12:10] <LocutusOfBorg1> ;)
[12:41] <pitti> LocutusOfBorg1: I don't know what is best, I don't know why that line got removed
[12:41] <pitti> LocutusOfBorg1: is there some upstream commit that this refers to which might have some more info?
[12:44] <pitti> stgraber: systemd with the recent user lxc fixes is now in vivid
[12:52] <LocutusOfBorg1> pitti, found it https://www.virtualbox.org/changeset/48422/vbox/trunk/src/VBox/Additions/linux/drm/vboxvideo_drm.c
[12:53] <LocutusOfBorg1> " Additions/linux/drm: removed .fasync as drm_fasync is an unneeded no-op to be removed in Linux 3.12."
[13:15] <pitti> LocutusOfBorg1: ah cool, thanks!
[13:16] <Bluefoxicy> folks
[13:16] <Bluefoxicy> listen, seriously.
[13:16] <Bluefoxicy> Turn off swap.
[13:16] <Bluefoxicy> Now have a process eat a ton of RAM.  Just buttload it.
[13:16]  * pitti did ages ago
[13:17] <Bluefoxicy> Like, that disk cache thing, the buffers?  They go down.
[13:17] <Bluefoxicy> 16GB RAM, 7GB used, 9GB disk cache?  Turns into 15GB used, 1GB ... then 0.5GB... then 100MB
[13:17] <Bluefoxicy> know what happens?
[13:17] <Bluefoxicy> Your computer starts thrashing the hard disk, and just locks up.  If you wait long enough, the OOM killer eventually kicks in (if the process keeps consuming more RAM), kills something, and you can use your PC again.
[13:18] <Bluefoxicy> Because you wind up re-reading the same library files again and again several times per second when you run low on disk cache.
[13:18] <Bluefoxicy> So
[13:18] <Bluefoxicy> really
[13:18] <pitti> LocutusOfBorg1: uploaded, thanks! I update the bug
[13:18] <Bluefoxicy> Why isn't there a tunable to tell the kernel to kick in OOM kill early?
[13:18] <LocutusOfBorg1> thanks for caring pitti ;)
[13:19] <Bluefoxicy> e.g when reclaimable RAM (including disk cache, buffers, etc.) drops below a certain threshold
[13:19] <Bluefoxicy> just to say "your PC really won't be usable if you have less than this much RAM for disk cache and buffers, so falling below this is an OOM situation"
[13:21]  * Bluefoxicy sets kernel.sysrq to 240 so he can throw an OOM kill manually when this happens.
[13:37] <highvoltage> /win 11
[13:37] <pitti> highvoltage: /lose 5
[13:37] <pitti> highvoltage: hey Jonathan, how are you?
[13:40] <highvoltage> pitti: hey! doing good thanks and you?
[13:40] <pitti> highvoltage: quite fine, thanks!
[13:40] <pitti> highvoltage: the ZA summer a few weeks ago was nice :)
[13:41] <highvoltage> pitti: are you visiting again next month?
[13:41] <pitti> highvoltage: no, I won't; I'll go to FOSDEM (Brussels)
[13:42] <xnox> pitti: see you there ;-) i've booked everything for myself.
[13:42] <pitti> xnox: I don't have much to book except for the train
[13:43] <pitti> xnox: beer time after the hackfest and on Sat evening then, I figure? :-)
[13:43] <highvoltage> ah, still nice :)
[13:46] <xnox> pitti: yeap.
[13:55] <hallyn> pitti: i'm a bit lost at this point.  You mean all is well if we just do nothing?
[13:56] <pitti> hallyn: well, we still need to start cgmanager by default
[14:20] <pitti> hallyn: but I meant aside from that it seems there's nothing else blocking that?
[14:22] <pitti> jamespage: ironic's new dep on the nonexisting python-pysendfile -- is that just a typo and should be python-sendfile, or is that a PPA package of some sort?
[14:22] <jamespage> pitti, argh that's me being a dumbass
[14:22] <jamespage> pitti, at least I think so
[14:22]  * jamespage looks
[14:23] <didrocks> pitti: didn't you tell there was an issue about ressource management? like both settings process in the same cgroup resources?
[14:23] <pitti> jamespage: debian/pydist-overrides removes "pysendfile", that apparently led to that
[14:23] <hallyn> pitti: with no other changes?
[14:23] <jamespage> pitti, hmm - apparently so although I thought the dh-python was clever enough to figure out where that comes from based on installed packages
[14:23] <pitti> didrocks: obviously everything has to decide whether it talks to systemd or cgmanager for shuffling stuff around, but the use cases should be fairly non-overlapping
[14:24] <pitti> hallyn: the "disallow fumbling with the systemd controller" was discussed and isn't possible, and you already wrote that cgmanager doesn't change the setup at startup
[14:24] <hallyn> yup
[14:24] <pitti> hallyn: so I see nothing else ATM -- do you still?
[14:25] <pitti> jamespage: ah, that was bug 1391960 -- so apparently it either needs to become a build dep or a manual binary dep?
[14:25] <didrocks> tedg: so nothing to do for you as well in UAL then? ^
[14:25] <jamespage> pitti, it is a build dep
[14:26] <pitti> jamespage: oh ok, so dh_python isn't as clever as it should be then?
[14:26] <pitti> didrocks: yep
[14:26] <pitti> didrocks: talked to tedg a few days ago
[14:27] <xnox> pitti: hallyn: is that cgroups/systemd discussion somewhere on a bug report mailing list, or just irc?
[14:27] <tedg> didrocks, It depends on Upstart, if it's still using CGManager to create the cgroups, we need to talk to cgmanager to access them. Which I think is the plan. So there's no UAL items (in theory).
[14:27] <pitti> xnox: summary is on bug 1400394, and I hope followups go there from now on
[14:27] <jamespage> pitti, that may indicate something broken in sendfile - looking now
[14:27] <xnox> jamespage: pitti: one can provide hints / overrides for dh_python there was a text file where to hint what dh_python should do when it sees "foo" requires.
[14:28] <hallyn> pitti: hm, so was that only done in debian/rule?
[14:28] <pitti> jamespage: ok; sorry for nagging, just reviewing what's stuck in -proposed
[14:28] <hallyn> pitti: just remove the --no-enable?
[14:28] <jamespage> xnox, yeah - I know but I'm pretty sure it should be able to figure out the binary package from the install bits
[14:28] <pitti> hallyn: "that"?
[14:28] <hallyn> yeah, having it not run by default
[14:28] <pitti> hallyn: oh -- yes, that should suffice, hang on
[14:28] <hallyn> yeah i thought ther emight e something in the actual systemd unit file too, but i see nothing
[14:29] <hallyn> stgraber: ^ is there anything else beside the 3 last patches to help lxcfs which you'd want in a new cgmanager releases?
[14:29] <pitti> hallyn: yep, that should do
[14:29] <hallyn> (any features i haven't implemented yet)
[14:35] <hallyn> jamespage: had any thoughts of merging ipxe from debian? :)
[14:36] <hallyn> (if not i'll do it, don't want to step on toes)
[14:36] <jamespage> hallyn, happy for you todo that :-)
[14:37] <pitti> cyphermox: looking at urfkill -- what was the reason to drop d-bus activation in favor of an upstart job? isn't starting on demand appropriate somehow? (and how doesn't that affect debian then?)
[14:40] <rbasak> Logan_: any objection if I sync haproxy 1.5.10-1 from Debian experimental? Looks like a straightforward upstream bugfix release.
[14:43] <hallyn> jamespage: on it
[14:47] <stgraber> hallyn: nope, I think we're good with current git trunk
[14:47] <stgraber> pitti: cool, thanks!
[14:49] <hallyn> pitti: are you by chance DD ?
[14:49] <pitti> stgraber: bonjour !
[14:49] <pitti> hallyn: yes
[14:49] <hallyn> pitti: cool, i'll hit you up for sponsoring? :)
[14:49] <pitti> hallyn: "by chance" .. it's what brought me into this Ubuntu business in the first place :)
[14:49] <hallyn> pitti: i really need ot pursue dm
[14:49] <pitti> hallyn: sure!
[14:50] <hallyn> pitti: i had a feeling  :)  but i've been wrong about that before
[14:51] <pitti> hallyn: so, toss me a .dsc or a debdiff or a git link, and I can upload it
[14:53] <pitti> hallyn, stgraber: btw, any immediate idea what breaks overlayfs (for lxc-start-ephemeral) on current 3.18 kernel? I filed bug 1409425
[14:53] <pitti> I tried to look into the upstream git, and there's a commit that sounded related
[14:53] <pitti> but we already have that
[14:54] <pitti> hallyn, stgraber: i. e. my question is -- is current git head working for you? if so, then I'll just wait for the new release :0
[14:55] <stgraber> pitti: nope, no clear idea as to what's going on here. I'd have to try the daily PPA on a 3.18 system to see what's going on. (Currently running on a 3.13 kernel here as I've been having other problems with 3.16 and 3.18)
[14:55] <Saviq> tvoss, hey, could we have your opinion on https://bugs.launchpad.net/ubuntu/+source/trust-store/+bug/1384950/comments/7 ?
[14:57] <tvoss> Saviq, sure, on my list
[15:08] <hallyn> pitti: i'm on 3.18.0-8-generic #9 with ppa lxc.  overlay clones are working for me
[15:08] <pitti> hallyn: great! I like retroactive bug fixing :)
[15:08] <pitti> stgraber: ^ FYI
[15:09] <cyphermox> pitti: as I recall there was a conflict between the dbus activation and the upstart job; but really xnox and awe knew about the details of this more than I did
[15:09] <hallyn> pitti: i would've thought the mount fix for overlay was in the archive...  but maybe not
[15:09] <pitti> hallyn: it is, that's the thing
[15:09] <hallyn> hm
[15:09] <pitti> hallyn: maybe it needed something else or there was a followup fix which I missed; I didn't really look very hard
[15:09] <hallyn> pitti: could you 'lxc-start -n <container> -l trace -o outout' and pastebinit outout?
[15:09] <cyphermox> pitti: the only thing I could think of right now is that we'd want urfkill to be started as early as possible on touch, earlier even than NM would start it or whatever, since it has to do some device enablement early on
[15:10] <pitti> hallyn: lxc-start is fine, it's -ephemeral which is broken (overlayfs)
[15:10] <pitti> hallyn: and l-s-e doesn't seem to have any debug options?
[15:10] <xnox> cyphermox: yo, sup? use busname in systemd units, don't mix dbus activation and upstart jobs. E.g. look at ofono, $ sudo stop ofono => yet org.ofono remains on the bus.
[15:10] <xnox> (spawned as a new process if there were any org.ofono clients e.g. d-feet)
[15:11] <pitti> xnox: I was looking at our urfkill delta, and we install an upstart job instead of using dbus activation, and I was wondering why
[15:11] <xnox> pitti: let me tell you why.
[15:11] <pitti> xnox: cyphermox's "early device setup" certainly makes sense, if we need that
[15:11] <pitti> Debian might not have that use case
[15:11] <hallyn> pitti: oh, but try 'lxc-clone -s -o container1 -n container2' and then lcx-start -n container2
[15:12] <pitti> hallyn: how does that use overlayfs?
[15:12] <cyphermox> pitti: I'm not sure that's a good enough reason not to properly fix urfkill to be started properly by systemd ;)
[15:12] <hallyn> yes
[15:12] <pitti> hallyn: cloning and starting works fine
[15:12] <pitti> oh, -s?
[15:12] <hallyn> d'oh
[15:12] <hallyn> pitti: don't bother
[15:12] <hallyn> stgraber: i was thinking lcx-start-ephemeral used the api more tha nit does.
[15:13] <hallyn> stgraber: lcx-start-ephemeral needs to be updated the same way the api did, for the new overlayfs options
[15:13] <xnox> pitti: did urfkilld restore state of things? and thus we wanted it to start earlier. Anyway, it should be systemd unit with busname and WantedBy=multi-user.target or some-such, to stay equivalent.
[15:14] <xnox> pitti: and my grep of all upstart jobs and initscripts does not reviel any reverse dependencies (e.g. start on started urfkill) or anything like that.
[15:14] <xnox> cyphermox: pitti: oh I remember why i dropped dbus activation and added upstart job.
[15:15] <stgraber> hallyn: ah, right
[15:15] <xnox> cyphermox: pitti: we were at a sprint in malta and the phone testing would not work, because urfkill would start even when not needed during testing.
[15:16] <cyphermox> not needed during testing?
[15:16] <xnox> cyphermox: pitti: dropping dbus activation allowed to reliably control execution -> not needed with proper systemd unit / dbus-activation.
[15:16] <xnox> cyphermox: as in testing would mock urfkill, and the real one should not be present at the time.
[15:17] <xnox> cyphermox: there was this other guy from phonedations that came to me with a bug about it.
[15:17] <cyphermox> ah, makes sense
[15:17] <cyphermox> yeah, Tony
[15:17] <xnox> old, tall, skinny, scruffy. probably tony.
[15:17] <hallyn> xnox: hi, any updates on the netcf upload for debian?
[15:17] <xnox> pitti: is there a way to suspend dbus activation?
[15:18] <hallyn> (don't know what tz you'r ein and don't want to miss you :)
[15:18] <xnox> hallyn: bah, did not upload. Can you please drop me an email to xnox @ debian . org, such that I do it when I'm back home?
[15:18] <xnox> hallyn: mostly +0 UTC ~=
[15:18] <pitti> xnox: yeah, don't install a .service file
[15:18] <hallyn> xnox: thanks
[15:18] <pitti> xnox: so, why would a test not just stop the system urfkill and/or replace its bus name?
[15:19] <xnox> pitti: well that's what we did.... I mean suspend on temporary basis.
[15:19] <pitti> xnox: anyway, it's not a problem to port the upstart job, I was just curious why
[15:19] <xnox> pitti: good point. i mean have .service file, but disable it via /run or some such.
[15:20] <xnox> pitti: with .service file and systemd-dbus activation one can do $ systemctl disable urfkill and that will suspend that job, even if dbus activation of it is attempted (as far as i can tell)
[15:20] <xnox> pitti: talk to tony, he might remember where/how "urfkill was getting spuriously activated, when not desired"
[15:20] <pitti> xnox: right
[15:21] <xnox> pitti: i have just little bits and pieces to extend in the local-bridge and then our session-upstart-init will be fully decoupled from upstart-pid1 and we can port phone to systemd, atleast for pid1.
[15:21] <xnox> well, phonedations people can.
[15:22] <pitti> yay!
[15:25] <Riddell> didrocks: what's the status of bluez5 in utopic?
[15:26] <Riddell> didrocks: _Groo_ is packaging bluedevil
[15:30] <didrocks> Riddell: waiting on some unity-system-settings change
[15:30] <didrocks> Riddell: then, we'll be good to go, but we need rsalveti and the kernel team to work on the Touch side
[15:39] <Riddell> didrocks: this new bluedevil only supports bluez5, is there a ppa we should put it in until bluez5 gets in the archive?
[15:40] <didrocks> Riddell: yes! please use https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
[15:40] <didrocks> Riddell: core-devs should have access to it
[15:40] <didrocks> Riddell: building on all archs
[15:41] <Riddell> all arches? ppas can do that?
[15:42] <slangasek> pitti: hi, why did you remove the juju-related systemd workitem from the blueprint?
[15:43] <pitti> slangasek: it was replaced with a bug link
[15:43] <slangasek> ok
[15:43] <didrocks> Riddell: some are devirtualized, yeah
[15:43] <didrocks> Riddell: it's using the distro builders
[15:44] <slangasek> pitti: regarding mailing u-d-a, I'm not sure this needs u-d-a as opposed to just u-d
[15:44] <pitti> slangasek: u-d@ WFM too, but I thought such kinds of announcements would be on-topic
[15:45] <xnox> slangasek: are phonedations people going to be on the sprint?
[15:45] <xnox> doko: why do you statically link libpython2.7 into the python interpreter?
[15:45] <pitti> slangasek: anyway, I think except for a hangout time (which we can put into the pad later) we should be set?
[15:47] <hallyn> pitti: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.35-1.dsc
[15:50] <pitti> hallyn: any reason why you didn't just write LP: #1400394 in the changelog to actually close the bug?
[15:51] <pitti> hallyn: can I do that on upload, or will that disrupt some git?
[15:54] <slangasek> pitti: is this pad the draft for the announcement you're sending?  if so I guess we should set the hangout time first :)
[15:54] <hallyn> pitti: no git involved.  i just didn't do it bc debian <shrug>
[15:54] <hallyn> pitti: please go ahead
[15:54] <pitti> slangasek: no, that's the actual working scratchpad; for the annoucement we shouldn't replicate that IMHO, just saying when and wher it happens
[15:54] <slangasek> pitti: ok
[15:54] <slangasek> let me give the pad a quick read this morning (currently otp)
[15:56] <xnox> pitti: can i haz url plz =)
[15:56] <pitti> xnox: http://pad.ubuntu.com/systemd-porting-sprint
[15:58] <mitya57> sil2100, hi, when will you be able to look at appmenu-qt5?
[15:58] <mitya57> I got submenus working yesterday, that needed some patching on qt side
[15:59] <mitya57> also I tested it with more real-world applications, worked fine
[16:01] <pitti> hallyn: uploaded
[16:02] <sil2100> mitya57: hey! Sorry about that, I was supposed to do that before EOY but I think I got distracted due to the last-year touch image milestone, I promise looking at parts of it today and finalizing it tomorrow
[16:03] <mitya57> Thank you, no problem, we all were on holidays
[16:05] <hallyn> pitti: thanks!
[16:08] <jamespage> pitti, ironic should be sorted now - pysendfile was missing egg-info
[16:09] <flexiondotorg> I've submitted some merge proposal for livecd-rootfs and ubuntu-cdimage that add support for Ubuntu MATE.
[16:09] <pitti> jamespage: ah, dh_python looks at that to map the "import" to the python:Depends? I see
[16:09] <jamespage> pitti, indeed it does
[16:09] <flexiondotorg> How do I go about "integrating" (for want of a better expression) the Ubuntu MATE seeds?
[16:09] <flexiondotorg> Is there a package I should create a merge proposal against?
[16:11] <flexiondotorg> The Ubuntu MATE seeds are here - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid
[16:27] <hallyn> jamespage: the kvm-ipxe package was there for p->t transitions, so we can drop it now right?
[16:27] <hallyn> yeah i think so.  anyway i'll try some upgrades to make sure
[16:42] <cjwatson> flexiondotorg: Mm, that stuff is not handled very well, needs an archive admin to mirror them on http://people.canonical.com/~ubuntu-archive/seeds/ and point a few things at them.  Will sort that out for you.
[16:42] <flexiondotorg> cjwatson, Many thanks for helping.
[16:45] <cjwatson> flexiondotorg: That part is done, should be visible soon.  There are various bits of lp:ubuntu-cdimage that need to be edited to point to the appropriate places.  Grepping for something like ubuntu-gnome is probably a good way to find them.
[16:46] <xnox> cjwatson: has kylin been fixed in those places?
[16:46] <cjwatson> I think so
[16:46] <xnox> cool.
[16:52] <flexiondotorg> cjwatson, Thanks. I think I've identified all the place ubuntu-mate need to be added. Prepairing a new proposal now.
[17:01] <flexiondotorg> cjwatson, When I try to resubmit the merge proposal launchpad tells me: This branch is not mergeable into lp:~ubuntu-cdimage/debian-cd/ubuntu.
[17:04] <cjwatson> flexiondotorg: That's because your branch is in the ubuntu-cdimage project, not in the debian-cd project.
[17:04] <cjwatson> flexiondotorg: You can move it on https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate/+edit
[17:04] <pitti> slangasek: off for the night; if/when you are happy with the pad, perhaps you can send the announcement over your day, otherwise I'll send it tomorrow morning?
[17:05] <flexiondotorg> cjwatson, Understood.
[17:12] <flexiondotorg> cjwatson, Thanks for your help. I've resubmitted and it looks sane.
[17:45] <hallyn> jamespage: pushing a test build of ipxe to ppa:serge-hallyn/virt.  will push to vivid in a few hours
[18:59] <hallyn> stgraber: did you want me to take a stab at that lxc-start-ephemeral update, or are you doing it?
[19:01] <stgraber> hallyn: feel free to do it. I'm currently busy getting the lxcfs packaging ready for the archive. Though I'm happy to take care of it once I'm done.
[19:59] <hallyn> stgraber: ok, doesn't look too bad;  and i see Miklos made the overlay filesystem type 'overlay', so you can check for a 'overlay' (in additoin to or instead of 'overlayfs') entry in /proc/filesystems.
[20:00] <stgraber> hallyn: right
[20:26] <hallyn> stgraber: feh, just lost some time bc i was re-using a test container in a bad state
[20:27] <hallyn> k got something working
[22:06] <ahoneybun> balloons, I have a machine I can play around with now, how best do I help with testing?
[22:08] <Unit193> ahoneybun: I'd think the best place to ask would be channel 27, #ubuntu-quality.
[22:09] <ahoneybun> k thanks Unit193
[22:10] <staylor_> Curious about the recommended way of handling device trees with custom kernel packaging.  We have a custom package for support various embedded boards for a number of customers, right now we have one package per customer but the kernels themselves are effectively all the same and custom device tree files is the main difference.
[22:12] <staylor_> So I'm thinking of just removing the *.dtb from the kernel-image-custom package and instead have a number of device-tree-customerA/device-tree-customerB packages.