| === Guest48238 is now known as RAOF | ||
| hallyn | is there a problem with the ppa upload ftp server? (like disk full) it keeps telling me my upload has a md5sum mismatch | 03:32 |
|---|---|---|
| === handsome_feng is now known as LinusBenedictTor | ||
| === LinusBenedictTor is now known as handsome_feng | ||
| pitti | Laney: good morning! | 05:16 |
| pitti | Laney: http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream xenial-amd64 is stuck in an eternel retry loop; I switched that yesterday to build from https://git.launchpad.net/~pitti/systemd/+git/debian#biebl/meson , i. e. from the biebl/meson branch | 05:16 |
| pitti | Laney: I think it actually runs through to the very end, maybe there is some exception on uploading the results, due to the '#' somewhere? I don't think this has been used very often so far; could you please check the logs if you see the exception? | 05:17 |
| rbalint | does anyone know how i could add comments to https://merges.ubuntu.com/main.html ? | 07:46 |
| rbalint | i would like to add the BTS bug numbers for the forwarded deltas | 07:46 |
| sil2100 | rbalint: hm, I suppose you might not have the required permissions to do that, maybe only people with upload rights can comment | 07:49 |
| sil2100 | Since it seems to work for me | 07:49 |
| sil2100 | rbalint: what do you want to have added and where? | 07:49 |
| rbalint | sil2100: so far: | 07:49 |
| * sil2100 wasn't aware those needed any permissions but well | 07:51 | |
| rbalint | sil2100, all: hah, there is an invisible textbox in the comment column! :-) | 07:54 |
| sil2100 | Yes ;) | 07:54 |
| rbalint | sil2100: thanks! :-) | 07:54 |
| sil2100 | It's not really intuitive | 07:54 |
| sil2100 | np! | 07:55 |
| sil2100 | I guess that's ACL-through-obscurity ;p | 07:55 |
| === marcusto_ is now known as marcustomlinson_ | ||
| === JanC is now known as Guest35192 | ||
| === JanC_ is now known as JanC | ||
| Laney | pitti: i'll look | 08:14 |
| Laney | meh | 08:17 |
| Laney | some of the messages were eaten by the rate limiter | 08:17 |
| pitti | Laney: there should be plenty since yesterday morning, though; all of them are cut? :( | 08:18 |
| Laney | doing more paging | 08:18 |
| Laney | Apr 26 08:24:22 juju-prod-ues-proposed-migration-machine-3 sh[12701]: novaclient.exceptions.ClientException: An unexpected error prevented the server from fulfilling your request. (OperationalError) | 08:20 |
| Laney | Apr 26 08:24:22 juju-prod-ues-proposed-migration-machine-3 sh[12701]: No UUID given. Instance won't be deleted! | 08:21 |
| Laney | Apr 26 08:24:22 juju-prod-ues-proposed-migration-machine-3 sh[12701]: <VirtSubproc>: failure: setup script failed with code 1: /home/ubuntu/autopkgtest/ssh-setup/nova open --flavor autopkgtest --nam | 08:21 |
| Laney | but that one failed almost immediately | 08:21 |
| Laney | meh | 08:41 |
| Laney | let me just run one interactively | 08:41 |
| Laney | I see a few reboot timeouts | 08:41 |
| cjwatson | hallyn: it has a couple of TB free; but it looks like you managed to produce an upload it accepted eventually? | 09:22 |
| pitti | Laney: hmm, no 'Three tmpfails in a row'? Some of these have retried since yesterday | 09:26 |
| === CRogers_________ is now known as CRogers | ||
| pitti | http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 is definitively fishy.. | 09:28 |
| Laney | pitti: yes, they end in timeouts | 09:31 |
| pitti | Laney: oh, in the boot-smoke test? I ran the complete suite here, with the production autopkgtest command, and it worked well | 09:32 |
| pitti | but a test timeout shouldn't count as a tmpfail | 09:32 |
| Laney | sec | 09:32 |
| Laney | pitti: Apr 27 08:48:47 juju-prod-ues-proposed-migration-machine-3 sh[656]: <VirtSubproc>: failure: timed out waiting for testbed to reboot | 09:37 |
| Laney | Apr 27 08:48:47 juju-prod-ues-proposed-migration-machine-3 sh[656]: autopkgtest [08:48:41]: ERROR: testbed failure: unexpected eof from the testbed | 09:37 |
| Laney | that is in boot-smoke | 09:37 |
| pitti | hmm, interesting; that's the bit which I can't seem to reproduce with qemu; thanks for digging it out | 09:38 |
| pitti | Laney: I reverted the web hook back to the autoconf build system; could you please prune the meson-y bits from http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 to put the infra out of its misery? | 09:41 |
| Laney | pitti: yeah | 09:41 |
| Laney | you think meson could have provoked this? | 09:42 |
| Laney | some different CFLAGS or something? | 09:42 |
| pitti | not sure why -- as I said, it works fine with xenial QEMU, and the exact same repos | 09:42 |
| pitti | (and PPAs, etc.) | 09:42 |
| pitti | autopkgtest --setup-commands 'apt-key adv --keyserver keyserver.ubuntu.com --recv-key FB322597BBC86D52FEE950E299B656EA8683D8A2' --setup-commands 'REL=$(sed -rn "/^(deb|deb-src) .*(ubuntu.com|ftpmaster)/ { s/^[^ ]+ +(\[.*\] *)?[^ ]* +([^ -]+) +.*$/\2/p; q }" /etc/apt/sources.list); echo "deb http://ppa.launchpad.net/pitti/systemd-semaphore/ubuntu $REL main" > | 09:42 |
| pitti | /etc/apt/sources.list.d/autopkgtest-pitti-systemd-semaphore.list; echo "deb-src http://ppa.launchpad.net/pitti/systemd-semaphore/ubuntu $REL main" >> /etc/apt/sources.list.d/autopkgtest-pitti-systemd-semaphore.list;' --apt-upgrade 'https://git.launchpad.net/~pitti/systemd/+git/debian#biebl/meson' --env=CFLAGS=-O0 --env=DEB_BUILD_PROFILES=noudeb --env=TEST_UPSTREAM=1 --env=UPSTREAM_PULL_REQUEST=5704 -- | 09:42 |
| pitti | qemu /srv/vm/autopkgtest-xenial-amd64.img | 09:42 |
| Laney | I would have expected a more obvious failure from switching this :/ | 09:43 |
| pitti | yeah, and there were plenty ;) | 09:43 |
| Laney | my test run got to boot-smoke now | 09:43 |
| Laney | I'll let it run through that and then kill all the things | 09:43 |
| pitti | the CFLAGS are very similar now, just some minor differences in linking | 09:44 |
| pitti | but up to boot-smoke it actually does a handful of reboots already, and it seems they are just fine | 09:44 |
| pitti | so no immediate idea, I'm afradi | 09:45 |
| Laney | pitti: http://people.canonical.com/~laney/weird-things/log.xz in case that's helpful | 09:58 |
| pitti | Laney: thanks | 10:05 |
| Laney | pitti: want to resubmit a job, for validation? | 10:09 |
| pitti | Laney: done, triggered https://github.com/systemd/systemd/pull/5815 on xenial-amd64 (I reverted the meson webhook change, should be the normal barnch now) | 10:10 |
| Laney | merci, let's see what happens | 10:10 |
| pitti | I see it in the queue,after the snap tests; thanks for your help! | 10:11 |
| pitti | Laney: I'd run a meson test on s390x, let's see if it works there | 10:11 |
| Laney | you did, or you want me to? | 10:12 |
| pitti | I will | 10:12 |
| * Laney nod | 10:12 | |
| xnox | juliank, once we fix xenial+, it will be fun to backport this to trusty. we have a bit more data trusty-updates is the culprit with a clear 30min window. | 10:13 |
| juliank | xnox: Well, it only works because we have systemd on xenial. Working around this on trusty would not be a wise idea IMO. I guess you could just move the cron job to run hourly or so instead, that would distribute load based on when systems are turned on due to apts stamp files | 10:54 |
| juliank | And rename the cron job to zzzapt | 10:55 |
| juliank | (So it runs last) | 10:55 |
| juliank | That is, after you split it like now | 10:55 |
| juliank | and keep upgrade as daily | 10:55 |
| juliank | (though, not sure if upgrade might be failing then) | 10:56 |
| xnox | juliank, i thought to do the whole lot. Split update+download and upgrade; and schedule the first one to be @daily; whilst the upgrade at the 6..7am window | 10:56 |
| juliank | xnox: Well @daily runs at 6 in cron ... | 10:57 |
| xnox | that should work with anacron, or was the bug with anacron that it schedules all @daily jobs at 6? | 10:57 |
| xnox | right, yeah. | 10:57 |
| juliank | *I* wouldn't change it, seems dangerous to build this logic in there | 10:58 |
| juliank | Load hopefully reduces automatically eventually, as people migrate to xenial | 10:59 |
| bdrung_work | infinity, regarding ddeb in artful, will you keep the .ddeb suffix or will it be dropped? reprepro stumbles over the .ddeb file extension. | 11:19 |
| bdrung_work | https://bugs.launchpad.net/ubuntu/+source/reprepro/+bug/799889 | 11:19 |
| ubottu | Launchpad bug 799889 in reprepro (Ubuntu) "fails to import ddeb packages" [Undecided,Confirmed] | 11:19 |
| xnox | juliank, yeah trusty is hard. ha, you would think the load minimises, wouldn't you? people on xenial, are those that upgraded from precise. | 11:20 |
| xnox | juliank, we are expecting trusty users to only upgrade to 18.04. | 11:20 |
| xnox | 5 year support cycles, with LTS every 2 years are wonderful, as we only have half the people upgrade to each LTS. | 11:21 |
| cjwatson | bdrung_work: dropping it would be a lot of work in LP | 11:22 |
| cjwatson | we argued against Debian using the .deb extension for this at the time ... | 11:22 |
| cjwatson | (possibly non-trivial work in apport as well, but I don't know about that) | 11:23 |
| pitti | changes in apport would be fairly small | 11:36 |
| pitti | in fact, an one-line change in the special case for installing kernel debug symbols | 11:36 |
| pitti | (apport by and large works on Debian too) | 11:37 |
| pitti | Laney: amd64 succeeded; and s390x finished as well (with a failure, but that's our problem) | 11:53 |
| juliank | xnox: So, units ran for me as expected. Not sure if I actually enabled any settings though, but at least the timing works :D | 12:06 |
| Laney | pitti: ok, thanks - sorry it's breaking with meson :( | 12:12 |
| === CRogers_________ is now known as CRogers | ||
| mdeslaur | Is something special required to upload to artful? My upload is getting rejected because of a GPG verification failure of the .buildinfo file... | 12:55 |
| cjwatson | Do you have current devscripts? | 12:56 |
| cjwatson | You might possibly have a dpkg-dev that's new enough to generate .buildinfo, but not a devscripts that's new enough to sign it | 12:56 |
| mdeslaur | I'm running whatever devscripts is in xenial, so I guess not | 12:56 |
| cjwatson | And a newer dpkg-dev? | 12:57 |
| cjwatson | Maybe you're doing build-source-package-in-chroot or something | 12:57 |
| mdeslaur | oh, probably, yes | 12:57 |
| cjwatson | We might consider weakening the buildinfo-must-be-signed requirement; file an LP bug? | 12:57 |
| cjwatson | but signing with testing's or artful's devscripts should work fine | 12:58 |
| pitti | hm, isn't that useful for reproducible builds? | 12:58 |
| pitti | I mean, certifying its correctness | 12:58 |
| cjwatson | Yeah, it is | 12:58 |
| cjwatson | Hence me only saying "consider" :) | 12:58 |
| mdeslaur | well, I'm signing on xenial...so I assume I need to install artful's devscripts in xenial? | 12:59 |
| cjwatson | Possibly we should SRU the buildinfo signing change to devscripts instead | 12:59 |
| cjwatson | I sometimes run debsign in an schroot with my homedir mounted | 12:59 |
| cjwatson | I think the relevant debsign changes were in devscripts 2.17.{2,3,4}, if somebody wants to look into that | 13:00 |
| xnox | mdeslaur, hm, i usually build my source packages with no clean on my host system; and sign that. | 13:12 |
| xnox | if there are crazy stuff that e.g. ./debian/rules clean generates for the source package, i run that in the chroot; but then do debuild -S -nc on my host, and sign that. | 13:12 |
| xnox | so far i have been managing to build source packages and upload them from xenial like that. | 13:13 |
| smoser | hm.. | 13:16 |
| smoser | so i just realize that many things (at least those of my authorship) use distro-info to indicate if a release is supported. | 13:17 |
| smoser | and, at this current time, they all say that 12.04 is not supported | 13:17 |
| smoser | how should we handle that ? | 13:17 |
| smoser | with regard to https://insights.ubuntu.com/2017/03/14/introducing-ubuntu-12-04-esm-extended-security-maintenance/ | 13:17 |
| pitti | well, wrt. to the world in general it isn't, right? just for some paying customers, who then need access to a private PPA? | 13:19 |
| Son_Goku | smoser: imho, you should leave it as is | 13:19 |
| Son_Goku | generally speaking, you're not supporting precise anymore | 13:19 |
| pitti | it would be far more confusing to declare it as supported in public distro-info IMHO | 13:19 |
| smoser | Son_Goku, thats a solutino, yes. but the specific thing i realized was with regard to creation of metadata on images produced in cloud-images.ubuntu.com . | 13:20 |
| smoser | w | 13:20 |
| Son_Goku | they should be marked as unsupported | 13:20 |
| Son_Goku | because they are | 13:20 |
| smoser | which seems like it shoudl still be updated (or people would get old images) | 13:21 |
| Son_Goku | I'm certain Canonical has another avenue for ESM customers | 13:21 |
| Son_Goku | let 12.04 die with some grace | 13:21 |
| xnox | infinity, distro-info-data claims precise EOL is 26th, when it is 28th. And also things have started to claim that precise is EOL... do we need to add eol-esm into the distro-info-data csv? | 13:26 |
| mdeslaur | xnox: and MOTD says "Ubuntu 12.04 LTS end-of-life is April 25, 2017 -- Upgrade your Precise systems!" | 13:27 |
| mdeslaur | so many different dates! :) | 13:27 |
| xnox | such that things can check if they are on ESM or not. Or e.g. does ESM repository ship an updated distro-info-data with tweaked dates to point at end of ESM | 13:27 |
| xnox | 25 -> because of 26th April UTC to your local time conversion? | 13:27 |
| hallyn | cjwatson: yeah; it's possible it was network on my end, but it thought it succeeded every time | 13:31 |
| mdeslaur | xnox: https://motd.ubuntu.com/ | 13:32 |
| zhhuabj | hi cpaelzer | 13:33 |
| cpaelzer | hi zhhuabj | 13:36 |
| cpaelzer | whats up zhhuabj | 13:36 |
| cpaelzer | new SRUs around the corner? | 13:36 |
| zhhuabj | cpaelzer, yeah :) could you help nominate this bug to xenial - https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1686679 | 14:02 |
| ubottu | Launchpad bug 1686679 in autofs5 (Ubuntu) "[SRU] Ubuntu16.04 : autofs takes extreamly long with large number of direct maps" [Undecided,New] | 14:02 |
| cpaelzer | zhhuabj: let me read what it is | 14:05 |
| zhhuabj | cpaelzer, ok | 14:07 |
| cpaelzer | zhhuabj: I nominated, but you need to work on your patch - I documented all in the bug as I'm soon unavailable due to meetings | 14:26 |
| slashd | o/ morning rbasak, did you have the time to look at my recent Xenial debdiff for isc-dhcp (LP: #1176046) update since last time we speak (last week) about some modifications you request me to perform ? | 14:51 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046 | 14:51 |
| zhhuabj | cpaelzer, ok, thanks | 14:59 |
| rbasak | slashd: sorry, not yet | 15:01 |
| slashd | rbasak, no problem, note that I'll out starting tomorrow EOD for 2 weeks, but if you update the LP and I'll be notify by email which I'll check regularly. | 15:02 |
| slashd | rbasak, tks | 15:03 |
| rbasak | ack | 15:04 |
| juliank | xnox: slangasek: So I played a bit with the services and it seems that daily-upgrade waits for daily to complete, but if daily-upgrade is running, daily would start too (and then fail and retried 12 hours later) | 16:19 |
| juliank | I guess that works out OK | 16:20 |
| xnox | nah, that's not ok. | 16:20 |
| xnox | between dpkg runs within an upgrade; apt update can come in and steal a lock. | 16:20 |
| xnox | i used to have this happen before with e.g. desktop packgekit updates / apt gui package manager | 16:21 |
| juliank | xnox: This can't happen anymore since the last round of SRUs | 16:21 |
| xnox | juliank, nice! | 16:21 |
| juliank | xnox: But well on trusty it can, but maybe you can backport it there too :) | 16:22 |
| juliank | * don't lock dpkg in 'apt-get clean' | 16:22 |
| juliank | * don't lock dpkg in update commands | 16:22 |
| juliank | Soon we will add one more lock file to dpkg itself, then this also can't happen even if we overlooked something somewhere else :D | 16:23 |
| juliank | (and with other applications) | 16:24 |
| juliank | (That's https://lists.debian.org/debian-dpkg/2017/01/msg00044.html) | 16:25 |
| juliank | xnox: I guess I should add Also=apt-daily-upgrade to the apt-daily ones, so systemctl disable for apt-daily.timer also disables the upgrade one | 16:27 |
| xnox | juliank, hm. but that is a two way thing, and one will not be able to unable daily.timer without the upgrade one. | 16:29 |
| powersj | xnox: thanks for merging the artful ISO tests | 16:29 |
| xnox | as install will unable the upgrade too, no? | 16:30 |
| xnox | powersj, no problem. now need to fix static validation in utah, send merge proposal but do not have powers to do anything else about it. | 16:30 |
| juliank | I guess you could manually run systemctl disable apt-daily-upgrade, but if you run systemctl enable apt-daily it would be reenabled? | 16:30 |
| slangasek | juliank, xnox: so I explicitly don't want daily to fail and retry 12 hours later if daily-upgrade is still running, I want it to wait for daily-upgrade to release the lock and run immediately (in part because I don't think we should run twice a day ;) | 16:31 |
| xnox | juliank, i will be testing it extensively tomorrow; i got to run soon today. And we don't publish srus on friday, so it may be best to iron any issues tomorrow, and to do srus next week. | 16:31 |
| xnox | juliank, yes. | 16:31 |
| powersj | xnox: Yeah, got a merge up here https://code.launchpad.net/~powersj/utah/remove_cdromupgrade/+merge/323337 | 16:31 |
| xnox | powersj, that is another thing; i have a branch for wubi | 16:34 |
| juliank | slangasek: I get that you don't want to run twice a day. Maybe we will eventually, but I think this needs some more planning. And we should try to get a clear improvement now. I guess we can easily do a wait-lock thingy by just wrapping the script invocation in a flock run | 16:35 |
| juliank | ExecStart=/usr/bin/flock -w 3600 /var/lib/apt/apt-daily.flock /usr/lib/apt/apt.systemd.daily | 16:37 |
| * juliank will also be off in about 20-30 minutes to watch guardians of the galaxy volume 2 | 16:40 | |
| juliank | Eww, flock leaks the file descriptor into the child | 16:43 |
| * juliank is not sure if that causes issues, I think we close all fds in apt | 16:43 | |
| juliank | Ah, we can drop -w and make it wait indefintely | 16:44 |
| juliank | I played with Conflicts and now systemd is all like "Looping too fast. Throttling execution a little." | 16:50 |
| juliank | Anyway, I'll continue playing with stuff tomorrow, and shut down now :) | 16:52 |
| gQuigs | can I get an SRU upload, please - https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1673579 | 17:55 |
| ubottu | Launchpad bug 1673579 in pcs (Ubuntu Xenial) "Corosync/Pacemaker: Error when enabling Pacemaker service,Error when starting the cluster " [Low,In progress] | 17:55 |
| nacc | gQuigs: looking | 17:57 |
| nacc | gQuigs: debdiff doesn't close the bug and teh version is not as expected (https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging) | 17:59 |
| nacc | gQuigs: 0.9.149-1ubuntu1.1 rather than ubuntu2 | 17:59 |
| nacc | it doesn't matter in this case, but for consistency with our documentation :) | 18:00 |
| nacc | gQuigs: are you ok if i change those locally? | 18:00 |
| gQuigs | nacc: sure, thanks! | 18:00 |
| gQuigs | nacc: does the version number thing apply to SRUs? that wiki page seems focused on security, /me trying to understand for next time | 18:02 |
| nacc | gQuigs: it doesn't explicitly apply to SRUs, but their policy always give sane version numbers | 18:03 |
| nacc | gQuigs: e.g., if you were SRU'ing the same version back to multiple versions | 18:03 |
| nacc | gQuigs: so it's just one less thing I (as sponsor) have to think about :) | 18:03 |
| gQuigs | gotcha, will bookmark that for later | 18:03 |
| nacc | gQuigs: since if 1ubuntu2 was in yakkety, then your version would definitely be wrong (but that's why it's technically fine in this case) | 18:03 |
| gQuigs | oh, got it | 18:04 |
| nacc | gQuigs: I'm also not an SRU team member, but I have been referred to that page in the past, so I think it's a good policy to follow | 18:04 |
| nacc | slangasek: can you release src:php7.1 from the new queue for artful? | 18:13 |
| slangasek | nacc: I can at least look at it! | 18:14 |
| slangasek | nacc: I'm confused, why is it back in new? I thought we already had php7.1 in -proposed | 18:15 |
| nacc | slangasek: yeah i'm not sure what happened, i looked yesterday and rmadison said it wasn't in ubuntu at ll | 18:18 |
| nacc | *all | 18:18 |
| nacc | slangasek: but it was earlier this week (per rmadison) | 18:19 |
| nacc | slangasek: is it possible changing that bug's state caused something to delete it? | 18:19 |
| slangasek | "deleted 18 hours ago by Ubuntu Archive Robot: moved to release" | 18:19 |
| slangasek | except wasn't | 18:19 |
| nacc | slangasek: strange! | 18:19 |
| slangasek | https://launchpad.net/ubuntu/+source/php7.1/+publishinghistory | 18:19 |
| === _salem is now known as salem_ | ||
| nacc | slangasek: duh, i didn't even think to look there last night | 18:20 |
| slangasek | infinity, cjwatson: ^^ FYI, lp claims php7.1 was "moved to release" but it never made it there; not sure if that was an lp bug or a p-m bug | 18:20 |
| infinity | Grr. That's the bug I filed. | 18:21 |
| slangasek | which'un? | 18:21 |
| infinity | LP: #1685672 | 18:21 |
| ubottu | Launchpad bug 1685672 in Launchpad itself "Copies with binaries from artful to artful-proposed fail if package was built in older release" [Undecided,New] https://launchpad.net/bugs/1685672 | 18:21 |
| slangasek | k | 18:21 |
| infinity | (Bug applies in the other direction too, obviously) | 18:21 |
| nacc | infinity: interesting, thanks for the pointer | 18:22 |
| infinity | slangasek: You can fix it by manually copying from zesty-proposed with exact version. | 18:22 |
| infinity | (to artful) | 18:22 |
| nacc | infinity: it's not in z-p either | 18:22 |
| infinity | nacc: It was. | 18:22 |
| nacc | yeah, but pubhistory says you deleted it to move it to a-p | 18:22 |
| infinity | copyPackage() is magic. | 18:22 |
| slangasek | nacc: you can do magic copies of deleted things | 18:22 |
| nacc | oh ok :) | 18:22 |
| slangasek | but in this case I'll just release your new sync | 18:22 |
| infinity | nacc: *you* can't fix it, cause you can't copy to the release pocket, but slangasek or I can fix it. | 18:22 |
| nacc | infinity: ah, AA magic, got it :) | 18:23 |
| slangasek | actually, I will do the magic copy as well so that we might skip binary new | 18:23 |
| nacc | slangasek: ack, thanks | 18:23 |
| infinity | Where is this new sync you're "releasing"? | 18:24 |
| infinity | Or you mean just doing in general? | 18:24 |
| slangasek | infinity: it was synced to artful-proposed and landed in new | 18:24 |
| slangasek | infinity: new version from Debian | 18:24 |
| slangasek | it is no longer in new | 18:24 |
| infinity | Oh, and already accepted. That was the confusion. | 18:25 |
| infinity | slangasek: And it's gone to main in the process, I guess? | 18:26 |
| slangasek | infinity: I did that, yes | 18:27 |
| nacc | infinity: if it hasn't, that's my next step and i'll need to upload a new php-defaults to change all the src:php-defaults deps to php7.1 | 18:27 |
| slangasek | (pre-emptive on my part) | 18:27 |
| nacc | at which point, i believe we can demote php7.0 and remove it | 18:27 |
| nacc | slangasek: thanks! :) | 18:27 |
| === stgraber_ is now known as stgraber | ||
| nacc | slangasek: just uploaded the delta which should allow php7.1 to migrate through and fix the c-m | 19:55 |
| === salem_ is now known as _salem | ||
| === Serge is now known as hallyn | ||
| === jdstrand_ is now known as jdstrand | ||
| rbasak | lamont, ScottK: seen https://scotthelme.co.uk/nomx-the-worlds-most-secure-communications-protocol/ ? Thought you might be interested (well, amused). Also, https://news.ycombinator.com/item?id=14209874 | 21:27 |
| === ubott2 is now known as ubottu | ||
| === wxl_ is now known as wxl | ||
| === fossfreedom_ is now known as help | ||
| === help is now known as Guest30781 | ||
| === Guest30781 is now known as fossfreedom | ||
| === JanC_ is now known as JanC | ||
| === wendar_ is now known as wendar | ||
| nacc | rbasak: when you get a chance, can you look at ruby-riddle? it seems to be failing to start mysql-server (invalid argument --force?) | 23:46 |
| nacc | rbasak: https://launchpad.net/ubuntu/+source/ruby-riddle/1.5.12-4 (and my upload https://launchpad.net/ubuntu/+source/ruby-riddle/1.5.12-4ubuntu1) failed to build | 23:47 |
| nacc | rbasak: is it because --force is legall with mariadb maybe? | 23:47 |
| rbasak | nacc: that seems likely. | 23:57 |
| nacc | rbasak: ack, i'm not sure what the intention is, but if you could give it a once-over, that'd be great, otherwise i'll dig into it more tmrw | 23:58 |
| rbasak | nacc: could you file a bug please, and assign it to ~lars-tangvald? | 23:59 |
| rbasak | He's Skuggen here, but not in this channel right now. | 23:59 |
| rbasak | I think I'm meeting him (online) tomorrow so I can menion it. | 23:59 |
| rbasak | mention | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!