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:01 |
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:02 |
juliank | rbalint: Together with the immediate configuration nastiness, this causes the bug | 10:06 |
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:07 |
juliank | Discussing this vs other solution which just ignores failures to configure in lockstep | 10:24 |
juliank | well blurting it out in #debian-apt and waiting for feedback | 10:25 |
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] | 10:28 |
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:04 |
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) | 11:13 |
rafaeldtinoco | doko: sure | 12:50 |
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:33 |
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:42 |
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:43 |
bdmurray | $2 = arch | 14:44 |
seb128 | right, the one others are more obvious :) | 14:44 |
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:55 |
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 | 14:59 |
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:02 |
bdmurray | seb128: It might help if you told me some specific buckets or OOPSes you looked at | 15:04 |
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:08 |
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:09 |
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:24 |
seb128 | bdmurray, those things would be easier if coredev had commit access to the vcs... | 15:28 |
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:31 |
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:40 |
seb128 | k | 15:42 |
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:43 |
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:44 |
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:45 |
juliank | heh no, it actually uses the depcache so 1s for opening the depcache it can't get rid off :/ | 15:46 |
bdmurray | jibel: Could do it! | 15:49 |
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:48 |
bdmurray | seb128: great, thanks | 18:50 |
seb128 | np! | 18:50 |
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:05 |
jdstrand | mwhudson: yes | 19:08 |
jdstrand | we did an upload for that | 19:08 |
* jdstrand looks | 19:08 | |
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:09 |
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/series2020-09-01 01:10:54.000000000 +0000 | 19:10 |
jdstrand | +++ docker.io-19.03.13/debian/patches/series1970-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:10 |
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 | 19:11 |
=== hlmjr is now known as herbmillerjr | ||
mwhudson | jdstrand: oh whoops | 19:28 |
mwhudson | yay for autopkgtest i guess | 19:30 |
jdstrand | heh, indeed :) | 19:35 |
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 | 19:57 |
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:16 |
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 | 20:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!