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:00 |
sarnold | infinity: awesome, thanks :) | 00:01 |
=== salem_ is now known as _salem | ||
=== ljp is now known as lpotter | ||
pitti | Good morning | 05:15 |
sladen | good morning pitti | 05:18 |
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:19 |
sladen | pitti: I think that has hit the TB moderation | 05:20 |
pitti | sladen: hey Paul, good morning! | 05:25 |
pitti | sladen: I moderated your post | 05:25 |
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:29 |
pitti | infinity: perhaps I really should join ~ubuntu-release to do this myself | 05:30 |
dholbach | good morning | 06:51 |
LocutusOfBorg1 | nothing pitti everything is good, somebody already retried cmake and now it is on -release pocket | 07:14 |
LocutusOfBorg1 | :D | 07:14 |
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? | 07:46 |
cjwatson | LocutusOfBorg1: syncpackage won't do it, because it was already in Ubuntu - it needs a build1 upload. I've done that now | 09:51 |
LocutusOfBorg1 | thanks cjwatson | 10:07 |
LocutusOfBorg1 | whenever debian uploads a -2 revision, is the sync automatic? | 10:07 |
Unit193 | build1 will be, yes. | 10:08 |
LocutusOfBorg1 | thanks! so buildN are sync'd, while ubuntuN are conserved | 10:08 |
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:09 |
LocutusOfBorg1 | yes of course | 10:10 |
LocutusOfBorg1 | thanks | 10:13 |
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:29 |
ubottu | Ubuntu bug 1440368 in sessioninstaller (Ubuntu) "sessioninstaller should be ported to Python3" [Undecided,New] | 11:29 |
=== _salem is now known as salem_ | ||
=== MacSlow is now known as MacSlow|lunch | ||
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 |
ubottu | Ubuntu bug 1448394 in python-apt (Ubuntu) "lauch icon distort in ubuntu 15.04" [Undecided,New] | 11:52 |
* juliank is not sure which, but it's definitely not a python-apt bug | 11:52 | |
seb128 | juliank, done | 11:55 |
juliank | seb128: thanks | 11:55 |
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:08 |
pitti | seb128: ^ do you know, are we still actually using sessioninstaller? | 12:09 |
seb128 | juliank, yw! | 12:09 |
seb128 | pitti, I don't think we changed anything in that area so likely yes | 12:10 |
=== MacSlow|lunch is now known as MacSlow | ||
juliank | barry: Did you ever manage to reproduce https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1220013? | 12:35 |
ubottu | Ubuntu bug 1220013 in python-apt (Ubuntu) "python-apt can SIGSEGV when encountering Packages stanzas with no Description field (was: update-apt-xapian-index crashed with SIGSEGV in File())" [High,Triaged] | 12:35 |
infinity | pitti: I don't think anyone would object to you (re)joining the release team. | 12:43 |
=== anthonyf is now known as Guest73520 | ||
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:11 |
barry | juliank: maybe it's fixed by now? | 13:13 |
=== mvo_ is now known as mvo | ||
=== mvo_ is now known as mvo | ||
=== Spads is now known as M-SpaceHobo | ||
jamespage | doko, what's the timeframe around having python3.5 as the default python3 ? | 14:28 |
doko | jamespage, -> barry | 14:28 |
jamespage | doko, ta for the redirection | 14:29 |
=== M-SpaceHobo is now known as Spads | ||
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:32 |
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:33 |
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:35 |
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:38 |
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:41 |
barry | jamespage: cool :) | 14:42 |
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:05 |
pitti | rbasak: locally it fails differently for me: http://paste.ubuntu.com/11735834/ | 15:21 |
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:25 |
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:27 |
rbasak | Let me try again locally. | 15:28 |
rbasak | (with proposed) | 15:28 |
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:46 |
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:47 |
infinity | pitti: SO MUCH YAY. | 15:48 |
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? | 15:57 |
=== rickspencer3_ is now known as rickspencer3 | ||
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:12 |
pitti | barry: in a week or so perhaps; I just started today with setting up the clouds and some baby steps :) | 16:14 |
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:17 |
mdeslaur | TJ- do you have "user" configured in/etc/libvirt/qemu.conf? | 16:54 |
mdeslaur | TJ- are you using the real ubuntu libvirt/qemu packages? | 16:55 |
TJ- | mdeslaur: to your 2nd: yes ... let me check on the 1st | 16:59 |
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:02 |
mdeslaur | TJ- weird, sorry, no idea | 17:05 |
mdeslaur | oh, actually, all my images are root:root too | 17:05 |
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:06 |
TJ- | mdeslaur: No, standard permissions on $HOME | 17:07 |
mdeslaur | not sure why you're getting access denied on them | 17:07 |
TJ- | mdeslaur: Ahhh, yes, the $HOME is 710 so that'd stop libvirt traversing | 17:08 |
TJ- | I wish I knew why libvirtd needs to take ownership when it's running as root | 17:10 |
arges | hallyn: bug 1425619, is now a verification-failed and blocking qemu/libvirt SRUs. How would you like to proceed? | 17:14 |
ubottu | bug 1425619 in ubuntu-cloud-archive "Migration fails between QEMU 1.5 and QEMU 2.0" [Undecided,New] https://launchpad.net/bugs/1425619 | 17:14 |
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 | 18:02 |
ubottu | bug 1466432 in unity8-lxc (Ubuntu) "Cannot install click packages on the unity 8 desktop session" [Undecided,Confirmed] https://launchpad.net/bugs/1466432 | 18:02 |
=== mhall119_ is now known as mhall119 | ||
hallyn | argefeh | 19:08 |
hallyn | arges: feh | 19:08 |
arges | foo | 19:08 |
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:10 |
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:11 |
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:13 |
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:14 |
arges | hallyn: gotta look through the list. i think right now its just libvirt | 19:15 |
hallyn | bug 1448205 | 19:16 |
ubottu | bug 1448205 in libvirt (Ubuntu Trusty) "Crash when removing <filterref> from interface with update-device" [High,Fix committed] https://launchpad.net/bugs/1448205 | 19:16 |
hallyn | weird, wouldn't work for me through pad.lv | 19:16 |
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:17 |
hallyn | ok | 19:19 |
hallyn | arges: pushed | 19:22 |
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:23 |
hallyn | cool. thanks as always for all your sru work :) | 19:24 |
arges | no problem | 19:24 |
apostoj | Anyone familiar with the "static-network-up" upstart signal? | 20:10 |
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:04 |
hallyn | apostoj: been awhile since i've looked at it, but several ppl here should be able to help | 21:05 |
hallyn | (guess i'll just test; just need an upstart machine to do so :) | 21:07 |
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:08 |
hallyn | start on stopped ? | 21:09 |
hallyn | sarnold_: was looking for best suggestion for bug #1466103. i went with 'start on stopped' | 21:12 |
ubottu | bug 1466103 in dnsmasq (Ubuntu) "dnsmasq runs unconfined due to starting before apparmor on boot" [Critical,Triaged] https://launchpad.net/bugs/1466103 | 21:12 |
hallyn | you may have another suggestion... | 21:12 |
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:16 |
sarnold_ | especially since the fix there is 100% not going to help here. | 21:17 |
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:20 |
ubottu | Ubuntu bug 770766 in morse (Ubuntu Oneiric) "morse version 2.2-1 failed to build on amd64 with GCC-4.6/oneiric" [High,Fix released] | 21:20 |
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 | 21:23 |
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!