[07:32] sarnold, cjwatson: I can login now, thank you very much! [08:45] hello, is it normal that ubuntu-build doesn't work anymore? [08:45] some debugging results in this return from launchpad [08:45] lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized [08:45] but I'm not printed anymore for the token accept on jammy [08:45] I removed the whole ~/.launchpadlib directory [08:47] ubuntu-build is saying AttributeError: 'NoneType' object has no attribute 'canUploadPackage' and this is true, since the PersonTeam(Launchpad.me.self_link) is returning error and then set to "none" [08:50] well, version 176 of ubuntu-dev-tools works [08:50] (with some python3 cherry-picks for callable object, so its not a lp issue thanks) [11:57] hello s390x, did you take a vac? [11:59] I mean we normally call it crashing [12:31] LocutusOfBorg: they're back now, thanks [12:32] thanks! [22:25] Can someone help me understand what's going on here? https://launchpad.net/~realtime-robotics/+archive/ubuntu/incoming/+build/24187992 [22:26] it's a no-change backport of opencascade from Kinetic to Focal. It wants `libtbb-dev` as a build dependency. Focal _has_ libtbb-dev: https://packages.ubuntu.com/focal/libtbb-dev [22:26] hence my confusion [22:34] realtime-neil: is there a conflict with one of the other (transitive) build dependencies? That's the usual cause of that kind of thing. Have you tried a local build? [22:34] realtime-neil: "libtbb-dev but it is not going to be installed" means that libtbb-dev exists but that its dependencies can't be satisfied (either because they're literally unsatisfiable in isolation, or because something else you're build-depending on conflicts with something in there [22:34] snap [22:35] ) [22:35] "snap" the package is incompatible with the Build-Depends I'm attempting to install there? [22:36] I mean that rbasak and I were saying basically the same thing in different words [22:36] ah [22:36] thanks to rbasak for finding my dropped parenthesis ;-) [22:36] chdist is good for investigating this sort of thing interactively [22:37] That's a new one for me; Am i using chdist to wrap some packagebuild command? [22:38] probably chdist focal apt-cache show libtbb-dev (or something similar, I've had 'set up chdist' on my todo list for months) [22:39] it's a tool for setting up isolated apt configs so that you can simulate installations [22:39] you don't want to use it to try to actually install packages, but you can test-run apt's resolver [22:39] After setting it up, try using chdist to "apt-get install -s ". After reproducing the issue, you can give apt more specifics on what you expect, and it'll eventually tell you the specific conflict that is stopping it. [22:40] oh dang you can get all the way to an apt-get install -s ? that's awesome [22:41] Hm, though I have to say that when I try that locally it seems to work for me [22:41] It's probably related to the alternatives in that build-dep line [22:41] $ chdist focal apt-get update && chdist focal apt-cache policy libtbb-dev Reading package lists... Done [22:41] N: Unable to locate package libtbb-dev [22:42] https://paste.ubuntu.com/p/ScNGNdXJ7F/ [22:42] so it might be necessary to try a full local sbuild run in this case [22:42] cjwatson: you used the focal build deps though, not the kinetic ones. Or are they the same? [22:43] the failing build was for focal [22:43] "it's a no-change backport of opencascade from Kinetic to Focal" [22:43] indeed [22:43] but it's not the kinetic build that's failing [22:44] or at least that wasn't what was reported [22:46] The build depends are different though. libtbb-dev vs libtbb2-dev [22:47] Sure, but I was consistently using focal to match the failing build [22:48] But the failing build is the kinetic source of opencascade, not the focal source. At least that's what I understood. [22:48] rbasak: that's not what was reported - https://launchpad.net/~realtime-robotics/+archive/ubuntu/incoming/+build/24187992 is for focal [22:49] It's _on_ Focal, but the source package is _from_ Kinetic. [22:49] Okay, I think I got this working for me. [22:49] I suspect that it's the libtbb2 vs libtbb thing. [22:49] rbasak: I grabbed the source package from focal too though [22:50] rbasak: Since that's what LP will have done [22:50] How do I tell backportpackage to extract the source to let me tweak it before uploading? [22:50] rbasak: Er indeed that's what "apt build-dep opencascade" will do as well. kinetic just isn't really relevant here [22:51] realtime-neil: just omit the -u option so that it doesn't upload, and then you can fiddle with it then upload for yourself [22:51] cjwatson: "apt build-dep opencascade" in a focal chdist will use Focal's opencascade build-dep line. But the failing build uses Kinetic's opencascade build-dep line, because realtime-neil uploaded a no-change backport of the Kinetic package. [22:52] rbasak: Won't it use the opencascade package in the PPA in question? [22:52] Oh, you added the PPA in the chdist? [22:52] That's what I was missing! [22:52] rbasak: And anyway I get the same result from "chdist apt realtime-neil-test build-dep ./opencascade_7.5.2+dfsg1-2~ubuntu20.04.1~ppa1.dsc" [22:53] Also sbuild works for me after I set it up with the same config LP will have been using [22:53] Is it possible that this was a transient problem of some kind and would go away if you just retried the build? [22:53] Sorry I completely missed that. [22:53] clicking the retry [22:54] It wasn't that long ago; an alternative possibility is that archive.ubuntu.com is behind compared to ftpmaster.internal [22:54] (which is not unexpected; there's a mirroring delay) [22:55] Oh look, there we go, it got past that point on retry [22:56] So it must have been a temporary inconsistency somewhere [22:57] I hate these kind of bugs the hardest. [22:57] I could probably reverse-engineer what it was if I absolutely had to but I think we should just take the win at this point ;-) [22:57] What lesson should I take away from this? Retry often? What's the latency associated with that "mirroring delay" you mentioned earlier? [22:59] This was a pretty unusual situation - I'm not sure it's worth taking a specific lesson [22:59] You're saying you expect it to be rare? Why? [22:59] Generally speaking it's worth making sure that you have a matching local environment where you can run test builds [23:00] Yes, it is relatively rare for dependencies to flat-out be unsatisfiable like that, because usually QA machinery in the archive prevents that. Without fully diagnosing this I'm not sure what would have gone wrong exactly [23:01] Okay. Welp, thanks for the help, as always. [23:01] Mirroring delay from the internal primary archive to the public mirrors can be perhaps a few tens of minutes depending on circumstances, but that also wasn't the issue directly - it just confounded debugging a little [23:03] I am still a little puzzled, but looking at the logs before and after I think it can only have been an archive state change that fixed the build [23:03] I have been tooling on realtime-robotics/incoming for most of the day [23:03] that might not have helped me [23:04] Right, it could have been a state change in your own PPA, indeed, I didn't look into that in detail [23:04] In most cases when this sort of problem is reported to us, it's reproducible on retry and it turns out to be due to something like conflicting build-dependencies, which is why both rbasak and I went in that direction first [23:05] understood [23:05] So I also expect this particular case to be rare because, empirically, as somebody on the other end of LP support requests, it's rare :) [23:05] is there something in ubuntu-archive-tools that will let me see "changes that have yet to be applied" for a given PPA? [23:05] Not in u-a-t, but the LP web UI will show such things as pending publication [23:06] And it's possible to dig further with the API if necessary [23:06] Yeah. Yeah, I have grown to dislike the spinning green flower.