[12:34] <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:35] <realtime-neil> What is this "Primary Archive for Ubuntu" mentioned in the error message?
[12:35] <cjwatson> The Ubuntu archive.  archive.ubuntu.com
[12:36] <realtime-neil> Okay. How do I find that package so I can use it instead of the one I'm trying to upload?
[12:38] <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:39] <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:40] <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:41] <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:43] <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:44] <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:45] <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:46] <realtime-neil> gbp import-orig --pristine-tar ?
[12:48] <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:49] <cjwatson> "man pristine-tar"
[12:50] <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:51] <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:52] <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:53] <cjwatson> Ah, make that "pristine-tar commit ../fcl_0.6.1.orig.tar.gz upstream/0.6.1" by the looks of things
[12:54] <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:55] <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:56] <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:57] <realtime-neil> huh, okay
[12:58] <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:59] <cjwatson> https://git.launchpad.net/git-build-recipe/tree/gitbuildrecipe/deb_util.py#n51
[13:02] <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:03] <realtime-neil> welp, that worked worse than I had hoped: https://launchpadlibrarian.net/529559463/buildlog.txt.gz
[13:04] <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:05] <realtime-neil> okay
[13:06] <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:07] <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:08] <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:09] <realtime-neil> Oh, if it's a local operation followed by a dput, I think I prefer a recipe.
[13:25] <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:56] <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:59] <cjwatson> You should get an email notification unless there was a signing failure
[14:00] <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:37] <cjwatson> PPA uploads seem to be recovering now
[14:38] <realtime-neil> retrying now
[14:40] <cjwatson> No need
[14:40] <cjwatson> Uploads were queued
[14:46] <rbasak> utkarsh2102: ^
[14:47] <utkarsh2102> perfect, thanks
[14:49] <realtime-neil> What does this mean? "Rejected: PPA uploads must be for the RELEASE pocket."
[14:52] <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:53] <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:54] <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:55] <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:56] <realtime-neil> It's all I can do to master deb packaging -- I'll learn snap at the next job.
[15:21] <utkarsh2102> even though PPA uploads are accepted, the builders are almost down, it seems?
[15:22] <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:23] <utkarsh2102> *hugs* to them, either way
[17:24] <cjwatson> Most builders are back, though ppc64el still has some persistent problems about which I filed a ticket earlier today
[18:52] <utkarsh2102> yay
[19:42] <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:43] <cjwatson> Ugh yes, that looks rather unhealthy, thanks for mentioning it
[19:43] <cjwatson> Not obviously a result of the outage though ...
[19:47] <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:48] <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:50] <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:51] <realtime-neil> sweet, much thanks
[20:44] <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:45] <realtime-neil> whoops, I may have spoken too soon
[22:46] <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:47] <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:48] <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:49] <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:50] <cjwatson> And either Python 2 or 3
[22:50] <cjwatson> (select py3 with `make PYTHON=python3`)
[23:51] <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*