[10:01] <juliank> rbalint: So, bug 1871268 is a regression from bug 835625 sort of
[10:01] <ubottu> bug 1871268 in apt (Ubuntu Focal) "Installation fails when "Install Third-Party Drivers" is selected" [High,Confirmed] https://launchpad.net/bugs/1871268
[10:01] <ubottu> bug 835625 in apt (Ubuntu Oneiric) "apt may try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg" [High,Fix released] https://launchpad.net/bugs/835625
[10:02] <juliank> rbalint: We needed to change the code to unpack packages in the correct order in lock-step, but it was additionally also changed to do the same for configuration, even though that is not strictly necessary
[10:06] <juliank> rbalint: Together with the immediate configuration nastiness, this causes the bug
[10:07] <juliank> rbalint: So I turned off lock-step configuration for immediately configured packages in https://salsa.debian.org/apt-team/apt/-/merge_requests/133
[10:07] <juliank> which solves the issue
[10:24] <juliank> Discussing this vs other solution which just ignores failures to configure in lockstep
[10:25] <juliank> well blurting it out in #debian-apt and waiting for feedback
[10:28] <juliank> oh https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618288
[10:28] <ubottu> Debian bug 618288 in apt "apt doesn't honor multiarch version requirements when configuring" [Important,Fixed]
[11:04] <Laney> If someone like bdmurray is planning to update tzdata to the new release, please be aware of https://gitlab.gnome.org/GNOME/glib/-/issues/2219
[11:13] <doko> rafaeldtinoco: could you have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/o/open-iscsi/20201007_143730_f9b7c@/log.gz  (cannot be triggered by the dependency package)
[12:50] <rafaeldtinoco> doko: sure
[14:33] <seb128> bdmurray, hey, are retracers known to have problems on 20.10? loading the weekly view it seems the reports that started in 20.10 all fail to have a stacktrace
[14:33] <seb128> https://errors.ubuntu.com/?release=Ubuntu%2020.10&period=week
[14:42] <bdmurray> Laney: noted, thanks
[14:42] <bdmurray> seb128: I'll have a look later today
[14:42] <seb128> bdmurray, thanks, I'm trying to poke at log since I've access now
[14:42] <bdmurray> oh yeah, that's right
[14:43] <seb128> bdmurray, what's the first argument of your result.sh script?
[14:43] <seb128> START=$1
[14:43] <bdmurray> the date around when the crash would have been retraced
[14:43] <bdmurray> eg 20200918
[14:43] <seb128> so a date like 20200925?
[14:43] <seb128> k
[14:43] <seb128> thanks
[14:44] <bdmurray> $2 = arch
[14:44] <seb128> right, the one others are more obvious :)
[14:55] <seb128> bdmurray, nothing obvious from the logs from what I can tell, is there any easy way to trigger a retry on an oopsid maybe in manual mode to see the apport-retracer output?
[14:59] <bdmurray> seb128: you could look for a recent crash that failed for 20.10 that says something like 'Saved OOPS ... manual investigation'.
[14:59] <bdmurray> seb128: then we could ask IS for those crash files
[15:02] <seb128> bdmurray, hum, k, most of those have what seems a valid reason, like outdated packages, I'm a bit lost of how to poke more efficiently but if you have a go at it let me know what you do, maybe I can do better next time
[15:04] <bdmurray> seb128: It might help if you told me some specific buckets or OOPSes you looked at
[15:08] <seb128> bdmurray, I basically tried https://errors.ubuntu.com/?release=Ubuntu%2020.10&period=week from the top
[15:08] <seb128> so
[15:08] <seb128> https://errors.ubuntu.com/problem/5a56214a25fff7acaadab83596f28ca48b2c3a4a
[15:08] <seb128> https://errors.ubuntu.com/problem/9ace446c7efa9e848ba843abc8bd6c0809db511f
[15:08] <seb128> https://errors.ubuntu.com/problem/2e25f5d3e7aa6566a2835e57283e0a9c279cc131
[15:09] <seb128> then picked some other components in case it makes a difference
[15:09] <seb128> https://errors.ubuntu.com/problem/a1ed5547f529129d60f520d80ee1d5c3d1588c3f
[15:09] <seb128> https://errors.ubuntu.com/problem/8001aea69f50d0d8ffc8ba90729856ada2f629a7
[15:09] <seb128> https://errors.ubuntu.com/problem/eddba3341754bbda4a3276338e8a79ebd4cb6c1d
[15:24] <bdmurray> seb128: last week we talked about updating the ubiquity translations templates for the active directory strings y'all added. Is that something the desktop team can do?
[15:28] <seb128> bdmurray, those things would be easier if coredev had commit access to the vcs...
[15:31] <seb128> bdmurray, https://code.launchpad.net/~seb128/ubiquity/+git/ubiquity/+merge/391994
[15:31] <seb128> bdmurray, if you want to merge, I don't have access
[15:40] <seb128> juliank, is that new that we call update-motd-updates-available after each apt install? it creates a noticable delay after packages installation on my groovy system, quite annoying
[15:40] <juliank> seb128: Maybe? I didn't do it :)
[15:42] <seb128> k
[15:43] <juliank> seb128: Investigation shows we do since timestamp: Tue 2016-04-12 11:26:52 +0100 to fix LP: #1558270
[15:43] <ubottu> Launchpad bug 1558270 in Ubuntu on IBM z Systems "[Ubuntu 16.04] update-notifier motd doesn't update with apt full-upgrade" [Medium,Fix released] https://launchpad.net/bugs/1558270
[15:43] <seb128> k, I wonder if that became slower for some reasons
[15:44] <bdmurray> seb128: I don't have access either so I guess we should sort this out!
[15:44] <seb128> bdmurray, can you find someone in foundations to figure that out?
[15:45] <juliank> seb128: apt-check which is run by it takes 1.3s here which is not entirely optimal, but not a regression since focal
[15:45] <juliank> and it's not possible to go faster in python
[15:45] <juliank> Maybe in groovy+1
[15:45] <juliank> I need to add better APIs to python-apt
[15:45] <bdmurray> seb128: yeah, we'll discuss it
[15:45] <seb128> bdmurray, thanks, meanwhile the mp is up for review so hopefully someone from the ubiquity team notice and get it merged
[15:46] <juliank> heh no, it actually uses the depcache so 1s for opening the depcache it can't get rid off :/
[15:49] <bdmurray> jibel: Could do it!
[18:48] <seb128> bdmurray, small status update on ubiquity/active directory strings, L_aney merged my changes, I uploaded the updated template directly to launchpad to avoid waiting for the next upload and I emailed translators to let them know the new strings are available on launchpad now
[18:50] <bdmurray> seb128: great, thanks
[18:50] <seb128> np!
[19:05] <mwhudson> docker: Error response from daemon: AppArmor enabled on system but the docker-default profile could not be loaded: strconv.Atoi: parsing "0-beta1": invalid syntax. <- ring any bells for anyone?
[19:08] <jdstrand> mwhudson: yes
[19:08] <jdstrand> we did an upload for that
[19:08]  * jdstrand looks
[19:09] <jdstrand> mwhudson: did the 19.03.13-0ubuntu1 upload drop amurray's patch in 19.03.11-0ubuntu3?
[19:09] <jdstrand> mwhudson: it did
[19:10] <jdstrand> diff -Nru docker.io-19.03.11/debian/patches/series docker.io-19.03.13/debian/patches/series
[19:10] <jdstrand> --- docker.io-19.03.11/debian/patches/series	2020-09-01 01:10:54.000000000 +0000
[19:10] <jdstrand> +++ docker.io-19.03.13/debian/patches/series	1970-01-01 00:00:00.000000000 +0000
[19:10] <jdstrand> @@ -1 +0,0 @@
[19:10] <udevbot> Error: "@" is not a valid command.
[19:10] <jdstrand> -handle-apparmor-beta-version-suffix.patch
[19:11] <jdstrand> mwhudson: you want this: https://launchpadlibrarian.net/495816608/docker.io_19.03.11-0ubuntu2_19.03.11-0ubuntu3.diff.gz
[19:11] <jdstrand> mwhudson: note, we are planning a new apparmor upload with the final release tarball so this will go away, but that won't be until next week
=== hlmjr is now known as herbmillerjr
[19:28] <mwhudson> jdstrand: oh whoops
[19:30] <mwhudson> yay for autopkgtest i guess
[19:35] <jdstrand> heh, indeed :)
[19:57] <tdaitx> who knows about availability of popcon historical data? there was a question about it in discourse: https://discourse.ubuntu.com/t/popcon-to-be-removed-from-the-standard-seed/17238/4
[20:16] <vorlon> tdaitx: checking the server, we have some logs in a directory called logs/all-popcon-results/ that are listed by date.  We could perhaps expose them, though the inquiry there is about using them for research... and I don't see how they're going to learn anything interesting from this data :)
[20:17] <tdaitx> vorlon: neither do I, but that was what they asked for, if we have it and it is ok (and easy) to share, then I don't see why we shouldn't