[07:24] Hm. Mesa doesn't seem to play nicely with debuginfod.ubuntu.com; I think the source map might not be quite right? [07:24] gdb can't find any of the source files. [09:04] RAOF: on which release? Source file indexing depends on a fairly recent patch AIUI. [09:05] (and won't work on older releases) [09:06] On mantic. Actually building the package, I *still* can't find the files it's referencing 🤷‍♀️ [09:09] Like, gdb is looking for libegl.c; I can't find that file with that name in a built tree! [13:23] 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] 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] rbasak, yes, I just posted the reply - https://bugs.launchpad.net/ubuntu/+source/magnum-ui/+bug/1996229/comments/5 [14:09] ack, reading [14:13] 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] rbasak, yes, when I was going through the git log I didn't find code removed (e.g. deprecated API removed) [14:15] Great, thanks [14:21] updated the bug description to include the impacted packages and this aspect of users running custom code with magnumclient as a library [14:24] freyes: will the CLI for ListCluster (not sure what the command is exactly) now output more columns by default? [14:24] 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] rbasak, yes, it will [14:27] rbasak, this has been identified as a problem, not showing that column, since operators have no visibility on the cluster's state [14:27] rbasak, the general guideline has been to use the openstackclients snap [14:28] which ships newer versions of the clients (from upstream python tarballs) [14:29] although this change may break bash scripts :-/ I didn't think about it [14:34] 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] 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] freyes: I'm also curious why you didn't only cherry-pick the necessary patches - looks like that would be feasible? [14:38] /lastlog -clear [14:38] woops :) [14:40] 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] 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] adrien: i think that combination was tried, but failed with 'websocket: bad handshake' -- let's try again... [14:46] 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] 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] 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] 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 === esembee_ is now known as esembee [14:59] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: sergiodj [15:28] 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] I think the solution is to re-trigger with rust-jsonwebtoken too; is that analysis correct? [15:29] Probably, yes. [15:31] there's a followup comment but I need to get some stats first [15:33] 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] 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] first one [15:35] % ./retry-autopkgtest-regressions --blocked-by-tests rust-jsonwebtoken [15:35] https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=armhf&package=rust-jsonwebtoken&trigger=rust-pem%2F1.0.2-2 [15:39] rust-syn seems to be a slightly different issue: it searches for the 2.0.16 directory while testing 2.0.18 [15:40] the trigger is 2.0.18 and the -dev package is at version 2.0.18 [15:41] 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] the only place I find 2.0.16 is in debian experimental and I'm not even sure that version was synced [15:44] I'll leave for now but I'm very interested in any idea people could have about this [15:57] 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] adrien: re rust-syn -- yes you are correct, the only mention of 2.0.16 is in the test itself [16:18] https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/syn/debian/tests/control [16:18] looks like that is the problem! [16:21] 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] 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] ah, right, almost 6 hours ago I pasted one URI which I had similarly misread (repeteadly) [16:52] 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] thanks, rbasak [17:17] sergiodj: oh sorry I missed the doc. I didn't have anything to pass along [17:17] jbicha: ACK, np. thanks [18:01] 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] ogayot: done [18:03] sergiodj: thanks! [18:03] np [18:44] 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] 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] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A [20:13] 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] 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] adrien: the documentation for retry-autopkgtest-regressions talks about pipeing the output to vipe and you could add a trigger in there [20:57] 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] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: mwhudson [22:26] bdmurray, adrien: I've been known to pipe to sed :) [22:27] that's what he said [22:28] Right Sed Fred [22:28] lol [23:41] lol