mfabian_ | sarnold, cjwatson: I can login now, thank you very much! | 07:32 |
---|---|---|
LocutusOfBorg | hello, is it normal that ubuntu-build doesn't work anymore? | 08:45 |
LocutusOfBorg | some debugging results in this return from launchpad | 08:45 |
LocutusOfBorg | lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized | 08:45 |
LocutusOfBorg | but I'm not printed anymore for the token accept on jammy | 08:45 |
LocutusOfBorg | I removed the whole ~/.launchpadlib directory | 08:45 |
LocutusOfBorg | 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:47 |
LocutusOfBorg | well, version 176 of ubuntu-dev-tools works | 08:50 |
LocutusOfBorg | (with some python3 cherry-picks for callable object, so its not a lp issue thanks) | 08:50 |
LocutusOfBorg | hello s390x, did you take a vac? | 11:57 |
cjwatson | I mean we normally call it crashing | 11:59 |
cjwatson | LocutusOfBorg: they're back now, thanks | 12:31 |
LocutusOfBorg | thanks! | 12:32 |
realtime-neil | Can someone help me understand what's going on here? https://launchpad.net/~realtime-robotics/+archive/ubuntu/incoming/+build/24187992 | 22:25 |
realtime-neil | 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 |
realtime-neil | hence my confusion | 22:26 |
rbasak | 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 |
cjwatson | 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 |
cjwatson | snap | 22:34 |
rbasak | ) | 22:35 |
realtime-neil | "snap" the package is incompatible with the Build-Depends I'm attempting to install there? | 22:35 |
cjwatson | I mean that rbasak and I were saying basically the same thing in different words | 22:36 |
realtime-neil | ah | 22:36 |
cjwatson | thanks to rbasak for finding my dropped parenthesis ;-) | 22:36 |
cjwatson | chdist is good for investigating this sort of thing interactively | 22:36 |
realtime-neil | That's a new one for me; Am i using chdist to wrap some packagebuild command? | 22:37 |
sarnold | probably chdist focal apt-cache show libtbb-dev (or something similar, I've had 'set up chdist' on my todo list for months) | 22:38 |
cjwatson | it's a tool for setting up isolated apt configs so that you can simulate installations | 22:39 |
cjwatson | you don't want to use it to try to actually install packages, but you can test-run apt's resolver | 22:39 |
rbasak | After setting it up, try using chdist to "apt-get install -s <list of build deps you expect to use>". 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:39 |
sarnold | oh dang you can get all the way to an apt-get install -s ? that's awesome | 22:40 |
cjwatson | Hm, though I have to say that when I try that locally it seems to work for me | 22:41 |
rbasak | It's probably related to the alternatives in that build-dep line | 22:41 |
realtime-neil | $ chdist focal apt-get update && chdist focal apt-cache policy libtbb-dev Reading package lists... Done | 22:41 |
realtime-neil | N: Unable to locate package libtbb-dev | 22:41 |
cjwatson | https://paste.ubuntu.com/p/ScNGNdXJ7F/ | 22:42 |
cjwatson | so it might be necessary to try a full local sbuild run in this case | 22:42 |
rbasak | cjwatson: you used the focal build deps though, not the kinetic ones. Or are they the same? | 22:42 |
cjwatson | the failing build was for focal | 22:43 |
rbasak | "it's a no-change backport of opencascade from Kinetic to Focal" | 22:43 |
cjwatson | indeed | 22:43 |
cjwatson | but it's not the kinetic build that's failing | 22:43 |
cjwatson | or at least that wasn't what was reported | 22:44 |
rbasak | The build depends are different though. libtbb-dev vs libtbb2-dev | 22:46 |
cjwatson | Sure, but I was consistently using focal to match the failing build | 22:47 |
rbasak | But the failing build is the kinetic source of opencascade, not the focal source. At least that's what I understood. | 22:48 |
cjwatson | rbasak: that's not what was reported - https://launchpad.net/~realtime-robotics/+archive/ubuntu/incoming/+build/24187992 is for focal | 22:48 |
rbasak | It's _on_ Focal, but the source package is _from_ Kinetic. | 22:49 |
realtime-neil | Okay, I think I got this working for me. | 22:49 |
realtime-neil | I suspect that it's the libtbb2 vs libtbb thing. | 22:49 |
cjwatson | rbasak: I grabbed the source package from focal too though | 22:49 |
cjwatson | rbasak: Since that's what LP will have done | 22:50 |
realtime-neil | How do I tell backportpackage to extract the source to let me tweak it before uploading? | 22:50 |
cjwatson | rbasak: Er indeed that's what "apt build-dep opencascade" will do as well. kinetic just isn't really relevant here | 22:50 |
cjwatson | 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 |
rbasak | 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:51 |
cjwatson | rbasak: Won't it use the opencascade package in the PPA in question? | 22:52 |
rbasak | Oh, you added the PPA in the chdist? | 22:52 |
rbasak | That's what I was missing! | 22:52 |
cjwatson | 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:52 |
cjwatson | Also sbuild works for me after I set it up with the same config LP will have been using | 22:53 |
cjwatson | Is it possible that this was a transient problem of some kind and would go away if you just retried the build? | 22:53 |
rbasak | Sorry I completely missed that. | 22:53 |
realtime-neil | clicking the retry | 22:53 |
cjwatson | It wasn't that long ago; an alternative possibility is that archive.ubuntu.com is behind compared to ftpmaster.internal | 22:54 |
cjwatson | (which is not unexpected; there's a mirroring delay) | 22:54 |
cjwatson | Oh look, there we go, it got past that point on retry | 22:55 |
cjwatson | So it must have been a temporary inconsistency somewhere | 22:56 |
realtime-neil | I hate these kind of bugs the hardest. | 22:57 |
cjwatson | 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 |
realtime-neil | What lesson should I take away from this? Retry often? What's the latency associated with that "mirroring delay" you mentioned earlier? | 22:57 |
cjwatson | This was a pretty unusual situation - I'm not sure it's worth taking a specific lesson | 22:59 |
realtime-neil | You're saying you expect it to be rare? Why? | 22:59 |
cjwatson | Generally speaking it's worth making sure that you have a matching local environment where you can run test builds | 22:59 |
cjwatson | 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:00 |
realtime-neil | Okay. Welp, thanks for the help, as always. | 23:01 |
cjwatson | 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:01 |
cjwatson | 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 |
realtime-neil | I have been tooling on realtime-robotics/incoming for most of the day | 23:03 |
realtime-neil | that might not have helped me | 23:03 |
cjwatson | Right, it could have been a state change in your own PPA, indeed, I didn't look into that in detail | 23:04 |
cjwatson | 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:04 |
realtime-neil | understood | 23:05 |
cjwatson | 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 |
realtime-neil | 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 |
cjwatson | Not in u-a-t, but the LP web UI will show such things as pending publication | 23:05 |
cjwatson | And it's possible to dig further with the API if necessary | 23:06 |
realtime-neil | Yeah. Yeah, I have grown to dislike the spinning green flower. | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!