=== salem_ is now known as _salem [01:41] anyone have any idea what's causing this? http://fpaste.org/354429/46042524/ [01:44] this is the full log here: http://fpaste.org/354435/25442146/ [05:45] cjwatson: hm, I'm getting hash sum mismatches in a container apt-get update again, was this disabled again? [05:46] cjwatson: indeed http://archive.ubuntu.com/ubuntu/dists/xenial/by-hash/SHA256/ has nothing from today, latest update is from yesterday morning [05:58] pitti: http://archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/by-hash/SHA256/ [05:58] 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] Oh. Contents files, probably. [05:59] And those aren't updated more than once a day. [05:59] ah, thanks [06:06] good morning === athairus is now known as afkthairus [06:22] infinity: hm, I forgot which page I really mean instead of the outdated https://wiki.ubuntu.com/ReleaseChecklist -- do you know? [06:22] infinity: I was wondering when to disable Launchpad crash reports in apport [06:23] pitti: https://wiki.ubuntu.com/ReleaseProcess [06:23] pitti: It claims -7 days [06:24] ah, thanks; so on Thursday [06:24] 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] I have another bug fix to go along with disabling LP reports [06:26] infinity: ok, so actually aiming for Thu might be good then, to give a few days for NM [06:26] 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] pitti: Yeah. I trust NM upstream as much as I trust stgraber to reach things on the top shelf. [06:27] rotfl [06:27] so, I'll cron the generation, but I can't self-accept them [06:27] or, if you are happy with an upload on Sunday, that would work for me [06:27] pitti: That's fine. If they can magically end up in the queue somehow, I can get them. [06:28] pitti: Or Sunday. Don't care that much, really. [06:28] 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] 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] infinity: ok, Sunday it is then [06:37] 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] wgrant: can we pre-schedule this with an extra cron job? or should we do it live on Friday morning? [06:39] pitti: Easiest to just manually kick it off on Friday. [06:39] wgrant: ack, thanks [06:50] Could somebody take a look at snapd in NEW? [06:52] (please :-)) [06:55] it'll build the ubuntu-snappy package from now on [06:55] and is required for a milestone today [07:00] brb [07:14] cyphermox: hm, latest NM drops the .upstart file, was that on purpose? now NM doesn't start any more under upstart [07:15] cyphermox: I noticed because "adt-run --testname cmdline-upstart-boot systemd" fails now [07:15] it still has a sysv init script, but it doesn't get enabled on package install apparently [07:19] 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] mvo: Ahh, ubuntu-core-snapd-units? === juliank_ is now known as juliank [07:27] cyphermox: filed/tracked as bug 1569204 [07:27] bug 1569204 in network-manager (Ubuntu Xenial) "xenial regression: does not start any more under upstart" [Critical,Triaged] https://launchpad.net/bugs/1569204 [07:31] 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] that's Xenial, for the record [07:40] infinity: exactly [08:00] cyphermox: also, do you know why NM does not seem to log to syslog any more? === sil2100_ is now known as sil2100 [08:38] 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] 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] I got a confirmation it's working on another channel (and in the bug report) [08:55] thanks to whoever reviewed snapd [08:55] snapd is in binNEW now [09:04] dholbach: You're welcome, and now I should sleep. [09:04] * dholbach hugs infinity [09:04] you're a hero [09:04] mvo, ^ [09:35] pitti: Do you have -oDebug::Acquire::http=true output? [09:49] * mvo hugs infinity [10:00] pitti, have you seen bug #1566465 ? [10:00] bug 1566465 in linux (Ubuntu Xenial) "[regression]: Failed to call clock_adjtime(): Invalid argument" [Medium,Confirmed] https://launchpad.net/bugs/1566465 [10:00] i'm not sure if that's a kernel or systemd bug. [10:06] woah [10:06] pitti, that last systemd update in trusty just turned my screen off [10:07] (for about 30sec or so) [10:07] ogra_: bug 1473800 [10:07] bug 1473800 in systemd (Ubuntu Trusty) "restarting logind during systemd update causes screen to lock" [Medium,Fix released] https://launchpad.net/bugs/1473800 [10:08] heh [10:08] didnt lock [10:08] 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] well, same thing [10:08] X becoming confused when logind restarts [10:08] yeah [10:09] 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] xnox: I didn't yet, no; putting on list of things to look at [10:17] 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] doko, I referred to the committed LICENSE file in the upstream codebase - is that not sufficient to clarify the licensing? [10:18] jamespage, but this file is not in the package which is sitting in NEW [10:18] doko, yes that's why I added a comment to d/copyright... [10:19] hmm [10:19] doko, if you are not comfortable with that approach, I'll ask marcoceppi to make a new release... [10:20] cjwatson: http://paste.ubuntu.com/15783270/ [10:23] 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] 0.8.9-1ubuntu1, shoudl be current xenial [10:24] I haven't actually directly confirmed that my fix to the built-in configuration works. [10:24] You could try putting "PfilePatternEx: /dists/.*/by-hash/.*" in acng.conf [10:24] I wonder what the "de.archive." things in the debug output are [10:25] maybe I have that mirror in some schroot config, and that's the one acng cached [10:25] That's acng's repository mapping [10:25] Surely it shouldn't be caching the 404 though [10:25] Hm, maybe it is [10:25] 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] jamespage, ok, accepted [10:26] HTTP/1.1 404 Not Found [10:26] X-Original-Source: http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/source/by-hash/SHA256/8b81701065e3fa4957c5df3c6edc6a6f55301b7e20ac04d6a0aa19881b852320 [10:26] That sure looks like negative caching to me [10:27] /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] 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] where does this X-Original-Source come from.. [10:28] pitti: Can you find 8b81701065e3fa4957c5df3c6edc6a6f55301b7e20ac04d6a0aa19881b852320 anywhere? [10:29] no, neither with find nor with grep [10:29] Or 6966a83abdd3fc2582ee280fa45561c6a6ffa1ca37cba6e891072a98e431ce66 [10:29] also doesn't exist at all in the cache [10:29] Hmm [10:29] http://de.archive.ubuntu.com/ubuntu/dists/xenial/universe/source/by-hash/SHA256/6966a83abdd3fc2582ee280fa45561c6a6ffa1ca37cba6e891072a98e431ce66 *is* 404 [10:30] So maybe acng is configured to try de.archive in preference, and reports its 404 as if it were for archive [10:30] neither the container nor my host use de.archive [10:30] yeah, some built-in mirror selection perhaps [10:31] de.archive is presumably in /etc/apt-cacher-ng/backends_ubuntu [10:31] ah yes, it is [10:31] This must be something to do with how the Remap-* stuff works, I think [10:33] and if I drop the de. from /etc/apt-cacher-ng/backends_ubuntu then everything works [10:34] cjwatson: many thanks for finding /etc/apt-cacher-ng/backends_ubuntu! I wasn't aware that it remaps mirrors like that [10:34] 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] dholbach: maybe ca-certificates is pre-installed in VMs but not containers [10:35] pitti, ah, that might be [10:35] dholbach: armhf and s390x run in LXC; i386, amd64, and ppc64el run in scalingstack instances [10:35] so if pass/fail maps to these two sets of arches, that smells like a missing "ca-certifictes" test dep [10:35] nice catch [10:37] pitti, is this something which could be fixed in the infrastructure? should I file a bug? [10:37] dholbach: you mean cleaning up ca-certificates from instances? yes, we could do that [10:37] except on lcy01, which still doesn't allow me to build custom images as that times out [10:37] so it can't be reliable [10:37] oh... cleaning... I thought adding ;-) [10:38] well, at least make the list of packages the same, if that's possible :) [10:38] dholbach: not entirely possible, as scalingstack instances need some more packages to actually boot/work than a container [10:38] we can approximate it, though [10:38] although cf. the lcy01 bug, we run tests on the (very fat) standard cloud images there [10:39] (RT has been pending for a few months) [10:41] pitti: I followed up to https://bugs.debian.org/819852 with a summary of this [10:41] Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open] [10:41] (should appear in a couple of minutes) [10:41] cheers! [10:49] xnox, infinity: is this post-release material? https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1564918 [10:49] Launchpad bug 1564918 in glibc (Ubuntu) "glibc/s390: Save and restore fprs/vrs while resolving symbols." [High,New] [10:50] pitti, ok [10:52] 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] Launchpad bug 1563784 in Ubuntu on IBM z Systems "S390: glibc should not be configured with lock elision." [Critical,Incomplete] [10:52] the lock elision one is claimed to be critical. [10:53] 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] anyone have any idea what’s causing this? http://fpaste.org/354429/46042524/ === _salem is now known as salem_ [12:01] 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] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur, infinity [12:15] * dholbach hugs mdeslaur [12:15] * mdeslaur hugs dholbach back [12:39] Who should I talk to about akonadi's mysql backend and kubuntu? [12:58] shadeslayer: around? Not sure who to ask. [12:58] hi there [12:58] I thought I had akokadi covered with the MySQL 5.7 transition, but just realised that it hardcodes dependencies on -5.6-. [12:59] rbasak: I'm not really working on Kubuntu per se these days, but can have a look I guess, or maybe yofel [12:59] mysql-server-core-5.6 specifically. [12:59] 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] right, best to tell yofel I think [13:00] rbasak: go ahead [13:00] Thanks. [13:00] I hope it has good test coverage! [13:00] I totally missed that because the upgrade went fine as virtual-mysql-server-core covered 5.7 [13:01] Also mysql-client-core-5.6 but I'm less concerned by that. [13:01] yofel: ah so it's not actually using 5.6 right now? [13:01] (we haven't deleted 5.6 yet - still getting through the reverse deps) [13:01] not on my machine, but I also run the full server, so that probably pulled 5.7 in [13:02] OK [13:02] I'll build and dep8 test locally first. [13:02] 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] 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] yofel: my concern is any behaviour change by making it use 5.7 by default on the server. [13:05] 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] hm... right [13:09] superm1: ^^ the same applies to mythtv :-/ [13:34] rbasak: what behavior change? [13:34] it seems that 5.7 is being pulled in fine in our ISO's right now for mythbuntu [13:35] and it sounds like upgrades will just keep 5.6 and not actually transition to 5.7 right? [13:38] If you have mysql-server-5.6 and not mysql-server, yes [13:40] superm1: Some packages have had failures because 5.7 uses different default settings for sql modes, at least [13:40] 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] 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] 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] Skuggen: oh.. yeah mysql-server is what we had, so yes i guess that means upgrades will come up to 5.7 [13:59] can you make mysql-server resolve to mysql-server-5.7 | mysql-server-5.6 to avoid that happening? [14:06] superm1: we want to remove 5.6. [14:06] oh [14:06] so the hope is that 5.6->5.7 is a smooth transition then, i see [14:06] Yeah [14:06] I'm fairly confident about the upgrade path for the data. [14:06] Mostly it should be, unless you rely on the old default behavior [14:06] mysql_upgrade etc. [14:07] i.e. things like trunkating out-of-range values instead of throwing an error [14:07] Or auto-creating users that don't exist if you try to grant them privileges... [14:07] i don't think those two scenarios should affect myth stuff [14:07] 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] If you've been testing 5.7 already, then I think we'll be good. [14:08] OK [14:08] https://bugs.launchpad.net/ubuntu/+source/neutron-vpnaas/+bug/1567899 is an example of the sort of thing we've seen [14:08] Launchpad bug 1567899 in neutron "alembic migration failure with mysql 5.7" [Undecided,In progress] [14:09] Fixes are usually pretty straightforward. [14:09] (so far) [14:09] And we've touched quite a few packages now. [14:13] cyphermox: I picked the options that are in the upstart job, i. e. none [14:14] pitti: yeah, I figure, but that should have logged normally ;) [14:38] Mirv, hi, I've committed a change to qtbase's ubuntu branch that backports upstream fix for tray icons on Xubuntu/Lubuntu. [14:41] Mirv, are you planning a new upload before Xenial release? Or can I upload it on my own? [14:41] cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial-amd64/etc/localtime' are the same file [14:41] Anyone else seeing that with mk-sbuild on Xenial? [14:44] mk-sbuild runs cp -a on /etc/localtime. In my case, they *point* to the same file. [14:44] * rbasak tries -P [14:51] That worked. [14:53] 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] 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] dholbach: please run --- lxd -d ... to enable debugging [14:55] pitti, yep, I added that following https://www.piware.de/2015/12/whats-new-in-autopkgtest-lxd-maas-apt-pinning-and-more/ :) [14:56] dholbach: if you do "lxc launch lco:ubuntu/xenial/amd64 x1", does that work? [14:56] error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: no such file or directory [14:57] dholbach: seems you don't actually have lxd installed? [14:57] ouch sorry, it's been a long day already [14:57] thanks pitti [15:01] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity [15:11] elbrus: ping [15:15] apw: hey Andy [15:15] apw: still remember bug 1531768? [15:15] bug 1531768 in linux (Ubuntu) "[arm64] locks up a few minutes after booting" [Medium,Confirmed] https://launchpad.net/bugs/1531768 [15:15] 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] apw: TBH, I mainly tell you this in a public channel to coerce it to fail again :-) [15:15] pitti, :) [15:16] but yeah, trying to trigger Murphy's law deliberately fails because of Murphy's law [15:27] cjwatson, sorry to bother. bug 1505839 you suggested yesterday gfxboot-theme-ubuntu as the likely source of the issue [15:27] bug 1505839 in debian-installer (Ubuntu) "Unable to install from text mode interface" [High,Triaged] https://launchpad.net/bugs/1505839 [15:28] but that package is unmodified from vivid (works) to wily (fails) [15:28] yes, I know. syslinux/gfxboot/gfxboot-theme-ubuntu are tightly coupled though [15:28] 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] ok. yeah. that makes sense then. [15:28] but in the past, it has sometimes been the case that changes to one of those required changes to others [15:28] thanks [15:29] 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] yep [15:29] finally, gcc-5-cross-ports migrated \o/ [15:34] doko: ah yes, I was just going to tell you [15:34] infinity: ^- [15:39] 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] Mirv, so after that mine is OK for upload? Or do you want me to go through the CI Train too? [15:41] mitya57: ok, pushed, I think you could upload ubuntu8 directly too [15:41] we're only doing the QA for the vivid+overlay 5.4.1 anyway [15:41] ACK, will upload directly after that one lands [15:41] so general smoketesting would be ok [15:42] I've built that in my PPA, and some people tested the fix [15:44] Pharaoh_Atem: ping === shuduo is now known as shuduo-afk [15:56] 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] http://paste.ubuntu.com/15794227/ [15:56] Any ideas? [15:58] 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] rbasak: hmm, not off-hand; can you please file a bug with a reproducer? sorry, TB meeting now, then dinner [15:58] mitya57: I would then only publish the vivid-overlay part of 046 when it's approved [15:58] pitti: OK, np. [15:58] slangasek, kees, infinity, mdeslaur, stgraber: TB meeting reminder [15:59] Mirv, ok, will combine with ubuntu7 then [15:59] * slangasek nods [15:59] pitti: ack [15:59] Ú;#Ú;/win 8 [16:00] That's a new take on it. [16:01] mitya57: thanks [16:05] pitti: bug 1569434 [16:05] bug 1569434 in autopkgtest (Ubuntu) "adt-run fails with "dpkg-genchanges: error: cannot read ../akonadi_15.12.1-0ubuntu4.dsc: No such file or directory"" [Undecided,New] https://launchpad.net/bugs/1569434 [16:05] cheers [16:10] 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] rbasak: production just runs straight out of git, so usually git master or maybe a few commits behind [16:11] OK thanks [16:32] nacc: pong [16:36] 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] 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] they've already branched php7.0.6 [16:38] so they have [16:38] Pharaoh_Atem: ok, so the 7.0.x will be selective backporting of bugfixes from the master? [16:38] yes [16:38] nacc: https://github.com/php/php-src/blob/PHP-7.0.6/NEWS [16:38] Pharaoh_Atem: i'm just trying to get some reassurance that will be true :) [16:39] there's not much in the way of reassurance with the PHP people [16:39] but the best I can say is that they seem to be following that model for now [16:39] 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] git master is a scary place for LTS distros [16:40] historically with the php versioning scheme, it follows a structure similar to Python [16:41] where major.minor.patch is more or less supermajor.major.minor [16:43] 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] Pharaoh_Atem: ack, thanks [16:45] 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] Pharaoh_Atem: PHP has a poor track record in this area. [17:02] rbasak: *sigh* [17:03] 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] 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] 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] that tracks upstream's stable -fixes branch [17:11] but i think virtual-mysql-server should still resolve that properly [17:12] 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] That's the sort of the reason I had in mind for not touching it :) [17:13] Actually [17:13] I'm sorry. [17:13] That upload probably wasn't needed at all in that case. [17:13] It's an alternative. Sorry, my fault. === damascene is now known as az [17:38] tsimonq2: just to be clear, do you mean the missing articles throughout the document? (the, a)? [17:41] nacc: huh [17:41] *huh? [17:42] tsimonq2: re: php7.0 serverguide review [17:42] ohhhhh [17:42] tsimonq2: sorry :) [17:42] no it's alright :) [17:43] what specifically are you talking about? have you read my inline comments? [17:43] tsimonq2: yeah, the ones that all refer to l130 review, i'm just trying to understand what you meant :) [17:44] nacc: i'm lost or i'd know what you and simon were talking about (saw 'php7.0' and 'serverguide') [17:44] teward: he submitted an MP to the server guide [17:44] teward: i'm submitting a MP to fix up server guide [17:44] links are nice [17:44] relating to PHP [17:44] https://code.launchpad.net/~nacc/serverguide/php7.0/+merge/291655 [17:44] nacc: so basically what I meant was to keep it consistent when referring to the terminal [17:45] tsimonq2: you mentioned "weird wording" -- most of what i have found is missing "the"s or "a"s [17:45] tsimonq2: oh i see! === afkthairus is now known as athairus [17:45] tsimonq2: is there a standard preferred way to refer to it? [17:46] tsimonq2: there's a comment inbound from me [17:46] nacc: I don't know anything specific, maybe you have an idea, but it just looked weird :) [17:46] teward: alright :) [17:46] tsimonq2: ack ... i will at least make it consistent [17:46] nacc: and it's not all line 130 [17:46] :) [17:47] teward: Pharaoh_Atem: we should also document fpm, no? [17:47] teward: and nginx and php? [17:47] nacc: nginx will come later [17:47] teward: k [17:47] we can probably add that later [17:47] nacc: did you draft Release Notes items for php7.0? [17:47] tsimonq2: right, i just meant a bunch of comments (afaict) were "see l130" -- wanted to clarify that [17:47] teward: nope, on my todo for today [17:47] teward: having not done it before, do you have a pointer to where is tart? [17:48] *i start [17:48] 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] nacc: well, we have php7.0-fpm configs available now [17:48] so why not? [17:48] rbasak: --^ ? any pointers to where to start for php7.0 release notes? [17:48] 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] nacc: though if you feel comfortable linking to my blog, i"ll have something posted for it by Saturday [17:49] Pharaoh_Atem: care to write something up? and send a MP? [17:49] nacc: maybe https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes for style? [17:49] teward: reiterating my point ;) [17:49] rbasak: thanks [17:49] And similar URL scheme for previous releases. [17:49] tsimonq2: actually, correcting your suggestion. [17:49] tsimonq2: E:BadGrammar [17:49] nacc: you can also edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes directly. [17:49] (which we'll do in the end when transferring from bugs anyway) [17:49] teward: oh :P [17:49] tsimonq2: switch PHP Apache for Apache PHP [17:49] yep ack [17:49] nacc: how exactly do I do this? [17:49] teward: ack [17:50] https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Ubuntu_Server is blank right now :) [17:50] lol [17:50] ruh roh [17:50] Pharaoh_Atem https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/UbuntuServerGuide [17:50] 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] teward: yes - no longer applicable to nginx, right? [17:51] rbasak: correct - HTTP/2 is in Xenial [17:51] as of 1.9.14 [17:51] and tested to confirm it works [17:51] Great. Thanks! [17:51] thanks to infinity asking for OpenSSL tests :P [17:51] rbasak: you're welcome. [17:51] 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] Pharaoh_Atem: luckily it's not tied to the release schedule, afaict [17:51] Pharaoh_Atem: so when/if you can [17:52] certainly [17:52] Pharaoh_Atem: it seems like a nice-to-have documentation [17:52] well, it's a good thing to have [17:52] we want people not using mod_php7.0 as much as possible [18:03] 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] I'd say "at" [18:09] rbasak: ack, thanks [18:16] tsimonq2: can i push to the same branch to update the merge, or do i need to request a new merge? [18:16] with a corresponding new branch [18:19] nacc: "at" [18:19] nacc: BTW, nginx + php7.0 data at http://dark-net.net/?p=125 [18:19] i'll set up a 'nice link' when i'm not busy beating the Internet to death for being laggy [18:19] that's also aggregated on Planet [18:20] 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] (also Planet aggregated) [18:20] teward: ack, updated locally, pending an answer to my last question for a fresh MP [18:20] teward: they have trusty for that [18:20] nacc: yes, but you know the people who 'must have the latest' [18:20] >.> [18:21] teward: inasmuch as I don't know what "back" is in this context; there is no "back" :) [18:21] teward: as you suggest in the post, you can use a PPA, but then you're relying on the PPA's owner [18:21] indeed [18:21] nacc: i was just giving you an FYI [18:21] no need to include it in release notes [18:22] but linking to my post regarding the php7.0 transition, and updating existing sitei configs is still relevant [18:22] 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] indeed. [18:23] 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] 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] nacc: ah, cool, let me know how that goes :) [18:23] teward: it was rbasak's suggestion (sort of) [18:24] indeed [18:28] tsimonq2: fyi, the tabulation issue is inconsistency in the file itself (tabs vs. spaces) [18:30] tsimonq2: add that to the list - "fix indentation inconsistencies" [18:30] you've just given yourself that task :P [18:31] 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] nacc: i didn't see that question. #launchpad may be able to help? [18:32] teward: np, good point [18:44] nacc: does libapache2-mod-php exist as an installable object in Xenial? [18:44] teward: yes, it's a virtual pkg that depends on libapache2-mod-php7.0 [18:44]