[00:00] <infinity> sarnold: I sure hope no one's hitting that, given that I fixed it...
[00:00] <sarnold> infinity: oh! I missed that bit :)
[00:01] <sarnold> infinity: awesome, thanks :)
[05:15] <pitti> Good morning
[05:18] <sladen> good morning pitti
[05:19] <sladen> pitti: I've taken the liberty of cross-posting (shudder, I rarely, rarely do it)  https://lists.ubuntu.com/archives/ubuntu-community-team/2015-June/000612.html
[05:20] <sladen> pitti: I think that has hit the TB moderation
[05:25] <pitti> sladen: hey Paul, good morning!
[05:25] <pitti> sladen: I moderated your post
[05:29] <pitti> infinity: I went through the dozen regressions in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 and none are gcc's fault; could we do the make-it-go-in-anyway magic?
[05:30] <pitti> infinity: perhaps I really should join ~ubuntu-release to do this myself
[06:51] <dholbach> good morning
[07:14] <LocutusOfBorg1> nothing pitti everything is good, somebody already retried cmake and now it is on -release pocket
[07:14] <LocutusOfBorg1> :D
[07:46] <LocutusOfBorg1> can anybody please "syncpackage sysdig" ? it doesn't build everywhere, but at least should be build against libjsoncpp on -release
[07:46] <LocutusOfBorg1> it was kicked out yesterday, and the auto import didn't pick it again?
[09:51] <cjwatson> LocutusOfBorg1: syncpackage won't do it, because it was already in Ubuntu - it needs a build1 upload.  I've done that now
[10:07] <LocutusOfBorg1> thanks cjwatson
[10:07] <LocutusOfBorg1> whenever debian uploads a -2 revision, is the sync automatic?
[10:08] <Unit193> build1 will be, yes.
[10:08] <LocutusOfBorg1> thanks! so buildN are sync'd, while ubuntuN are conserved
[10:09] <cjwatson> LocutusOfBorg1: The substring "ubuntu" in a version inhibits auto-sync; that's its sole technical purpose
[10:09] <LocutusOfBorg1> seems legit, thanks!
[10:09] <cjwatson> Nothing is special about buildN except that such versions don't normally contain "ubuntu"
[10:09] <cjwatson> Oh and that it's << ubuntuN
[10:10] <LocutusOfBorg1> yes of course
[10:13] <LocutusOfBorg1> thanks
[11:29] <doko> pitti, could you have a look at https://bugs.launchpad.net/ubuntu/+source/sessioninstaller/+bug/1440368 ? or find somebody from desktop (although this is foundations)
[11:52] <juliank> Can somebody reassign https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1448394 to the correct package (some unity one I suppose)
[11:52]  * juliank is not sure which, but it's definitely not a python-apt bug
[11:55] <seb128> juliank, done
[11:55] <juliank> seb128: thanks
[12:08] <pitti> doko: not familiar with sessioninstaller and swamped, so I can't promise that I can get to it in the next two weeks or so
[12:08] <doko> ok
[12:09] <pitti> seb128: ^ do you know, are we still actually using sessioninstaller?
[12:09] <seb128> juliank, yw!
[12:10] <seb128> pitti, I don't think we changed anything in that area so likely yes
[12:35] <juliank> barry: Did you ever manage to reproduce https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1220013?
[12:43] <infinity> pitti: I don't think anyone would object to you (re)joining the release team.
[13:11] <barry> juliank: no, never did.  i wonder if mvo__ has taken a look.  iirc we needed a reproducer
[13:11] <juliank> barry: Because I cannot reproduce it in Debian unstable by dropping that package without description into /var/lib/dpkg/status and then trying to get a description. It just raises an Exception, as expected
[13:13] <barry> juliank: maybe it's fixed by now?
[14:28] <jamespage> doko, what's the timeframe around having python3.5 as the default python3 ?
[14:28] <doko> jamespage, -> barry
[14:29] <jamespage> doko, ta for the redirection
[14:32] <barry> jamespage: maybe this cycle.  if i can find some time where i don't have to hack on system-image, i am working on the transition.  first step is to do a partial test rebuild in a ppa and address any problems that come up.  then we can do a full archive rebuild on all arches.  if that looks good, we can at last make it supported, then hopefully default by the rc time frame (august)
[14:33] <jamespage> barry, ack - we're enabling py3 across the openstack clients - started hitting a few py3.5 issues - just figuring out how to deal with them upstream as 3.5 is not on the 'even trying' list yet
[14:35] <barry> jamespage: very cool.  how can i follow the issues and resolutions (well, without being avalanched by email ;)?
[14:35] <jamespage> barry, I'll figure that out and let you know :-)
[14:38] <Daviey> jamespage: Are you using a tag for py35 issues?
[14:38] <jamespage> Daviey, tbh I only just started thinking about this - thats a nice idea
[14:41] <rbasak> jibel, pitti: I'm confused by the juju-core dep8 failure. It looks like an environment issue, but failed on both amd64 and i386 (ie. two separate runs)? It passes locally on amd64. Please could you take a look?
[14:42] <barry> jamespage: cool :)
[15:05] <xnox> is it me, or is docker lxc exec driver totally broken on 15.04?!
[15:05] <pitti> rbasak: hm, will investigate in a bit (meeting now)
[15:21] <pitti> rbasak: locally it fails differently for me: http://paste.ubuntu.com/11735834/
[15:25] <rbasak> pitti: is that with LXC? I used qemu, since the test actually exercises Juju+LXC and I didn't want to turn it into a test for nested LXC.
[15:27] <pitti> rbasak: it's QEMU, standard adt-buildvm-ubuntu-cloud image
[15:27] <pitti> with -proposed
[15:27] <rbasak> Oh. I don't think I used proposed
[15:28] <rbasak> Let me try again locally.
[15:28] <rbasak> (with proposed)
[15:46] <infinity> pitti: Will the autopkgtesting move to scalingstack happen hand-in-hand with killing jenkins from the workflow, or are those two different goals?
[15:47] <pitti> infinity: I'm rebuilding this entirely from scratch with just AMQP and swift, so it'll all go away in one stap
[15:47] <pitti> step
[15:47] <pitti> or rather, we don't need to touch jenkins and the static machines to run the new stuff in parallel, and can switch over once we are satisfied
[15:48] <infinity> pitti: SO MUCH YAY.
[15:57] <barry> pitti: i'm (slowly) working on the python3.5 transition.  first step is test rebuilds in a ppa.  after that i'd like to run dep-8 tests on any of those packages that have them.  what are your thoughts about infra to do that?  can we reuse some bits of prodscalingcanonistack?
[16:12] <TJ-> Any ideas about this strange issue with libvirt on 14.04? Got a VM image in $USER home directory that has previously worked (many months ago) but now when I try to start the VM (from Virtual Machine Manager) it reports "Access Denied". I check and find that the file ownership keeps being changed from '$USER:$USER' to 'root:root', despite that libvirt runs as user libvirt, which means that libvirtd (running as root) is changing ownership preventing itself fro
[16:12] <TJ-> m opening the image!
[16:14] <pitti> barry: in a week or so perhaps; I just started today with setting up the clouds and some baby steps :)
[16:17] <barry> pitti: cool, np!  thought i would put it on your radar.  "a week or so" is probably when i'll be ready to try it anyway
[16:54] <mdeslaur> TJ- do you have "user" configured in/etc/libvirt/qemu.conf?
[16:55] <mdeslaur> TJ- are you using the real ubuntu libvirt/qemu packages?
[16:59] <TJ-> mdeslaur: to your 2nd: yes ... let me check on the 1st
[17:02] <TJ-> mdeslaur: to the 1st. no changes to qemu.conf. I worked around the issue by moving the image to /var/lib/libvirt/images/
[17:05] <mdeslaur> TJ- weird, sorry, no idea
[17:05] <mdeslaur> oh, actually, all my images are root:root too
[17:06] <mdeslaur> looks like it's normal
[17:06] <mdeslaur> did you change the permissions on your home directory?
[17:06] <TJ-> mdeslaur: that was my reaction, too :)   I've always had this issue whenever libvirt opens an image it takes ownership. Used to annoy the heck out of me when I was writing/altering those images manually or by script
[17:07] <TJ-> mdeslaur: No, standard permissions on $HOME
[17:07] <mdeslaur> not sure why you're getting access denied on them
[17:08] <TJ-> mdeslaur: Ahhh, yes, the $HOME is 710 so that'd stop libvirt traversing
[17:10] <TJ-> I wish I knew why libvirtd needs to take ownership when it's running as root
[17:14] <arges> hallyn: bug 1425619, is now a verification-failed and blocking qemu/libvirt SRUs. How would you like to proceed?
[18:02] <dpm> mvo, cjwatson, would you be able to help with some guidance on bug 1466432? It seems to be quite difficult to find anyone who is familiar with click
[19:08] <hallyn> argefeh
[19:08] <hallyn> arges: feh
[19:08] <arges> foo
[19:10] <hallyn> arges: but,
[19:10] <hallyn> he only shows his qemu pkg version.  it requires both qemu and libvirt to fix this
[19:10] <arges> hallyn: i think he upgraded both, i spoke with him this morning. In addition I tried it myself and couldn't get it to work
[19:11] <arges> hallyn: not sure if there is something special that needs to be done other than 'virsh migrate'
[19:11] <arges> hallyn: it would be great if the original reporter tried it again. but I think we may want to skip this for now so we can get other fixes in
[19:11] <hallyn> agreed
[19:11] <hallyn> checking the changelogs
[19:13] <hallyn> so qemu had no other colocated bugs.  so yeah i'd say revert it and push 2.0.0+dfsg-2ubuntu1.15 with whatever you were wanting to sru there
[19:13] <hallyn> libvirt's more of a pain
[19:14] <hallyn> hm, do you have anything for qemu that you want to sru to trusty?
[19:14] <hallyn> I see two or libvirt perhaps, 1455608 and 146417
[19:15] <arges> hallyn: gotta look through the list. i think right now its just libvirt
[19:16] <hallyn> bug 1448205
[19:16] <hallyn> weird, wouldn't work for me through pad.lv
[19:17] <hallyn> arges: ok so those two are verifiaction-done.  let's rush the next libvirt with just those two for a clean confirmation
[19:17] <hallyn> do yo uwant me to push the new libvirt version, or were you already on it?
[19:17] <arges> hallyn: i haven't done anything yet, so have at it, and I can push the next batch with those two fixes
[19:19] <hallyn> ok
[19:22] <hallyn> arges: pushed
[19:23] <arges> hallyn: ok i'll reivew
[19:23] <hallyn> (i left the patch in but commented out in series;  maybe someone will want to take another look at some point...  )
[19:23] <hallyn> (if you think i should drop it altogether for cleanliness lemme know)
[19:23] <arges> hallyn: i think that's fine for now.
[19:24] <hallyn> cool.  thanks as always for all your sru work :)
[19:24] <arges> no problem
[20:10] <apostoj> Anyone familiar with the "static-network-up" upstart signal?
[21:04] <hallyn> stgraber: do you happen to know whether, for a task upstart job A that has a script section, if job B starts on started A, will it start when A's script section has started or finished?
[21:05] <hallyn> apostoj: been awhile since i've looked at it, but several ppl here should be able to help
[21:07] <hallyn> (guess i'll just test;  just need an upstart machine to do so :)
[21:08] <hallyn> answer: as soon as it starts :)
[21:08] <sarnold_> I thought there was  a way to wait for the script to have finished
[21:09] <hallyn> start on stopped ?
[21:12] <hallyn> sarnold_: was looking for best suggestion for bug #1466103.  i went with 'start on stopped'
[21:12] <hallyn> you may have another suggestion...
[21:16] <sarnold_> hallyn: hmm. I don't see any output from grep -r apparmor in the dnsmasq source packages
[21:16] <sarnold_> oh durrr that'sfrom apparmor-profiles
[21:16] <sarnold_> uh
[21:16] <hallyn> :)
[21:16] <hallyn> yeah especiallythe mentoin of libvirt threw me for a while
[21:17] <sarnold_> especially since the fix there is 100% not going to help here.
[21:20] <hallyn> right
[21:20] <hallyn> he hasn't yet said which dnsmasq he wants running
[21:20] <doko> bdmurray, https://bugs.launchpad.net/bugs/770766 ?
[21:23] <infinity> doko: THe patch was accepted in Debian 2.4-3 and mentioned in the changelog, and that upload is a backport of same, hence the bug closure 4 years later. :P