=== Guest48238 is now known as RAOF [03:32] is there a problem with the ppa upload ftp server? (like disk full) it keeps telling me my upload has a md5sum mismatch === handsome_feng is now known as LinusBenedictTor === LinusBenedictTor is now known as handsome_feng [05:16] Laney: good morning! [05:16] 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] 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] does anyone know how i could add comments to https://merges.ubuntu.com/main.html ? [07:46] i would like to add the BTS bug numbers for the forwarded deltas [07:49] rbalint: hm, I suppose you might not have the required permissions to do that, maybe only people with upload rights can comment [07:49] Since it seems to work for me [07:49] rbalint: what do you want to have added and where? [07:49] sil2100: so far: [07:51] * sil2100 wasn't aware those needed any permissions but well [07:54] sil2100, all: hah, there is an invisible textbox in the comment column! :-) [07:54] Yes ;) [07:54] sil2100: thanks! :-) [07:54] It's not really intuitive [07:55] np! [07:55] I guess that's ACL-through-obscurity ;p === marcusto_ is now known as marcustomlinson_ === JanC is now known as Guest35192 === JanC_ is now known as JanC [08:14] pitti: i'll look [08:17] meh [08:17] some of the messages were eaten by the rate limiter [08:18] Laney: there should be plenty since yesterday morning, though; all of them are cut? :( [08:18] doing more paging [08:20] 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] Apr 26 08:24:22 juju-prod-ues-proposed-migration-machine-3 sh[12701]: No UUID given. Instance won't be deleted! [08:21] Apr 26 08:24:22 juju-prod-ues-proposed-migration-machine-3 sh[12701]: : failure: setup script failed with code 1: /home/ubuntu/autopkgtest/ssh-setup/nova open --flavor autopkgtest --nam [08:21] but that one failed almost immediately [08:41] meh [08:41] let me just run one interactively [08:41] I see a few reboot timeouts [09:22] hallyn: it has a couple of TB free; but it looks like you managed to produce an upload it accepted eventually? [09:26] Laney: hmm, no 'Three tmpfails in a row'? Some of these have retried since yesterday === CRogers_________ is now known as CRogers [09:28] http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 is definitively fishy.. [09:31] pitti: yes, they end in timeouts [09:32] Laney: oh, in the boot-smoke test? I ran the complete suite here, with the production autopkgtest command, and it worked well [09:32] but a test timeout shouldn't count as a tmpfail [09:32] sec [09:37] pitti: Apr 27 08:48:47 juju-prod-ues-proposed-migration-machine-3 sh[656]: : failure: timed out waiting for testbed to reboot [09:37] 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] that is in boot-smoke [09:38] hmm, interesting; that's the bit which I can't seem to reproduce with qemu; thanks for digging it out [09:41] 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] pitti: yeah [09:42] you think meson could have provoked this? [09:42] some different CFLAGS or something? [09:42] not sure why -- as I said, it works fine with xenial QEMU, and the exact same repos [09:42] (and PPAs, etc.) [09:42] 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] /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] qemu /srv/vm/autopkgtest-xenial-amd64.img [09:43] I would have expected a more obvious failure from switching this :/ [09:43] yeah, and there were plenty ;) [09:43] my test run got to boot-smoke now [09:43] I'll let it run through that and then kill all the things [09:44] the CFLAGS are very similar now, just some minor differences in linking [09:44] but up to boot-smoke it actually does a handful of reboots already, and it seems they are just fine [09:45] so no immediate idea, I'm afradi [09:58] pitti: http://people.canonical.com/~laney/weird-things/log.xz in case that's helpful [10:05] Laney: thanks [10:09] pitti: want to resubmit a job, for validation? [10:10] 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] merci, let's see what happens [10:11] I see it in the queue,after the snap tests; thanks for your help! [10:11] Laney: I'd run a meson test on s390x, let's see if it works there [10:12] you did, or you want me to? [10:12] I will [10:12] * Laney nod [10:13] 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] 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] And rename the cron job to zzzapt [10:55] (So it runs last) [10:55] That is, after you split it like now [10:55] and keep upgrade as daily [10:56] (though, not sure if upgrade might be failing then) [10:56] 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] xnox: Well @daily runs at 6 in cron ... [10:57] that should work with anacron, or was the bug with anacron that it schedules all @daily jobs at 6? [10:57] right, yeah. [10:58] *I* wouldn't change it, seems dangerous to build this logic in there [10:59] Load hopefully reduces automatically eventually, as people migrate to xenial [11:19] 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] https://bugs.launchpad.net/ubuntu/+source/reprepro/+bug/799889 [11:19] Launchpad bug 799889 in reprepro (Ubuntu) "fails to import ddeb packages" [Undecided,Confirmed] [11:20] 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] juliank, we are expecting trusty users to only upgrade to 18.04. [11:21] 5 year support cycles, with LTS every 2 years are wonderful, as we only have half the people upgrade to each LTS. [11:22] bdrung_work: dropping it would be a lot of work in LP [11:22] we argued against Debian using the .deb extension for this at the time ... [11:23] (possibly non-trivial work in apport as well, but I don't know about that) [11:36] changes in apport would be fairly small [11:36] in fact, an one-line change in the special case for installing kernel debug symbols [11:37] (apport by and large works on Debian too) [11:53] Laney: amd64 succeeded; and s390x finished as well (with a failure, but that's our problem) [12:06] 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] pitti: ok, thanks - sorry it's breaking with meson :( === CRogers_________ is now known as CRogers [12:55] 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] Do you have current devscripts? [12:56] 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] I'm running whatever devscripts is in xenial, so I guess not [12:57] And a newer dpkg-dev? [12:57] Maybe you're doing build-source-package-in-chroot or something [12:57] oh, probably, yes [12:57] We might consider weakening the buildinfo-must-be-signed requirement; file an LP bug? [12:58] but signing with testing's or artful's devscripts should work fine [12:58] hm, isn't that useful for reproducible builds? [12:58] I mean, certifying its correctness [12:58] Yeah, it is [12:58] Hence me only saying "consider" :) [12:59] well, I'm signing on xenial...so I assume I need to install artful's devscripts in xenial? [12:59] Possibly we should SRU the buildinfo signing change to devscripts instead [12:59] I sometimes run debsign in an schroot with my homedir mounted [13:00] I think the relevant debsign changes were in devscripts 2.17.{2,3,4}, if somebody wants to look into that [13:12] mdeslaur, hm, i usually build my source packages with no clean on my host system; and sign that. [13:12] 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] so far i have been managing to build source packages and upload them from xenial like that. [13:16] hm.. [13:17] 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] and, at this current time, they all say that 12.04 is not supported [13:17] how should we handle that ? [13:17] with regard to https://insights.ubuntu.com/2017/03/14/introducing-ubuntu-12-04-esm-extended-security-maintenance/ [13:19] 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] smoser: imho, you should leave it as is [13:19] generally speaking, you're not supporting precise anymore [13:19] it would be far more confusing to declare it as supported in public distro-info IMHO [13:20] 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] w [13:20] they should be marked as unsupported [13:20] because they are [13:21] which seems like it shoudl still be updated (or people would get old images) [13:21] I'm certain Canonical has another avenue for ESM customers [13:21] let 12.04 die with some grace [13:26] 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] xnox: and MOTD says "Ubuntu 12.04 LTS end-of-life is April 25, 2017 -- Upgrade your Precise systems!" [13:27] so many different dates! :) [13:27] 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] 25 -> because of 26th April UTC to your local time conversion? [13:31] cjwatson: yeah; it's possible it was network on my end, but it thought it succeeded every time [13:32] xnox: https://motd.ubuntu.com/ [13:33] hi cpaelzer [13:36] hi zhhuabj [13:36] whats up zhhuabj [13:36] new SRUs around the corner? [14:02] cpaelzer, yeah :) could you help nominate this bug to xenial - https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1686679 [14:02] Launchpad bug 1686679 in autofs5 (Ubuntu) "[SRU] Ubuntu16.04 : autofs takes extreamly long with large number of direct maps" [Undecided,New] [14:05] zhhuabj: let me read what it is [14:07] cpaelzer, ok [14:26] 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] 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] 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:59] cpaelzer, ok, thanks [15:01] slashd: sorry, not yet [15:02] 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] rbasak, tks [15:04] ack [16:19] 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] I guess that works out OK [16:20] nah, that's not ok. [16:20] between dpkg runs within an upgrade; apt update can come in and steal a lock. [16:21] i used to have this happen before with e.g. desktop packgekit updates / apt gui package manager [16:21] xnox: This can't happen anymore since the last round of SRUs [16:21] juliank, nice! [16:22] xnox: But well on trusty it can, but maybe you can backport it there too :) [16:22] * don't lock dpkg in 'apt-get clean' [16:22] * don't lock dpkg in update commands [16:23] 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] (and with other applications) [16:25] (That's https://lists.debian.org/debian-dpkg/2017/01/msg00044.html) [16:27] 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] 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] xnox: thanks for merging the artful ISO tests [16:30] as install will unable the upgrade too, no? [16:30] 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] 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] 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] 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] juliank, yes. [16:31] xnox: Yeah, got a merge up here https://code.launchpad.net/~powersj/utah/remove_cdromupgrade/+merge/323337 [16:34] powersj, that is another thing; i have a branch for wubi [16:35] 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] 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] 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] Ah, we can drop -w and make it wait indefintely [16:50] I played with Conflicts and now systemd is all like "Looping too fast. Throttling execution a little." [16:52] Anyway, I'll continue playing with stuff tomorrow, and shut down now :) [17:55] can I get an SRU upload, please - https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1673579 [17:55] Launchpad bug 1673579 in pcs (Ubuntu Xenial) "Corosync/Pacemaker: Error when enabling Pacemaker service,Error when starting the cluster " [Low,In progress] [17:57] gQuigs: looking [17:59] 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] gQuigs: 0.9.149-1ubuntu1.1 rather than ubuntu2 [18:00] it doesn't matter in this case, but for consistency with our documentation :) [18:00] gQuigs: are you ok if i change those locally? [18:00] nacc: sure, thanks! [18:02] 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] gQuigs: it doesn't explicitly apply to SRUs, but their policy always give sane version numbers [18:03] gQuigs: e.g., if you were SRU'ing the same version back to multiple versions [18:03] gQuigs: so it's just one less thing I (as sponsor) have to think about :) [18:03] gotcha, will bookmark that for later [18:03] 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] oh, got it [18:04] 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] slangasek: can you release src:php7.1 from the new queue for artful? [18:14] nacc: I can at least look at it! [18:15] nacc: I'm confused, why is it back in new? I thought we already had php7.1 in -proposed [18:18] slangasek: yeah i'm not sure what happened, i looked yesterday and rmadison said it wasn't in ubuntu at ll [18:18] *all [18:19] slangasek: but it was earlier this week (per rmadison) [18:19] slangasek: is it possible changing that bug's state caused something to delete it? [18:19] "deleted 18 hours ago by Ubuntu Archive Robot: moved to release" [18:19] except wasn't [18:19] slangasek: strange! [18:19] https://launchpad.net/ubuntu/+source/php7.1/+publishinghistory === _salem is now known as salem_ [18:20] slangasek: duh, i didn't even think to look there last night [18:20] 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] Grr. That's the bug I filed. [18:21] which'un? [18:21] LP: #1685672 [18:21] 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] k [18:21] (Bug applies in the other direction too, obviously) [18:22] infinity: interesting, thanks for the pointer [18:22] slangasek: You can fix it by manually copying from zesty-proposed with exact version. [18:22] (to artful) [18:22] infinity: it's not in z-p either [18:22] nacc: It was. [18:22] yeah, but pubhistory says you deleted it to move it to a-p [18:22] copyPackage() is magic. [18:22] nacc: you can do magic copies of deleted things [18:22] oh ok :) [18:22] but in this case I'll just release your new sync [18:22] nacc: *you* can't fix it, cause you can't copy to the release pocket, but slangasek or I can fix it. [18:23] infinity: ah, AA magic, got it :) [18:23] actually, I will do the magic copy as well so that we might skip binary new [18:23] slangasek: ack, thanks [18:24] Where is this new sync you're "releasing"? [18:24] Or you mean just doing in general? [18:24] infinity: it was synced to artful-proposed and landed in new [18:24] infinity: new version from Debian [18:24] it is no longer in new [18:25] Oh, and already accepted. That was the confusion. [18:26] slangasek: And it's gone to main in the process, I guess? [18:27] infinity: I did that, yes [18:27] 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] (pre-emptive on my part) [18:27] at which point, i believe we can demote php7.0 and remove it [18:27] slangasek: thanks! :) === stgraber_ is now known as stgraber [19:55] slangasek: just uploaded the delta which should allow php7.1 to migrate through and fix the c-m === salem_ is now known as _salem === Serge is now known as hallyn === jdstrand_ is now known as jdstrand [21:27] 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 === 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 [23:46] 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] 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] rbasak: is it because --force is legall with mariadb maybe? [23:57] nacc: that seems likely. [23:58] 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] nacc: could you file a bug please, and assign it to ~lars-tangvald? [23:59] He's Skuggen here, but not in this channel right now. [23:59] I think I'm meeting him (online) tomorrow so I can menion it. [23:59] mention