[00:46] <andrewrk> is the fix for the fact that GtkStatusIcon does not work with Unity included in Utopic?
[00:51] <slangasek> desrt: so mbiebl_ has reopened Debian bug #756076, saying that systemd-shim 8-1 doesn't actually work with logind
[00:58] <slangasek> hallyn: cgmanager 0.32-2 uploaded
[01:00] <ScottK> So is phone a long term fork of the regular distro now?
[01:01] <ScottK> (trying to figure out how Oli's email relates to other stuff)
[01:05] <slangasek> no
[01:06] <slangasek> the exact release cycle alignment is TBD
[01:06] <slangasek> this merely stipulates the cycle by which updates are made available to phone end users
[01:13] <ScottK> OK.  Given the content of the updates, I don't see alignment with distro release/updates.
[01:14] <ScottK> Maybe someone that understands both could propose how they might relate.
[01:53] <hallyn> slangasek: thanks.  (the other bug is just the recursive proxy fn calling the on-recursive main fn)
[02:11] <hallyn> slangasek: 0.32-3 pushed to mentors, but if you want to wait on that that should be fine.  it can probably wait until 0.33 for that matter
[02:12] <hallyn> (which should have the listkeys method stgraber needs)
[02:26] <slangasek> hallyn: uploaded
[02:36] <hallyn> slangasek: thanks!
[02:39] <hallyn> will sync into utopic tomorrow.
[02:40] <hallyn> that's where i expect some bug reports through systemd-shim in containers
[04:46] <Mirv> if there's a core-dev around wanting to help, there'd be a packaging ack to ack or nack which changes a funny build-dep to a useful build-dep now that they apparently use it https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/19/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1239+14.10.20140908-0ubuntu1.diff
[04:47] <pitti> Good morning
[04:47] <pitti> slangasek: yes, I understand it (bit of a long story); I added an ugly workaround last night and will now fix that properly
[04:52] <pitti> slangasek: can you please push systemd-shim to bzr? I'll do an 8-1exp1 upload now to rebuild against 215
[04:52] <slangasek> pitti: yep, pushed
[04:53] <pitti> slangasek: cheers; mbiebl wants to upload 215 to unstable RSN, so that double-upload won't be necessary any more
[04:54] <slangasek> Mirv: looking at this diff, I'm more concerned about the dropping of qml files from a package that's part of the SDK - are we sure this isn't an API break?
[04:57] <Mirv> bzoltan: http://pastebin.ubuntu.com/8315784/
[04:57] <Mirv> bzoltan: so that's regarding the Colors/*.qml
[04:58] <Mirv> bzoltan: what about apps that use them?
[04:58] <bzoltan> Mirv:  none of the System and Core apps are using that, but let m check
[05:03] <bzoltan> Mirv: slangasek: the Colors/*.qml is not the part of the API offering. No apps should directly use those files.
[05:43] <slangasek> Mirv, bzoltan: ok, packaging changes acked
[05:44] <bzoltan> slangasek:  thank you :) and thanks for being alert
[05:48] <Mirv> thanks!
[06:33] <mvo_> jamespage, jamespage_: is  lp:~james-page/software-properties/juno-support  stillrelevant? if so, I have a look now
[06:42] <dholbach> good morning
[07:19] <doko> stgraber, zul: looking at the python-lxc package in NEW. is there a reason that you don't build a python3-lxc package?
[08:41] <doko> pitti, jibel: please give back the python3.4 autopkg test on i386
[08:41] <pitti> doko: already done
[08:41] <doko> thanks
[08:54] <doko> NBS empty \o/
[08:55] <pitti> hooray! and so much before release!
[08:55] <pitti> s/much/long/
[09:17] <nik90> stgraber: hey, so I was able to open qtcreator running in the lxc :) I used pretty much the same config you used for google chrome.
[09:18] <nik90> stgraber: I am running into 2 issues which I couldn't fix, the first being able to detect a connected N4 phone (/dev/usb doesn't seem to exist) and second being able to create a schroot inside qtcreator.
[09:18] <nik90> stgraber: On trying to create a schroot, I get the following message http://paste.ubuntu.com/8317272/
[09:19] <nik90> stgraber: in particular the line "E: Cannot install into target '/var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf' mounted with noexec or nodev" seems interesting. I don't see any lxc.mount statement which does this. Anyway I can change that to allow creating a schroot
[09:31] <nik90> stgraber: sry, I meant can I change that to allow creating a schroot?
[09:36] <doko> robru, dbus-test-runner autopkg tests fail after your recent upload
[09:38] <doko> glance (1:2014.2~b2-0ubuntu2 to 1:2014.2~b3-0ubuntu1)
[09:38] <doko> Maintainer: Ubuntu OpenStack
[09:38] <doko> 4 days old
[09:38] <doko> python-glance/i386 unsatisfiable Depends: pyhton-osprofiler
[09:38] <doko> python-glance/i386 unsatisfiable Depends: python-ordereddict
[09:38] <doko> Not considered
[09:38] <doko> zul, jamespage: just another typo, don't know about python-ordereddict
[09:40] <shadeslayer_> mvo_: poke
[09:42] <victorp> popey, ping
[09:44] <popey> hello victorp
[09:45] <mvo_> hey shadeslayer_ - I'm about to leave for lunch, but I will read scrollback and can answer when I'm back
[09:45] <mvo_> shadeslayer_: unless its quick in which case I can answer right away :)
[09:46] <shadeslayer_> mvo_: any ideas if appstream in lp is something you will be working on?
[09:47] <mvo_> shadeslayer_: I plan to work on client side support in apt to make the content fetching a (optional) part of apt-get update. but nothing more is planed on my part right now
[09:51] <shadeslayer_> mvo_: right, but how would content generation work ?
[09:51] <shadeslayer_> I.e. extract appstream data from packages
[09:52] <doko> pitti, infinity: is the glibc/langpack merge still scheduled for 14.10?
[10:03] <cjwatson> doko,stgraber,zul: there's already a python3-lxc in the archive, built from separate source
[10:05] <doko> ahh, ok
[10:05] <doko> then I'll accept the one in NEW
[10:24] <doko> jamespage, zul: python-oslo.utils MIR is incomplete
[10:26] <Mirv> doko: I got datetime - module not found with python 2.7 on utopic. downgrading to 2.7.8-6ubuntu1 fixed my issue.
[10:26] <Mirv> running lp:click-toolbelt
[10:28] <doko> Mirv, works here
[10:30] <doko> Mirv, so please be more specific
[10:31] <doko> there was a change, it is now a builtin instead of an extension
[10:33] <Mirv> doko: yes, I filed bug #1368144 about it now. maybe I'd need to recompile it or something, but at least that's what happens when executing the old ./click-toolbelt with new python. I must admit that click-toolbelt is a bit confusing beast to build for me, so I've tended to use the existing one when possible.
[10:34] <Mirv> I know that simple import datetime still works
[10:34] <cjwatson> python-saharaclient needs an MIR from somebody who cares about python-heat
[10:38] <doko> Mirv, is there a virtualenv involved?
[10:42] <Mirv> doko: yes. so, if this is expected, feel free to mark as invalid. just reporting the oddity.
[10:42] <jamespage> doko, ack - will followup with zul when he starts
[10:42] <jamespage> looking at oslo.utils now
[10:42] <doko> Mirv, I guess the python executable is copied into it, but not the standard extensions.
[10:49] <doko> jamespage, just fyi, https://launchpad.net/ubuntu/+source/tuskar/0.4.2-2/+build/6072038, requires new nova
[10:50] <cjwatson> shadeslayer_,Riddell: somebody needs to refresh the kubuntu-plasma5 PPA for the libav11 transition, it seems
[10:50] <cjwatson>  libkf5filemetadata-bin : Depends: libavformat55 (>= 6:10~beta1~) but it is not installable
[10:50] <cjwatson>                           Depends: libavutil53 (>= 6:10~beta1~) but it is not installable
[10:50] <cjwatson> that's the root of the current image build failure
[10:50] <shadeslayer_> cjwatson: we're all at Akademy, with shit internet
[10:50] <shadeslayer_> so it's going to be hard to get to it before Monday
[10:51] <cjwatson> looks like just that one package
[10:51] <shadeslayer_> I'll try
[10:51] <cjwatson> it's probably just a straight rebuild of kfilemetadata-kf5
[10:52] <cjwatson> shadeslayer_: oh wait, I apparently have upload privileges
[10:52] <shadeslayer_> ack
[10:52] <shadeslayer_> cjwatson: oh awesome :D
[10:52] <cjwatson> things I did not know.  I'll sort it out then
[10:53] <cjwatson> and I'll not bother with next-staging since it's uninstallable right now anyway ...
[11:05] <jamespage> doko, ack
[11:12] <doko> mlankhorst, are there still some xserver binaries to remove?
[11:28] <doko> mlankhorst, should x11-xfs-utils really be demoted?
[11:28] <zul> doko/jamespage: ack
[11:30] <sil2100> @pilot in
[11:31] <pitti> cjwatson: what was the trick again to tell "apt-get -o Dir::Etc::sourcelist=/dev/null" to not remove already downloaded indexes again from /var/lib/apt/lists?
[11:31] <pitti> or mvo_ ^
[11:31] <cjwatson> pitti: --no-list-cleanup
[11:31] <pitti> I'd like to only download the indexes from one added source (a local file:// or a PPA), for efficiency
[11:31] <pitti> cjwatson: ah, cheers!
[11:31] <mvo_> pitti: APT::Get::List-Cleanup=false
[11:31] <mvo_> aha, or the other one :)
[11:32] <cjwatson> but I'm not sure whether that still forgets that the packages from the other sources exist
[11:32] <pitti> mvo_: ah thanks, "apt-config dump|grep -i clean" (or "grep -i list") didn't give anything, but it's indeed in the manpage
[11:33] <pitti> cjwatson: at least apt-cache policy seems happy
[11:34] <cjwatson> cool
[11:36] <pitti> sudo apt-get --no-list-cleanup -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/canonical-x-x-staging-utopic.list -o Dir::Etc::sourceparts=/dev/null update
[11:36] <pitti> that seems to by and large do what I want
[11:36] <pitti> and like 50 times faster :)
[11:37] <mvo_> pitti: great
[11:37]  * pitti puts that into autopkgtest and checks whether all the tests are still happy
[11:41] <sil2100> @pilot out
[11:42]  * sil2100 lunch o/
[12:10]  * dholbach hugs sil2100
[12:13]  * sil2100 hugs dholbach back
[12:13] <dholbach> :)
[12:15] <pitti> dpm: could you please add http://people.canonical.com/~dpm/data/ubuntu-l10n/ for 14.09 (ubuntu-rtm)?
[12:17] <sil2100> ;)
[12:25] <dpm> pitti, yes, I'll have to talk to wgrant on how to do it. It requires setting up a cron job for an exporter script in LP, and I'm assuming we can do it for ubuntu-rtm/14.09 in the same way we can do it for ubuntu series
[12:25] <pitti> yeah, it's pretty well the same
[12:33] <pitti> wgrant: I just filed bug 1368209, I can't explain that myself
[12:34] <pitti> dpm: I added a WI to https://blueprints.launchpad.net/ubuntu/+spec/qa-u-spanish-translations FYI
[12:35] <dpm> thanks pitti, I'm on it
[12:35] <pitti> dpm: cheers
[12:35] <pitti> (just for tracking stuff)
[12:38] <dpm> pitti, replied to that bug
[12:41] <pitti> dpm: yes, unity8's domain is indeed "unity8"; I just diffed our current langpacks with some extra "directly from trunk" imports, I wondered about that too
[12:41] <dpm> pitti, yeah, I was surprised that we pull unity as well
[12:41] <dpm> along unity8, I mean
[12:42] <sil2100> @pilot in
[12:42] <pitti> dpm: yeah, it's in the package list, apparenlty something still keeps it in the seeds
[12:42] <pitti> dpm: but yeah, that one can probably go
[12:44] <pitti> dpm, wgrant: closed bug then, thanks!
[12:44] <dpm> pitti, sent the RT, updated BP
[12:44] <pitti> dpm: it's great to have you back :)
[12:45] <dpm> pitti, thanks, it's great to have you, and I expect it to be for 10 more years at least! ;)
[12:46] <wgrant> Oh
[12:46] <wgrant> I was just going through them all to work out why you were wrong :P
[12:46] <pitti> wgrant: I expected that I was, but I wanted to understand why :)
[12:52] <flexiondotorg> cjwatson, dholbach is helping get some of the Ubuntu MATE package cleaned up.
[12:53] <flexiondotorg> cjwatson, I am also wondering what format I should provide Ubuntu MATE SYSLINUX themes in? I have theme, just not sure if they should be packaged as debs?
[13:13] <desrt> hallyn: looks like we have troubles :(
[13:18] <dpm> seb128, quick question: the translations for indicator-transfer for the RTM distro don't seem to be enabled, and I don't see any templates in its import queue: https://translations.launchpad.net/ubuntu-rtm/14.09/+source/indicator-transfer/, whereas you showed me that the ones on ubuntu/utopic are: https://translations.launchpad.net/ubuntu/utopic/+source/indicator-transfer/ - any ideas why? I'm not quite sure how the upload workflow works between the two
[13:18] <dpm>  distros
[13:19] <seb128> dpm, hey, no idea how those imports work with pocket copies
[13:20] <dpm> pitti, perhaps you know? ^
[13:20] <seb128> dpm, pitti, oh
[13:21] <seb128> it seems like that version just didn't get uploaded to rtm
[13:21] <seb128> https://launchpad.net/ubuntu-rtm/+source/indicator-transfer
[13:21] <seb128> dpm, let me file a sync request for it
[13:21] <dpm> ah, that'd explain it, thanks seb128
[13:31] <pitti> dpm, seb128: ATM I'm still syncing ubuntu langpacks to RTM
[13:32] <pitti> as ubuntu-rtm langpacks are still blocked by some small things
[13:34] <seb128> pitti, blocked?
[13:35] <pitti> seb128: main thing for now is getting dpm's translation stats for RTM
[13:35] <pitti> I think everything else is sorted out, I did some import queue approvals etc.
[13:35] <seb128> pitti, how are stats blocking package copies?
[13:35] <pitti> seb128: oh, they don't
[13:35] <pitti> seb128: I mean RTM specific langpack builds
[13:36] <seb128> oh, ok
[13:36] <pitti> seb128: right now I do package copies as we haven't diverted too much
[13:36] <seb128> right
[13:57] <stgraber> doko, cjwatson: correct, we ship a python3-only binding as part of the upstream source and don't want to be backward compatible to python2 there. However openstack and some other distros (RHEL) don't ship or don't support python3 quite completely yet so we have that separate source tree with a python2 part of our binding. The main reason for the separation is that we support the python3 binding for 5 years whereas we have absolutely no inte
[13:59] <stgraber> nik90: so schroot is going to be tricky I suspect. The reason is that this is an unprivileged container so it's restricted in what it can do since it's not real root. One thing it can't do is create device nodes and that may be what's upsettin schroot.
[14:00] <stgraber> nik90: try adding lxc.aa_profile = unconfined to your config and see if that does the trick for schroot, but I doubt that'll be enough :(
[14:00] <stgraber> nik90: as for /dev/usb, you did put "lxc.mount.entry = /dev/usb dev/usb none bind,create=dir" in your container's config right?
[14:12] <sil2100> @pilot out
[14:24] <cjwatson> flexiondotorg: just send the updated images, in formats that match the Ubuntu ones
[14:26] <flexiondotorg> cjwatson, So for Ubiquity I should submit a merge proposal to ubquity-slideshow.
[14:26] <flexiondotorg> cjwatson, Where do I "send" the SYSLINUX theme too?
[14:26] <nik90> stgraber: I tried  "lxc.mount.entry = /dev/usb dev/usb none bind,create=dir" but the container does not start anymore since /dev/usb doesnt exist
[14:27] <nik90> stgraber: may be I should instead create a container as root
[14:27] <nik90> stgraber: although everytime I open the gui app, it will ask for sudo priviledges I suppose
[14:28] <cjwatson> flexiondotorg: ideally, a merge proposal against lp:~ubuntu-cdimage/debian-cd/ubuntu - the files go in data/utopic/
[14:28] <cjwatson> you should see the layout there, such as it is
[14:28] <flexiondotorg> cjwatson, Perfect. Thanks.
[14:29] <stgraber> nik90: hmm, the point of create=dir is that it should be creating it... anyway, you can just mkdir /dev/usb and try again, that should work
[14:30] <nik90> stgraber: ok
[14:47] <hallyn> desrt: i don't see any bug reports
[14:49] <doko> zul: just drop argparse everywhere. it's included in 2.7 and 3.4
[14:51] <doko> mlankhorst, xorg-server ping
[14:55] <desrt> hallyn: slangasek said that we got the original report reopen
[14:55] <desrt> http://bugs.debian.org/756076
[14:56] <hallyn> hm.  is there some 'we're done with this method' signal shim needs to send?
[14:56] <desrt> ya.  the method return message :p
[14:56]  * hallyn starts to suspect that comcast is anti-net-neutrality-ing the ubuntu archive
[14:57] <hallyn> hm, no, i guess it is ipv6  70% [Connecting to us.archive.ubuntu.com (2001:67c:1562::15)] [Connecting to se
[14:57] <hallyn> desrt: i'm trying ot update my system so i can test here
[14:57] <desrt> me too
[15:02] <hallyn> there we go, disalbed ipv6 in sysctl and now it works
[15:02] <hallyn> maybe it's comcast.  i hope it's comcast
[15:03] <hallyn> stgraber: ^ any known ipv6 bugs in the utopic kenrel right now?
[15:03] <zul> stgraber: has the openvsiwtch support made it to utopic yet for lxc?
[15:04] <stgraber> hallyn: nothing that I've noticed
[15:04] <stgraber> zul: no
[15:04] <zul> stgraber: is it?
[15:04] <hallyn> stgraber: when will you be merging lxc into utopic?
[15:04] <hallyn> stgraber: and ok, thx, i assume comcast is messing around then
[15:05] <flexiondotorg> cjwatson, I'm looking for where I should inject the Ubuntu MATE gfxboot.cfg settings. Looks like in tools/boot/utopic/boot-*. Correct?
[15:05] <stgraber> hallyn: once we're done getting the regressions out of master so I can finally tag alpha2
[15:05] <hallyn> regressions?  pshaw
[15:10] <cjwatson> flexiondotorg: yes
[15:14] <slangasek> hallyn, desrt: note specifically that mbiebl says this problem was with logind from 215 after a rebuild of systemd-shim
[15:15] <desrt> slangasek: not sure i understand why that would make a difference..
[15:15] <slangasek> desrt: I'm merely pointing out the difference, in case anyone has difficulty reproducing it
[15:16] <desrt> i just installed the update and am now rebooting...
[15:18] <desrt> hmm... i have 208 here
[15:19] <desrt> so he's right
[15:19] <desrt> the cgroup gets cleaned up, but logind doesn't know about it
[15:19] <desrt> i'll take a look
[15:19] <desrt> maybe there should be a signal or something, indeed
[15:39] <doko> zul: python-cliff has the same argparse problem
[15:39] <zul> doko: ack
[15:52] <flexiondotorg> cjwatson, Please could you cast an eye over my changes? If all looks good to you I'll submit a merge proposal - http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate/revision/1898
[15:52] <cjwatson> flexiondotorg: it's much easier for me to review after you submit a merge proposal - that's what they're for
[15:52] <flexiondotorg> cjwatson, OK.
[15:52] <cjwatson> you can always commit fixes on top after review (you don't need to resubmit the MP or anything)
[15:53] <cjwatson> well, assuming you branched from the right place
[15:53] <cjwatson> but looks like you did
[15:56] <flexiondotorg> cjwatson, Merge proposal submitted. Thanks for your help.
[16:00] <mlankhorst> doko: pong?
[16:01] <doko> mlankhorst, are there still some xserver binaries to remove?
[16:04] <mlankhorst> nvidia-173, glamor-egl, xserver-xorg-video-sis xserver-xorg-video-msm need to be gone
[16:05] <mlankhorst> I've asked on #ubuntu-release, no reply yet afaik
[16:05] <flexiondotorg> cjwatson, OK, that Merge proposal looks awfully wrong.
[16:06] <flexiondotorg> cjwatson, I've submitted it against the wrong branch. I'll resubmit.
[16:07] <mlankhorst> oops, xf86-video-msm (source package)
[16:07] <mlankhorst> but after that it should migrate
[16:10] <flexiondotorg> cjwatson, I don't appear to be able to submit a merge prospal against lp:~ubuntu-cdimage/debian-cd/ubuntu
[16:11] <mlankhorst> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt (near the bottom)
[16:12] <cjwatson> flexiondotorg: just mail me the URL then, I'm firefighting something else and can't look now.
[16:12] <flexiondotorg> cjwatson, Will do. Thanks.
[16:12] <doko> mlankhorst, please can you file a bug and add ubuntu-archive to the subscribers
[16:13] <mlankhorst> ok
[16:13] <mlankhorst> actually that's going to be a bit hard from here... don't have sso access and won't work until monday
[16:14] <mlankhorst> lets see..
[16:58] <Elv1313> Is it possible to enable ppc and ppc64 build for PPAs? It doesn't seem so ( https://help.launchpad.net/Packaging/PPA#Supported_architectures ), but we got a bug report that the official package doesn't build for it and would like to add ppc to our PPA repository
[16:59] <doko> no
[17:01] <cjwatson> Elv1313: we may do so in future once we have virtualisation working, but it's not available yet
[17:01] <Elv1313> ok thanks
[17:01] <Elv1313> arm64 would also be nice
[17:02] <cjwatson> arm64 is possible now, file a ticket on answers.launchpad.net/launchpad
[17:02] <cjwatson> although it'll have to build through qemu
[17:02] <Elv1313> (but we already have hardware to test that)
[17:02] <cjwatson> qemu-user-static that is
[17:02] <Elv1313> or cross compile
[17:03] <dobey> PPAs don't do cross compiling
[17:03]  * Elv1313 would not want to be the one setuping that
[17:05] <cjwatson> dobey: (yet; I have been thinking about how to do that ...)
[17:05] <Elv1313> Another question, is it totally too late to get an upgraded package into 14.10? We (sflphone) have made a release in July that fix all issues reported by errors.ubuntu.com and then some. The changes are too large to be considered a stable update. We have enough PPA users to have confirmation that this version is much more stable then the one currently in 14.10
[17:05] <doko> mlankhorst, there are still reverse dependencies
[17:06] <dobey> Elv1313: is it in main or universe?
[17:07] <Elv1313> dobey: https://launchpad.net/ubuntu/utopic/+package/sflphone-daemon
[17:08] <dobey> Elv1313: it's in universe, so it should be pretty easy to get a newer version in.
[17:08] <cjwatson> it would be very helpful to get the new version into Debian first
[17:09] <cjwatson> much easier then for us to just merge, and it helps more people that way
[17:09] <Elv1313> dobey: Ok, thanks. If there any protocol to follow? I only pushed stable updates before, never totally new versions
[17:09] <dobey> indeed. especially if it's already there, and the new version can drop the ubuntu-specific changes
[17:09] <Elv1313> so email debian guys first?
[17:11] <dobey> whoever maintains it in debian, yeah
[17:11] <Elv1313> then, ask again or #ubuntu-devel or fill a launchpad bug?
[17:12] <cjwatson> LP + here
[17:16] <Elv1313> ok thanks
[17:35] <RoyK> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1364091 is this being worked on?
[18:06] <smoser> hey.
[18:06] <smoser> i have a upstart quesiton
[18:06] <smoser> it seems from experimenting that a pre-start script does not get a kill on 'stop'. is that right ?
[18:29] <slangasek> smoser: that doesn't sound "right", but perhaps there's a bug.  Maybe check the open bug list to see if it's a known issue?
[18:47] <mlankhorst> doko: nvidia-173 still seems to be a possible fullfilment as dependency for boinc-nvidia-cuda in debian
[18:47] <mlankhorst> but it works fine without
[18:51] <mlankhorst> and -ati was fixed in -proposed to not need glamor-egl
[18:51] <desrt> slangasek: i think this might actually be vaguely something like a logind bug
[18:51] <desrt> slangasek: but it's a bug that wouldn't be a problem in normal circumstances, so that makes it our bug again....
[18:51] <slangasek> desrt: bug-for-bug compatibility
[18:51] <slangasek> welcome to Windows
[18:52] <desrt> the problem is that we never properly signal the _start_ of the session, which leaves a stale job in the 'scope_job' field of the session in logind
[18:52] <desrt> at logout time, logind sees this and assumes that it's the _stop_ job still in progress
[18:52] <desrt> whereas abandon doesn't signal completion
[18:52] <desrt> logind for this reason doesn't properly clear the scope_job field when issuing Abandon
[18:53] <desrt> should have a test to fix soon...
[18:54] <desrt> er... a fix to test :)
[18:54] <slangasek> oh, I assumed you were being TDD ;)
[18:54] <desrt> tests?  in systemd-shim?  surely you kid :p
[19:07] <smoser> slangasek, http://paste.ubuntu.com/8321182/
[19:08] <smoser> i think that illustrates my point.
[19:08] <smoser> and now i'll bother you with what i was trying to do
[19:08] <smoser> i was trying to block bringing up of network interfaces until some event had occurred.
[19:09] <slangasek> smoser: are you expecting upstart to kill the sleep process?  that's not the main process of the job; the main process of the job is the shell
[19:09] <smoser> it kills neither
[19:10] <slangasek> so I would expect one of two things: 1) upstart kills the script, making it the shell's job to clean up the child process; or 2) upstart kills all related processes via cgroupy magic, and the shell doesn't get a chance to tell you what happened
[19:10] <smoser> well, its neither :)
[19:10] <slangasek> sure, understood
[19:10] <slangasek> I just don't think your script here illustrates that particularly well :)
[19:10] <smoser> i would have expected it to send SIGTERM to the script
[19:11] <smoser> well, i avoided the handling of traps to simplify
[19:11] <smoser> http://paste.ubuntu.com/8321199/
[19:11] <slangasek> smoser: anyway, perhaps compare with wait-for-state, which does exactly this sort of thing with a main script instead of a pre-start script - I don't see that a pre-start gives you anything here (except, apparently, some bugs)
[19:11] <smoser> ^ that one is what i was actually trying to do.
[19:11] <smoser> pre-start allows you to block starting
[19:11] <smoser> i dont think starting does
[19:11] <smoser> er.. i dont think main script does
[19:11] <slangasek> it does if you mark the job 'task'
[19:11] <smoser> at least per comments in /etc/init/network-interface-security.conf
[19:11] <slangasek> IIRC
[19:12] <smoser> # Since we need these profiles to be loaded before any of the above services
[19:12] <smoser> # begin running, this service must be a pre-start so that its pre-start
[19:12] <smoser> # script finishes before the above services' start scripts begin.
[19:12] <slangasek> smoser: see documentation of 'task' in init(5), which agrees
[19:12] <smoser> that may be out of date.
[19:12] <slangasek> or it may have never been true ;)
[19:13] <slangasek> well, for the specific case of n-i-security, it applies because we care about those jobs ending in a 'started' state
[19:13] <slangasek> you may care about that here also, in which case yeah, you can't 'task' it to work around a bug in pre-start handling
[19:14] <smoser> where do you see information about task that you're pointing me at ?
[19:14] <slangasek> I would say that at that point, the only workaround would be polling (ick)
[19:14] <slangasek> smoser: the init(5) manpage?
[19:14] <slangasek>       task   This stanza may be used to  specify  that  the  job  is  a  task
[19:14] <slangasek>               instead.   This  means  that  the act of starting the job is not
[19:14] <smoser> right.
[19:14] <slangasek>               considered to be finished until the job itself has been run  and
[19:14] <slangasek>               stopped  again,  but  that exiting with a zero exit status means
[19:14] <slangasek>               the task has completed successfully and will not be respawned.
[19:14] <smoser> i didn't understand that to mean exactly what you said.
[19:14] <smoser> i'll try that.
[19:14] <slangasek> implied is that, until the task is 'started', it doesn't release the starting event
[19:15] <smoser> you're aying make my job a task
[19:15] <slangasek> yes
[19:15] <smoser> and make it 'script' instead of 'pre-script'
[19:15]  * slangasek nods
[19:15] <slangasek> and if you /still/ aren't getting signalled, then... ick
[19:16] <smoser> hm..
[19:54] <desrt> urg... every further step i take requires me to take one more
[20:11] <smoser> slangasek, http://paste.ubuntu.com/8321639/
[20:12] <smoser> thats my cloud-init-blocknet.conf .
[20:12] <smoser> does not seem to block networking.
[20:13] <smoser> as i can ssh in, and see a blocker running (cloud-init-blocknet (network-interface/eth0) start/running, process 465)
[20:16] <slangasek> smoser: er, of course it doesn't block it, where's the word 'task'? :)
[20:17] <smoser> bah
[20:18] <smoser> ok.
[20:18] <smoser> well that fixed that... now to figure out why it wasn't getting stopped.
[20:19] <hallyn> jdstrand: oh hurray!  i've got apparmor-confined libvirt-lxc containers.
[20:19] <jdstrand> hallyn: oh nice!
[20:19] <hallyn> now, do we want to make these default?  i think we do, but maybe we'll break someone?
[20:20] <jdstrand> I would say 'yes'
[20:23] <hallyn> ok.  i'm going to add this to the libvirt 1.2.8 proposed package, then ping here on the FFE we're waiting on to push 1.2.8
[20:25] <hallyn> jdstrand: one more thing, i notice that upstream libvirt-qemu abstraction has a sub-policy for running qemu-bridge-helper.  i'll add that to ours (in debian/apparmor/lbivirt-qemu) unless you say that's a bad idea
[20:25] <jdstrand> no, that's good
[20:26] <jdstrand> I think I reviewed it
[20:28] <hallyn> cool
[20:30] <blkperl> hi, I'm running into bug 1124250, would someone be able to push this bug forward?
[20:33] <slangasek> blkperl: it doesn't appear that a fix is known, right?  does changing the settings in /proc/sys/kernel/keys, as discussed in the linked RH bug, have any effect?
[20:37] <blkperl> slangasek: ok ill try that
[21:50] <hallyn> jdstrand: apparmor policy will need a few tweaks though to let an ubuntu container run. :(
[21:56] <jdstrand> hallyn: that's ok. that is thankfully not difficult
[22:01] <hallyn> jdstrand: yeah but i suppose i ought to do it before uploading 1.2.8 (with default=on :)
[22:02] <jdstrand> heh, yes :)
[22:06] <jdstrand> pretty
[22:06] <jdstrand> peer_addr="@/tmp/.X11-unix/X0��������عg#" peer="unconfined"
[22:06] <sarnold> ooo
[22:07] <jdstrand> jjohansen: fyi, it happens with peer_addr to (not surprising with shared code)
[22:08] <jdstrand> jjohansen: this is what lsof gives me: http://paste.ubuntu.com/8322328/
[22:09] <jdstrand> jjohansen: with my policy updates: http://paste.ubuntu.com/8322337/
[22:09] <jdstrand> ok, wandering off for quite a while
[22:14] <jdstrand> jjohansen: oh, hah, didn't mean to past that here
[22:14] <jdstrand> paste
[22:17] <hallyn> all right think i've got it
[22:17] <hallyn> now who to ping about the FFE
[22:17] <hallyn> oh.  i was wrong.  still hanging at /dev populating
[22:21] <hallyn> sarnold: hey, so i'm getting this denial message:
[22:21] <hallyn> type=1400 audit(1410473999.866:25): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="libvirt-4b477da6-28c4-4497-87f1-bafeb853f90b" name="/sys/" pid=1711 comm="mount" flags="rw, nosuid, nodev, noexec, remount"
[22:21] <hallyn> my policy does have 'mount fstype=sysfs -> /sys/',
[22:21] <hallyn> what am i missing?  i need a separate remount rule?
[22:22] <sarnold> hallyn: maybe? (at this point you've used the mount rules far more than I have.. :)
[22:23] <hallyn> heh, yeah but at such long intervals tha ti don't remember anything from one instnace to the next :)
[22:23] <hallyn> just allowing 'mount,' allows full container boot, so it's something lik ehtat...
[22:24] <sarnold> hallyn: ah! this might explain it, "Specifically fstype matching currently only works when creating a new mount and not remount, bind, etc."
[22:24] <sarnold> hallyn: hehe
[22:25] <hallyn> oh, hm, then maybe th eproblem is our rule ot avoid remounting / ro ?
[22:25] <hallyn> drat,
[22:25] <hallyn> well i may just allow 'mount,' right now just to get this out the door
[22:25] <hallyn> bc as it stands you can't stop a container once you start one :)
[22:25] <hallyn> (bc of dnsmasq policy)
[22:26] <sarnold> haha
[22:26] <sarnold> that's .. awesome :)
[22:26] <sarnold> watch out oracle, we've got our own "unstoppable linux"  :)
[22:26] <hallyn> well that was my concern with the way the new unix class was written
[22:26] <hallyn> it'll have the same sort of implications, but worse
[22:27] <sarnold> hallyn: can you get away with a 'remount /sys/ -> /sys/,  rule?
[22:27] <hallyn> (bc any confined daemon will have to be given the right to talk to another daemon over unix sock, aiui)
[22:27] <hallyn> i'll try!
[22:29] <hallyn> sarnold: holy schnickities.  that inexplicably makes the container instantly crash
[22:29] <sarnold> hallyn: yikes
[22:30] <hallyn> oh, i guess it doesn't like the rule,
[22:30] <hallyn> 2014-09-11 22:28:58.685+0000: 1: error : AppArmorSetSecurityProcessLabel:617 : internal error: error calling aa_change_profile()
[22:31] <sarnold> :(
[22:31] <sarnold> sorry, I thoght that would work
[22:31] <hallyn> uh oh, compiz is at 2.5G, probably time for a 'kill compiz from console after all windows freeze' soon
[22:32] <hallyn> sarnold: hah, np, thanks for trying.  i guess i'll just try with all the remount flags it gives in the denied msg
[22:36] <hallyn> all right now mountall is just being annoying
[22:36] <hallyn> sarnold: got past the sys remount one, now mountall wants to remounta ll th eothers
[22:37] <hallyn> drama queen
[22:37] <sarnold> remount ALL the things!
[22:40] <hallyn> yeah, and all separately.  so i need a remount options=(remount rw) -> /sys/fs/pstore as well as a remount options=(remount ro) -> /sys/fs/pstore,
[22:40] <hallyn> but!  it works.
[22:41] <hallyn> this is better than good enough for gov work.  ship it!
[22:44] <hallyn> sarnold: thanks for the moral support :)
[22:45] <sarnold> hallyn: oh man :/ you may be able to use remount options in (remount rw) ... options in (remount ro) ...   rules
[22:46] <hallyn> sarnold: heh, that would be nice.  lemme try
[22:47] <Logan_> xnox: naughty
[22:48] <hallyn> sarnold: eh, i must not be getting the syntax right - but actually i think separately may be easier to read