[07:24] <RAOF> Hm. Mesa doesn't seem to play nicely with debuginfod.ubuntu.com; I think the source map might not be quite right?
[07:24] <RAOF> gdb can't find any of the source files.
[09:04] <rbasak> RAOF: on which release? Source file indexing depends on a fairly recent patch AIUI.
[09:05] <rbasak> (and won't work on older releases)
[09:06] <RAOF> On mantic. Actually building the package, I *still* can't find the files it's referencing 🤷‍♀️
[09:09] <RAOF> Like, gdb is looking for libegl.c; I can't find that file with that name in a built tree!
[13:23] <vinodwa> rbasak Hi, did you got your questions answered regarding LP#1996229 ? We need this reviewed and approved as soon as possible. Thanks
[13:24] -ubottu:#ubuntu-devel- Launchpad bug 1996229 in python-magnumclient (Ubuntu Focal) "[SRU] magnum ui can not delete the coe cluster" [High, Triaged] https://launchpad.net/bugs/1996229
[14:08] <rbasak> freyes: to check we're not waiting on each other: you're working on answering my questions in bug 1996229, right?
[14:08] -ubottu:#ubuntu-devel- Bug 1996229 in python-magnumclient (Ubuntu Focal) "[SRU] magnum ui can not delete the coe cluster" [High, Triaged] https://launchpad.net/bugs/1996229
[14:08] <freyes> rbasak, yes, I just posted the reply - https://bugs.launchpad.net/ubuntu/+source/magnum-ui/+bug/1996229/comments/5
[14:09] <rbasak> ack, reading
[14:13] <rbasak> freyes: so another class of "Where problems could occur" would be users directly using python3-magnumclient with their own code, right? Has this been considered?
[14:14] <freyes> rbasak, yes, when I was going through the git log I didn't find code removed (e.g. deprecated API removed)
[14:15] <rbasak> Great, thanks
[14:21] <freyes> updated the bug description to include the impacted packages and this aspect of users running custom code with magnumclient as a library
[14:24] <rbasak> freyes: will the CLI for ListCluster (not sure what the command is exactly) now output more columns by default?
[14:24] <rbasak> I'm thinking about https://github.com/openstack/python-magnumclient/commit/74c5f22c6ffb23154f2e0412ba43371f3c02f3b7#diff-f055b476bf7193ad89f9512f8f9d13dc2fe6d32644ea5d8755294d45c8a23ea7
[14:24] -ubottu:#ubuntu-devel- Commit 74c5f22 in openstack/python-magnumclient "Support health_status on client side"
[14:26] <freyes> rbasak, yes, it will
[14:27] <freyes> rbasak, this has been identified as a problem, not showing that column, since operators have no visibility on the cluster's state
[14:27] <freyes> rbasak, the general guideline has been to use the openstackclients snap
[14:28] <freyes> which ships newer versions of the clients (from upstream python tarballs)
[14:29] <freyes> although this change may break bash scripts :-/ I didn't think about it
[14:34] <rbasak> freyes: how configurable is the list CLI currently? Would it be feasible/trivial to make the default not output that column, for example, but make it possible with an option? Or would that be not useful anyway?
[14:35] <rbasak> If you want to deliberately change the output, then that wouldn't be unreasonable. We just need to be careful to think about the possible consequences.
[14:35] <rbasak> freyes: I'm also curious why you didn't only cherry-pick the necessary patches - looks like that would be feasible?
[14:38] <adrien>  /lastlog -clear
[14:38] <adrien> woops :)
[14:40] <sergiodj> jbicha: hey, I'm about to start my patch pilot shift and I couldn't find your entry in the handoff doc.  is there anything worth mentioning from yesterday's shift?
[14:40] <adrien> ginggs: you retried rust-globset on yesterday but I'm wondering if the triggers were right: more specifically I'm wondering if the needed ones are exactly rust-bstr/1.5.0-1 and rust-globset/0.4.10-1 , which would be that URI: https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=armhf&package=rust-globset&trigger=rust-bstr%2F1.5.0-1&trigger=rust-globset%2F0.4.10-1
[14:44] <ginggs> adrien: i think that combination was tried, but failed with 'websocket: bad handshake' -- let's try again...
[14:46] <freyes> rbasak, on the aspect of bash scripts, typically users run the openstack clients with flags (e.g. `openstack coe cluster list --format json | jq ...`), it's a very common practice by the complexity of the objects in OpenStack. Even users who don't want to deal with jq they do things like `openstack coe cluster list --format value -c ID` to filter the specific data they want to consume
[14:47] <freyes> rbasak, why not cherry-pick, this is because we went initially that route, and we kept finding incompatibility issues, so we were taking a path where the client would become more unstable than just bumping up the version with what was really tested upstream
[14:49] <adrien> ginggs: yup, that's why I think it's worth a new try; tbh I'm not certain that will be the solution but it seems plausible enough
[14:52] <freyes> rbasak, about patching the CLI to not display the health status, removing it from the list of default columns is a oneline change, I would need to check how large a change would be if to allow users to opt-in to the show the column, there is a "-c" flag that allows users to make the CLI print specific columns
[14:59] <sergiodj> @pilot in
[15:28] <adrien> I have a question about rust packages: for instance rust-jsonwebtoken; for 8.2.0, it says " crate directory not found: /usr/share/cargo/registry/jsonwebtoken-8.2.0" and that path comes from librust-jsonwebtoken-dev which is pulled at version 8.3.0-1
[15:29] <adrien> I think the solution is to re-trigger with rust-jsonwebtoken too; is that analysis correct?
[15:29] <schopin> Probably, yes.
[15:31] <adrien> there's a followup comment but I need to get some stats first
[15:33] <adrien> I only get three packages affected by this at the moment but is there something to improve to prevent these from occuring again?
[15:34] <adrien> I think I can get the triggers for the affected packages fairly easily but only if I manage to do it before the children hord of children arrives
[15:35] <adrien> first one
[15:35] <adrien> % ./retry-autopkgtest-regressions --blocked-by-tests rust-jsonwebtoken
[15:35] <adrien> https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=armhf&package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2
[15:39] <adrien> rust-syn seems to be a slightly different issue: it searches for the 2.0.16 directory while testing 2.0.18
[15:40] <adrien> the trigger is 2.0.18 and the -dev package is at version 2.0.18
[15:41] <adrien> the only mention of 2.0.16 in https://autopkgtest.ubuntu.com/results/autopkgtest-mantic/mantic/amd64/r/rust-syn/20230621_233537_be14d@/log.gz is basically the failure itself
[15:44] <adrien> the only place I find 2.0.16 is in debian experimental and I'm not even sure that version was synced
[15:44] <adrien> I'll leave for now but I'm very interested in any idea people could have about this
[15:57] <ginggs> adrien: package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2 retried, but i think that combination has been retried many times
[16:00]  * ginggs tries package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2&trigger=rust-jsonwebtoken/8.3.0-1
[16:18] <ginggs> adrien: re rust-syn -- yes you are correct, the only mention of 2.0.16 is in the test itself
[16:18] <ginggs> https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/syn/debian/tests/control
[16:18] <ginggs> looks like that is the problem!
[16:21] <adrien> this looks like a good way to have version issues; I think the author was focused on a transition and specifically 2.0.16
[16:22] <adrien> ginggs: oh, yes, I definitely wanted to have jsonwebtoken itself as part of the triggers; I think I completely misread the output of r-a-r and that's probably not the first time today; I think I was reading the package as part of the triggers
[16:23] <adrien> ah, right, almost 6 hours ago I pasted one URI which I had similarly misread (repeteadly)
[16:52] <rbasak> freyes: thanks. I think this is mostly on me now to finish my review, and then I might have some further discussion. I've been distracted by meetings and have a prior commitment this evening. I'm hoping to come back later though.
[16:56] <freyes> thanks, rbasak
[17:17] <jbicha> sergiodj: oh sorry I missed the doc. I didn't have anything to pass along
[17:17] <sergiodj> jbicha: ACK, np.  thanks
[18:01] <ogayot> Hi, may I ask somebody to trigger this autopkgtest for me please? https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=pyparted&ppa=ogayot%2Fmantic-proposed&trigger=pyparted%2F3.12.0-4ubuntu1~ppa2 Thanks!
[18:03] <sergiodj> ogayot: done
[18:03] <ogayot> sergiodj: thanks!
[18:03] <sergiodj> np
[18:44] <adrien> create an issue for rust-syn: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/46 (I'll link it to LP and upd*ate-excuse on tomorrow)
[18:44] -ubottu:#ubuntu-devel- Issue 46 in rust-team/debcargo-conf "syn: d/tests/control not synchronized with d/changelog" [Opened]
[18:48] <sergiodj> RAOF: hey, https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1995606 has been updated and is in the sponsorship queue but I don't have enough time/knowledge to review it properly.  it seems like you're driving the review whenever you have time, so I'll leave it to you
[18:48] -ubottu:#ubuntu-devel- Launchpad bug 1995606 in thermald (Ubuntu Jammy) "Upgrade thermald to 2.5.1 for Jammy (22.04)" [Undecided, Incomplete]
[19:09] <sergiodj> @pilot out
[20:13] <adrien> for rust-rustls-pemfile, I would like to run the rust-rustls tests on all arches again *but* with the additional rust-base64 trigger version 0.21.2-1 and I see no way to do that with retry-autopkgtest-regressions
[20:15] <adrien> for amd64 that would be https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=rust-rustls&trigger=rust-rustls-pemfile%2F1.0.2-1&trigger=rust-base64%2F0.21.2-1 (I guess dropping arch=amd64 runs it on all arches?)
[20:33] <bdmurray> adrien: the documentation for retry-autopkgtest-regressions talks about pipeing the output to vipe and you could add a trigger in there
[20:57] <adrien> bdmurray: ok, thanks; I remember vorlon was asking for invocations of r-a-r rather than links to click on but I guess an invocation and a comment about what to change would work too
[22:21] <mwhudson> @pilot in
[22:26] <vorlon> bdmurray, adrien: I've been known to pipe to sed :)
[22:27] <bdmurray> that's what he said
[22:28] <vorlon> Right Sed Fred
[22:28] <bdmurray> lol
[23:41] <sarnold> lol