=== jamesh_ is now known as jamesh [12:34] Why was my upload rejected and what can I do to work around it? https://launchpadlibrarian.net/529552570/upload_2762614_log.txt [12:35] What is this "Primary Archive for Ubuntu" mentioned in the error message? [12:35] The Ubuntu archive. archive.ubuntu.com [12:36] Okay. How do I find that package so I can use it instead of the one I'm trying to upload? [12:38] You can get to it from https://launchpad.net/ubuntu/+source/fcl, or "pull-lp-source -d fcl" will download the Ubuntu version [12:39] Just need to make sure that you've built your source package with the same fcl_0.6.1.orig.tar.gz as used in Ubuntu (I think the main motivation for this is to avoid people getting into weird situations if they're using a PPA as a staging area for Ubuntu development, but it's generally best for source package files with the same name to have the same content anyway to minimize confusion) [12:40] So, if I want to build the latest version of that source for, say, focal, do I make a recipe that eats from the "official" source? [12:41] Are you using a recipe right now? Can you point me to it? [12:41] https://code.launchpad.net/~realtime-robotics/+recipe/fcl-daily [12:43] Easiest way is probably to commit Ubuntu's fcl_0.6.1.orig.tar.gz to that packaging repository using pristine-tar [12:43] Then recipe builds should use that [12:44] There's a 0.6.1 tag, so if you've put Ubuntu's tarball in ../fcl_0.6.1.orig.tar.gz, then "pristine-tar commit ../fcl_0.6.1.orig.tar.gz 0.6.1" should commit it. That'll create a pristine-tar branch which you can push [12:45] I don't think I've ever done that before. Is there a HowTo pristine-tar page somewhere? [12:45] I'm usually using gbp [12:46] gbp import-orig --pristine-tar ? [12:48] I don't use gbp much so can't help with any authority on that, but the command I gave should work regardless of whether you normally use gbp [12:49] "man pristine-tar" [12:50] I would expect gbp import-orig to do more than what you need here, but I suppose you can try it if you want. You might need to do some more git juggling if you do that though [12:50] Probably makes sense for future updates from upstream at least, maybe not for one you've already mostly prepared ... [12:51] (Because it'll unpack the upstream sources onto a git branch, and so you'd probably need to rebase your work on top of that. Whereas pristine-tar on its own is a bit more surgical) [12:52] yeah, I already imported a tarball for that version -- you're saying I should destroy that work and start over [12:52] ? [12:52] No, I gave you a command which does nothing of the sort :-) [12:52] You could just run it [12:52] okay, will do [12:52] * cjwatson tests it just in case [12:53] Ah, make that "pristine-tar commit ../fcl_0.6.1.orig.tar.gz upstream/0.6.1" by the looks of things [12:54] As I say, I think for future updates you could reasonably use "gbp import-orig --pristine-tar" [12:54] For example that's part of the procedure recommended in https://wiki.debian.org/Python/GitPackaging#New_upstream_release [12:55] that created a branch "pristine-tar" [12:55] Right. If you push that to LP, then recipe builds should use it [12:55] oh, dear, it's based on the wrong branch [12:55] ? [12:56] according to DEP-14, that is [12:56] Ignore DEP-14 for this purpose [12:56] Though actually I don't see what the DEP-14 problem here is anyway [12:56] "If the package maintainers use the pristine-tar tool to efficiently store a byte-for-byte copy of the upstream tarballs, this should be done in the pristine-tar branch." [12:57] huh, okay [12:58] The important thing is just that it can be recovered using "pristine-tar checkout" [12:58] (Otherwise, git-build-recipe falls back to making up its own using "git archive") [12:59] https://git.launchpad.net/git-build-recipe/tree/gitbuildrecipe/deb_util.py#n51 [13:02] Do I understand correctly that there's no way to create my own recipe that consumes the official source? And that there's no way to duplicate that effort without using the pristine-tar ? [13:03] welp, that worked worse than I had hoped: https://launchpadlibrarian.net/529559463/buildlog.txt.gz [13:04] The official source package is itself maintained in git at https://salsa.debian.org/science-team/fcl, so it ought to be possible to fork that [13:04] Er [13:04] Could I "import" it to a launchpad git and recipe that? [13:04] Why did you change the recipe to say "pristine-tar"? [13:04] It's used implicitly - you aren't supposed to set it as the branch for the recipe [13:05] okay [13:06] In principle it's certainly possible to use a code import from the Debian repository and base a recipe on that. I don't know whether there'd be any particular gotchas in this case [13:06] Recipes were designed more for people trying to follow upstream closely [13:07] So this is a bit of a bolt-on use case for them [13:07] AIUI most people doing backports just use "backportpackage" rather than recipes [13:08] that sounds like what I want; where is that documented? [13:08] But it's true that recipes are more automated if you can get them to work :-) [13:08] "man backportpackage" [13:09] Oh, if it's a local operation followed by a dput, I think I prefer a recipe. [13:25] heh, failed to build latest release of fcl on bionic/focal because missing debhelper 13 ... I'm not at all surprised. [13:25] Okay, I'm going to revamp my gbp via pristine tar and see if I can't get that working. [13:56] I uploaded a *_source.changes via dput and I have yet to receive any notification on the repo page or email about it [13:56] Is there any other place I should be checking for status updates? [13:59] You should get an email notification unless there was a signing failure [14:00] However we're also having some infrastructure problems at the moment [14:00] I can't get to the machine from which I normally check logs ... === cjwatson changed the topic of #launchpad to: Canonical infrastructure problems, stand by | Help contact: @pappacena (12:00-21:00 UTC Mon-Fri) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad [14:37] PPA uploads seem to be recovering now [14:38] retrying now [14:40] No need [14:40] Uploads were queued [14:46] utkarsh2102: ^ [14:47] perfect, thanks [14:49] What does this mean? "Rejected: PPA uploads must be for the RELEASE pocket." [14:52] realtime-neil: It means that you targeted your upload at focal-backports, which only exists in the primary Ubuntu archive - for a PPA you need to target it at focal instead [14:52] -r, --release-pocket [14:52] Target the upload at the release pocket, rather than the -backports pocket. This is required for Launchpad PPAs, which are pocket-less (and the default, when the upload target is a PPA). [14:52] (from "man backportpackage") [14:52] thank you [14:53] Is "pocket" yet another name for "component"? [14:53] No [14:53] suite? [14:53] Sort of [14:53] It's a piece of jargon I'm not fond of but we don't have a better term for [14:53] suite = series + pocket [14:54] So "pocket" is the "backports" part of focal-backports (might also be "proposed", "updates", "security") [14:54] While focal is the series [14:54] so much lore [14:55] It essentially denotes a risk level - so it's analogous to stable/candidate/beta/edge in the snap store [14:55] Which may or may not be a helpful analogy depending on your background [14:56] It's all I can do to master deb packaging -- I'll learn snap at the next job. [15:21] even though PPA uploads are accepted, the builders are almost down, it seems? [15:22] oh actually they're not down; https://launchpad.net/builders tells me that they're super busy. [15:22] utkarsh2102: for some architectures, yes. I think a nova controller is dead [15:22] aw :/ [15:22] utkarsh2102: sysadmins are a bit busy putting out all the other fires though [15:22] Okay, thanks! [15:23] *hugs* to them, either way [17:24] Most builders are back, though ppc64el still has some persistent problems about which I filed a ticket earlier today === Laney is now known as Awayney [18:52] yay [19:42] Is there a backlog on publishing? I've been waiting over an hour for one particular repository? [19:42] Let me see if that was also taken out by the outage earlier [19:43] Ugh yes, that looks rather unhealthy, thanks for mentioning it [19:43] Not obviously a result of the outage though ... [19:47] Working on it, waiting for a sysadmin to get back to me [19:47] cjwatson: I thought you _were_ the sysadmin. :D [19:48] realtime-neil: I'm one of the LP developers and have some site staff superpowers, but Canonical's sysadmin team run the actual machines [19:48] So sometimes we need to do arm's-length stuff via them [19:50] realtime-neil: OK, publisher is back up now and should catch up in a bit [19:50] And I should probably check what alerts we have on that [19:51] sweet, much thanks [20:44] cjwatson: is there a status page I can look at? I have packages that have been publishing for over 90 minutes, now. [20:45] whoops, I may have spoken too soon [22:46] cjwatson: does Launchpad really still use 16.04? o.O [22:46] are there any plans to update that in the ${future} since 16.04 standard support is... coming to an end :P [22:47] teward: sadly. upgrading later this year I hope [22:47] just curious as i read through the dev docs [22:47] teward: LP works fine on 18.04, we just haven't had sysadmin cycles to upgrade production [22:47] that i can understand heh [22:47] (20.04 maybe not so much, that's not tested yet and may need some fixes) [22:48] cjwatson: lp dev docs suggest 16.04 for the runtime env for a dev version - only hunting this again because I stupidly deleted my lpdev LXD environment >.<) [22:48] hence the questions :P [22:48] https://dev.launchpad.net/Running/LXD "We currently test on 16.04 and 18.04, with the aim of upgrading production to 18.04 soon" [22:49] I"m blind heh didn't see the link on the 4k screen (small text!) the main Running page doesn't say 18.04 though so :p [22:49] It's true, we haven't necessarily gone around and updated all of those in advance of the production upgrade [22:49] Anyway, feel free to use either xenial or bionic [22:50] And either Python 2 or 3 [22:50] (select py3 with `make PYTHON=python3`) [23:51] cjwatson: i'll use Bionic, i'm still on the rocketfuel setup step. had to do some things to make the env work the way i wanted *shrugs*