[01:41] <Pharaoh_Atem> anyone have any idea what's causing this? http://fpaste.org/354429/46042524/
[01:44] <Pharaoh_Atem> this is the full log here: http://fpaste.org/354435/25442146/
[05:45] <pitti> cjwatson: hm, I'm getting hash sum mismatches in a container apt-get update again, was this disabled again?
[05:46] <pitti> cjwatson: indeed http://archive.ubuntu.com/ubuntu/dists/xenial/by-hash/SHA256/ has nothing from today, latest update is from yesterday morning
[05:58] <infinity> pitti: http://archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/by-hash/SHA256/
[05:58] <infinity> pitti: That's up to date.  I'm not even sure what's meant to be in that top-level by-hash dir.
[05:59] <infinity> Oh.  Contents files, probably.
[05:59] <infinity> And those aren't updated more than once a day.
[05:59] <pitti> ah, thanks
[06:06] <cpaelzer> good morning
[06:22] <pitti> infinity: hm, I forgot which page I really mean instead of the outdated https://wiki.ubuntu.com/ReleaseChecklist -- do you know?
[06:22] <pitti> infinity: I was wondering when to disable Launchpad crash reports in apport
[06:23] <infinity> pitti: https://wiki.ubuntu.com/ReleaseProcess
[06:23] <infinity> pitti: It claims -7 days
[06:24] <pitti> ah, thanks; so on Thursday
[06:24] <infinity> pitti: Any time nowish would probably be fine.  Though, with the new NM having just landed, we might want to keep repots verbose for a bit.
[06:25] <pitti> I have another bug fix to go along with disabling LP reports
[06:26] <pitti> infinity: ok, so actually aiming for Thu might be good then, to give a few days for NM
[06:26] <pitti> infinity: oh, btw -- I promised that I'd do a fresh langpack upload on Friday evening, but it turns out I'll be AFK from Friday noon to about Saturday evening
[06:27] <infinity> pitti: Yeah.  I trust NM upstream as much as I trust stgraber to reach things on the top shelf.
[06:27] <pitti> rotfl
[06:27] <pitti> so, I'll cron the generation, but I can't self-accept them
[06:27] <pitti> or, if you are happy with an upload on Sunday, that would work for me
[06:27] <infinity> pitti: That's fine.  If they can magically end up in the queue somehow, I can get them.
[06:28] <infinity> pitti: Or Sunday.  Don't care that much, really.
[06:28] <infinity> pitti: I'm sure I'll spin a new set on Sunday when I land in London, and I'm equally sure we'll do another set during the week. :P
[06:28] <pitti> infinity: given that it requires an off-the-schedule export from LP via webops and I usually do a coarse diff review before uplaod, that actually sounds better then
[06:29] <pitti> infinity: ok, Sunday it is then
[06:37] <pitti> wgrant: so what do we need to do to arrange a full xenial langpack export on Friday? (I already ticked the "full export" box, but cron would only run on Sunday)
[06:37] <pitti> wgrant: can we pre-schedule this with an extra cron job? or should we do it live on Friday morning?
[06:39] <wgrant> pitti: Easiest to just manually kick it off on Friday.
[06:39] <pitti> wgrant: ack, thanks
[06:50] <dholbach> Could somebody take a look at snapd in NEW?
[06:52] <dholbach> (please :-))
[06:55] <dholbach> it'll build the ubuntu-snappy package from now on
[06:55] <dholbach> and is required for a milestone today
[07:00] <dholbach> brb
[07:14] <pitti> cyphermox: hm, latest NM drops the .upstart file, was that on purpose? now NM doesn't start any more under upstart
[07:15] <pitti> cyphermox: I noticed because "adt-run --testname cmdline-upstart-boot systemd" fails now
[07:15] <pitti> it still has a sysv init script, but it doesn't get enabled on package install apparently
[07:19] <infinity> mvo: If ubuntu-snappy and ubuntu-snappy-cli have both become snapd, how is snapd avoiding the same issues that you previously split the package to deal with?
[07:20] <infinity> mvo: Ahh, ubuntu-core-snapd-units?
[07:27] <pitti> cyphermox: filed/tracked as bug 1569204
[07:31] <andrewsh> hey guys, I'm having graphics issues on Ubuntu for the first time (previously I had them on Debian only), who should I prod: https://www.dropbox.com/s/dtq4o4p0mxrgusf/2016-04-12_08-28-01.png?dl=0
[07:31] <andrewsh> that's Xenial, for the record
[07:40] <mvo> infinity: exactly
[08:00] <pitti> cyphermox: also, do you know why NM does not seem to log to syslog any more?
[08:38] <Mirv> TheMuso: since I would not want to start my core-dev career with a botched ubiquity upload, please consider reviewing and sponsoring https://code.launchpad.net/~timo-jyrinki/ubiquity/kubuntu_slideshow_i18n_lp1512834/+merge/291581 (debdiff https://launchpadlibrarian.net/253401826/ubiquity_2.21.54_2.21.55.diff.gz).
[08:39] <Mirv> TheMuso: it'd also be possible to do ./copy-package --from=~timo-jyrinki/ubuntu/grilo --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed ubiquity if happy
[08:39] <Mirv> I got a confirmation it's working on another channel (and in the bug report)
[08:55] <dholbach> thanks to whoever reviewed snapd
[08:55] <dholbach> snapd is in binNEW now
[09:04] <infinity> dholbach: You're welcome, and now I should sleep.
[09:04]  * dholbach hugs infinity 
[09:04] <dholbach> you're a hero
[09:04] <dholbach> mvo, ^
[09:35] <cjwatson> pitti: Do you have -oDebug::Acquire::http=true output?
[09:49]  * mvo hugs infinity
[10:00] <xnox> pitti, have you seen bug #1566465 ?
[10:00] <xnox> i'm not sure if that's a kernel or systemd bug.
[10:06] <ogra_> woah
[10:06] <ogra_> pitti, that last systemd update in trusty just turned my screen off
[10:07] <ogra_> (for about 30sec or so)
[10:07] <pitti> ogra_: bug 1473800
[10:08] <ogra_> heh
[10:08] <ogra_> didnt lock
[10:08] <pitti> ogra_: the fix was SRUed in the latest update, but it can only apply for any updates from now on, not for updates from previous versions *to* this one
[10:08] <pitti> well, same thing
[10:08] <pitti> X becoming confused when logind restarts
[10:08] <ogra_> yeah
[10:09] <ogra_> obviously my card then powers off the HDMI ports so that i get "no signal" on all three screens ... that was quite scary
[10:16] <pitti> xnox: I didn't yet, no; putting on list of things to look at
[10:17] <doko> jamespage, marcoceppi: python-libcharmstore doesn't have any copyright information except for the debian/copyright. Please could you add a LICENSE file, or add the license to the source files?
[10:17] <jamespage> doko, I referred to the committed LICENSE file in the upstream codebase - is that not sufficient to clarify the licensing?
[10:18] <doko> jamespage, but this file is not in the package which is sitting in NEW
[10:18] <jamespage> doko, yes that's why I added a comment to d/copyright...
[10:19] <doko> hmm
[10:19] <jamespage> doko, if you are not comfortable with that approach, I'll ask marcoceppi to make a new release...
[10:20] <pitti> cjwatson: http://paste.ubuntu.com/15783270/
[10:23] <cjwatson> pitti: Well, the URLs that your apt-cacher-ng is reporting as 404 do exist ... which exact package version of acng is that?
[10:23] <pitti> 0.8.9-1ubuntu1, shoudl be current xenial
[10:24] <cjwatson> I haven't actually directly confirmed that my fix to the built-in configuration works.
[10:24] <cjwatson> You could try putting "PfilePatternEx: /dists/.*/by-hash/.*" in acng.conf
[10:24] <pitti> I wonder what the "de.archive." things in the debug output are
[10:25] <pitti> maybe I have that mirror in some schroot config, and that's the one acng cached
[10:25] <cjwatson> That's acng's repository mapping
[10:25] <cjwatson> Surely it shouldn't be caching the 404 though
[10:25] <cjwatson> Hm, maybe it is
[10:25] <pitti> no, not that, but if it caches some de.archive.u.c. bits and pretends they are from archive.u.c. that migth cause some collisions without by-hash/ ?
[10:25] <doko> jamespage, ok, accepted
[10:26] <cjwatson> HTTP/1.1 404 Not Found
[10:26] <cjwatson> X-Original-Source: http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/source/by-hash/SHA256/8b81701065e3fa4957c5df3c6edc6a6f55301b7e20ac04d6a0aa19881b852320
[10:26] <cjwatson> That sure looks like negative caching to me
[10:27] <pitti> /var/cache/apt-cacher-ng/uburep/dists/xenial/main/source/by-hash/SHA256/*.head only has "200", no 404s, but maybe these are hidden somewhere
[10:28] <pitti> meh, I moved /var/cache/apt-cacher-ng/uburep/ away, restarted acng, and I still get teh 404 and de.archive.u.c.
[10:28] <pitti> where does this X-Original-Source come from..
[10:28] <cjwatson> pitti: Can you find 8b81701065e3fa4957c5df3c6edc6a6f55301b7e20ac04d6a0aa19881b852320 anywhere?
[10:29] <pitti> no, neither with find nor with grep
[10:29] <cjwatson> Or 6966a83abdd3fc2582ee280fa45561c6a6ffa1ca37cba6e891072a98e431ce66
[10:29] <pitti> also doesn't exist at all in the cache
[10:29] <cjwatson> Hmm
[10:29] <cjwatson> http://de.archive.ubuntu.com/ubuntu/dists/xenial/universe/source/by-hash/SHA256/6966a83abdd3fc2582ee280fa45561c6a6ffa1ca37cba6e891072a98e431ce66 *is* 404
[10:30] <cjwatson> So maybe acng is configured to try de.archive in preference, and reports its 404 as if it were for archive
[10:30] <pitti> neither the  container nor my host use de.archive
[10:30] <pitti> yeah, some built-in mirror selection perhaps
[10:31] <cjwatson> de.archive is presumably in /etc/apt-cacher-ng/backends_ubuntu
[10:31] <pitti> ah yes, it is
[10:31] <cjwatson> This must be something to do with how the Remap-* stuff works, I think
[10:33] <pitti> and if I drop the de. from /etc/apt-cacher-ng/backends_ubuntu then everything works
[10:34] <pitti> cjwatson: many thanks for finding /etc/apt-cacher-ng/backends_ubuntu! I wasn't aware that it remaps mirrors like that
[10:34] <dholbach> pitti, do you have an idea why http://paste.ubuntu.com/15783673/ might come up in the autopkgtest of snapd for some arches and not for others?
[10:35] <pitti> dholbach: maybe ca-certificates is pre-installed in VMs but not containers
[10:35] <dholbach> pitti, ah, that might be
[10:35] <pitti> dholbach: armhf and s390x run in LXC; i386, amd64, and ppc64el run in scalingstack instances
[10:35] <pitti> so if pass/fail maps to these two sets of arches, that smells like a missing "ca-certifictes" test dep
[10:35] <dholbach> nice catch
[10:37] <dholbach> pitti, is this something which could be fixed in the infrastructure? should I file a bug?
[10:37] <pitti> dholbach: you mean cleaning up  ca-certificates from instances? yes, we could do that
[10:37] <pitti> except on lcy01, which still doesn't allow me to build custom images as that times out
[10:37] <pitti> so it can't be reliable
[10:37] <dholbach> oh... cleaning... I thought adding ;-)
[10:38] <dholbach> well, at least make the list of packages the same, if that's possible :)
[10:38] <pitti> dholbach: not entirely possible, as scalingstack instances need some more packages to actually boot/work than a container
[10:38] <pitti> we can approximate it, though
[10:38] <pitti> although cf. the lcy01 bug, we run tests on the (very fat) standard cloud images there
[10:39] <pitti> (RT has been pending for a few months)
[10:41] <cjwatson> pitti: I followed up to https://bugs.debian.org/819852 with a summary of this
[10:41] <cjwatson> (should appear in a couple of minutes)
[10:41] <pitti> cheers!
[10:49] <doko> xnox, infinity: is this post-release material? https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1564918
[10:50] <dholbach> pitti, ok
[10:52] <xnox> doko, infinity - last glibc upload was from before that bug was filed. It certainly is SRU candidate, if we don't take it in. There are more comments on https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1563784
[10:52] <xnox> the lock elision one is claimed to be critical.
[10:53] <xnox> maybe it's worth taking both in. At the moment I am strugling to find any benchmark that does show that lock elision is good. So far i get things that widely range from 0.5x - 3x in performance, on multiple reruns. I'm guessing lpar is busy elsewhere, and I'm not getting the CPU resources I think I am.
[11:39] <Son_Goku> anyone have any idea what’s causing this? http://fpaste.org/354429/46042524/
[12:01] <alex116> I am using the gadget-fs to create a serial interface to communicate over USB. When I test it with microcom, I have to restart microcom after disconnecting the USB port. In a c++ program, would this be the equivalent of closing the file descriptor from which I am reading and opening it again?
[12:01] <mdeslaur> @pilot in
[12:15]  * dholbach hugs mdeslaur 
[12:15]  * mdeslaur hugs dholbach back
[12:39] <rbasak> Who should I talk to about akonadi's mysql backend and kubuntu?
[12:58] <rbasak> shadeslayer: around? Not sure who to ask.
[12:58] <shadeslayer> hi there
[12:58] <rbasak> I thought I had akokadi covered with the MySQL 5.7 transition, but just realised that it hardcodes dependencies on -5.6-.
[12:59] <shadeslayer> rbasak: I'm not really working on Kubuntu per se these days, but can have a look I guess, or maybe yofel
[12:59] <rbasak> mysql-server-core-5.6 specifically.
[12:59] <rbasak> I'd like to switch that to 5.7. I can do it, but I thought a heads-up was appropriate given the time we are in the cycle.
[13:00] <shadeslayer> right, best to tell yofel I think
[13:00] <yofel> rbasak: go ahead
[13:00] <rbasak> Thanks.
[13:00] <rbasak> I hope it has good test coverage!
[13:00] <yofel> I totally missed that because the upgrade went fine as virtual-mysql-server-core covered 5.7
[13:01] <rbasak> Also mysql-client-core-5.6 but I'm less concerned by that.
[13:01] <rbasak> yofel: ah so it's not actually using 5.6 right now?
[13:01] <rbasak> (we haven't deleted 5.6 yet - still getting through the reverse deps)
[13:01] <yofel> not on my machine, but I also run the full server, so that probably pulled 5.7 in
[13:02] <rbasak> OK
[13:02] <rbasak> I'll build and dep8 test locally first.
[13:02] <rbasak> Sorry about this. I've been following http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/rdepends/mysql-5.6/ and didn't realise that didn't cover the flavors until just now.
[13:04] <yofel> np. As I said, worst case the virtual dep would've covered 5.7, even if that's not why it's there originally
[13:05] <rbasak> yofel: my concern is any behaviour change by making it use 5.7 by default on the server.
[13:05] <rbasak> You can get 5.7 to work very similarly to 5.6 but some defaults have changed. Skuggen (upstream) can help us with that if needed.
[13:06] <yofel> hm... right
[13:09] <rbasak> superm1: ^^ the same applies to mythtv :-/
[13:34] <superm1> rbasak: what behavior change?
[13:34] <superm1> it seems that 5.7 is being pulled in fine in our ISO's right now for mythbuntu
[13:35] <superm1> and it sounds like upgrades will just keep 5.6 and not actually transition to 5.7 right?
[13:38] <Skuggen> If you  have mysql-server-5.6 and not mysql-server, yes
[13:40] <Skuggen> superm1: Some packages have had failures because 5.7 uses different default settings for sql modes, at least
[13:40] <Skuggen> Though the one I'm thinking of was a bunch of tests that more than anything seemed to be testing the server configuration
[13:41] <Skuggen> http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-setting the first line lists the defaults now. In 5.6 it was only NO_ENGINE_SUBSTITUTION
[13:47] <cyphermox> pitti: it probably just doesn't log to syslog with the specific set of options you picked, but NM definitely does log to syslog
[13:59] <superm1> Skuggen: oh.. yeah mysql-server is what we had, so yes i guess that means upgrades will come up to 5.7
[13:59] <superm1> can you make mysql-server resolve to mysql-server-5.7 | mysql-server-5.6 to avoid that happening?
[14:06] <rbasak> superm1: we want to remove 5.6.
[14:06] <superm1> oh
[14:06] <superm1> so the hope is that 5.6->5.7 is a smooth transition then, i see
[14:06] <Skuggen> Yeah
[14:06] <rbasak> I'm fairly confident about the upgrade path for the data.
[14:06] <Skuggen> Mostly it should be, unless you rely on the old default behavior
[14:06] <rbasak> mysql_upgrade etc.
[14:07] <Skuggen> i.e. things like trunkating out-of-range values instead of throwing an error
[14:07] <Skuggen> Or auto-creating users that don't exist if you try to grant them privileges...
[14:07] <superm1> i don't think those two scenarios should affect myth stuff
[14:07] <rbasak> Yeah my concern was that 5.7 would refuse something previously permitted, causing things to break, etc. I don't expect anything subtle. I expect things to error out if it's not right.
[14:08] <rbasak> If you've been testing 5.7 already, then I think we'll be good.
[14:08] <superm1> OK
[14:08] <rbasak> https://bugs.launchpad.net/ubuntu/+source/neutron-vpnaas/+bug/1567899 is an example of the sort of thing we've seen
[14:09] <rbasak> Fixes are usually pretty straightforward.
[14:09] <rbasak> (so far)
[14:09] <rbasak> And we've touched quite a few packages now.
[14:13] <pitti> cyphermox: I picked the options that are in the upstart job, i. e. none
[14:14] <cyphermox> pitti: yeah, I figure, but that should have logged normally ;)
[14:38] <mitya57> Mirv, hi, I've committed a change to qtbase's ubuntu branch that backports upstream fix for tray icons on Xubuntu/Lubuntu.
[14:41] <mitya57> Mirv, are you planning a new upload before Xenial release? Or can I upload it on my own?
[14:41] <rbasak> cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial-amd64/etc/localtime' are the same file
[14:41] <rbasak> Anyone else seeing that with mk-sbuild on Xenial?
[14:44] <rbasak> mk-sbuild runs cp -a on /etc/localtime. In my case, they *point* to the same file.
[14:44]  * rbasak tries -P
[14:51] <rbasak> That worked.
[14:53] <dholbach> pitti, I'm trying to run snapd through a local autopkgtest to avoid uploading umpteen times due to missing test depends ... I tried both lxc and cloud image (following instructions from one of your last blog entries and from packaging.u.c): http://paste.ubuntu.com/15792347/ - both fail for me ... is there a known working way? or should I ask somebody else? :)
[14:55] <pitti> dholbach: lxd> do you have an "lco:" remote? the images.linuxcontainers.org image is now available by default as images: (and the latest autopkgtest also updated the documentation)
[14:55] <pitti> dholbach: please run --- lxd -d ... to enable debugging
[14:55] <dholbach> pitti, yep, I added that following https://www.piware.de/2015/12/whats-new-in-autopkgtest-lxd-maas-apt-pinning-and-more/ :)
[14:56] <pitti> dholbach: if you do "lxc launch lco:ubuntu/xenial/amd64 x1", does that work?
[14:56] <dholbach> error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: no such file or directory
[14:57] <pitti> dholbach: seems you don't actually have lxd installed?
[14:57] <dholbach> ouch sorry, it's been a long day already
[14:57] <dholbach> thanks pitti
[15:01] <mdeslaur> @pilot out
[15:11] <nacc> elbrus: ping
[15:15] <pitti> apw: hey Andy
[15:15] <pitti> apw: still remember bug 1531768?
[15:15] <pitti> apw: I have an instance with current xenial running for about two hours, chugging through a loop of tests, and so far it works fine
[15:15] <pitti> apw: TBH, I mainly tell you this in a public channel to coerce it to fail again :-)
[15:15] <apw> pitti, :)
[15:16] <pitti> but yeah, trying to trigger Murphy's law deliberately fails because of Murphy's law
[15:27] <smoser> cjwatson, sorry to bother. bug 1505839 you suggested yesterday gfxboot-theme-ubuntu as the likely source of the issue
[15:28] <smoser> but that package is unmodified from vivid (works) to wily (fails)
[15:28] <cjwatson> yes, I know.  syslinux/gfxboot/gfxboot-theme-ubuntu are tightly coupled though
[15:28] <cjwatson> I don't actually know what the problem is here, it would take hours of investigation to establish more and I don't have that time
[15:28] <smoser> ok. yeah. that makes sense then.
[15:28] <cjwatson> but in the past, it has sometimes been the case that changes to one of those required changes to others
[15:28] <smoser> thanks
[15:29] <cjwatson> it's not *necessarily* the case that a change to syslinux would require a change to one of the others; this is just an educated guess
[15:29] <smoser> yep
[15:29] <doko> finally, gcc-5-cross-ports migrated \o/
[15:34] <cjwatson> doko: ah yes, I was just going to tell you
[15:34] <cjwatson> infinity: ^-
[15:39] <Mirv> mitya57: hi. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-046/+packages is landing soon first.
[15:39]  * Mirv notices lacks one git push
[15:41] <mitya57> Mirv, so after that mine is OK for upload? Or do you want me to go through the CI Train too?
[15:41] <Mirv> mitya57: ok, pushed, I think you could upload ubuntu8 directly too
[15:41] <Mirv> we're only doing the QA for the vivid+overlay 5.4.1 anyway
[15:41] <mitya57> ACK, will upload directly after that one lands
[15:41] <Mirv> so general smoketesting would be ok
[15:42] <mitya57> I've built that in my PPA, and some people tested the fix
[15:44] <nacc> Pharaoh_Atem: ping
[15:56] <rbasak> pitti: I'm getting an odd error with adt-run on a package that has a test that needs a built tree: dpkg-genchanges: error: cannot read ../akonadi_15.12.1-0ubuntu4.dsc: No such file or directory
[15:56] <rbasak> http://paste.ubuntu.com/15794227/
[15:56] <rbasak> Any ideas?
[15:58] <Mirv> mitya57: I mean, you could skip the wait for silo 046 upload ubuntu8 (or combine it into new ubuntu7) already to save time because freezes are so near.
[15:58] <pitti> rbasak: hmm, not off-hand; can you please file a bug with a reproducer? sorry, TB meeting now, then dinner
[15:58] <Mirv> mitya57: I would then only publish the vivid-overlay part of 046 when it's approved
[15:58] <rbasak> pitti: OK, np.
[15:58] <pitti> slangasek, kees, infinity, mdeslaur, stgraber: TB meeting reminder
[15:59] <mitya57> Mirv, ok, will combine with ubuntu7 then
[15:59]  * slangasek nods
[15:59] <mdeslaur> pitti: ack
[15:59] <highvoltage>  Ú;#Ú;/win 8
[16:00] <Unit193> That's a new take on it.
[16:01] <Mirv> mitya57: thanks
[16:05] <rbasak> pitti: bug 1569434
[16:05] <pitti> cheers
[16:10] <rbasak> pitti: quick question if you're able: what version of autopkgtest runs when I upload? I was about to Just Upload given that I can't easily locally test, but just thought that might cause issues in xenial-proposed perhaps?
[16:10] <pitti> rbasak: production just runs straight out of git, so usually git master or maybe a few commits behind
[16:11] <rbasak> OK thanks
[16:32] <Pharaoh_Atem> nacc: pong
[16:36] <nacc> Pharaoh_Atem: so i just took a look at the upstream PHP7.0 changelog ... while at least this one is arguably all bugfixes (http://php.net/ChangeLog-7.php) [I'd need to check on the hugepage chagne which seems a functional change and the libzip thing, although irrelevant to us, since we link to our libzip], looking at the upstream NEWS file (which maybe 7.0.6 or 7.1.0 depending on the upstream track,
[16:36] <nacc> aiui) http://git.php.net/?p=php-src.git;a=blob;f=NEWS;h=dfbc707d7abcddd2a13eba8df4d41508a211ca31;hb=HEAD, I get a bit more worried -- a few lines of "Implemented"
[16:37] <Pharaoh_Atem> they've already branched php7.0.6
[16:38] <nacc> so they have
[16:38] <nacc> Pharaoh_Atem: ok, so the 7.0.x will be selective backporting of bugfixes from the master?
[16:38] <Pharaoh_Atem> yes
[16:38] <Pharaoh_Atem> nacc: https://github.com/php/php-src/blob/PHP-7.0.6/NEWS
[16:38] <nacc> Pharaoh_Atem: i'm just trying to get some reassurance that will be true :)
[16:39] <Pharaoh_Atem> there's not much in the way of reassurance with the PHP people
[16:39] <Pharaoh_Atem> but the best I can say is that they seem to be following that model for now
[16:39] <nacc> right, but if i file a SRU request, I need to back it up somewhat -- otherwise I'm individually backporting stuff as bugs get filed in ubuntu
[16:40] <Pharaoh_Atem> git master is a scary place for LTS distros
[16:40] <Pharaoh_Atem> historically with the php versioning scheme, it follows a structure similar to Python
[16:41] <Pharaoh_Atem> where major.minor.patch is more or less supermajor.major.minor
[16:43] <Pharaoh_Atem> nacc: given we don't expect the supermajor to change for a while, the major version will largely be incremented for feature implementations, while the minor version is incremented for bugfixes
[16:44] <nacc> Pharaoh_Atem: ack, thanks
[16:45] <Pharaoh_Atem> If Ubuntu is okay with that for Python and Perl, I don't see why they aren't okay with it for PHP
[17:02] <rbasak> Pharaoh_Atem: PHP has a poor track record in this area.
[17:02] <Pharaoh_Atem> rbasak: *sigh*
[17:03] <rbasak> Pharaoh_Atem: historically, Ubuntu is OK with it only after a case has been made. I expect that it was made and accepted for Python and Perl if indeed it is done in Ubuntu.
[17:10] <rbasak> superm1: I uploaded mythtv ubuntu4 dropping the 5.6 deps. FYI, I think the "| mysql-server-5.7 | mariadb-server" is redundant (and for client too) since maria and mysql both agree in Debian to always provide virtual-mysql-{client,server} but I didn't change that - not my call and also probably a good idea to change as little as possible at this stage in the cycle.
[17:10] <superm1> rbasak: thanks for the heads up, the main reason everything was called out is that we use the same packaging on all distros in a backports PPA
[17:11] <superm1> that tracks upstream's stable -fixes branch
[17:11] <superm1> but i think virtual-mysql-server should still resolve that properly
[17:12] <rbasak> superm1: ah, OK. In that case you may have to wait until virtual-mysql-* appears in the oldest release to which you backport.
[17:12]  * rbasak isn't sure when that might be.
[17:12] <rbasak> That's the sort of the reason I had in mind for not touching it :)
[17:13] <rbasak> Actually
[17:13] <rbasak> I'm sorry.
[17:13] <rbasak> That upload probably wasn't needed at all in that case.
[17:13] <rbasak> It's an alternative. Sorry, my fault.
[17:38] <nacc> tsimonq2: just to be clear, do you mean the missing articles throughout the document? (the, a)?
[17:41] <tsimonq2> nacc: huh
[17:41] <tsimonq2> *huh?
[17:42] <nacc> tsimonq2: re: php7.0 serverguide review
[17:42] <tsimonq2> ohhhhh
[17:42] <nacc> tsimonq2: sorry :)
[17:42] <tsimonq2> no it's alright :)
[17:43] <tsimonq2> what specifically are you talking about? have you read my inline comments?
[17:43] <nacc> tsimonq2: yeah, the ones that all refer to l130 review, i'm just trying to understand what you meant :)
[17:44] <teward> nacc: i'm lost or i'd know what you and simon were talking about (saw 'php7.0' and 'serverguide')
[17:44] <tsimonq2> teward: he submitted an MP to the server guide
[17:44] <nacc> teward: i'm submitting a MP to fix up server guide
[17:44] <teward> links are nice
[17:44] <tsimonq2> relating to PHP
[17:44] <nacc> https://code.launchpad.net/~nacc/serverguide/php7.0/+merge/291655
[17:44] <tsimonq2> nacc: so basically what I meant was to keep it consistent when referring to the terminal
[17:45] <nacc> tsimonq2: you mentioned "weird wording" -- most of what i have found is missing "the"s or "a"s
[17:45] <nacc> tsimonq2: oh i see!
[17:45] <nacc> tsimonq2: is there a standard preferred way to refer to it?
[17:46] <teward> tsimonq2: there's a comment inbound from me
[17:46] <tsimonq2> nacc: I don't know anything specific, maybe you have an idea, but it just looked weird :)
[17:46] <tsimonq2> teward: alright :)
[17:46] <nacc> tsimonq2: ack ... i will at least make it consistent
[17:46] <tsimonq2> nacc: and it's not all line 130
[17:46] <tsimonq2> :)
[17:47] <nacc> teward: Pharaoh_Atem: we should also document fpm, no?
[17:47] <nacc> teward: and nginx and php?
[17:47] <teward> nacc: nginx will come later
[17:47] <nacc> teward: k
[17:47] <teward> we can probably add that later
[17:47] <teward> nacc: did you draft Release Notes items for php7.0?
[17:47] <nacc> tsimonq2: right, i just meant a bunch of comments (afaict) were "see l130" -- wanted to clarify that
[17:47] <nacc> teward: nope, on my todo for today
[17:47] <nacc> teward: having not done it before, do you have a pointer to where is tart?
[17:48] <nacc> *i start
[17:48] <teward> nacc: never had to write a release notes item in my entire Ubuntu-ness.  rbasak is my guide, i worked off his drafts for the HTTP/2 stuff
[17:48] <Pharaoh_Atem> nacc: well, we have php7.0-fpm configs available now
[17:48] <Pharaoh_Atem> so why not?
[17:48] <nacc> rbasak: --^ ? any pointers to where to start for php7.0 release notes?
[17:48] <teward> nacc: though, when you write it, it would be sufficient to make a note for php fpm that this breaks older nginx configurations, and need to be updated for PHP7.0 default paths.
[17:49] <teward> nacc: though if you feel comfortable linking to my blog, i"ll have something posted for it by Saturday
[17:49] <nacc> Pharaoh_Atem: care to write something up? and send a MP?
[17:49] <rbasak> nacc: maybe https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes for style?
[17:49] <tsimonq2> teward: reiterating my point ;)
[17:49] <nacc> rbasak: thanks
[17:49] <rbasak> And similar URL scheme for previous releases.
[17:49] <teward> tsimonq2: actually, correcting your suggestion.
[17:49] <teward> tsimonq2: E:BadGrammar
[17:49] <rbasak> nacc: you can also edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes directly.
[17:49] <rbasak> (which we'll do in the end when transferring from bugs anyway)
[17:49] <tsimonq2> teward: oh :P
[17:49] <teward> tsimonq2: switch PHP Apache for Apache PHP
[17:49] <tsimonq2> yep ack
[17:49] <Pharaoh_Atem> nacc: how exactly do I do this?
[17:49] <nacc> teward: ack
[17:50] <rbasak> https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Ubuntu_Server is blank right now :)
[17:50] <teward> lol
[17:50] <tsimonq2> ruh roh
[17:50] <nacc> Pharaoh_Atem https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/UbuntuServerGuide
[17:50] <teward> rbasak: regarding release notes, did you see my notes on your bug for the HTTP/2 stuff under the release notes tracker on LP?
[17:50] <rbasak> teward: yes - no longer applicable to nginx, right?
[17:51] <teward> rbasak: correct - HTTP/2 is in Xenial
[17:51] <teward> as of 1.9.14
[17:51] <teward> and tested to confirm it works
[17:51] <rbasak> Great. Thanks!
[17:51] <teward> thanks to infinity asking for OpenSSL tests :P
[17:51] <teward> rbasak: you're welcome.
[17:51] <Pharaoh_Atem> nacc: atm I'm doing a wonderfully annoying set of merges and cleanups related to libvirt-php, but I may have something to contribute in relation to the server notes for php7
[17:51] <nacc> Pharaoh_Atem: luckily it's not tied to the release schedule, afaict
[17:51] <nacc> Pharaoh_Atem: so when/if you can
[17:52] <Pharaoh_Atem> certainly
[17:52] <nacc> Pharaoh_Atem: it seems like a nice-to-have documentation
[17:52] <Pharaoh_Atem> well, it's a good thing to have
[17:52] <Pharaoh_Atem> we want people not using mod_php7.0 as much as possible
[18:03] <nacc> teward: tsimonq2: do you think "enter the following at the terminal prompt" or "enter the following in the terminal prompt" is more correct? I use the former normally
[18:08] <rbasak> I'd say "at"
[18:09] <nacc> rbasak: ack, thanks
[18:16] <nacc> tsimonq2: can i push to the same branch to update the merge, or do i need to request a new merge?
[18:16] <nacc> with a corresponding new branch
[18:19] <teward> nacc: "at"
[18:19] <teward> nacc: BTW, nginx + php7.0 data at http://dark-net.net/?p=125
[18:19] <teward> i'll set up a 'nice link' when i'm not busy beating the Internet to death for being laggy
[18:19] <teward> that's also aggregated on Planet
[18:20] <teward> nacc: I strongly suspect people will want php5 back at some point - there's another post on that on my blog as well.
[18:20] <teward> (also Planet aggregated)
[18:20] <nacc> teward: ack, updated locally, pending an answer to my last question for a fresh MP
[18:20] <nacc> teward: they have trusty for that
[18:20] <teward> nacc: yes, but you know the people who 'must have the latest'
[18:20] <teward> >.>
[18:21] <nacc> teward: inasmuch as I don't know what "back" is in this context; there is no "back" :)
[18:21] <nacc> teward: as you suggest in the post, you can use a PPA, but then you're relying on the PPA's owner
[18:21] <teward> indeed
[18:21] <teward> nacc: i was just giving you an FYI
[18:21] <teward> no need to include it in release notes
[18:22] <teward> but linking to my post regarding the php7.0 transition, and updating existing sitei configs is still relevant
[18:22] <nacc> teward: ack, we know it's a potential issue, but well broadcasted (as much as I can) and ack on documentation links/needs
[18:22]  * teward just added the other post in order to make a note that if people get annoyed there is a non-supported solution)
[18:22] <teward> indeed.
[18:23] <nacc> teward: i'm also going to try and set up an env to test using lxd and/or adapt to just have xenial with appropriate redirection to trusty containers and host php5 + php7 at the same time, both in supporte environments
[18:23] <teward> rbasak: probably should add something for nginx about the php7.0 transition, though i'm tempted to leave that on nacc's section
[18:23] <teward> nacc: ah, cool, let me know how that goes :)
[18:23] <nacc> teward: it was rbasak's suggestion  (sort of)
[18:24] <teward> indeed
[18:28] <nacc> tsimonq2: fyi, the tabulation issue is inconsistency in the file itself (tabs vs. spaces)
[18:30] <teward> tsimonq2: add that to the list - "fix indentation inconsistencies"
[18:30] <teward> you've just given yourself that task :P
[18:31] <nacc> teward: do you know the answer to my prior question? should i push to the same branch and will lp handle that properly or should i send a new MP with a new branch?
[18:32] <teward> nacc: i didn't see that question.  #launchpad may be able to help?
[18:32] <nacc> teward: np, good point
[18:44] <teward> nacc: does libapache2-mod-php exist as an installable object in Xenial?
[18:44] <nacc> teward: yes, it's a virtual pkg that depends on libapache2-mod-php7.0
[18:44] <nacc> teward: the ubuntu/debian preference going fwd is to use unversioned metapacakges
[18:44] <teward> nacc: ack
[18:47] <teward> nacc: I don't have merge powers, not sure why i'm on the approvers list on this one
[18:47] <nacc> teward: just wanted you to review
[18:47] <nacc> teward: as you already reviewed the other :)
[18:48] <teward> ack
[18:48] <teward> I've made a comment that it looks OK to me, but my 'review' is listed as "Abstain"
[18:48] <teward> simon's got more review say in this than I unfortunately
[18:48] <nacc> teward: fair enough, wasn't aware it was that formal, sorry!
[18:48] <teward> nacc: I'm treating it as formal :)
[18:48] <teward> no problem though
[18:49] <teward> glad to be in the loop :)
[18:50] <teward> tsimonq2: ^ just as an fyi
[18:50] <teward> i know you're not here right now thoug
[18:50] <nacc> teward: ack, thanks
[18:51] <teward> nacc: now, if it were an nginx section, I'd be asserting myself as needing to review it, due to being the one working on nginx right now; highly doubt the documentation team would mind heh
[18:52] <nacc> :)
[19:27] <nacc> slangasek: so php7.0.5 has a bunch of security fixes, etc. pacakged by debian now; if i file and am granted a SRU exception for php7.0 microreleases, will that mean i can just request a merge as appropriate?
[19:27] <teward> nacc: thought it was decided the fixes were backported and not as important to get included?
[19:27] <teward> (i.e. to not need the FFe)
[19:28] <nacc> teward: i just did a quick review -- upstream claims they are pretty important, and at least one is a BC unbreak
[19:28] <nacc> teward: i also just want to understand the policy :)
[19:28] <teward> :P
[19:28] <jtaylor> hm apparmor is spamming me with dnsmasq messages since the update today
[19:29] <tyhicks> jtaylor: since you updated to apparmor 2.10.95?
[19:29] <jtaylor> seems to actually be from yesterday, yes 2.10.95
[19:30] <tyhicks> jjohansen, sarnold: fyi ^
[19:30] <tyhicks> jtaylor: there should have been no changes in apparmor 2.10.95 that would cause that
[19:30] <tyhicks> jtaylor: I'll do some digging
[19:31] <jtaylor> operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/dnsmaq" name="run/dbus/system_bus_socket"
[19:31] <tyhicks> jtaylor: for now, you can follow https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1569316
[19:31] <jjohansen> what other packages were updated at the same time?
[19:31] <jtaylor> ah yes looks like that
[19:32] <jtaylor> a bunch I hadn't updated in a couple days, I can dig out the history if needed
[19:32] <tyhicks> it would be helpful
[19:32] <tyhicks> I'm going to begin trying to isolate the apparmor package update to determine if it was a change in there
[19:33] <jtaylor> I'll disable aa-notify for now ;)
[19:33] <jtaylor> please don't hack me now D:
[19:33] <sarnold> tyhicks: hah, talk about fun timing
[19:33] <sarnold> jtaylor: thanks for the report :)
[19:33]  * tyhicks defines fun differently
[19:36] <slangasek> nacc: it wouldn't be requesting a merge; we wouldn't track arbitrary packaging changes from Debian as part of a microrelease exception
[19:37] <nacc> slangasek: ok, so we'd be actually repackagind from upstream via uscan/uupdate?
[19:39] <slangasek> nacc: yes
[19:40] <jtaylor> tyhicks: attached the apt history to the log
[19:41] <nacc> slangasek: ok, thank you for clarifying
[19:41] <jtaylor> s/log/bug
[19:41] <nacc> slangasek: so at that point, do we still need to enforce our orig tarballs match debian's? if debian has already packaged the same version?
[19:45] <tyhicks> jtaylor: thank you
[19:46] <infinity> nacc: Yes.
[19:47] <nacc> infinity: thanks, just trying to understand all the bits so i can make it as easy as possible
[19:47] <infinity> nacc: You can only have one orig per upstream version, so while your 16.04 SRU uploads might be forked from Debian, your 16.10 uploads wouldn't be.
[19:47] <nacc> infinity: ack
[19:47] <infinity> nacc: So, you want the correct orig in 16.10, then uupdate with the same orig in 16.04
[19:47] <nacc> infinity: got it
[19:48] <infinity> nacc: If Debian is using pristine upstream tarballs (are they?) you can certainly agree in advance how the orig will be obtained and skip ahead.  Or agree that they use yours if you're ahead.  But it's definitely less hassle to use the same one.
[19:48] <nacc> infinity: does that imply we can't sru 16.04's php7.0 until 16.10 opens (e.g., with 7.0.5 as currently available) [again, presuming a microrelease SRU exception were to be granted]
[19:49] <infinity> nacc: No, it doesn't imply that, it just implies that it would be in your best interest to make sure you and Debian will use the same 7.0.5 orig, regardless of who uploads first.
[19:49] <nacc> infinity: got it
[19:49] <nacc> infinity: i believe debian is using pristine tarballs, but i'll review it to be sure
[19:50] <infinity> nacc: If the watch file grabs by URL and does gpg validation, that's a pretty good sign. ;)
[19:50] <infinity> nacc: But best to just make sure you and ondrej agree on what the method is (bonus points for the method being codified in the package), so you don't step on each others' toes.
[19:51] <nacc> infinity: ack, will do
[19:55] <nacc> teward: fyi, i put some notes in https://wiki.ubuntu.com/XenialXerus/ReleaseNotes will try and flesh it out more too
[20:07] <tsimonq2> nacc, teward: I'm back, what's up?
[20:08] <jderose> nacc: might be nice to mention apt 1.2 and its shiny new DropPrivs feature :)
[20:11] <nacc> jderose: oh i was just updating for php7 :)
[20:11] <nacc> tsimonq2: sent an updated MP
[20:12] <tsimonq2> nacc: k cool
[20:13] <tsimonq2> nacc: and if you pushed to the branch, the MP would have updated :)
[20:16] <nacc> tsimonq2: ok i wasn't true, the guide mentions needing to put a new branch for every push, which seems confusing :)
[20:16] <tsimonq2> yeah :)
[20:17] <infinity> jderose: iz a wiki. ;)
[20:17] <infinity> jderose: *hint*
[20:20] <tsimonq2> nacc: reply incoming
[20:21] <jderose> infinity: is a wiki indeed, just crazy busy with something else ATM :P maybe later i'll have a chance
[20:25] <smoser> hey
[20:26] <smoser> anyone know how /run/network/ifstate gets initialized ?
[20:26] <smoser> i'm seeing that /lib/open-iscsi/net-interface-handler may end up populating it before it gets initialized. so /lib/open-iscsi/net-interface-handler does what it wanted (to make it appear like the iscsi root device nic is already up)
[20:26] <smoser> but that runs to early, and something else stomps it
[20:30] <teward> tsimonq2: scrollback is important
[20:30] <teward> tsimonq2: also, assign yourself to "Fix the inconsistencies with indentation - tabs and spaces should not exist simultaneously" issue
[20:31] <tsimonq2> teward: is that a bug already or no?
[20:31] <tsimonq2> s/bug/bug report/
[20:31] <teward> tsimonq2: nope, but nacc identified it as a problem
[20:32] <tsimonq2> k I'll do that in like 30 mins
[20:34] <smoser> slangasek, ^ or xnox ^ or pitti ^ (/me knows that 2 out of those 3 certainly should be EOD)
[20:37] <slangasek> smoser: ifupdown creates that file the first time it brings an interface up
[20:40] <smoser> slangasek, how does it know its the first time ?
[20:40] <slangasek> smoser: because the file isn't there yet
[20:40] <smoser> not true
[20:40] <teward> nacc: ack on the ping, looking now
[20:40] <smoser> i write it before it does, and then it truncates it
[20:40] <smoser> s/i/lib/open-iscsi/
[20:40] <slangasek> smoser: did you take a lock before you created it?
[20:40] <smoser> how do i take a lock ?
[20:41] <teward> nacc: s/configuration step/configuration change/ on the nginx bulletpoint,  but since it's a wiki I'll edit.
[20:42] <slangasek> smoser: ifupdown/main.c; it appears you need an fcntl(F_SETLK) on /run/network/.ifstate.lock
[20:43] <smoser> i'm pretty sure i'm not racing with it.
[20:44] <smoser> as this is running from udev
[20:44] <smoser> on the added lo event
[20:44] <smoser> which would later bring it up
[20:47] <smoser> slangasek, that make sense ?
[20:47] <smoser>  /lib/open-iscsi/net-interface-handler (http://paste.ubuntu.com/15800985/) is running via udev rule on a RUN+=
[20:48] <smoser> and i even had it runnign from a IMPORT (meaning it ran right then) and still saw the issue
[20:49] <tyhicks> jjohansen, sarnold, jtaylor: the new network-manager is what triggered the "disconnected path" denials (the new apparmor was *not* the cause)
[20:50] <tyhicks> jjohansen, sarnold: that's the case for the dnsmasq denials - I'm not sure about dhclient yet
[20:50] <jjohansen> tyhicks: thanks
[20:52] <slangasek> smoser: I don't think it's safe to assume that 'added lo' doesn't race other network interfaces
[20:52] <slangasek> whether you're tripping the race or not in this case, I'm sure there is a race there
[21:35] <sarnold> tyhicks: nice find :)
[21:57] <TheMuso> Mirv: If nobody else has looked at your merge by now, I can have a look.
[22:25] <seb128> cyphermox, hey, did you see bug #1568336?
[22:26] <seb128>   1646: 	option_error("Plugin %s is for pppd version %s, this is %s",
[22:26] <seb128> in the nm plugin :-/
[23:13] <nacc> slangasek: what/who should i subscribe to the microrelease-exception request for php7.0?
[23:45] <xnox> smoser, haha