[07:32] <mfabian_> sarnold, cjwatson: I can login now, thank you very much!
[08:45] <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:47] <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:50] <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)
[11:57] <LocutusOfBorg> hello s390x, did you take a vac?
[11:59] <cjwatson> I mean we normally call it crashing
[12:31] <cjwatson> LocutusOfBorg: they're back now, thanks
[12:32] <LocutusOfBorg> thanks!
[22:25] <realtime-neil> Can someone help me understand what's going on here? https://launchpad.net/~realtime-robotics/+archive/ubuntu/incoming/+build/24187992
[22:26] <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:34] <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:35] <rbasak> )
[22:35] <realtime-neil> "snap" the package is incompatible with the Build-Depends I'm attempting to install there?
[22:36] <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:37] <realtime-neil> That's a new one for me; Am i using chdist to wrap some packagebuild command?
[22:38] <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:39] <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:40] <sarnold> oh dang you can get all the way to an apt-get install -s  ? that's awesome
[22:41] <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:42] <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:43] <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:44] <cjwatson> or at least that wasn't what was reported
[22:46] <rbasak> The build depends are different though. libtbb-dev vs libtbb2-dev
[22:47] <cjwatson> Sure, but I was consistently using focal to match the failing build
[22:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <cjwatson> Oh look, there we go, it got past that point on retry
[22:56] <cjwatson> So it must have been a temporary inconsistency somewhere
[22:57] <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:59] <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
[23:00] <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:01] <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:03] <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:04] <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:05] <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:06] <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.