=== kiska1 is now known as kiska === seb129 is now known as seb128 [13:14] So I'm changing the owner of ~6000 git repositories with a small script (https://paste.ubuntu.com/p/kPRzPKr7dQ/) but iterating over the repositories using the Launchpad API, AFAICT the iterator keeps stopping for no apparent reason. [13:14] It's idempotent so I'm just rerunning it to get some more done, but I wonder if I'm missing something? [13:14] Down to 1000 now, so I think I can just keep rerunning it until it's done. [13:16] In the first attempt I got ~3000 before it stopped IIRC. Now the stoppages seem to be getting more frequent. [13:20] Are you effectively modifying the iterator while iterating over it? [13:20] Yeah, you are [13:21] lazr.restfulclient iterates over collections in batches, each of which is a separate HTTP request [13:21] So if you change a bunch of repository owners, you're effectively changing the results of the "repositories with this owner" query while iterating over it, and you're going to get very confusing results [13:22] rbasak: For this sort of thing, I'd suggest "for repo in list(packages_imported(lp)):" to materialize the whole collection up-front before making any changes [13:29] Ah. I see, thanks! [13:34] Hi, I've registered a git code import about an hour ago, it's still scheduled 'ASAP', usually it's been just a few minutes for import to start or sometimes even finish - is there any issue currently? anything I can do? [13:47] mijn: A URL to the code import in question is normally helpful. The code import queue is being processed, though one of the four import workers seems to have got stuck, which perhaps isn't helping - I've asked for it to be killed so it can restart === mdeslaur__ is now known as mdeslaur [13:53] cjwatson, i've killed original import and replaced it since, but it's still under this repo: https://code.launchpad.net/openloco [13:53] thanks [13:53] mijn: OK, don't kill it again please [13:54] (It won't help and will only put you further back in the queue) [13:55] I suspect as much, still went ahead [13:56] The missing worker is back now, so the queue should process more quickly. There are about 1.7K overdue imports at the moment, so I can't give you a very exact ETA, but maybe a couple of hours [13:57] :o [13:57] that's a lot [13:57] The queue is at least diminishing now [13:57] still, thanks for getting it unstuck [13:57] Most of those imports will be no-op or very small updates to existing imports, so it's not as bad as it sounds [14:04] is the queue public? [14:06] https://code.launchpad.net/+code-imports/+machines sort of shows it, but it only shows "pending" and not "overdue" - "pending" is nearly all imports so it's not very informative [14:07] Must get around to fixing that at some point [14:07] At the moment we rely on internal graphs [14:16] * cjwatson requests adding two more code import workers [16:15] mijn: I see your import ran about an hour ago, BTW [16:16] yup, working on overlay already, thanks! [19:09] hi, i'm trying to use a recipe to build a i386-only package. It works fine on Bionic, but anything newer fails to upload. Recipe in question: https://code.launchpad.net/~janisozaur/+recipe/openloco-daily-test [19:09] error message was: Cannot build any of the architectures requested: i386 [19:10] but the same happened when I specified `Architecture: any`, which works with another recipe I maintain (although the working one isn't limited to i386) [19:12] mijn: Ubuntu >= 20.04 only supports i386 as a very limited partial architecture [19:12] I can build this easily in a docker with 20.04 [19:12] mijn: Are you sure you had the same problem when you specified `Architecture: any`? Can I see some evidence? [19:13] and then actually launch this docker-built binary on amd64 [19:13] Why are you building on i386? [19:13] the project calls into a binary which is i386 [19:14] Ugh. Support for this is only going to deteriorate further [19:14] I know, there is progress being made towards removing this dependency - but it works for now, only not when trying to use a recipe [19:15] I can see why you want to do this in that case, but as a consequence of https://bugs.launchpad.net/launchpad/+bug/1855069 (more or less), you very probably can't [19:15] proof with `Architecture: any`: https://launchpad.net/~janisozaur/+archive/ubuntu/openloco-debian-test/+recipebuild/2883381 [19:16] Oh I see, that's because the target PPA (https://launchpad.net/~janisozaur/+archive/ubuntu/openloco-debian-test) is configured i386-only [19:16] So basically the same deal [19:17] Until bug 1855069 is fixed I don't think you'll be able to build this on anything newer than bionic [19:17] Are the dependencies of the bionic-built binaries compatible with newer Ubuntu series? Perhaps you can build it only on bionic and then copy it forward including the binaries? [19:17] I did so to not get errors about failed builds - if I enabled amd64, would it be able to get built? [19:18] It would build but I have no idea whether the build would work [19:18] ok, let me try [19:18] I mean, the build would be dispatched (if you enabled the arch in the PPA's config and also used "Architecture: any") [19:21] how do i build the deb package locally? [19:25] sbuild (some setup work required: https://wiki.ubuntu.com/SimpleSbuild) [19:27] oh, I think I understand now what that bug was about - there are no i386 builds scheduled at all for post-bionic [19:27] Right [19:29] We had to take some moderately brutal steps so that Ubuntu wouldn't have to implement its demotion of i386 to a partial architecture by editing several thousand source packages one by one [19:29] So there's a specific list of which sources can be built on i386 [19:29] And for the most part it makes sense to apply that to PPAs as well, but this is one of the exceptions [19:33] ok, will have to think of some other way for getting it packaged then [19:33] thanks once again [19:36] Mm, and I checked, the dependencies of your bionic build aren't all directly compatible with >=focal, unfortunately [19:36] (there's been a yaml-cpp ABI change, at least) [19:43] yaml-cpp is a thorn in my side, I work with multiple projects using it and there's always something wrong with it [19:45] Well, it's common enough for there to be ABI changes between Ubuntu series regardless of the specifics