[02:15] <mwhudson> @pilot out
[05:11] <David_Hedlund> How do I show this update icon in the panel?: https://askubuntu.com/questions/1149772/ubuntu-update-notifier-keeps-showing
[07:34] <adrien> rah, by the time the tests for these rust packages succeeded, another rust package came in and stuck everything again :D
[08:27] <adrien> can someone re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=rust-oauth2&trigger=rust-reqwest%2F0.11.14-2&trigger=rust-oauth2%2F4.4.1-2&trigger=rust-base64%2F0.21.2-1&trigger=rust-rustls-pemfile%2F1.0.2-1 ? and actually this is needed for arm64 and armhf too
[08:27] <adrien> these things are painful to craft
[08:28] <seb128> adrien, triggered
[08:30] <adrien> thanks
[08:56] <David_Hedlund> Can anyone please have a look at this?: Indicator Applet Complete: update-notifier is displayed for Trisquel 11 but not for Ubuntu MATE 23.04 #79 - https://github.com/mate-desktop/mate-indicator-applet/issues/79
[08:56] -ubottu:#ubuntu-devel- Issue 79 in mate-desktop/mate-indicator-applet "Indicator Applet Complete: update-notifier is displayed for Trisquel 11 but not for Ubuntu MATE 23.04" [Open]
[10:06] <adrien> looks like everything passed but I hate when update_excuses is updated with only part of the results
[10:31] <adrien> hmmm, maybe that when doing such package=A&trigger=B&trigger=C, we also need package=B&trigger=C&trigger=A and package=C&trigger=A&trigger=B
[10:37] <adrien> can someone re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=rust-rustls&trigger=rust-rustls-pemfile/1.0.2-1&trigger=rust-base64/0.21.2-1 ? same on arm64, armhf, ppc64el and s390x (everything but i386)
[10:38] <adrien> I'm not entirely sure I understand this one so I'm reuing a previous trigger which failed but maybe there were other causes back then and they're now solved and impossible to look at now
[10:38] <seb128> adrien, no, when you do A&B&C and it's green then it's flagged as ok for A, B and C
[10:39] <seb128> adrien, what's the issue you are trying to investigate?
[10:43] <adrien> seb128: rust packages seem to have a special "issue" where rust-foo and librust-foo-dev can be pulled with incompatible versions; that has been blocking several things and was apparently not a (widely) well-known failure cause
[10:44] <adrien> I thought the one two hours ago was going to be enough to make a whole bunch of rust packages to migrate (actually, the one from yesterday would have been enough if a new version of a related package hadn't been sync'ed at the same time)
[10:44] <adrien> right now for rust-rustls-pemfile there are "badpkg" errors on all arches ( https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#rust-rustls-pemfile )
[10:46] <adrien> (hmmm, hold on a minute)
[10:47] <adrien> right, so
[10:48] <seb128> adrien, I've retried the one you just asked for, let's see how it's working
[10:49] <adrien> and https://autopkgtest.ubuntu.com/results/autopkgtest-mantic/mantic/amd64/r/rust-rustls/20230615_132556_28493@/log.gz says "Broken autopkgtest-satdep:amd64 Depends on librust-base64-0.13+default-dev:amd64 < none @un H >" but triggers included "rust-rustls-pemfile/1.0.2-1 rust-base64/0.21.2-1" which is what I'm expecting to be the right set
[10:49] <adrien> but that would be the right set now while the last time this was tried was a week ago
[10:49] <adrien> thanks :)
[10:50] <seb128> np!
[10:50] <adrien> tbh I'm not exactly enjoying crafting triggers; it's a bit time-consuming and it's very annoying to do; if that happens again in the future, we'll certainly want to improve something somewhere
[10:50] <seb128> another hammer is all_proposed=1
[10:52] <adrien> that could make sense here; I'd like to see if this is manageable with well-crafted triggers and if it helps to do this earlier on when there are fewer packages in the cluster that is trying to migrate
[10:53] <seb128> adrien, you could also use
[10:53] <seb128> $ ./retry-autopkgtest-regressions --blocked-by-tests rust-rustls
[10:53] <seb128> https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=rust-rustls&trigger=rust-rustls-pemfile%2F1.0.2-1
[10:53] <seb128> https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=arm64&package=rust-rustls&trigger=rust-rustls-pemfile%2F1.0.2-1
[10:54] <seb128> and script around, but yes it's not always fun :/
[10:58] <adrien> I've written something on monday to analyze logs and maybe I could extract errors from the logs and try to re-use the version numbers but I'm not very confident it would work reliably (I'm finding it difficult to reason about it for now at least, and I'm not sure I can write code that is smarter than throwing versions around and hoping for the best)
[11:35] <adrien> hmpf, this failed with the same error: I don't know why it's still referring to rust-base64 0.13
[11:37] <adrien> the build of rust-rustls used rust-base64 0.13.1-1
[11:38] <adrien> does that requires a new build of rust-rustls using some specific setting?
[11:38] <adrien> schopin: ^
[11:39] <schopin> adrien: rust library packages pretty much never require no-change rebuilds (they basically only package the source, but do try to build them first as a sanity check)
[11:41] <adrien> :'( I was hoping that would be an easy explanation; I'll need to dig deeper
[11:41] <adrien> thanks
[11:41] <adrien> (but first probably: food)
[11:43] <schopin> Ooooh. rustls isn't maintained by the Debian Rust team.
[11:45] <schopin> OK, this is confusing. There's some packaging work done in debcargo-conf (the Rust team's monorepo), but the changelog of the package we have in the archive is completely different.
[11:48] <schopin> adrien: this should tell you everything you need. I'll incorporate the patch in a 4ubuntu1 version shortly. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038420
[11:48] -ubottu:#ubuntu-devel- Debian bug 1038420 in rust-rustls "rust-rustls - autopkgtest failure with new base64." [Serious, Open]
[11:50] <adrien> thanks for having a look! :)
[11:51] <adrien> I wasn't sure at first that making a version specifically for this was worth it but considering the triggers required, it's probably best to do it now before something else is synced; thans again :)
[12:38] <schopin> adrien: the bug isn't a week old, so we might just want to open an update-excuse bug and revisit the issue later if it isn't fixed in Debian.
[12:44] <adrien> yes but I wouldn't mind that the cluster migrates; but whether or not you want to make a version now is entirely up to you: I know it can be quite time-consuming afterwards
[12:44] <adrien> I'm fine either way because it will also be interesting to see how the cluster "behaves" in the next few days
[13:56] <adrien> schopin: I've only taken a cursory glance but it looks like rust-glib had a lot of troubles with triggers
[13:57] <schopin> adrien: sure. There's a whole bunch of co-dependent crates that all have the same upstream, and thus need to be triggered together. *Someone* just needs to figure out which are the right triggers ;)
[13:59] <adrien> or try all-proposed?
[14:00] <adrien> I can have a look at determining the list but only next week
[14:05] <schopin> adrien: you can try all-proposed but I'm not sure it's going to help britney figure out what should migrate with it.
[14:12] <adrien> I don't think I've ever used it so I have really no idea
[14:12] <adrien> do you think it can still be worth a try? it'll run during the week-end and the infrastructure is lightly loaded
[14:13] <adrien> will the worst result be that we learn a bit more how to handle these situations?
[15:01] <vorlon> @pilot in
[15:03] <enr0n> Can a core dev please retry the following: `retry-autopkgtest-regressions --blocks setuptools -s mantic`?
[15:06] <bdmurray> enr0n: I can do that
[15:06] <enr0n> bdmurray: thanks!
[15:08] <bdmurray> enr0n: Will the MP of ubuntu-release-upgrader you asked for my review on result in an SRU of it?
[15:10] <enr0n> bdmurray: yeah, that's the plan
[15:12] <bdmurray> enr0n: you might look at including the fix for bug 2020414. Although based on my previous research I didn't find any duplicates of it.
[15:12] -ubottu:#ubuntu-devel- Bug 2020414 in ubuntu-release-upgrader (Ubuntu Mantic) "20.04 -> 22.04 upgrade with KDE frontend crashes due to ''str' object has no attribute 'toUtf8''" [High, Fix Released] https://launchpad.net/bugs/2020414
[15:16] <enr0n> bdmurray: okay, if I can easily reproduce that bug on upgrades to Lunar then I will include it
[19:10] <vorlon> @pilot out
[20:30] <enr0n> bdmurray: I was able to reproduce that error message during an upgrade, but it didn't crash or anything. The upgrade completed fine.
[20:31] <bdmurray> enr0n: alright, thanks for looking!
[20:31] <enr0n> no problem