[00:04] <xnox> tjaalton:  Laney: i have no idea! also weird! and thank you for the reject.
[00:04] <xnox> will re-upload.
[08:05] <juliank> Laney, sil2100 Seems we're still hitting the issue where autopkgtest installs unattended-upgrades from release rather than updates.
[08:06] <juliank> It triggered 0.90 for python-apt/1.1.0~beta1ubuntu0.16.04.5
[08:06] <juliank> last known good was May 6; python-apt/1.1.0~beta1ubuntu0.16.04.4 triggering 1.1ubuntu1.18.04.7~16.04.2
[08:06] <juliank> rbalint: ^
[08:09] <Laney> juliank: sorry, what is the problem in more detail?
[08:10] <juliank> Laney: unattended-upgrades in xenial is 0.90, xenial-updates has  1.1ubuntu1.18.04.7~16.04.3
[08:10] <juliank> Laney: All new tests are triggering 0.90
[08:10] <juliank> That makes no sense, as it does not happen for other stuff
[08:10] <juliank> AFAICT
[08:11] <juliank> even security has 0.90ubuntu0.10
[08:13] <juliank> autopkgtest [17:04:49]: @@@@@@@@@@@@@@@@@@@@ apt-source unattended-upgrades
[08:13] <juliank> Get:1 http://ftpmaster.internal/ubuntu xenial/main unattended-upgrades 0.90 (dsc) [1,766 B]
[08:13] <juliank> like, this should already be pulling from -updates
[08:14] <Laney> yeah OK, and there is other stuff being fetched from -updates in there
[08:14] <juliank> Hang on a sec
[08:15] <juliank> cjwatson: xenial-updates is broken
[08:15] <juliank> cjwatson: Packages that should be in there are not
[08:16] <juliank> Laney: Do we have -security disabled on autopkgtest?
[08:16] <juliank> That + broken -updates pocket would explain why it fetches from release
[08:17] <juliank> cjwatson: So, rmadison unattended-upgrades:  unattended-upgrades | 1.1ubuntu1.18.04.7~16.04.3 | xenial-updates   | source
[08:17] <juliank> no binary in archive
[08:17] <juliank> Seems like we probably have more issues with apt-ftparchvie than we realized, and need to regenerate all the dbs
[08:18] <juliank> as that's across all architectures
[08:18] <Laney> https://launchpad.net/ubuntu/xenial/amd64/unattended-upgrades/
[08:19] <juliank> Huh
[08:19] <juliank> hmm
[08:19] <Laney> not sure re: security, that's not my intention but it could be
[08:20] <juliank> rbalint: the unattended-upgrades binary in xenial-updates was removed on may 7th
[08:20] <juliank> um may 8th
[08:21] <juliank> Laney: But do we know why it was removed, or who removed it?
[08:21] <apw> Laney, its not showing removed in the primary publishing list
[08:21] <juliank> Laney: Log says it superseded itself?
[08:22] <juliank> This is very odd
[08:22] <Laney> sorry, I can't decipher all of this stuff
[08:23] <juliank> apw: only binary was removed, not source
[08:23] <apw> but only the source is published
[08:23] <Laney> there is a bug where binaries eat themselves if something is copied twice in the same publisher run, not sure if that manifests itself in the publishing history like this
[08:24] <juliank> apw: Can you fix that up and like copy back the binary into updates?
[08:24] <Laney> copy-package --from=ubuntu --from-suite=xenial-updates --to=ubuntu --to-suite=xenial-updates --version=1.1ubuntu1.18.04.7~16.04.3 --include-binaries --force-same-destination unattended-upgrades
[08:24] <apw> Laney, yeah, that could be, i think a copy over self is worth a try here and let cj-watson et al work out if there are any others
[08:24] <Laney> probably something like that would recover it
[08:24]  * apw will give it a go
[08:25] <juliank> thanks Laney, apw
[08:25] <juliank> Makes me wonder how we can ensure this does not happen again
[08:26] <Laney> if it's that LP bug then it's well known
[08:26] <juliank> or well, a better way to discover it
[08:26] <apw> normally when these things are suspected log magic is applied
[08:26] <juliank> I guess I could write a cron job that goes through -updates and looks for missing builds
[08:26] <juliank> run that once a day and have it send an email
[08:27] <juliank> s/missing builds/built packages missing/
[08:29] <apw> juliank, perhaps, or i wonder if teh superceeded by self is an indicator here
[08:29] <Laney> juliank: as for missing -security, it's probably https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed#L141
[08:29] <juliank> ack
[08:29] <apw> juliank, or actually the 'latest' status being superceeded which seems impossible in and of itself
[08:30] <juliank> apw: Yeah, that makes sense I guess. I guess with access to the database, it should be easy to write up a report for all binaries whose latest state is superseded
[08:31] <juliank> but it's probably hilariously slow as I guess there's no index on the status field :)
[08:31] <apw> i suspect it can be done via the api all be it slowly
[08:32] <juliank> Well, one query per binary is a ton of queries
[08:33] <juliank> but I guess it's only problematic on the first run
[08:33] <juliank> like we can cache status for a random time so we re-check versions we've seen before eventually but not all the time
[08:34] <apw> juliank, you can get all binaries together for a source, and in the right order that the first should always be published or deleted i believe
[08:35] <apw> (well or pending, or no records all being good in this context)
[08:37] <juliank> I wonder if it's faster to just load Sources and Packages files and then look if a given source package has binaries in the Packages file. The only API calls we then need are "which architectures did this build on?"
[08:38] <juliank> and we can indefinitely cache those API calls
[08:38] <cjwatson> I'll look after meetings
[08:39] <cjwatson> no index on the status field> what planet do you think we live on
[08:40] <apw> the publisher presumably uses that field rather heavily
[08:40] <juliank> ok
[08:40] <juliank> hey, I was just guessing, I don't have a launchpad checkout handy
[08:41] <juliank> Oh, I do have one
[08:41] <juliank> silly me
[08:42] <juliank> I should continue my Valid-Until branch
[08:44] <cjwatson> Looks like phased updates ate it in this case
[08:46] <apw> juliank, ok the re-copy has published; so the binaries ought to be back
[08:47] <juliank> $ curl -s http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.xz | xzcat  | grep-dctrl -P unattended-upgrades | wc -l
[08:47] <juliank> 0
[08:47] <juliank> unattended-upgrades | 1.1ubuntu1.18.04.7~16.04.3 | xenial-updates   | source
[08:48] <juliank> rmadison and archive.u.c don't know about it yet
[08:48] <cjwatson> Packages/Sources queries will be fatally flawed because deliberate removals are sometimes a thing
[08:49] <apw> cjwatson, removals would express as deleted though right?  and this was expressing as Superceeded
[08:49] <juliank> cjwatson: Oh right, I was thinking if we remove the SRU, we'd copy back the security one; but I'm not sure we do, and there's not always one available.
[08:49] <cjwatson> Superseded
[08:49] <cjwatson> please
[08:50] <cjwatson> apw: Right, but that distinction does not show up in Packages/Sources files which is what juliank was talking about querying in isolation
[08:50] <juliank> apw: Yes, but you don't see that in Packages files, which I was considering as a faster alternative to API calls
[08:50] <apw> juliank, ahh but might it give you a subset to then check via the api
[08:50] <cjwatson> juliank: I don't know why you would consider this problem for <stable>-updates and nowhere else
[08:51] <juliank> cjwatson: Oh, I do consider it a problem elsewhere, but that's harder to solve efficiently
[08:51] <cjwatson> And anyway I'm not talking about removing the entire source, but about removing individual binaries from it, which happens
[08:52] <juliank> So yeah, I guess we do need to check the launchpad status
[08:52] <juliank> * publisher status
[08:52] <apw> cjwatson, in this case the binary itself was showing superseded
[08:52] <cjwatson> Yes, I know
[08:52]  * apw shuts up :)
[08:52] <cjwatson> I'm saying that you can't spot the vanished-binary problem just from published indexes, because individual binaries from a source can be deliberately deleted
[08:53] <cjwatson> (And it would be incorrect to make the assumption that *all* binaries from a given source vanish when this bug is triggered)
[08:54] <juliank> So should we wait more or is it safe to conclude that copying it back did not work?
[08:54] <cjwatson> I'm afraid grepping logs in this case is not going to be useful, because it was a double-override and overrides aren't well-logged
[08:54] <cjwatson> juliank: copying works
[08:54] <cjwatson> You can see it in https://launchpad.net/ubuntu/xenial/amd64/unattended-upgrades
[08:54] <apw> juliank, the launchpad side says it is back
[08:55] <juliank> I see it there, sure, I'm just waiting for it to be back in rmadison :)
[08:56] <cjwatson> Publishing is not terribly instant
[08:56] <cjwatson> It'll get there
[08:57]  * juliank adds a watch -n60
[08:57] <juliank> Gotta retry some autopkgtests once it's there :)
[08:58] <cjwatson> apw: Superseded-by-self is valid because that's how overrides work
[08:58] <apw> cjwatson, would there then not be a further Pending/Published record after ?
[08:58] <cjwatson> Sure, but that's harder to check :)
[08:59] <cjwatson> If we can work out the correct logic then we might just as well fix the actual dominator bug rather than writing complicated workaround monitoring scripts
[09:01] <juliank> it has arrived :)
[09:26] <apw> i think i just had unattended-upgrades try and upgrade itself; and it did not go well
[09:45]  * cjwatson tries to understand the dominator
[09:46] <cjwatson> It looks correct ...
[09:46] <cjwatson> I guess I could try setting up a matching situation in the test suite though
[09:51] <LocutusOfBorg> anybody, please hit gazebo! autopkgtest for gazebo/9.6.0-1build1: amd64: Pass, arm64: Regression ♻ , armhf: Regression ♻ , i386: Pass, ppc64el: Regression ♻ , s390x: Always failed
[09:51] <LocutusOfBorg> it fails on arm64, armhf, ppc64el because the binary doesn't exist there anymore...
[09:51] <LocutusOfBorg> (and it won't exist for long time, hopefully never)
[10:25] <cjwatson> Oh
[10:25] <cjwatson> Is it that easy
[10:37] <LocutusOfBorg> isn't it?
[10:37] <cjwatson> I mean the double-override bug
[10:38] <apw> cjwatson, oh cornered it by accident ?
[10:38] <cjwatson> Well not so much by accident, I was aiming at it
[10:39] <cjwatson> But it actually looks quite easy now that I've narrowed it down
[10:40] <cjwatson> I'll run some more tests though
[10:41]  * apw hands cjwatson a snap-trap ...
[10:41] <cjwatson> We've only ever seen this on arch: all binaries, right?
[10:41] <cjwatson> Those are all the examples I can find in remotely-recent IRC history, at least
[10:44] <apw> cjwatson, i don't think i remember in enough detail
[10:50] <LocutusOfBorg> oh... it wasn't an answer to me lol, I just figured it out
[10:52] <cjwatson> Yeah, sorry, overlapping conversations
[12:15] <LocutusOfBorg> its me being sorry, I thought the conversation was over, after some minutes of idling :)
[12:16] <LocutusOfBorg> force-badtest gazebo/all/arm64 gazebo/all/armhf gazebo/all/ppc64el <-- please because NBS there
[17:35] <bdmurray> cpaelzer: bug 1819207 is in the Launchpad-Bugs-Fixed for open-vm-tools in the cosmic unapproved queue so that bug will get modified. Is that what you want?
[17:35] <ubot5> bug 1819207 in ubuntu-drivers-common (Ubuntu Disco) "[FFe] Add Modaliases to open-vm-tools-desktop to allow automatic installation by ubuntu-drivers" [High,Fix released] https://launchpad.net/bugs/1819207
[17:46] <bdmurray> tsimonq2: Can you add ubuntu package tasks and test cases for bug 1530697, bug 1744861, bug 1789059, bug 1805559
[17:46] <ubot5> bug 1530697 in Mixxx "qt5: GLSL renderers draw signal at wrong scale and position" [Medium,Fix released] https://launchpad.net/bugs/1530697
[17:46] <ubot5> bug 1744861 in Mixxx "skin does not scale for high resolution screens with Qt5" [Critical,Fix released] https://launchpad.net/bugs/1744861
[17:46] <ubot5> bug 1789059 in Mixxx "continual GUI freeze" [Critical,Fix released] https://launchpad.net/bugs/1789059
[17:46] <ubot5> bug 1805559 in Mixxx "Xlib deadlock in GUI thread" [Critical,Fix released] https://launchpad.net/bugs/1805559
[17:55] <vorlon> Laney: nothing's been done that would turn off updating of autopkgtest indices for trusty, has it?  I was looking for new test results on http://autopkgtest.ubuntu.com/packages/l/lxc/trusty/ppc64el and http://autopkgtest.ubuntu.com/packages/g/glib-networking/trusty/ppc64el (et al) to see what gnutls26's state actually is
[17:55] <vorlon> and the test results haven't shown
=== jdstrand_ is now known as jdstrand
[19:44] <Trevinho> hey, bdmurray could you have a look at the mutter/gnome-shell SRU, as it's waiting for some weeks now (as previous package was there before than the re-upload). Thanks :)
[19:46] <bdmurray> Trevinho: For what release?
[19:46] <Trevinho> bionic
[19:46] <bdmurray> I'll have a look
=== TJ_Remix is now known as TJ-
[20:25] <bdmurray> Trevinho: bug 1827029 is missing mutter tasks
[20:25] <ubot5> bug 1827029 in gnome-shell (Ubuntu Cosmic) "Extended characters in OSK don't get entered" [Medium,In progress] https://launchpad.net/bugs/1827029
[20:25] <Trevinho> bdmurray: fixed
[20:25] <Trevinho> and thanks for looking into this
[20:26] <bdmurray> Trevinho: was d/p/clutter-Smooth-out-master-clock-to-smooth-visuals.patch superseded by daniel's other changes?
[20:27] <Trevinho> bdmurray: yes
[20:28] <Trevinho> bdmurray: here's the rationale https://git.launchpad.net/~3v1n0/ubuntu/+source/mutter/commit/?h=ubuntu/bionic&id=05baba0d0a78775f18d9e16e8f7d074bcbe86cf5
[20:38] <bdmurray> Trevinho: also the NEWS file lists a fair number of changes were those part of 3.28.3+git20190124?
[20:39] <Trevinho> bdmurray: yes, basically is almost the same. However since upstream did a new release, we decided to merge with it
[20:41] <Trevinho> bdmurray: these are the changes from git version to 3.28.4 in mutter https://git.launchpad.net/~3v1n0/ubuntu/+source/mutter/commit/?h=ubuntu/bionic&id=becbb8ffd09d9fd6b1ee38505ad21560c5fdb226 and shell https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-shell/commit/?h=ubuntu/bionic&id=c04b315d13b603743f2ae84a009cc900568674ed
[20:41] <Trevinho> as you can see, a part the autotools stuff there's not much change