[01:56] <spotter> is pepper flash plugin not working in yakkety correctly?  chromium lists it in about://plugins but eveyr site that tries to do flash shows an error of "couldn't load plugin"
[02:01] <Unit193> spotter: That's a support question thus should be asked in a support channel such as #ubuntu.  Chromium may have click-to-play, but visit http://www.adobe.com/software/flash/about/ and see if it tells you what version you have.
[02:02] <spotter> asked here as its a yakkety issue, but can ask there too, but that page shows same error, "Couldn't load plugin"
[02:02] <Unit193> Oooh, sorry yeah. #ubuntu+1.  My bad.
=== pavlushka is now known as Guest78383
=== Guest78383 is now known as pavlushka
[04:57] <mwhudson> xnox: re https://launchpad.net/ubuntu/+source/software-properties/0.96.24.6, gnupg1 is in universe, what's the plan there?
[05:40] <pitti> Good morning
[05:48] <cpaelzer> Good morning
[06:42] <pitti> xnox: http://autopkgtest.ubuntu.com/packages/m/mercurial/yakkety/amd64 is another (test-only) regression from gnupg2; do you track these somewhere with bug tags or so?
[07:40] <pitti> Mirv must have gotten up, autopkgtest infra is getting Qt'ed again :-P
[08:08] <andrewsh> pitti: could you please have a look at #835648?
[08:13] <ginggs> andrewsh: LP or BTS ?
[08:13] <Unit193> That number is BTS.
[08:13] <Unit193> Debian #835648
[08:14] <ubottu> Debian bug 835648 in wpasupplicant "wpasupplicant: suspend takes very long due to problematic system-sleep hook" [Normal,Open] http://bugs.debian.org/835648
[08:14] <ginggs> Unit193: thanks
[08:14] <Unit193> Sure.
[08:26] <Mirv> pitti: mornings! :)
[08:26] <Mirv> or lunch time actually
=== enrico_ is now known as enrico
[08:37] <andrewsh> ginggs, pitti: yes, I meant BTS, sorry for the confusion
[08:38] <Unit193> andrewsh: Well pretty sure you weren't talking about a bug in tomboy about 'Ubuntu One'
[08:39] <andrewsh> :)
[08:41] <pitti> andrewsh: so calling wpa_cli suspend takes 10s??
[08:41] <andrewsh> according to the reporter
[08:41] <pitti> andrewsh: it's been a while, but we've had the pre/post suspend hooks basically forever (in upstart/pm-utils time it was through /usr/lib/pm-utils/sleep.d/60_wpa_supplicant)
[08:42] <andrewsh> I see this in my journal too:
[08:42] <andrewsh> Sep 13 18:27:07 nuevo systemd-sleep[29472]: Suspending system...
[08:42] <andrewsh> Sep 13 21:21:55 nuevo systemd-sleep[29472]: Failed to connect to non-global ctrl_ifname: (nil)  error: No such file or directory
[08:42] <andrewsh> Sep 13 21:21:55 nuevo systemd-sleep[29472]: System resumed.
[08:42] <pitti> so obviously this is a workaround, but so far it seemed it helps more people than it hurts
[08:42] <andrewsh> (that's on Ubuntu)
[08:42] <andrewsh> Sep 13 21:21:55 nuevo systemd-sleep[29642]: /lib/systemd/system-sleep/wpasupplicant failed with error code 255.
[08:43] <andrewsh> adding & to background it sort of helped:
[08:43] <andrewsh> Sep 14 10:18:43 nuevo systemd-sleep[30309]: Suspending system...
[08:43] <andrewsh> Sep 14 10:18:43 nuevo systemd-sleep[30309]: Failed to connect to non-global ctrl_ifname: (nil)  error: No such file or directory
[08:43] <andrewsh> Sep 14 10:18:48 nuevo systemd-sleep[30309]: Failed to connect to non-global ctrl_ifname: (nil)  error: No such file or directory
[08:43] <andrewsh> Sep 14 10:18:48 nuevo systemd-sleep[30309]: System resumed.
[08:43] <andrewsh> (no error message)
[08:43] <andrewsh> (so probably no waiting)
[08:43] <pitti> right, but with & it might not actually finish before the suspend happens, so that's a bit pointless
[08:44] <pitti> and even detrimental -- you DON'T want wpa_cli suspend to run after resuming
[08:44] <andrewsh> yep
[08:44] <andrewsh> though if followed by resume it shouldn't hurt
[08:44] <andrewsh> this makes me think it somehow connects to a wrong socket
[08:45] <andrewsh> as it says No such file or directory
[08:59] <andrewsh> pitti: for some strange reason, at the moment systemd-sleep runs, /run/wpa_supplicant is already gone
[08:59] <pitti> andrewsh: so maybe a simple check would just be to guard this call with if [ -d /run/wpa_supplicant ] ?
[09:00] <andrewsh> pitti: maybe
[09:00] <andrewsh> I don't understand the reason though
[09:00] <andrewsh> wpa_supplicant is still running
[09:22] <Odd_Bloke> If there's a core dev with a few minutes, a review and merge of this livecd-rootfs change would be much appreciated: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/label-function/+merge/304767
[09:51] <doko_> kenvandine: please could you prepare your MIR's on yakkety? it's not that we wouldn't have work enough already
[10:01] <xnox> mwhudson, good point.
[10:07] <xnox> pitti, no not tracking things yet. But i guess i should be.
[10:07] <xnox> https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/1623423
[10:07] <ubottu> Launchpad bug 1623423 in mercurial (Ubuntu) "gnupg2 autopkgtest regression" [Undecided,New]
[10:08] <xnox> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1623424
[10:08] <ubottu> Launchpad bug 1623424 in lxc (Ubuntu) "lxc autopkgtest regression" [Undecided,New]
[10:08] <pitti> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=gnupg2
[10:08] <pitti> thanks
[10:09] <doko_> pitti: about #1622893, I don't think downgrading the gnutls is an option
[10:11] <pitti> doko_: right, I wasn't suggesting that; I have a workaround for our test VMs, but it still affects real installs
[10:11] <pitti> not a blocker though, I mostly pinged you for the lols
[10:12] <pitti> the new version moved from reading /dev/urandom to calling getrandom() which is a good thing from gnutls' POV I suppose; maybe NM just calls something too early and it can be fixed in NM
=== oSoMoN_ is now known as oSoMoN
[10:27] <cpaelzer> was there a reasonable local workaround to bug 1621269 until xenial gets an SRU for it?
[10:27] <ubottu> bug 1621269 in sbuild (Ubuntu Xenial) "not possible to build yakkety packages because of gpg changes" [High,Triaged] https://launchpad.net/bugs/1621269
[10:27] <cpaelzer> I remember there was quite some discussion about it, but searching the logfile of the chan wasn't as successful as i'd have hoped
[10:30] <cpaelzer> trying to move the sbuild apt keys away as suggsted in the debian linked debian bug
[10:30] <cpaelzer> passing the initial sign of the dummy repo, although I'm not sure this won't cause other pain later on - we will see
[10:35] <Unit193> xnox: Also on that note, LP should upgrade them and use the new-ish Signed-By field! :P
=== G_ is now known as G
[10:36] <xnox> Unit193, is there an LP bug open about that?
[10:37] <Unit193> xnox: I presume other than 1331914?
[11:01] <directhex> who's in charge of the ppc64le port, nominally? presumably there's someone at IBM spearheading that?
[11:11] <doko_> cyphermox, mwhudson, slangasek: accepted subquity. are the hardcoded python2 dependencies in subiquity-tools really intended?
[11:14] <mwhudson> doko_: seems unlikely to me
[11:19] <doko_> mwhudson: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1623448
[11:19] <ubottu> Launchpad bug 1623448 in subiquity (Ubuntu) "subiquity-tools has a lot of hard-coded Python2 dependencies" [Undecided,New]
[11:21] <mwhudson> doko_: thanks
[12:03] <doko_> xnox: gnupg1 is in component-mismatches now. promote it?
[12:04] <xnox> doko_, for now yes, ideally i want to drop it from software-properties.
[12:04] <xnox> but i'm not sure how yet.
[12:09] <doko_> xnox: subscribed foundations and promoted
=== _salem is now known as salem_
[12:24] <pitti> arges: there was a previously existing isc-dhcp in x-proposed (verified, just reached 7 days today, but causes test regressions); was accepting another one on top of that intended?
[12:24] <pitti> (AFAICS this fixes something unrelated)
[12:30] <arges> pitti: hmm... usually sru-review warns me when that's the case
[12:31] <arges> pitti: the SRU I accepted was for the same bug
[12:31] <pitti> ah, so follow-up fix then?
[12:31] <pitti> thanks
[12:31] <arges> pitti: checking on this now
[12:34] <arges> pitti: also I think the network-manager autopkgtest regression is a false negative.
[12:36] <arges> pitti: and last, i accepted the isc-dhcp into p/t-proposed, not x-proposed.
[12:36] <pitti> arges: ah, ok
[12:36] <arges> : )
[12:41] <arges> pitti: oh are you going through the queue too?
[12:41] <pitti> arges: no, I just did some releases some 30 mins ago
[12:42] <arges> pitti: ok
[13:00] <Odd_Bloke> smoser: pitti: Are "Transaction order is cyclic" messages from systemd in cloud-init package installation a sign that I don't have a recent enough cloud-init?
[13:00] <Odd_Bloke> (This is in yakkety.)
=== xclaesse` is now known as xclaesse
[13:09] <smoser> Odd_Bloke, hm..
[13:10] <smoser> what package installation ?
[13:10] <Odd_Bloke> smoser: This is happening when we take an old cloud image and upgrade on boot; I'm freshening the image we use to see if the problem goes away.
[13:12] <smoser> Odd_Bloke, ok. let me look some.
[13:15] <pitti> Odd_Bloke: oh, could be that init-system-helpers gets upgraded too early/too late or so; I haven't seen dependency loops in fresh installs, but I haven't tried a lot of upgrade scenarios
[13:16] <pitti> Odd_Bloke: do you mind posting the logs to bug 1576692?
[13:16] <ubottu> bug 1576692 in init-system-helpers (Ubuntu Xenial) "fully support package installation in systemd" [High,Fix committed] https://launchpad.net/bugs/1576692
[13:16] <pitti> Odd_Bloke: (assuming that this also happens on upgrading xenial to xenial-proposed, the changes are pretty well identical)
[13:22] <smoser> pitti: http://paste.ubuntu.com/23177905/
[13:22] <pitti> smoser: ah, that reproduces it?
[13:22] <smoser> yeah
[13:22] <smoser> having old images easily available is nice.
[13:23] <brendand> is launchpad in a bad mood or something?
[13:23] <pitti> I tried an upgrade with both .services having After=multi-user.target and didn't get into trouble, but different unpack orders can also make this hard to repro
[13:24] <pitti> brendand: at least on my end it seems to have a fit pretty well every day for some minutes (feels like an expensive cron job or so)
[13:24] <smoser> full log http://paste.ubuntu.com/23177914/
[13:28] <pitti> journal would be good to see too
[13:33] <smoser> pitti, well, you can ask me , or you can try it :)
[13:33] <smoser> i can get it to you.
[13:34] <smoser> i was just checking..
[13:34] <smoser> the latest xenial daily + proposed + package_upgrade=true does not shwo the issue.
[13:34] <smoser> trying now with release imae
[13:34] <smoser> image
[13:35] <smoser> released image seems fine too
[13:37] <smoser> actually, pitti...
[13:37] <smoser> i think its just that package upgrade with the version of cloud-init that is in the image doens't work.
[13:37] <smoser> as is known by that bug.
[13:37] <smoser> and we've (i think) fixed the bug.
[13:37] <smoser> but that doesnt fix the image
[13:38] <smoser> Odd_Bloke, does that make sense ?
[13:38] <smoser> you're hitting a bug that we've fixed.
[13:40] <Odd_Bloke> smoser: Yep, that definitely makes sense; newer image as the base works fine. :)
[13:41] <smoser> yeah, but its more than just "its fixed because there are no upgrades to do"
[13:42] <smoser> package_upgrade and package install was broken, this update to cloud-init fixes it, but you can't have the old cloud-init apply this update due to that bug :)
[14:08] <Odd_Bloke> smoser: Yep, understood; we're still installing a bunch of packages and we've stopped seeing failures.
[14:10] <pitti> smoser: oooh! yes, that makes perfect sense
[14:10] <pitti> (sorry, was OTP for a long time)
=== Daviey_ is now known as Daviey
[15:08] <pitti> smoser, Odd_Bloke: so that means people upgrading from xenial after that SRU lands should *not* run into this
[15:09] <pitti> and people upgrading from intra-yakkety, well, yeah, tough luck :)
[15:28] <semiosis> Odd_Bloke: are you aware of a reason why the livecd-rootfs hasn't been updated to 2.408.4 in xenial-updates yet?  I marked the bug verification-done about two days ago
[15:29] <semiosis> bug 1621393
[15:29] <ubottu> bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
[15:29] <nacc> semiosis: iirc, 7 days for srus
[15:29] <nacc> typically
[15:29] <nacc> not hard and fast
[15:29] <bipul> Yes, but that's how we can resize our lvm
[15:29] <semiosis> nacc: ah ok, thanks
[15:29] <Odd_Bloke> Though also: "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)" from https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
[15:30] <bipul> sorry Shrinking the logical volume.
[15:30] <bipul> To reduce the size of a logical volume, first unmount the file system. You can then use the lvreduce command to shrink the volume. After shrinking the volume, remount the file system.
[15:30] <nacc> Odd_Bloke: iirc, i saw that too and once it's release that page is not necessary accurate
[15:30] <bipul> That's what i did
[15:30] <Odd_Bloke> nacc: Ahh, OK.
[15:31] <nacc> bipul: wrong channel?
[15:31] <bipul> oh yes, sorry
[15:31] <semiosis> nacc: Odd_Bloke: so we wait a few more days?
[15:32] <nacc> semiosis: that would be my recommendation :)
[15:32] <nacc> semiosis: it should trickle in just fine
[15:32] <rbasak> semiosis: it gives other users a chance to flag regressions.
[15:32] <semiosis> ok, then in that case, Odd_Bloke, I would like to post the link to your test build image in the bug.  that sound good to you?
[15:34] <semiosis> will the download link expire?
[15:34] <Odd_Bloke> semiosis: I'm not sure what the expiry is; I'd just check if it's working still.
[15:34] <Odd_Bloke> semiosis: If it is, it'll probably be good for a while.
[15:34] <semiosis> it is working right now
[15:35] <Odd_Bloke> Then go for it. :)
[15:36] <semiosis> done.  thanks!
[15:48] <nacc> rbasak: i'm starting to think that using git-python may have been a mistake. In that, really, I think we can leverage just normal subprocess/`git commands` for most everything and it will be quite a bit faster. Especially for eventual cron usage
[15:48] <nacc> rbasak: i'll play with that on the side, might just need a little wrapper class for the various commands we need
[15:49] <rbasak> nacc: OK. I think we needed the hindsight to have known. I'd be happy with such a switch.
[15:49] <rbasak> nacc: I wonder if it's worth seeing if pypy or similar can speed things up, if that's easy and works? Might save you the effort in switching over.
[15:49] <nacc> rbasak: yep, absolutely -- not an error on our part, we're just not really needing the convenience of git-internals that python-git affords, really
[15:49] <nacc> rbasak: i'll take a look!
[15:49] <rbasak> Is speed the only issue?
[15:50] <arges> mwhudson: hey can you give bug 1602243 an SRU template? thanks
[15:50] <ubottu> bug 1602243 in Ubuntu on IBM z Systems "[16.10 FEAT] Upgrade Docker to newest version 1.12" [Medium,In progress] https://launchpad.net/bugs/1602243
[15:51] <nacc> rbasak: pretty much, as the initial load of an existing repository can take hours
[15:51] <rbasak> Wow
[15:51] <nacc> rbasak: as it verifies every object in the git database
[15:51] <nacc> rbasak: as it's creating an internal reference, i think
[15:51] <nacc> rbasak: not sure, exactly, but it's very slow
[15:51] <nacc> and will only get worse as the repos grow
[15:53] <rbasak> Sounds like we should either fix the library or move away from it.
[15:53] <nacc> rbasak: yeah, i think the 'fix' is really just a usage thing. I'm not sure if it could be parallelized more
[15:54] <nacc> rbasak: in that it has does that `git cat-file --batch-check` and `git cat-file --batch` on the repository
[15:54] <nacc> rbasak: i'll dig into it later
[15:54] <rbasak> ack
[15:57] <cjwatson> nacc: did you consider python-pygit2?
[15:57] <cjwatson> nacc: that's what the git.launchpad.net backend uses
[15:58] <nacc> cjwatson: interesting, i'll take a look -- i was trying to use python3 :)
[15:58] <cjwatson> nacc: python3-pygit2, then :)
[15:59] <nacc> cjwatson: ah yes, thanks!
[15:59] <nacc> cjwatson: i'll take a look!
[15:59] <cjwatson> (we're still on python2 for this because of some details of Twisted, but the library in question supports either)
[15:59] <nacc> great, i'll see if that's any different performance wise for our case
[16:00] <cjwatson> there are ways to make it hit pathological behaviour, but we certainly haven't noticed anything like what you suggest in general
[16:00] <cjwatson> and we would
[16:00] <nacc> cjwatson: yep, absolutely
[16:00] <nacc> cjwatson: thanks again!
[16:00] <cjwatson> npo
[16:00] <cjwatson> er, np
[16:01] <nacc> no problem, ole!
[16:01] <rbasak> A perfect example of why using public channels is good. Thanks cjwatson :)
[16:02] <nacc> rbasak: i think i have the patch bits implemented too, fyi -- testing it now
[16:02] <cjwatson> :)
[16:02] <cjwatson> https://git.launchpad.net/turnip if you need usage examples
[16:23] <smoser> pitti, i assume you are gone
[16:23] <smoser> but .. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1623570
[16:23] <smoser> fun.
[16:23] <ubottu> Launchpad bug 1623570 in cloud-init (Ubuntu Xenial) "Azure: cannot start walinux agent (Transaction order is cyclic.)" [High,Confirmed]
[16:23] <smoser> i think i have it in hand.
[16:26] <andrewsh> pitti: and now I see the following: I did suspend, wpa_cli suspend did *not* run; I resume — it does *not* run, and no wifi connection either
[16:26] <andrewsh> I manually run wpa_cli resume — wpa_supplicant wakes up and reconnects
[16:29] <andrewsh> I see this in the logs before I ran wpa_cli resume:
[16:29] <andrewsh> Sep 14 18:21:18 nuevo NetworkManager[2944]: <info>  [1473870078.9817] device (wlan0): supplicant interface state: starting -> ready
[16:29] <andrewsh> Sep 14 18:21:18 nuevo NetworkManager[2944]: <info>  [1473870078.9818] device (wlan0): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
=== elbrus_ is now known as elbrus
=== marga_ is now known as marga
[18:59] <nacc> Pharaoh_Atem: ping
[19:00] <Pharaoh_Atem> nacc: pong
[19:00] <nacc> Pharaoh_Atem: hey, looking at LP: #1623540
[19:00] <ubottu> Launchpad bug 1623540 in php7.0 (Ubuntu Xenial) "If php.ini is incorrect, php-frm starts without warning with default values" [Medium,Triaged] https://launchpad.net/bugs/1623540
[19:00] <nacc> Pharaoh_Atem: seems like debian dropped the hlper script, so it affects 16.10 too
[19:00] <nacc> Pharaoh_Atem: do you have any suggestions?
[19:01] <Pharaoh_Atem> isn't fpm supposed to just fail anyway?
[19:02] <Pharaoh_Atem> I'm not sure how to fix it if it's not working
[19:04] <nacc> Pharaoh_Atem: well, i would have expected fpm to fail, but it doesn't :)
[19:05] <Pharaoh_Atem> :S
[19:05]  * Pharaoh_Atem grumbles about php
[19:06] <nacc> Pharaoh_Atem: -t definitely says a line like '# abcd (' is a 'syntax error', but the service still runs
[19:08] <nacc> Pharaoh_Atem: if you have any ideas, i'd appreciate it, i guess the helper script (which can make this work in 16.04, where it's still present) was dropped because "php-fpm often ends with zend_mm_heap corrupted that prevents th service to be (re)started" with no reference to bugs, etc so not sure how common that is
[19:11] <Pharaoh_Atem> nacc: I could have sworn that php-fpm has it's own method for checking these things
[19:33] <nacc> Pharaoh_Atem: yeah, i mean '-t' does it
[19:33] <nacc> Pharaoh_Atem: but it's not used currently, perhaps?
[19:33] <Pharaoh_Atem> I think that's it
[19:33] <Pharaoh_Atem> it's not used by default, I think
[19:33] <Pharaoh_Atem> though, that's completely brain-dead
[19:34] <nacc> Pharaoh_Atem: so i wonder if the systemd script should be using that as a pre-exec
[19:34] <nacc> or whatever
[19:34] <Pharaoh_Atem> it probably should
[19:34] <nacc> but i mean, that's what the wrapper script basically did (incorrectly, though)
[19:34] <Pharaoh_Atem> well, the wrapper script is basically unnecessary, right?
[19:34] <nacc> Pharaoh_Atem: unclear :)
[19:34] <nacc> Pharaoh_Atem: i guess so
[19:34] <nacc> let me see what else it does
[19:39] <nacc> Pharaoh_Atem: it also did something with tmpfiles?
[19:39] <nacc>  /usr/lib/tmpfiles.d/php7.0-fpm.conf
[19:39]  * Pharaoh_Atem shrugged
[19:39] <Pharaoh_Atem> why not define tmpfiles in the service file?
[19:39] <Pharaoh_Atem> it supports that
[19:39] <nacc> i have no idea
[19:39] <nacc> ok, i'll play with adding a call to php7.0-fpm -t in the ExecStartPre
[19:40] <Pharaoh_Atem> does invocation with -t lead to a running interpreter?
[19:40] <Pharaoh_Atem> or does it exit after the check?
[19:40] <nacc> it always exits, afaict
[19:41] <nacc> sigh, but it exits successfully even if the syntax error occurs :)
[19:41] <Pharaoh_Atem> I repeat: php is brain-dead
[19:41] <Pharaoh_Atem> :)
[20:17] <tumbleweed> win 33
[20:22] <pitti> smoser: sorry, was just gone for dinner and basketball, looking
[20:23] <smoser> pitti, you are allowed to walk away from the computer
[20:23] <smoser> just not for more than 6 minutes
[20:24] <smoser> please take a look at http://pad.lv/1623570 . i've uploaded to both yakkety and xenial
[20:24] <ubottu> Launchpad bug 1623570 in walinuxagent (Ubuntu) "Azure: cannot start walinux agent (Transaction order is cyclic.)" [High,In progress]
[20:24] <smoser> but would like your thoughts, and can nack it and replace it if needed.
[20:27] <pitti> smoser: 6 minutes? *now* I know what "fast food" means!
=== salem_ is now known as _salem
[23:28] <mwhudson> arges: done
[23:31] <nacc> Pharaoh_Atem: well, i figured out *why* php7.0-fpm starts successfully even with the -t check. the -t check only applies to parsing of php-fpm.conf, not php.ini
[23:31] <nacc> Pharaoh_Atem: as the php.ini parsing happens at a top-php-level across all sapis