[03:32] <hallyn> is there a problem with the ppa upload ftp server?  (like disk full)  it keeps telling me my upload has a md5sum mismatch
[05:16] <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:17] <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?
[07:46] <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:49] <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:51]  * sil2100 wasn't aware those needed any permissions but well
[07:54] <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:55] <sil2100> np!
[07:55] <sil2100> I guess that's ACL-through-obscurity ;p
[08:14] <Laney> pitti: i'll look
[08:17] <Laney> meh
[08:17] <Laney> some of the messages were eaten by the rate limiter
[08:18] <pitti> Laney: there should be plenty since yesterday morning, though; all of them are cut? :(
[08:18] <Laney> doing more paging
[08:20] <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:21] <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:41] <Laney> meh
[08:41] <Laney> let me just run one interactively
[08:41] <Laney> I see a few reboot timeouts
[09:22] <cjwatson> hallyn: it has a couple of TB free; but it looks like you managed to produce an upload it accepted eventually?
[09:26] <pitti> Laney: hmm, no 'Three tmpfails in a row'? Some of these have retried since yesterday
[09:28] <pitti> http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 is definitively fishy..
[09:31] <Laney> pitti: yes, they end in timeouts
[09:32] <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:37] <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:38] <pitti> hmm, interesting; that's the bit which I can't seem to reproduce with qemu; thanks for digging it out
[09:41] <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:42] <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:43] <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:44] <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:45] <pitti> so no immediate idea, I'm afradi
[09:58] <Laney> pitti: http://people.canonical.com/~laney/weird-things/log.xz in case that's helpful
[10:05] <pitti> Laney: thanks
[10:09] <Laney> pitti: want to resubmit a job, for validation?
[10:10] <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:11] <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:12] <Laney> you did, or you want me to?
[10:12] <pitti> I will
[10:12]  * Laney nod
[10:13] <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:54] <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:55] <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:56] <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:57] <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:58] <juliank> *I* wouldn't change it, seems dangerous to build this logic in there
[10:59] <juliank> Load hopefully reduces automatically eventually, as people migrate to xenial
[11:19] <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:20] <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:21] <xnox> 5 year support cycles, with LTS every 2 years are wonderful, as we only have half the people upgrade to each LTS.
[11:22] <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:23] <cjwatson> (possibly non-trivial work in apport as well, but I don't know about that)
[11:36] <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:37] <pitti> (apport by and large works on Debian too)
[11:53] <pitti> Laney: amd64 succeeded; and s390x finished as well (with a failure, but that's our problem)
[12:06] <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:12] <Laney> pitti: ok, thanks - sorry it's breaking with meson :(
[12:55] <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:56] <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:57] <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:58] <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:59] <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
[13:00] <cjwatson> I think the relevant debsign changes were in devscripts 2.17.{2,3,4}, if somebody wants to look into that
[13:12] <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:13] <xnox> so far i have been managing to build source packages and upload them from xenial like that.
[13:16] <smoser> hm..
[13:17] <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:19] <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:20] <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:21] <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:26] <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:27] <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:31] <hallyn> cjwatson: yeah;  it's possible it was network on my end, but it thought it succeeded every time
[13:32] <mdeslaur> xnox: https://motd.ubuntu.com/
[13:33] <zhhuabj> hi cpaelzer
[13:36] <cpaelzer> hi zhhuabj
[13:36] <cpaelzer> whats up zhhuabj
[13:36] <cpaelzer> new SRUs around the corner?
[14:02] <zhhuabj> cpaelzer, yeah :) could you help nominate this bug to xenial - https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1686679
[14:05] <cpaelzer> zhhuabj: let me read what it is
[14:07] <zhhuabj> cpaelzer, ok
[14:26] <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:51] <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:59] <zhhuabj> cpaelzer, ok, thanks
[15:01] <rbasak> slashd: sorry, not yet
[15:02] <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:03] <slashd> rbasak, tks
[15:04] <rbasak> ack
[16:19] <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:20] <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:21] <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:22] <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:23] <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:24] <juliank> (and with other applications)
[16:25] <juliank> (That's https://lists.debian.org/debian-dpkg/2017/01/msg00044.html)
[16:27] <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:29] <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:30] <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:31] <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:34] <xnox> powersj, that is another thing; i have a branch for wubi
[16:35] <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:37] <juliank> ExecStart=/usr/bin/flock -w 3600 /var/lib/apt/apt-daily.flock /usr/lib/apt/apt.systemd.daily
[16:40]  * juliank will also be off in about 20-30 minutes to watch guardians of the galaxy volume 2
[16:43] <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:44] <juliank> Ah, we can drop -w and make it wait indefintely
[16:50] <juliank> I played with Conflicts and now systemd is all like "Looping too fast. Throttling execution a little."
[16:52] <juliank> Anyway, I'll continue playing with stuff tomorrow, and shut down now :)
[17:55] <gQuigs> can I get an SRU upload, please - https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1673579
[17:57] <nacc> gQuigs: looking
[17:59] <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
[18:00] <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:02] <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:03] <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:04] <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:13] <nacc> slangasek: can you release src:php7.1 from the new queue for artful?
[18:14] <slangasek> nacc: I can at least look at it!
[18:15] <slangasek> nacc: I'm confused, why is it back in new?  I thought we already had php7.1 in -proposed
[18:18] <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:19] <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:20] <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:21] <infinity> Grr.  That's the bug I filed.
[18:21] <slangasek> which'un?
[18:21] <infinity> LP: #1685672
[18:21] <slangasek> k
[18:21] <infinity> (Bug applies in the other direction too, obviously)
[18:22] <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:23] <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:24] <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:25] <infinity> Oh, and already accepted.  That was the confusion.
[18:26] <infinity> slangasek: And it's gone to main in the process, I guess?
[18:27] <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! :)
[19:55] <nacc> slangasek: just uploaded the delta which should allow php7.1 to migrate through and fix the c-m
[21:27] <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
[23:46] <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:47] <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:57] <rbasak> nacc: that seems likely.
[23:58] <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:59] <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