/srv/irclogs.ubuntu.com/2020/10/08/#ubuntu-devel.txt

juliankrbalint: So, bug 1871268 is a regression from bug 835625 sort of10:01
ubottubug 1871268 in apt (Ubuntu Focal) "Installation fails when "Install Third-Party Drivers" is selected" [High,Confirmed] https://launchpad.net/bugs/187126810:01
ubottubug 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/83562510:01
juliankrbalint: 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 necessary10:02
juliankrbalint: Together with the immediate configuration nastiness, this causes the bug10:06
juliankrbalint: So I turned off lock-step configuration for immediately configured packages in https://salsa.debian.org/apt-team/apt/-/merge_requests/13310:07
juliankwhich solves the issue10:07
juliankDiscussing this vs other solution which just ignores failures to configure in lockstep10:24
juliankwell blurting it out in #debian-apt and waiting for feedback10:25
juliankoh https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61828810:28
ubottuDebian bug 618288 in apt "apt doesn't honor multiarch version requirements when configuring" [Important,Fixed]10:28
LaneyIf someone like bdmurray is planning to update tzdata to the new release, please be aware of https://gitlab.gnome.org/GNOME/glib/-/issues/221911:04
dokorafaeldtinoco: 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
rafaeldtinocodoko: sure12:50
seb128bdmurray, 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 stacktrace14:33
seb128https://errors.ubuntu.com/?release=Ubuntu%2020.10&period=week14:33
bdmurrayLaney: noted, thanks14:42
bdmurrayseb128: I'll have a look later today14:42
seb128bdmurray, thanks, I'm trying to poke at log since I've access now14:42
bdmurrayoh yeah, that's right14:42
seb128bdmurray, what's the first argument of your result.sh script?14:43
seb128START=$114:43
bdmurraythe date around when the crash would have been retraced14:43
bdmurrayeg 2020091814:43
seb128so a date like 20200925?14:43
seb128k14:43
seb128thanks14:43
bdmurray$2 = arch14:44
seb128right, the one others are more obvious :)14:44
seb128bdmurray, 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
bdmurrayseb128: you could look for a recent crash that failed for 20.10 that says something like 'Saved OOPS ... manual investigation'.14:59
bdmurrayseb128: then we could ask IS for those crash files14:59
seb128bdmurray, 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 time15:02
bdmurrayseb128: It might help if you told me some specific buckets or OOPSes you looked at15:04
seb128bdmurray, I basically tried https://errors.ubuntu.com/?release=Ubuntu%2020.10&period=week from the top15:08
seb128so15:08
seb128https://errors.ubuntu.com/problem/5a56214a25fff7acaadab83596f28ca48b2c3a4a15:08
seb128https://errors.ubuntu.com/problem/9ace446c7efa9e848ba843abc8bd6c0809db511f15:08
seb128https://errors.ubuntu.com/problem/2e25f5d3e7aa6566a2835e57283e0a9c279cc13115:08
seb128then picked some other components in case it makes a difference15:09
seb128https://errors.ubuntu.com/problem/a1ed5547f529129d60f520d80ee1d5c3d1588c3f15:09
seb128https://errors.ubuntu.com/problem/8001aea69f50d0d8ffc8ba90729856ada2f629a715:09
seb128https://errors.ubuntu.com/problem/eddba3341754bbda4a3276338e8a79ebd4cb6c1d15:09
bdmurrayseb128: 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
seb128bdmurray, those things would be easier if coredev had commit access to the vcs...15:28
seb128bdmurray, https://code.launchpad.net/~seb128/ubiquity/+git/ubiquity/+merge/39199415:31
seb128bdmurray, if you want to merge, I don't have access15:31
seb128juliank, 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 annoying15:40
juliankseb128: Maybe? I didn't do it :)15:40
seb128k15:42
juliankseb128: Investigation shows we do since timestamp: Tue 2016-04-12 11:26:52 +0100 to fix LP: #155827015:43
ubottuLaunchpad 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/155827015:43
seb128k, I wonder if that became slower for some reasons15:43
bdmurrayseb128: I don't have access either so I guess we should sort this out!15:44
seb128bdmurray, can you find someone in foundations to figure that out?15:44
juliankseb128: apt-check which is run by it takes 1.3s here which is not entirely optimal, but not a regression since focal15:45
juliankand it's not possible to go faster in python15:45
juliankMaybe in groovy+115:45
juliankI need to add better APIs to python-apt15:45
bdmurrayseb128: yeah, we'll discuss it15:45
seb128bdmurray, thanks, meanwhile the mp is up for review so hopefully someone from the ubiquity team notice and get it merged15:45
juliankheh no, it actually uses the depcache so 1s for opening the depcache it can't get rid off :/15:46
bdmurrayjibel: Could do it!15:49
seb128bdmurray, 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 now18:48
bdmurrayseb128: great, thanks18:50
seb128np!18:50
mwhudsondocker: 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
jdstrandmwhudson: yes19:08
jdstrandwe did an upload for that19:08
* jdstrand looks19:08
jdstrandmwhudson: did the 19.03.13-0ubuntu1 upload drop amurray's patch in 19.03.11-0ubuntu3?19:09
jdstrandmwhudson: it did19:09
jdstranddiff -Nru docker.io-19.03.11/debian/patches/series docker.io-19.03.13/debian/patches/series19:10
jdstrand--- docker.io-19.03.11/debian/patches/series2020-09-01 01:10:54.000000000 +000019:10
jdstrand+++ docker.io-19.03.13/debian/patches/series1970-01-01 00:00:00.000000000 +000019:10
jdstrand@@ -1 +0,0 @@19:10
udevbotError: "@" is not a valid command.19:10
jdstrand-handle-apparmor-beta-version-suffix.patch19:10
jdstrandmwhudson: you want this: https://launchpadlibrarian.net/495816608/docker.io_19.03.11-0ubuntu2_19.03.11-0ubuntu3.diff.gz19:11
jdstrandmwhudson: 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 week19:11
=== hlmjr is now known as herbmillerjr
mwhudsonjdstrand: oh whoops19:28
mwhudsonyay for autopkgtest i guess19:30
jdstrandheh, indeed :)19:35
tdaitxwho 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/419:57
vorlontdaitx: 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
tdaitxvorlon: 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't20:17

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!