| 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" | 01:56 |
|---|---|---|
| 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:01 |
| 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. | 02:02 |
| === pavlushka is now known as Guest78383 | ||
| === Guest78383 is now known as pavlushka | ||
| mwhudson | xnox: re https://launchpad.net/ubuntu/+source/software-properties/0.96.24.6, gnupg1 is in universe, what's the plan there? | 04:57 |
| pitti | Good morning | 05:40 |
| cpaelzer | Good morning | 05:48 |
| 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? | 06:42 |
| pitti | Mirv must have gotten up, autopkgtest infra is getting Qt'ed again :-P | 07:40 |
| andrewsh | pitti: could you please have a look at #835648? | 08:08 |
| ginggs | andrewsh: LP or BTS ? | 08:13 |
| Unit193 | That number is BTS. | 08:13 |
| Unit193 | Debian #835648 | 08:13 |
| 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:14 |
| Mirv | pitti: mornings! :) | 08:26 |
| Mirv | or lunch time actually | 08:26 |
| === enrico_ is now known as enrico | ||
| andrewsh | ginggs, pitti: yes, I meant BTS, sorry for the confusion | 08:37 |
| Unit193 | andrewsh: Well pretty sure you weren't talking about a bug in tomboy about 'Ubuntu One' | 08:38 |
| andrewsh | :) | 08:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| andrewsh | as it says No such file or directory | 08:45 |
| 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 ] ? | 08:59 |
| andrewsh | pitti: maybe | 09:00 |
| andrewsh | I don't understand the reason though | 09:00 |
| andrewsh | wpa_supplicant is still running | 09:00 |
| 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:22 |
| doko_ | kenvandine: please could you prepare your MIR's on yakkety? it's not that we wouldn't have work enough already | 09:51 |
| xnox | mwhudson, good point. | 10:01 |
| 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:07 |
| 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:08 |
| doko_ | pitti: about #1622893, I don't think downgrading the gnutls is an option | 10:09 |
| 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:11 |
| 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 | 10:12 |
| === oSoMoN_ is now known as oSoMoN | ||
| 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:27 |
| 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:30 |
| Unit193 | xnox: Also on that note, LP should upgrade them and use the new-ish Signed-By field! :P | 10:35 |
| === G_ is now known as G | ||
| xnox | Unit193, is there an LP bug open about that? | 10:36 |
| Unit193 | xnox: I presume other than 1331914? | 10:37 |
| directhex | who's in charge of the ppc64le port, nominally? presumably there's someone at IBM spearheading that? | 11:01 |
| doko_ | cyphermox, mwhudson, slangasek: accepted subquity. are the hardcoded python2 dependencies in subiquity-tools really intended? | 11:11 |
| mwhudson | doko_: seems unlikely to me | 11:14 |
| 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:19 |
| mwhudson | doko_: thanks | 11:21 |
| doko_ | xnox: gnupg1 is in component-mismatches now. promote it? | 12:03 |
| 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:04 |
| doko_ | xnox: subscribed foundations and promoted | 12:09 |
| === _salem is now known as salem_ | ||
| 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:24 |
| arges | pitti: hmm... usually sru-review warns me when that's the case | 12:30 |
| 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:31 |
| arges | pitti: also I think the network-manager autopkgtest regression is a false negative. | 12:34 |
| 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:36 |
| 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:41 |
| arges | pitti: ok | 12:42 |
| 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.) | 13:00 |
| === xclaesse` is now known as xclaesse | ||
| smoser | Odd_Bloke, hm.. | 13:09 |
| 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:10 |
| smoser | Odd_Bloke, ok. let me look some. | 13:12 |
| 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:15 |
| 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:16 |
| 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:22 |
| 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:23 |
| 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:24 |
| pitti | journal would be good to see too | 13:28 |
| smoser | pitti, well, you can ask me , or you can try it :) | 13:33 |
| smoser | i can get it to you. | 13:33 |
| 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:34 |
| smoser | released image seems fine too | 13:35 |
| 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:37 |
| smoser | Odd_Bloke, does that make sense ? | 13:38 |
| smoser | you're hitting a bug that we've fixed. | 13:38 |
| Odd_Bloke | smoser: Yep, that definitely makes sense; newer image as the base works fine. :) | 13:40 |
| smoser | yeah, but its more than just "its fixed because there are no upgrades to do" | 13:41 |
| 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 :) | 13:42 |
| Odd_Bloke | smoser: Yep, understood; we're still installing a bunch of packages and we've stopped seeing failures. | 14:08 |
| pitti | smoser: oooh! yes, that makes perfect sense | 14:10 |
| pitti | (sorry, was OTP for a long time) | 14:10 |
| === Daviey_ is now known as Daviey | ||
| pitti | smoser, Odd_Bloke: so that means people upgrading from xenial after that SRU lands should *not* run into this | 15:08 |
| pitti | and people upgrading from intra-yakkety, well, yeah, tough luck :) | 15:09 |
| 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:28 |
| 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:29 |
| 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:30 |
| nacc | bipul: wrong channel? | 15:31 |
| bipul | oh yes, sorry | 15:31 |
| semiosis | nacc: Odd_Bloke: so we wait a few more days? | 15:31 |
| 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:32 |
| 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:34 |
| Odd_Bloke | Then go for it. :) | 15:35 |
| semiosis | done. thanks! | 15:36 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| cjwatson | nacc: did you consider python-pygit2? | 15:57 |
| cjwatson | nacc: that's what the git.launchpad.net backend uses | 15:57 |
| nacc | cjwatson: interesting, i'll take a look -- i was trying to use python3 :) | 15:58 |
| cjwatson | nacc: python3-pygit2, then :) | 15:58 |
| 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 | 15:59 |
| 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:00 |
| nacc | no problem, ole! | 16:01 |
| rbasak | A perfect example of why using public channels is good. Thanks cjwatson :) | 16:01 |
| 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:02 |
| 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:23 |
| 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:26 |
| 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] | 16:29 |
| === elbrus_ is now known as elbrus | ||
| === marga_ is now known as marga | ||
| nacc | Pharaoh_Atem: ping | 18:59 |
| 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:00 |
| Pharaoh_Atem | isn't fpm supposed to just fail anyway? | 19:01 |
| Pharaoh_Atem | I'm not sure how to fix it if it's not working | 19:02 |
| nacc | Pharaoh_Atem: well, i would have expected fpm to fail, but it doesn't :) | 19:04 |
| Pharaoh_Atem | :S | 19:05 |
| * Pharaoh_Atem grumbles about php | 19:05 | |
| nacc | Pharaoh_Atem: -t definitely says a line like '# abcd (' is a 'syntax error', but the service still runs | 19:06 |
| 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:08 |
| Pharaoh_Atem | nacc: I could have sworn that php-fpm has it's own method for checking these things | 19:11 |
| 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:33 |
| 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:34 |
| 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:39 |
| 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:40 |
| 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 | :) | 19:41 |
| tumbleweed | win 33 | 20:17 |
| pitti | smoser: sorry, was just gone for dinner and basketball, looking | 20:22 |
| smoser | pitti, you are allowed to walk away from the computer | 20:23 |
| smoser | just not for more than 6 minutes | 20:23 |
| 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:24 |
| pitti | smoser: 6 minutes? *now* I know what "fast food" means! | 20:27 |
| === salem_ is now known as _salem | ||
| mwhudson | arges: done | 23:28 |
| 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 | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!