[03:14] <smoser> pitti, around ?
[03:15] <smoser> i think i relize the issue with letting the udevrule go through.
[03:15] <smoser> cloud-init wont have written the .link file to rename at the point when the udev rule processes the .link
[03:16] <smoser> so cloud-init local *will* have to re-trigger or otherwise have the systemd.link stuff fire again
[03:19] <smoser> how were you re-triggering with udev to get the .links processed ?
[03:23] <cyphermox> cjwatson: yes, will SRU. thanks. I was looking hard at base-installer, not at apt-setup :/
[03:23] <cyphermox> or at least, not at that part of base-installer that has apt-setup keys.
[03:23] <cyphermox> between us we might manage to really fix the overlay code.
[03:35] <smoser> pitti, 'udevadm test-builtin net_setup_link /sys/class/net/ens4' works to show that the cloud-init written .link files do the right thing.
[03:35] <smoser> but i think i have to re-send the hotplug event to get it renamed.
=== hikiko is now known as hikiko|off
=== athairus is now known as afkthairus
[07:08] <CarlFK> https://help.ubuntu.com/lts/installation-guide/armhf/apbs04.html#preseed-apt   how do I get it to not #comment out deb-src  lines?  (new in xenial)
[07:25] <zyga> good morning
[08:14] <tjaalton> wgrant: still around? I sent a soyuz question (#293230) about bumping the size of ppa:canonical-x/x-staging, llvm is taking all the space preparing next lts stack :)
[08:15] <wgrant> how on earth
[08:15] <wgrant> It's already 8GiB!
[08:15]  * wgrant doubles
[08:15] <tjaalton> llvm is big
[08:15] <tjaalton> thanks!
[08:24] <mwhudson> is there a script for doing the Maintainers: Ubuntu Developers, XSBC-Original-Maintainers: thing?
[08:24] <Laney> mwhudson: updata-maintainer
[08:24] <Laney> with spelling that is good
[08:26] <mwhudson> Laney: thanks
[08:27] <mwhudson> oh wow, python, i was expecting perl :-)
[08:27] <Laney> it was probably written this decade :P
=== davmor2_ is now known as davmor2
[08:45] <zyga> hey mwhudson
[09:03] <cjwatson> CarlFK: d-i apt-setup/enable-source-repositories boolean true
=== marcusto_ is now known as marcustomlinson
[10:51] <sil2100> mvo: hey! Is it ok for me to release the currently staged changes in livecd-rootfs to yakkety?
[10:51] <sil2100> mvo: I have some of my changes that we'd need released to unblock image builds
=== xavigarcia is now known as xavigarcia_lunch
[10:59] <mvo> sil2100: yeah, thats fine
[11:00] <mvo> sil2100: ogra_ also has some pending changes
[11:00] <sil2100> Thanks!
[11:00] <ogra_> mvo, oh, didnt you say you pushed them to trunk ?
[11:00] <sil2100> They're pushed to trunk but not released yet
[11:00] <sil2100> I'm releasing trunk right now if that's ok
[11:01] <ogra_> bah, i just upgraded my phone to tonights rc-proposed image ... no apps in the apps scope ... no matter how often i refresh
[11:01] <ogra_> ok, seems ten times is the charm ...
=== xavigarcia_lunch is now known as xavigarcia
[12:09] <yofel> doko: did you intentionally drop the multiarch changes from libical?
[12:11] <doko> yofel, no, saw too late that they were only applied in experimental
[12:11] <doko> but I didn't check if we can sync the experimental package
[12:11] <doko> so maybe I better restore these
[12:12] <yofel> would be nice, it's causing build failures in some kde autopktests as cmake hardcodes the lib path in some places
[12:15] <doko> ahh, I remember
[12:16] <doko> breakfast first
[12:17] <yofel> doko: and thanks for merging digikam
[12:22] <alexbligh1> Is this the sort of thing you'd take a 14.04 SRU for (assuming my one character patch to fix it is OK): https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1578185
[12:22] <ubottu> Launchpad bug 1578185 in nbd (Ubuntu) "nbd-client 3.7 connects read-only to newer nbd servers" [Undecided,New]
[12:23] <smoser> alexbligh1, if if it doesn't break working with older nbd servers' it would surely seem appropriate for sru from what that bug says.
[12:24] <alexbligh1> smoser, nope, it doesn't break anything. OK, I will persuade Wouter (Debian maintainer and nbd maintainer) my one line patch is a good plan :-)
[12:24] <alexbligh1> smoser, thx
[12:39] <shadeslayer> chrisccoulson: hi, I was wondering if you had a moment to talk about firefox? I seem to be hitting a race condition when the configure step is a bit too slow
[12:39] <shadeslayer> for eg. on armhf
[12:40] <rbasak> alexbligh1: thank you for looking after this. Let me know if you need any help with sponsorship etc.
[12:40] <shadeslayer> chrisccoulson: I was wondering if you had seen something similar?
[12:40] <alexbligh1> rbasak, thx - if you could tell me how to mark it as 14.04 only that would be great.
[12:42] <rbasak> alexbligh1: is it Fix Released in Yakkety then? I can add the Trusty task for you. AIUI, that was ACL-restricted to uploaders and triagers only because people kept misunderstanding the purpose or something.
[12:42] <rbasak> alexbligh1: done
[12:43] <alexbligh1> rbasak, yes it was fixed in wily when 3.10 was imported. Thanks.
=== _salem is now known as salem_
[13:12] <roadmr> hey folks! so on xenial I get an "updates available" bubble but it's not actionable. Clicking on it does nothing, nor does the dancing update manager appar in the unity dash. I had to hunt it down manually. Is this a bug?
[13:22] <sergiusens> cjwatson pitti hello again, is the fact that I need to do this https://github.com/ubuntu-core/snapcraft/pull/499/files for yakkety a bug in snapcraft that went unnoticed (worked all through xenial) or the new apt/python-apt in yakkety?
[13:40] <cjwatson> sergiusens: Don't know, I'm afraid
[14:03] <ginggs> pitti: hi, can something be done about compute's ppc64el test failure blocking nvidia-cuda-toolkit please? From what I can see, nvidia-cuda-toolkit provides an alternate build-depends which isn't even being tested. The failures have been since the switch to boost1.60.
[14:14] <coreycb> bdmurray, arges: Hi, any chacne we could get a review for the liberty point release in bug 1569502 ?
[14:14] <ubottu> bug 1569502 in nova (Ubuntu Wily) "[SRU] liberty point releases" [Undecided,Confirmed] https://launchpad.net/bugs/1569502
[14:18] <pitti> ginggs: I added a compute/ppc64el ignore hint
[14:19] <ginggs> pitti: danke!
[14:32] <rbasak> "dpkg: dependency problems prevent processing triggers for ufw"
[14:32] <rbasak> Is this an apt bug? I don't see an obvious packaging deficiency or opportunity for there to be a dependency loop.
[14:33] <rbasak> http://paste.ubuntu.com/16218132/ is my reproduction of bug 1571174
[14:33] <ubottu> bug 1571174 in squid3 (Ubuntu) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Confirmed] https://launchpad.net/bugs/1571174
[14:35] <rbasak> It seems to me that apt should have chosen to configure python3 first.
[15:24] <arges> coreycb: i got it
[15:31] <pitti> rcj: cat /sys/class/tty/console/active
[15:31] <rcj> pitti, thanks
[15:38] <doko> yofel, https://bugs.launchpad.net/ubuntu/+source/ffmpegthumbs/+bug/1578269 (only recommended by digikam)
[15:38] <ubottu> Launchpad bug 1578269 in ffmpegthumbs (Ubuntu) "demote ffmpegthumbs to proposed, fails to build with new ffmpeg" [Undecided,Confirmed]
[16:07] <cjwatson> doko: why do you disable entire test suites rather than just the failing test?  (survex, which I'd just started to look at upon noticing that you'd sledgehammered it)
[16:13] <doko> cjwatson, sure, I could have done this as well. however I didn't see any failure on the local build
[16:13] <tjaalton> doko: arm64 fails to build llvm-3.8 on trusty, log says "internal compiler error". this probably is a blocker for lts-xenial. should I file a bug against gcc-4.8?
[16:14] <doko> tjaalton, I'm not involved with the lts uploads of clang. does this persist when you give it back?
[16:15] <tjaalton> doko: built it on a ppa, haven't tried rebuilding
[16:15] <tjaalton> will do that now
[16:17] <doko> cjwatson, alsa-plugins-extra is also merged
[16:17] <cjwatson> doko: I don't see any failure right now on the local build either (I'm investigating), but the point of a test suite is to make problems on future builds less likely
[16:18] <doko> cjwatson, right, that's why I filed a bug report which I intend to re-open after the current transitions
[16:19] <cjwatson> IME those bug reports get lost
[16:21] <doko> ok, then I'll re-upload after the transition with the fix reverted
[16:22] <cjwatson> well like I say I was working on them anyway ...
[16:23] <doko> I only worked on these while you were bringing you kids to bed last night, and just re-started again. but it's not just ffmpeg which is blocking
[16:26] <cjwatson> valgrind shows what the survex problem probably is
[16:30] <cjwatson> and the freshplayerplugin problem is easily reproducible locally in a UTF-8 locale
[16:31] <hallyn> pitti: is there a 'dh_systemd_disable' sort of thing?
[16:32] <pitti> hallyn: there isn't, what should that do?
[16:32] <pitti> units are disabled by default, after all
[16:32] <hallyn> pitti: problem is, we currently have libvirt-bin.service, which is Alias=libvirtd.  We're switching to debian packaging, which has libvirtd.service instead
[16:33] <hallyn> Which I want to Alias=libvirt-bin for ahwile probably
[16:33] <hallyn> but how should i do the renaming?
[16:33] <hallyn> (sorry, biam)
[16:33] <pitti> hallyn: ah, so you need to rename the enablement symlinks in the prerm?
[16:33] <pitti> err, preinst
[16:33] <pitti> hallyn: I think this would be a conditionalized mv in the preinst
[16:38] <cjwatson> doko: When you said "Revert last change" in freshplayerplugin (presumably the build-dependency on libjack-dev), you don't seem to have actually done so.  Should I do so since I plan to upload it anyway?
[16:41] <hallyn> pitti: so i should do it manually using 'mv'?
[16:42] <pitti> hallyn: I think that's better than just rm'ing it and re-creating the new ones, if you want to maintain the fact that an admin manually disabled it
[16:43] <pitti> i. e. it should still be disabled after the upgrade
[16:45] <hallyn> pitti: yeah right now i was just trying to stop it (as in https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/libvirt-daemon-system.preinst?h=2016-05-02/yakkety) and i manually tried 'disabling' it, but that didn't suffice
[16:45] <hallyn> i'll try moving the files - then do i do a systemctl reload?  (from inside prerm?)
[16:45] <cjwatson> doko: Seems to make no difference to the configuration, so I'll go ahead and do that
[16:46] <hallyn> (of course, i *could* just punt on this and keep this as delta from debian, but i'd really like to minimize that)
[16:56] <cjwatson> doko: freshplayerplugin and survex both fixed
[16:56] <doko> ta \o/
[16:56] <tjaalton> doko: rebuild fails too
[17:01] <cjwatson> and uploading an ffmpeg patch that's supposed to fix the autopkgtest failure
[17:06] <hallyn> pitti: gonna try http://paste.ubuntu.com/16221711/
[17:08] <pitti> hallyn: looks good at first sight, and also gets rid of the bare systemctl invocation (which breaks under upstart and with policy-rc.d in e. g. chroots)
[17:09] <pitti> hallyn: FTR, if you ever have that case, please use deb-systemd-invoke, this checks policy-rc.d
[17:09] <pitti> or just invoke-rc.d
[17:10] <hallyn> pitti: ok, thx
[17:10] <hallyn> actually, lemme think.  we have cloud archives, so in fact what i have in that paste is not sufficent,
[17:11] <hallyn> as it'll break if someone in 14.04 upgrades to it
[17:11] <hallyn> i don't suppose we can hae any sort of sanity guarantees about lts-to-lts upgrades even with cloud archives?
[17:11] <hallyn> jamespage: ^ is there going to be a cloud archive providing yakkety's libvirt to pre-15.10 users?
[17:11] <hallyn> (i..e non-systemd-based)
[17:12] <hallyn> zul: ^
[17:14] <zul> hallyn: dunno yet :)
[17:14] <hallyn> well maybe i'll just leave it broken until we know
[17:14] <hallyn> bc 'fixing' it also means papering over other potential bugs
[17:15] <hallyn> pitti: so instead of checking for that symlink by hand should i be doing 'deb-systemd-invoke systemctl is_enabled libvirt-bin' ?
[17:16] <hallyn> nah
[17:16] <pitti> hallyn: deb-systemd-invoke is just for start/stop; enable/disable is fine, not a thing that policy-rc.d covers
[17:16] <pitti> hallyn: but it's by and large the same as checking for the symlink directly, so mostly a matter of preference I'd say
[17:17] <hallyn> ok - thanks
[17:17] <pitti> hallyn: actually
[17:18] <pitti> hallyn: deb-systemd-helper has is-enabled, enable, disable etc., and that might be better as /var/lib/systemd/deb-systemd-helper-enabled/ also needs to be updated
[17:18] <pitti> that's the crazy Debian thing to sync enablement over upgrades, across init systems etc.
[17:19] <pitti> this might fire back if we don't update this too
[17:19] <hallyn> ugh
[17:19] <pitti> hallyn: sorry, I think that might be the first time this kind of upgrade issue happens
[17:19] <hallyn> but what about renames?
[17:20] <hallyn> that is deb-systemd-helper enable/disable isn't quite enough...  oh, but
[17:20] <doko> wgrant, cjwatson, pitti: https://launchpadlibrarian.net/257883350/buildlog_ubuntu-yakkety-i386.slurm-llnl_15.08.10-1build1_BUILDING.txt.gz (packages modifying -dbgsym packages).  is there a plan when we'll switch to the new dbgsym packages?
[17:20] <hallyn> i can just disable, move the classical links by hand, then enable?
[17:20] <hallyn> pitti: put another way: what the heck is under /var/lib/systemd/deb-systemd-helper-enabled/
[17:20] <pitti> hallyn: so I think "if deb-system-helper is-enabled <old name> then disable the old name, otherwise disable the new name
[17:21] <pitti> hallyn: so, I'm fairly sure that just handling the links as you do it now should work
[17:21] <pitti> as the /var/lib/helper stuff never trumps admin changes
[17:21] <pitti> so, forget what I said
[17:21] <hallyn> ok
[17:22] <pitti> hallyn: the stuff in /var/lib basically tracks the distro defaults
[17:22] <hallyn> otherwise i was thinking i'd need to deb-systemd-helper purge; move the files, deb-systemd-helper enable
[17:22] <hallyn> ok - so those files should get dropped naturally?
[17:22] <hallyn> i'll make a note to check them in a test - thanks pt
[17:22] <hallyn> uh.  thanks pitti
[17:22] <pitti> this would be really ugly indeed
[17:23] <pitti> hallyn: for testing, I think check that it upgrades correctly with an enabled and disabled service, and that installing it again works
[17:23] <pitti> and ignore the /var stuff
[17:23] <hallyn> ok thx
=== afkthairus is now known as athairus
[17:55] <hallyn> man sometimes ppas just take forever to publish after building...
[17:57] <doko> ubuntu-keyboard-swedish/amd64 unsatisfiable Depends: hunspell-sv-se
[17:57] <doko> ubuntu-keyboard-swedish/armhf unsatisfiable Depends: hunspell-sv-se
[17:57] <doko> ubuntu-keyboard-swedish/i386 unsatisfiable Depends: hunspell-sv-se
[17:57] <doko> sil2100, ^^^
[18:18] <hallyn> pitti: argh.  well i can't do that in pre-inst, apparently /lib/systemd/system/libvirt-bin.service has been removed by this point
[18:18] <pitti> hallyn: uh? that sounds wrong; preinst runs before unpack
[18:18] <hallyn> maybe i do it in the libvirt-bin (which is otherwise just a metapackage) preinst/
[18:19] <pitti> no, you can't rely on the unpack order then
[18:19] <hallyn> pitti: yeah but the libvirtd.service is in libvirt-daemon-system package;  libvirt-bin.servce is in libvirt-bin package
[18:19] <hallyn> so what to do?
[18:19] <pitti> oh
[18:20] <pitti> hallyn: does one depend on the other?
[18:20] <hallyn> yeah libvirt-bin depends on libvirt-daemon-system
[18:22] <hallyn> so, maybe it would be easier to keep libvirt-bin.service for now, and do that switch after we've gotten rid of the libvirt-bin package altogether?
[18:22] <hallyn> so the move is at least happening within one pkg?
[18:22] <pitti> hallyn: so you need to do it in the package which originally shipped the old name
[18:22] <hallyn> ok,
[18:22] <pitti> if that was libvirt-bin, its preinst needs to do that, yes
[18:22] <pitti> even if it's empty afterwards
[18:23] <hallyn> i can do that.  bu ti'm still worried about the file being gone,
[18:23] <pitti> but you need that empty package for upgrades anyway
[18:23] <hallyn> because at postinst time for libvirt-daemon-ssytem it still says that libvirt-bin.service exists
[18:23] <hallyn> so is that getting cached under /var/lib somewhere during package remove/unpack?
[18:26] <hallyn> all right so lemme try with that in libvirt-bin.preinst.  thx
[18:26] <pitti> hallyn: dependencies get configured before postinst runs; deb contents does not get cached, now
[18:26] <pitti> (sorry, distracted, sprint)
[18:27] <hallyn> pitti: hold on.  there is existing code there from debian's transition.  i was misreading that and thinking it was my code from an earlier upstart->systemd xition
[18:28] <hallyn> so actually mayb ei just need to tweak the version numbers there and it'll just work
[18:28] <hallyn> pitti: in particular, http://paste.ubuntu.com/16223586/
[18:28] <hallyn> does that look like it would work?
[18:29]  * hallyn tries
[18:31] <pitti> hallyn: that actually looks fairly good, yes
[18:31] <hallyn> cool let's see if it works
[18:31] <pitti> hallyn: it doesn't maintain admin changes, though
[18:32] <pitti> hallyn: i. e. if the admin manually disabled the service, it will restart after the upgrade
[18:32] <hallyn> hm
[18:32] <hallyn> and i can only check that from libvirt-bin.preinst?
[18:33] <hallyn> no, not if i use the deb-systemd helpers
[18:34] <hallyn> so to that hunk i could add a tmpfile created if the service is enabled, and only enable it by hand...
[18:34] <hallyn> pitti: by disabled you mean stopped or actually disabled so it won't start again?
[18:34] <pitti> hallyn: disabled (stopped is fine)
[18:36] <hallyn> sigh
[18:36] <hallyn> all right i'll test it both ways.  thx
[19:22] <hallyn> pitti: meh, that doesn't work. I still get http://paste.ubuntu.com/16224784/
[19:22] <hallyn> so i'll do it my way in libvirt-bin.preinst
[19:22] <hallyn> my way -> your way?  but not debian's way :)
[19:49] <doko> roaksoax, please could you have a look at https://launchpad.net/ubuntu/+source/virtualbox/5.0.20-dfsg-1/+build/9669239 ? currently blocking some transitions
[19:55] <roaksoax> doko: ???? I've never touched virtualbox i dont think ...
[19:56] <doko> ohh, looked at the wrong package
[19:58] <roaksoax> :)
[20:25] <cjwatson> doko: There is no current plan, nor am I even sure it's agreed that we will switch.
[20:26] <cjwatson> The way that ended up in Debian is significantly less convenient to deal with for no obvious advantage, although the delta is awkward.
[20:28] <doko> I should propose for debian policy not to modify dbgsym packages ...
[20:29] <pitti> cjwatson: we could make the delta a bit smaller by patching debhelper to name them .ddeb instead of .deb; in theory this should then not need LP changes, or am I missing something?
[20:31] <hallyn> pitti: nope, that (manual mv'ing in libvirt-bin.preinst) didn't work.  i'll use the deb-systemd-helper to disable and leave tmpfiles for postinst to know whether to reenable
[20:31] <hallyn> ugh
[20:33] <cjwatson> pitti: Not sure.  There's all the hairy stuff that arranges to control whether ddebs are built on an archive-by-archive basis
[20:33] <cjwatson> Build-Debug-Symbols etc.
[20:33] <pitti> cjwatson: oh, the parsing of /CurrentlyBuilding etc.
[20:38] <hallyn> oh great, this is helpful for testing:
[20:38] <hallyn> deb-systemd-helper is-enabled libvirt-bin.service
[20:38] <hallyn> /usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
[20:45]  * hallyn needs more info on deb-systemd-helper mask/unmask
[20:51] <doko> AlbertA: please could you have a look at https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1578381
[20:51] <ubottu> Launchpad bug 1578381 in mir (Ubuntu) "mir tests fail in yakkety on amd64 and i386" [Critical,Confirmed]
[20:52] <AlbertA> doko: 0.21? shouldn't it be 0.22?
[20:54] <doko> AlbertA, there is no 0.22 in https://launchpad.net/ubuntu/+source/mir
[20:55] <AlbertA> camako: bregma: ^
[20:55] <AlbertA> doko: I thought the ci-train was supposed to release to the transitional overlay thingy
[20:56] <doko> AlbertA, it's my understanding that this is not yet in effect for yakkety
[20:56] <AlbertA> doko: in any case, the test failures look intermittent:
[20:56] <AlbertA> [ FAILED ] ClientLatency.throttled_input_rate_yields_lower_latency
[20:56] <AlbertA> I think that test will potentially fail if there's too much load on the build machines
[20:56] <doko> AlbertA, I can give them back and see what happens. can you save a copy of the build log locally?
[20:58] <AlbertA> if you re-run the builds it will most likely be ok
=== salem_ is now known as _salem
[21:41] <doko> AlbertA, give back succeeded. closing the issue. ta
[21:42] <AlbertA> doku: ack
[21:43] <camako> AlbertA, mir 0.22 is not in xenial either
[21:43] <camako> weird
[21:44] <camako> or meybe expected due to the overlay
[21:59] <roaksoax> 8
[22:08] <pitti> infinity: FYI, just committed bug 1577966, so happy proxying (if you run autopkgtest from git, like all the kool kids do :) )
[22:08] <ubottu> bug 1577966 in autopkgtest (Ubuntu) "automatically setup proxies other than apt-cacher-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1577966