| === jamesh_ is now known as jamesh | ||
| realtime-neil | Why was my upload rejected and what can I do to work around it? https://launchpadlibrarian.net/529552570/upload_2762614_log.txt | 12:34 |
|---|---|---|
| realtime-neil | What is this "Primary Archive for Ubuntu" mentioned in the error message? | 12:35 |
| cjwatson | The Ubuntu archive. archive.ubuntu.com | 12:35 |
| realtime-neil | Okay. How do I find that package so I can use it instead of the one I'm trying to upload? | 12:36 |
| cjwatson | You can get to it from https://launchpad.net/ubuntu/+source/fcl, or "pull-lp-source -d fcl" will download the Ubuntu version | 12:38 |
| cjwatson | 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:39 |
| realtime-neil | 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:40 |
| cjwatson | Are you using a recipe right now? Can you point me to it? | 12:41 |
| realtime-neil | https://code.launchpad.net/~realtime-robotics/+recipe/fcl-daily | 12:41 |
| cjwatson | Easiest way is probably to commit Ubuntu's fcl_0.6.1.orig.tar.gz to that packaging repository using pristine-tar | 12:43 |
| cjwatson | Then recipe builds should use that | 12:43 |
| cjwatson | 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:44 |
| realtime-neil | I don't think I've ever done that before. Is there a HowTo pristine-tar page somewhere? | 12:45 |
| realtime-neil | I'm usually using gbp | 12:45 |
| realtime-neil | gbp import-orig --pristine-tar ? | 12:46 |
| cjwatson | 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:48 |
| cjwatson | "man pristine-tar" | 12:49 |
| cjwatson | 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 |
| cjwatson | Probably makes sense for future updates from upstream at least, maybe not for one you've already mostly prepared ... | 12:50 |
| cjwatson | (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:51 |
| realtime-neil | yeah, I already imported a tarball for that version -- you're saying I should destroy that work and start over | 12:52 |
| realtime-neil | ? | 12:52 |
| cjwatson | No, I gave you a command which does nothing of the sort :-) | 12:52 |
| cjwatson | You could just run it | 12:52 |
| realtime-neil | okay, will do | 12:52 |
| * cjwatson tests it just in case | 12:52 | |
| cjwatson | Ah, make that "pristine-tar commit ../fcl_0.6.1.orig.tar.gz upstream/0.6.1" by the looks of things | 12:53 |
| cjwatson | As I say, I think for future updates you could reasonably use "gbp import-orig --pristine-tar" | 12:54 |
| cjwatson | For example that's part of the procedure recommended in https://wiki.debian.org/Python/GitPackaging#New_upstream_release | 12:54 |
| realtime-neil | that created a branch "pristine-tar" | 12:55 |
| cjwatson | Right. If you push that to LP, then recipe builds should use it | 12:55 |
| realtime-neil | oh, dear, it's based on the wrong branch | 12:55 |
| cjwatson | ? | 12:55 |
| realtime-neil | according to DEP-14, that is | 12:56 |
| cjwatson | Ignore DEP-14 for this purpose | 12:56 |
| cjwatson | Though actually I don't see what the DEP-14 problem here is anyway | 12:56 |
| cjwatson | "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:56 |
| realtime-neil | huh, okay | 12:57 |
| cjwatson | The important thing is just that it can be recovered using "pristine-tar checkout" | 12:58 |
| cjwatson | (Otherwise, git-build-recipe falls back to making up its own using "git archive") | 12:58 |
| cjwatson | https://git.launchpad.net/git-build-recipe/tree/gitbuildrecipe/deb_util.py#n51 | 12:59 |
| realtime-neil | 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:02 |
| realtime-neil | welp, that worked worse than I had hoped: https://launchpadlibrarian.net/529559463/buildlog.txt.gz | 13:03 |
| cjwatson | 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 |
| cjwatson | Er | 13:04 |
| realtime-neil | Could I "import" it to a launchpad git and recipe that? | 13:04 |
| cjwatson | Why did you change the recipe to say "pristine-tar"? | 13:04 |
| cjwatson | It's used implicitly - you aren't supposed to set it as the branch for the recipe | 13:04 |
| realtime-neil | okay | 13:05 |
| cjwatson | 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 |
| cjwatson | Recipes were designed more for people trying to follow upstream closely | 13:06 |
| cjwatson | So this is a bit of a bolt-on use case for them | 13:07 |
| cjwatson | AIUI most people doing backports just use "backportpackage" rather than recipes | 13:07 |
| realtime-neil | that sounds like what I want; where is that documented? | 13:08 |
| cjwatson | But it's true that recipes are more automated if you can get them to work :-) | 13:08 |
| cjwatson | "man backportpackage" | 13:08 |
| realtime-neil | Oh, if it's a local operation followed by a dput, I think I prefer a recipe. | 13:09 |
| realtime-neil | heh, failed to build latest release of fcl on bionic/focal because missing debhelper 13 ... I'm not at all surprised. | 13:25 |
| realtime-neil | Okay, I'm going to revamp my gbp via pristine tar and see if I can't get that working. | 13:25 |
| realtime-neil | 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 |
| realtime-neil | Is there any other place I should be checking for status updates? | 13:56 |
| cjwatson | You should get an email notification unless there was a signing failure | 13:59 |
| cjwatson | However we're also having some infrastructure problems at the moment | 14:00 |
| cjwatson | I can't get to the machine from which I normally check logs ... | 14:00 |
| === 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 | ||
| cjwatson | PPA uploads seem to be recovering now | 14:37 |
| realtime-neil | retrying now | 14:38 |
| cjwatson | No need | 14:40 |
| cjwatson | Uploads were queued | 14:40 |
| rbasak | utkarsh2102: ^ | 14:46 |
| utkarsh2102 | perfect, thanks | 14:47 |
| realtime-neil | What does this mean? "Rejected: PPA uploads must be for the RELEASE pocket." | 14:49 |
| cjwatson | 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 |
| cjwatson | -r, --release-pocket | 14:52 |
| cjwatson | 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 |
| cjwatson | (from "man backportpackage") | 14:52 |
| realtime-neil | thank you | 14:52 |
| realtime-neil | Is "pocket" yet another name for "component"? | 14:53 |
| cjwatson | No | 14:53 |
| realtime-neil | suite? | 14:53 |
| cjwatson | Sort of | 14:53 |
| cjwatson | It's a piece of jargon I'm not fond of but we don't have a better term for | 14:53 |
| cjwatson | suite = series + pocket | 14:53 |
| cjwatson | So "pocket" is the "backports" part of focal-backports (might also be "proposed", "updates", "security") | 14:54 |
| cjwatson | While focal is the series | 14:54 |
| realtime-neil | so much lore | 14:54 |
| cjwatson | It essentially denotes a risk level - so it's analogous to stable/candidate/beta/edge in the snap store | 14:55 |
| cjwatson | Which may or may not be a helpful analogy depending on your background | 14:55 |
| realtime-neil | It's all I can do to master deb packaging -- I'll learn snap at the next job. | 14:56 |
| utkarsh2102 | even though PPA uploads are accepted, the builders are almost down, it seems? | 15:21 |
| utkarsh2102 | oh actually they're not down; https://launchpad.net/builders tells me that they're super busy. | 15:22 |
| cjwatson | utkarsh2102: for some architectures, yes. I think a nova controller is dead | 15:22 |
| utkarsh2102 | aw :/ | 15:22 |
| cjwatson | utkarsh2102: sysadmins are a bit busy putting out all the other fires though | 15:22 |
| utkarsh2102 | Okay, thanks! | 15:22 |
| utkarsh2102 | *hugs* to them, either way | 15:23 |
| cjwatson | Most builders are back, though ppc64el still has some persistent problems about which I filed a ticket earlier today | 17:24 |
| === Laney is now known as Awayney | ||
| utkarsh2102 | yay | 18:52 |
| realtime-neil | Is there a backlog on publishing? I've been waiting over an hour for one particular repository? | 19:42 |
| cjwatson | Let me see if that was also taken out by the outage earlier | 19:42 |
| cjwatson | Ugh yes, that looks rather unhealthy, thanks for mentioning it | 19:43 |
| cjwatson | Not obviously a result of the outage though ... | 19:43 |
| cjwatson | Working on it, waiting for a sysadmin to get back to me | 19:47 |
| realtime-neil | cjwatson: I thought you _were_ the sysadmin. :D | 19:47 |
| cjwatson | 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 |
| cjwatson | So sometimes we need to do arm's-length stuff via them | 19:48 |
| cjwatson | realtime-neil: OK, publisher is back up now and should catch up in a bit | 19:50 |
| cjwatson | And I should probably check what alerts we have on that | 19:50 |
| realtime-neil | sweet, much thanks | 19:51 |
| realtime-neil | cjwatson: is there a status page I can look at? I have packages that have been publishing for over 90 minutes, now. | 20:44 |
| realtime-neil | whoops, I may have spoken too soon | 20:45 |
| teward | cjwatson: does Launchpad really still use 16.04? o.O | 22:46 |
| teward | are there any plans to update that in the ${future} since 16.04 standard support is... coming to an end :P | 22:46 |
| cjwatson | teward: sadly. upgrading later this year I hope | 22:47 |
| teward | just curious as i read through the dev docs | 22:47 |
| cjwatson | teward: LP works fine on 18.04, we just haven't had sysadmin cycles to upgrade production | 22:47 |
| teward | that i can understand heh | 22:47 |
| cjwatson | (20.04 maybe not so much, that's not tested yet and may need some fixes) | 22:47 |
| teward | 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 |
| teward | hence the questions :P | 22:48 |
| cjwatson | 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:48 |
| teward | 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 |
| cjwatson | It's true, we haven't necessarily gone around and updated all of those in advance of the production upgrade | 22:49 |
| cjwatson | Anyway, feel free to use either xenial or bionic | 22:49 |
| cjwatson | And either Python 2 or 3 | 22:50 |
| cjwatson | (select py3 with `make PYTHON=python3`) | 22:50 |
| teward | 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* | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!