[08:47] <lubot> <RikMills> retrying some tests anyway
[08:48] <lubot> <RikMills> qcustomplot seems to be falling foul more more depreciated functions?
[08:48] <lubot> <mitya57> @RikMills [retrying some tests anyway], I also retried some an hour ago.
[08:48] <lubot> <RikMills> oops
[08:48] <lubot> <mitya57> @RikMills [qcustomplot seems to be falling foul some more depreciated functions?], Yes, filed debian #976062
[08:48] <ubottu> Debian bug 976062 in src:qcustomplot "qcustomplot autopkgtest fails with Qt 5.15.2: stderr: warning: ‘QRect QPrinter::pageRect() const’ is deprecated" [Important,Open] http://bugs.debian.org/976062
[08:49] <lubot> <RikMills> aha. I looked at bug reprts just before you filed that!
[08:50] <lubot> <RikMills> qcustomplot does not seem maintained much more upstream, so more patching I guess
[08:50] <lubot> <mitya57> When it is the only failing test in Ubuntu (or one of few), and still not fixed in Debian, I will upload a fix to Ubuntu
[08:51] <lubot> <RikMills> great :)
[08:51] <lubot> <mitya57> @RikMills [qcustomplot does not seem maintained much more upstream, so more patching I gues …], I wrote in the bug: … Now I think that the previously chosen strategy of fixing all deprecation … warnings was bad, and the tests should just use -Wno-deprecated-declarations.
[08:51] <lubot> <RikMills> makes sense
[08:51] <lubot> <RikMills> not finished my ☕️ yet, so did not notice that
[08:52] <lubot> <mitya57> @RikMills [qcustomplot does not seem maintained much more upstream, so more patching I gues …], https://gitlab.com/DerManu/QCustomPlot/-/commits/dev-2.1.0/ — last commits in May, so not 100% dead in my opinion. … But merge requests are disabled, so no easy way to forward a patch 😡
[08:53] <lubot> <RikMills> I could not immediately find a bugtracker either
[08:55] <lubot> <mitya57> There is a [forum](https://www.qcustomplot.com/index.php/support/forum), but I will leave it to Debian maintainer to forward the patches there if he wants
[08:56] <lubot> <mitya57> And it doesn't even support attachments
[08:57] <lubot> <RikMills> ok. kbibtex can be removed from proposed until a fixed version is available to sync, if that needed. though careful triggers may also work on the problem architctures
[08:59] <lubot> <RikMills> I misread the changlog when I synced, otherwise I never would have :/
[09:00] <lubot> <mitya57> If it build-depends on webengine now, maybe better to ask for removing old binaries on ppc64el/s390x/riscv64?
[09:03] <lubot> <RikMills> @mitya57 [If it build-depends on webengine now, maybe better to ask for removing old binar …], it is 'optional' on webengine, so it can just be be built on not qtwebengine arches without. e.g. qtwebengine-dev [amd64 amm64 armhf ] in build deps
[09:03] <lubot> <RikMills> but not sure which way the debian uploader is going to go
[09:04] <lubot> <RikMills> see: https://salsa.debian.org/science-team/kbibtex/-/commit/b183db4ef79f7ce36ddde34c8e6b425839b72855#note_204869
[09:05] <lubot> <mitya57> Ah, right. He changed to qtwebengine5-dev but didn't add architectures limit
[09:06] <lubot> <RikMills> plus I am not sure the autopkgtests in the new version are not broken in ubuntu. they failed for the arches that did build
[09:06] <lubot> <RikMills> against the new version itself
[09:08] <lubot> <mitya57> `The X11 connection broke (error 1). Did the X11 server die?`
[09:09] <lubot> <RikMills> plus they have never passed on debian CI
[09:10] <lubot> <mitya57> Ok. But why are Qt tests run against kbibtex in proposed? Because they fall back to all-proposed=1? Maybe a clever set of triggers will prevent that?
[09:10] <lubot> <RikMills> Fwd from RikMills: ok. kbibtex can be removed from proposed until a fixed version is available to sync, if that needed. though careful triggers may also work on the problem architctures
[09:10] <lubot> <RikMills> @mitya57 [Ok. But why are Qt tests run against kbibtex in proposed? Because they fall back …], that is what I meant there ^
[09:10] <lubot> <mitya57> Ah :)
[09:13] <lubot> <mitya57> Please do it then, I believe in your powers more than in mine :)
[09:17] <lubot> <RikMills> I will try to work them out later then. requires some manual checking of which test dependencies are really needed in proposed versions
[11:31] <lubot> <RikMills> tried with the automated triggers from retry-autopkgtest-regressions, but those failed
[11:31] <lubot> <RikMills> retried now with triggers worked out from the testbed, and I think that probably worked
[11:33] <lubot> <RikMills> one of them passed anyway. sadly on the test running page the output goes past way too fast on s390x/ppc64el
[11:33] <lubot> <mitya57> @RikMills [retried now with triggers worked out from the testbed, and I think that probably …], Good! There are not so many failures, so there is even a chance to get everything migrated before the transition happens in Debian.
[11:34] <lubot> <mitya57> @RikMills [one of them passed anyway. sadly on the test running page the output goes past w …], Maybe ppc64el runners should be replaced with some riscv64 ones 😂
[11:34] <lubot> <RikMills> would be good :)
[11:48] <lubot> <RikMills> @RikMills [would be good :)], getting the transition through, not the riscv64 test runners! 🤣
[15:59] <lubot> <RikMills> software-properties armhf test for pyqt5 just passed 🍻
[15:59] <lubot> <RikMills> (Photo, 1168x827) https://i.imgur.com/m5UzKDb.jpg
[16:00] <lubot> <mitya57> Great!
[16:00] <lubot> <mitya57> Looks like I need to upload qcustomplot today?
[16:01] <lubot> <mitya57> Ah, qcustomplot is fixed in Debian now. So it will be autosynced.
[16:02] <lubot> <RikMills> fantastic!
[16:02] <lubot> <RikMills> I think there is a chance to get this through then
[16:02] <lubot> <mitya57> Yes
[16:03] <lubot> <RikMills> Assuming something is not hiding in excuses like last time
[16:30] <lubot> <RikMills> (Photo, 1235x217) https://i.imgur.com/1wJNbyA.jpg This was hiding!
[16:30] <lubot> <RikMills> triggered retry
[16:32] <lubot> <mitya57> When I checked a few hours ago, there was some test running for LO on armhf
[16:33] <lubot> <RikMills> one against just 'qtbase-opensource-src-gles/5.15.2+dfsg-1 qtbase-opensource-src/5.15.2+dfsg-1' recently passed
[16:33] <lubot> <mitya57> Right, just saw that.
[16:36] <lubot> <RikMills> the britney out also suggests that qgis is still being 'grouped' with the landing ppa. perhaps it should have been deleted from the ppa and ticket once manually copied. or maybe it won't matter in the end. the new britney output is confusing
[16:38] <lubot> <RikMills> I: [2020-11-29T16:06:04+0000] - sourceppa: processing analitza, found invalid grouped package qgis/3.10.11+dfsg-1ubuntu3, will invalidate set
[16:39] <lubot> <RikMills> I am hoping britney will just say 'never mind' when nothing else blocks things
[16:40] <lubot> <mitya57> @RikMills [the britney output also suggests that qgis is still being 'grouped' with the lan …], I wonder if it will help if I delete it from PPA now. Or I can delete the PPA itself
[16:42] <lubot> <RikMills> I don't know. maybe just remove from the PPA and the ticket as a 1st try?
[16:43] <lubot> <mitya57> Deleted from PPA. The ticket should probably update automatically on next status run
[17:52] <lubot> <mitya57> @RikMills Your kxmlgui triggers didn't include qtbase-opensource-src-gles?
[17:53] <lubot> <mitya57> (On ppc64el/s390x)
[17:59] <lubot> <RikMills> I don't think I retried kxmlgui. do you mean kbibtex?
[18:00] <lubot> <RikMills> if so, then looks like no
[18:01] <lubot> <mitya57> Right, kbibtex, sorry.
[18:01] <lubot> <mitya57> I will trigger a new test with the same triggers + gles then
[18:02] <lubot> <RikMills> ok. I forgot about -gles obviously
[19:19] <lubot> <mitya57> My tests with gles passed, but kxmlgui had wrong version in triggers. So one more run of these tests is needed (triggered).
[19:20] <lubot> <mitya57> (this time I really meant kxmlgui 😄)
[19:23] <lubot> <mitya57> And qcustomplot will be probably synced at 11 pm UTC
[20:02] <lubot> <RikMills> @mitya57 [My tests with gles passed, but kxmlgui had wrong version in triggers. So one mor …], I don't think you need to, as regardless of the kxmlgui version triggered, it passed against the proposed version of qtbase-*gles
[20:03] <lubot> <RikMills> plus if you look at the actual package versions reported installed for the test, it picked the ubuntu2 kxmlgui from proposed anyway
[20:04] <lubot> <RikMills> (Photo, 1020x654) https://i.imgur.com/m5nyv5R.jpg
[20:04] <lubot> <RikMills> which is why the tests I triggered worked, even though I did against the wrong kxmlgui as well
[20:09] <lubot> <mitya57> @RikMills [I don't think you need to, as regardless of the kxmlgui version triggered, it pa …], Without this kxmlgui was not a valid candidate
[20:10] <lubot> <mitya57> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui
[20:11] <lubot> <RikMills> I would swear I went through that part of excuses!
[20:11] <lubot> * RikMills goes to specsavers
[20:13] <lubot> <mitya57> But after next Britney run it will be a valid candidate :)
[20:13] <lubot> <RikMills> @RikMills [/me goes to specsavers], https://www.youtube.com/watch?v=I3MUX3V0aUE
[20:14] <lubot> <mitya57> :D
[20:17] <lubot> <RikMills> libreoffice armhf test still running. that is the one that could most delay things if it flakes out
[20:19] <lubot> <mitya57> The Debian transition won't happen until tomorrow evening (I haven't got a green light yet). So we have time at least until tomorrow 23 UTC.
[20:20] <lubot> <mitya57> Maybe much more, the release team doesn't always reply quickly
[20:23] <lubot> <RikMills> actually, doesn't appear that qtx11extras-opensource-src depends on the Qt ABI, so perhaps it might not block anyway
[20:28] <lubot> <mitya57> But grouping by PPA will block it maybe?
[20:28] <lubot> <mitya57> Anyway, /me goes sleeping
[20:31] <lubot> <RikMills> night, and thanks!
[23:19] <lubot> <RikMills> libreoffice passed
[23:19] <lubot> <RikMills> qcustomplot  synced