=== maclin1 is now known as maclin
[03:28] -queuebot:#ubuntu-release- Unapproved: gnome-logs (zesty-proposed/universe) [3.24.1-0ubuntu1 => 3.24.2-0ubuntu0.1] (ubuntugnome)
=== Guest84782 is now known as RAOF
[10:41] <apw> slangasek, well even if the kernel i have just promoted would have helped with binutils ... the fact it has now been uploaded again negates any benefit there
[10:41] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-12.17] (core, kernel)
[10:42] <apw> (i assume)
[10:43] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-12.17]
[12:28] <apw> slangasek, ok confirmed with adam ... a no change rebuild uploaded for that
[13:00] <xnox> slangasek, i see a lot of s390x: regression but so far they are due to uninstallable test depends, i'm retrying those with all-proposed to see actual failures =/
[13:08] <xnox> retriggered all perl regressions on s390x with the right triggers and all-proposed=1 will check back the status of that.
[13:09] <doko> xnox: hmm, why just s390x?
[13:10] <xnox> "<slangasek> xnox: there appear to be a couple of genuine regressions on s390x autopkgtests with perl 5.26" to find these
[13:11] <xnox> slangasek, also do backdoor runs with all-proposed actually achieve anything w.r.t. britney? as everything still needs to have the right triggers to get the status updated for the right combo, no? or does all-proposed tests update any status of any tests?
[13:12] <xnox> using script from ubuntu-archive-tools i get requests that list _both_ triggers and all-proposed.
[13:39] -queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.4 => 9.4ubuntu4.5] (core)
[13:51] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.5]
[15:29] <xnox> I fixed http://autopkgtest.ubuntu.com/packages/ruby-httpclient =) it failed adt tests because of proxies set in the environment =)
[16:06] <ginggs> anyone have any ideas about eigensoft autopkgtest failure on amd64 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openblas ?  Removing autopkgtest-satdep:amd64 because I can't find eigensoft:amd64
[16:10] <nacc> ginggs: have you retried it? i see the one for perl at the same version of eigensoft passed
[16:14] <ginggs> nacc: i have retried it
[16:17] <slangasek> apw: -12 is the kernel we're after for binutils, not -11 :)
[16:19] <slangasek> apw: no change rebuild of the kernel in the archive?  weird :)
[16:19] <slangasek> xnox: you seem to have been looking at something different than I was.  I was talking about the autopkgtest failures shown under perl itself that were s390x-specific
[16:20] <slangasek> xnox: I have already done all the retriggers and there were s390x-specific failures, what I'm looking for here is analysis
[16:21] <slangasek> ginggs: you and me both, then?  The eigensoft autopkgtest is failing because for some reason the runner is failing to find packages that are in multiverse, despite a log file showing that it's downloaded the Packages file
[16:21] <slangasek> eigensoft was not the only example of this, and it's amd64-only
[16:21] <slangasek> Laney: ^^ do you have any insight here?
[16:24] <xnox> slangasek, ah.
[16:24]  * xnox goes to look again
[16:24] <slangasek> xnox: it's also possible that something changed in between my last retry and yours, since now there are zero s390x-specific failures listed <shrug> :)
[16:24] <slangasek> fwiw my approach here has been "work through the pile on perl, to get perl considered as a candidate; then work through the revdeps"
[16:25] <slangasek> we only have "interesting" autopkgtests failing now with the new perl - cacti, and all the databases
[16:25]  * xnox ponders if those have any users
[16:25] <xnox> *giggle*
[16:25] <apw> slangasek, yeah that one was prepped in a -security compatible PPA ie missed binutils ... we need to change our proceedures for queueing uploads for devel specificially
[16:25] <apw> slangasek, so that they are built in a ppa which has -proposed enabled
[16:26] <slangasek> (not counting auto-multiple-choice, which I fixed in -proposed but FTBFS because of TeX; arename, which is currently rerunning; libchi-perl, which I've bugged Debian; libtest-aggregate-perl, which I've just removed)
[16:26] <slangasek> apw: ah indeed
[16:27] <slangasek> xnox: oh, and there are test regressions against systemd; what do we do about those?
[16:28] <slangasek> (I assume systemd/{amd64,i386} will pass against new perl if we just run it with the right version)
[16:28] <xnox> slangasek, it seems to me that boot-smoke is not reliable in containers; thus i should blacklist to run only on full VMs / machines.
[16:28] <xnox> and there is an extra armhf regression which i thought is fixed (because it is fixed on arm64) bot alas that didn't fix it on armhf.
[16:28] <slangasek> xnox: so am I waiting for a new upload of systemd?
[16:29] <nacc> ginggs: hrm, i don't know, sorry
[16:29] <slangasek> nacc: see my reply to ginggs
[16:29] <nacc> slangasek: ah sorry, i missed that!
[16:29] <nacc> slangasek: yeah that does seem like an oddity
[16:30] <xnox> slangasek, si senior
[16:31] <slangasek> xnox: k.  one of the failing revdeps of systemd is unity8 still, so there's also that to drill into
[16:35] <xnox> slangasek, rm pay-service; rm ubuntu-push; rm unity8
[16:35] <xnox> https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1707680
[16:35] <ubot5> Ubuntu bug 1707680 in pay-service (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
[16:38] <xnox> slangasek, full updated with the chain https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1707680
[16:38] <ubot5> Ubuntu bug 1707680 in pay-service (Ubuntu) "RM: obsolete product" [Critical,Triaged]
[16:40] <slangasek> xnox, infinity: how is this apt SRU supposed to DTRT when the corresponding unattended-upgrades piece does not appear to have landed in SRU?
[16:41] <slangasek> xnox, infinity: I am concerned that by half-landing we have in fact regressed the distribution of downloads throughout the day
[16:41] <slangasek> which if true is critical and needs reverted
[16:45] <xnox> slangasek, we disucssed this in detail
[16:45] <xnox> slangasek, unattended-upgrades fixes are independant of the apt-timers fixes.
[16:46] <xnox> slangasek, this apt update does the right thing, w.r.t. timers. With current, or future unattended upgrades.
[16:46] <xnox> slangasek, the split of apt-timer into update step and upgrade step is the only critical piece, that the current apt in proposed resolves.
[16:46] <xnox> slangasek, it is critical, as there are affected partners w.r.t. timers.
[16:47] <xnox> there will be unattended-upgrades SRU in the future, which is decoupled from apt SRUs.
[16:50] <slangasek> xnox: ok, have satisfied myself that the unattended-upgrade piece is separate, thanks
[16:52] <slangasek> (what I don't understand is why you need to call unattended-upgrade --download-only at all, if the updates are already being handled in the previous section with 'apt-get -y -d dist-upgrade')
[16:53] <slangasek> xnox: hmmm except I find APT::Periodic::Download-Upgradeable-Packages "0"; in grep: /etc/apt/auth.conf: Permission denied
[16:53] <slangasek> no, not there
[16:53] <slangasek> in /etc/apt/apt.conf.d/10periodic
[16:57] <slangasek> xnox: how did you confirm that updates were actually downloaded when apt-daily.service ran, as opposed to being downloaded at 6am?
=== alan_g is now known as alan_g|EOD
[17:12] <xnox> slangasek, i did not check that in my test, because my container was up to date with respect to security updates. Let me downgrade things, to make that happen.
[17:12] <xnox> 1) downgrade package 2) clean caches 3) manually start apt-daily.service 4) verify that it download things
[17:12] <slangasek> xnox: yes please
[17:13] <slangasek> without that check, my reading of the code has me wary that w/o the unattended-upgrades fix we are indeed going to be doing all the downloads at 6
[17:13] <xnox> right, it is tricky, as the code above unatteded-upgrades should do ~= apt-get --download-only
[17:13] <xnox> but not obvious.
[17:14] <slangasek> xnox: yes, that's what the code does, but only if /configured/ to do so, using a flag that is set to 0 by default in apt
[17:15] <slangasek> AFAIK we were not using that code path at all and were only using unattended-upgrades; so now, since the u-u piece hasn't landed, we're a no-op in apt-daily.service and doing all the downloads in apt-daily-upgrade.service (AIUI)
=== ogra_ is now known as ogra
[17:27] <xnox> slangasek, and we would have saved so much time, if we would have assumed that you are right.
[17:28] <xnox> downgraded systemd to release pocket, because there is a systemd in security pocket.
[17:28] <xnox> wiped all the apt periodic timers
[17:28] <xnox> launched apt-daily.service -> it did not download anything
[17:29] <xnox> launchped apt-daily-upgrade.service, no-block, with watch -d over /var/cache/apt/archives/, and noticed how systemd and libsystemd0 got downloaded, (installed), and removed from the cache.
[17:29] <xnox> so yeah, apt lists are downloaded randomly, but the heavy downloads are done at 6am.
[17:30] <xnox> so we really need unattended-upgrades SRU too
[17:34] <xnox> slangasek, it would fix the customer problem, but regress the IS concern.
[17:34] <infinity> The unattended-upgrades --download-only thing is trivial, isn't it?  Can we JFDI?  Or should we revert apt?
[17:35] <xnox> well there is a pending unattended-upgrades SRU from steve
[17:35] <xnox> oh no, that is in updates
[17:35]  * xnox is blind
[17:39] -queuebot:#ubuntu-release- Unapproved: gnome-applets (zesty-proposed/universe) [3.22.0-2ubuntu0.1 => 3.22.0-2ubuntu0.2] (desktop-extra, edubuntu)
[17:42] <xnox> infinity, slangasek: so we would need - https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91 and https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6
[17:43] <xnox> is that landable? shall I prepare SRUs and test it?
[17:55] <slangasek> xnox: yes to those commits; apt also needs a versioned breaks: against unattended-upgrades
[17:55] <slangasek> infinity: ^^
[18:03] <infinity> slangasek: Cat's out of the bag a bit on the versioned Breaks.  People who already upgraded won't benefit, and the next round of upgrades would bring in unattended-upgrades.
[18:03] <infinity> slangasek: (and it doesn't technically "break" it, just gives you behaviour that's not perfectly ideal)
[18:04] <infinity> slangasek: But we can delete that update right now if you'd prefer it not go out to more people yet.
[18:04] <slangasek> infinity: "the next round of upgrades" - except that people may or may not install all of the updates together, and what if at a later date there's an updated apt in the security pocket
[18:04] <slangasek> infinity: the fact that this is all in -updates rather than -security leaves me confident that we don't need to revert anything if unattended-upgrades will happen ASAP
[18:04] <slangasek> but it does need to be in a coherent state before the point release
[18:05] <infinity> slangasek: Sure, I'm all for pushing out the u-a fix quickly.
[18:05] <xnox> u-a for Apgrades =)
[18:05] <infinity> slangasek: I was arguing that the versioned breaks doesn't buy us much at this point.
[18:06] <slangasek> infinity: yes, it's not a huge benefit and the versioned breaks don't even matter for the point release, but I think we should follow through on it all the same
[18:06] <infinity> xnox: The download-only commits indeed look trivial.  I can haz?
[18:07] <infinity> slangasek: Perhaps.  Though you're then asking for a time bomb on the next apt security update, unless someone copies u-a over there today.
[18:07] <xnox> infinity, sure. but later tonight. I'm like need to go to volleyball in 8minutes.
[18:07] <infinity> xnox: Okay, maybe I'll pick it up, then.  Or get $someone to, so I can do the review.
[18:08] <xnox> infinity, i'll be back in like 3h or so to do it.
[18:09] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[18:09] <slangasek> infinity: the alternative would be a time bomb that on the next apt security update, we regress unattended-upgrades behavior again for all the u-u security-only users (i.e. everyone with the default 16.04 config) and spike the load on archive.u.c
[18:10] <infinity> slangasek: Yeah.  I'm not convinced more than 3 users actually run security-only (though, indeed, most people run security-only-automatic, as it were).
[18:10] <slangasek> infinity: millions of cloud instances by default :)
[18:11] <infinity> slangasek: They're the latter, but not the former.
[18:12] <slangasek> right
[18:15] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[18:22] <smoser> can someone NACK both of my cloud-init uploads ?
[18:22] <smoser> i want to update the changelogs a bit
[18:24] <jdstrand> infinity: I meay be weird and 1 of the 3, but I've been known to run security only on a machine or two
[18:26] <slangasek> smoser: done
[18:26] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1]
[18:27] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1]
[18:29] <infinity> jdstrand: You're weird.
[18:29] <slangasek> :)
[18:29] <infinity> jdstrand: I dunno.  mdselaur and I have discussed it many times, usually in the context of "oh, look at that bug that's existed for the last 2 months for anyone who's security-only, and literally zero people reported it".
[18:29] <jdstrand> I never claimed otherwise :P
[18:32] <infinity> jdstrand: And while I'm aware that we have millions of users who don't report bugs, I'd also suspect that the sort of paranoid people who would deliberately choose tha tconfiguration would also have a higher representation in the "users that actually file bugs" cross-section.
[18:32] <jdstrand> I agree it is likely a small number and me as an example is obviously anecdotal
[18:33] <jdstrand> but, I do understand the desire and suspect there are enough to continue to support security only, which was really the only reason I brought it up
[18:34] <jdstrand> obviously I don't have any hard data
[18:34] <infinity> Yeah, we have something close to zero data.
[18:34] <infinity> Which is why we've not brought up the inverse seriously either.
[18:34] <infinity> THough we privately discuss "hey, maybe 18.04 should merge the security and updates pockets".
[18:36] <jdstrand> I suspect Dustin might be able to get something slightly better than anecdotal data for at least UA customers
[18:36]  * jdstrand shrugs
[19:36] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.6 => 0.90ubuntu0.7] (desktop-core, ubuntu-server)
[19:37] <slangasek> infinity: ^^ unattended-upgrades for review at your convenience
[19:38] <slangasek> xnox: I've also updated the test case to mention the 'manually trigger apt-daily.service' bit, please check that I have expressed this correctly
[19:41] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (zesty-proposed/main) [0.93.1ubuntu2.2 => 0.93.1ubuntu2.3] (desktop-core, ubuntu-server)
[19:44] -queuebot:#ubuntu-release- Unapproved: linux (artful-proposed/main) [4.11.0-12.18 => 4.11.0-12.18] (core, kernel)
[19:50] <slangasek> xnox: unity8 out.  are we now unblocked wrt the Qt transition?
[19:53] <slangasek> tsimonq2: ^^ are all of the ubuntu-touch qt packages gone that *you're* expecting to see removed in order to unblock Qt?
[20:19] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:21] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:42] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:56] -queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.31+17.04 => 2.33+17.04] (no packageset)
[20:58] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.31 => 2.33] (no packageset)
[20:59] <sergiusens> infinity: hi. Mind taking a look at those two? ^
[21:07] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[22:18] <xnox> slangasek, slight adjustment to the test case #1 remove periodic stamp files #2 after apt-daily.service systemd should be downloaded, but not upgraded. starting apt-daily-upgrade should upgrade it only /without/ downloading.
[22:25] <xnox> slangasek, you have unattended-upgrades in progress are you preparing the srus? /me checks the queue.
[22:26] <xnox> ah, it is.
[22:26] <xnox> looking good.
[22:30] <xnox> uploaded into artful, to fix the bugs there. and to test it there.
[22:30] <xnox> if and when infinity accepts unattended-upgrade i'll test it.
[23:00] <Laney> slangasek: Just want to say that I'm at a conference, so very limited ability to investigate stuff atm
[23:00] <slangasek> Laney: ack (DebConf?)
[23:00] <Laney> suggest trying it locally and seeing if it reproduces (commandline at the top, tweak that)
[23:01] <Laney> if so, then you have somewhere to start from to debug
[23:01] <Laney> no, GUADEC --- but will be at Debconf from Wednesday
[23:01] <slangasek> Laney: I didn't try the exact commandline, but fwiw it seems to only have trouble finding the multiverse packages on amd64, not on other archs... I will have a look though
[23:01] <Laney> yeah, not sure ottomh, sorry :(
[23:01] <slangasek> no worries
[23:02] <slangasek> gcc: error: unrecognized command line option '-mno-red-zone'; did you mean '-fno-regmove'?
[23:02] <slangasek> now, if someone could explain to me why git bisect of ffmpeg on s390x gives me *that* gem... :P
[23:04] <slangasek> mm that may not be the actual failure, n/m
[23:04] <slangasek> anyway, merge commits for git bisect == teh suck
[23:06] <xnox> yeah, people should use nice and linear history.
[23:08] <nacc> heh
[23:26] <xnox> slangasek, more removals https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm those that are trianged are good to go, to help towards removing UOA
[23:26] <xnox> not sure about the Qt5.6 removals.
[23:28] <xnox> i think we will not be able to remove ubuntu-ui-toolkit, until the mir kiosk people drop content-hub.
[23:28] <xnox> Saviq, what's the status around keeping content-hub? and can it be made to not depends on ubuntu-ui-toolkit or some such? (via libertine i think)
[23:29] <xnox> or rather i mean make libertine not depend on content-hub, such that we can remove liberitne.
[23:30] <xnox> looking at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.6
[23:31] <xnox> i think there are circular dependenices around libertine.
[23:31] <xnox> libertine and content-hub build-depend on each other.