[09:13] <lag> Is there any way to set the Git 'HEAD branch' in LP?
[09:17] <wgrant> lag: The git protocol doesn't provide a way to do it, so you have to do it through the web UI
[09:17] <wgrant> There's a "Default branch" field on the "Change details" page of the repository
[09:17] <wgrant> e.g. https://launchpad.net/~canonical-launchpad-branches/launchpad/+git/launchpad/+edit
[09:18] <lag> wgrant: "The information on this page is private."
[09:19] <wgrant> lag: Funnily enough you can't edit Launchpad's own repository. It was an example URL
[09:20] <lag> wgrant: Right.  I trigged on that after - I'm trying to edit it to suit my project/repo
[09:20] <lag> wgrant: Am I meant to see a link to be able to do it?  Or is the +edit the only way to get to the edit page?
[09:20] <wgrant> You can also just navigate to the repo in the web UI and hit the "Change details" link
[09:20] <wgrant> Make sure you're not on git.launchpad.net, though
[09:21] <wgrant> code.launchpad.net or just launchpad.net is the right place
[09:22] <lag> wgrant: Ah, in LP - I was trying to navigate via the Git UI
[09:22] <lag> wgrant: Thanks
[09:29] <lag> ..
[09:29] <lag> I have another question - been working on this for 4 days, so I figured 2 isn't too bad
[09:29] <lag> https://i.imgur.com/Le9D3vS.png
[09:30] <wgrant> lag: That usually means you've had two different builds that produced a package with the same version, which isn't allowed.
[09:30] <lag> Can anyone tell me why only Bionic succeeded?  Do the other releases require their own unique changelog entries?
[09:30] <lag> wgrant: I wish to create exactly the same package for each of the 3 releases
[09:30] <wgrant> lag: Does it need to be rebuilt between series?
[09:31] <lag> wgrant: Absolutely not - it's exactly the same
[09:31] <wgrant> lag: Not even any soname changes in dependencies?
[09:32] <lag> ?
[09:32] <wgrant> If not, build in the earliest series and then use the "Copy packages" link to copy it to newer ones, making sure you select to copy binaries.
[09:32] <wgrant> If a library changed versions significantly between bionic and disco, it might need a rebuild to be installable on disco
[09:32] <wgrant> If you do need to build it separately for each series, you'll need a separate changelog entry for each. It's common to append e.g. ~ubuntu18.04.1
[09:32] <lag> wgrant: It's the Linux kernel - it doesn't use libs
[09:33] <wgrant> lag: Fair enough then :)
[09:33] <wgrant> You are probably good with a binary copy.
[09:34] <lag> wgrant: Using 'Copy packages' sounds like a very manual process - is there any way to automate what I'm trying to achieve?
[09:34] <wgrant> The thing to remember is that a binary package within an archive must be unique by (name, version, architecture). You can't build the same thing twice, but you can copy them between architectures.
[09:34] <wgrant> lag: There's the copyPackages API which can be used for automation, but you'd need to run that script yourself.
[09:35] <wgrant> Unless you can use a source package recipe, but for something like the kernel that's rarely a good option.
[09:35] <lag> wgrant: I am using a source package recipe (I think)
[09:35] <lag> # git-build-recipe format 0.4 deb-version {debupstream}-laptops.{time}
[09:35] <lag> lp:~aarch64-laptops/+git/linux-kernel laptops
[09:35] <lag> merge kernel-packaging lp:~aarch64-laptops/+git/ubuntu-kernel-packaging master
[09:35] <lag> ..
[09:36] <lag> Is that wrong?
[09:38] <wgrant> lag: Oh, fair enough. That's a very weird version for an Ubuntu-derived kernel though.
[09:38] <wgrant> I'm not sure I've ever seen anyone try a recipe for a kernel due to ABI etc.
[09:39] <wgrant> lag: So, now you've mentioned the branch I can actually see what's going on :)
[09:39] <lag> wgrant: https://code.launchpad.net/~wip-kernel/+recipe/generic-lowlatency-build
[09:39] <wgrant> INFO File linux_5.0.0-rc5.tar.gz already exists in Linux Kernel, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
[09:40] <wgrant> In this case you're producing an orig tarball from the branch, but it's apparently different from the one that was generated or uploaded in the past.
[09:40] <lag> wgrant: Right, which would have been fine - but Bionic built fine?
[09:40] <lag> wgrant: ... which threw me
[09:41] <wgrant> Oh it's not even an orig tarball.
[09:41] <wgrant> It's a native with a weird version
[09:41] <wgrant> So, the kernel debian/rules is very weird
[09:41] <lag> wgrant: Which one?
[09:41] <wgrant> And it's probably clobbering debian/changelog after git-build-recipe adds its entry to it
[09:41] <lag> wgrant: The current one is the packaging the Kernel Team use
[09:41] <wgrant> Or your version template was bad
[09:42] <wgrant> Sure
[09:42] <wgrant> The one the kernel team uses is very weird :)
[09:42] <wgrant> It works for them, but it likely makes it incompatible with recipes
[09:42] <lag> wgrant: :D
[09:42] <wgrant> e.g. IIRC it overwrites debian/changelog with debian.master/changelog at the start of the build
[09:42] <lag> wgrant: Right, which I edit
[09:42] <lag> wgrant: The current change-log entry is mine (2 secs)
[09:42] <wgrant> Which is why the bionic build produced a version of "5.0-rc5" which clearly doesn't match your template of "{debupstream}-0~{revtime}"
[09:43] <wgrant> git-build-recipe assumes that debian/changelog won't be overwritten by the build, which is AFAIK a correct assumption for literally everything except linux
[09:44] <lag> wgrant: https://git.launchpad.net/~aarch64-laptops/+git/ubuntu-kernel-packaging/commit/?id=d5b6f0ea6f4810a29b1fca2a382eae1c2bb67942
[09:44] <wgrant> lag: Hm, have you done kernel packaging before?
[09:45] <wgrant> That's not a correct Debian version string, and it's particularly unlikely to be the right thing for a kernel
[09:45] <lag> wgrant: That's a very embarrassing question - I guess the best answer is, not for over a decade and even then only briefly
[09:45] <wgrant> lag: 5.0.0-rc5 technically means upstream version 5.0.0, Debian version rc5
[09:45] <wgrant> lag: What's this packaging based on?
[09:46] <wgrant> And do you need a recipe?
[09:46] <lag> wgrant: It's a mash-up of this: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc7/
[09:46] <wgrant> The kernel packaging is very, very strange and probably going to be difficult to turn into something that works, due to the ABI being included in package names etc.
[09:46] <lag> wgrant: And the project I sent you a link to a few lines back
[09:47] <lag> wgrant: I was told to use recipes by the person who owns the aforementioned project
[09:47] <wgrant> lag: Probably worth talking to them
[09:48] <wgrant> I'm not quite sure how they've done it
[09:48] <wgrant> But it seems to mostly work
[09:48] <lag> wgrant: I just want to build a kernel and push it into a PPA (easiest, simplest way possible)
[09:49] <lag> wgrant: The kernel has it's own built-in method of making packages, but that doesn't work will with LP either
[09:49] <wgrant> lag: There's nothing simple about building a sensible custom kernel package in a recipe. Recipes make some assumptions about how packages will behave, and the kernel has reasonable reasons for violating convention in many different ways
[09:49] <wgrant> Correct.
[09:49] <wgrant> It's not a common use case.
[09:49] <wgrant> If you have found someone who has done it, your best bet is to work with them.
[09:49] <wgrant> Bonus points if that approach gets documented :)
[09:50] <wgrant> It's easy enough (but not easy) to build a custom source package locally and upload it.
[09:50] <lag> wgrant: Maybe a changelog per-release wouldn't be such a bad thing after all ;)
[09:50] <wgrant> But having LP build it from a recipe is another matter entirely.
[13:45] <lag> So this is a new one - on upload of some source packages LP is telling me: "No changelog file found."
[13:45] <lag> .. then, in the same mail, it provides a copy of the changelog file - what gives?
[13:46] <lag> https://paste.ubuntu.com/p/Y7N2xVnqN5/
[13:46] <lag> Something wrong with the formatting?  Surely that would be a different error?
[13:54] <rbasak> lag: remember that parts of debian/changelog are duplicated into the changes file before upload. If the message is coming from the changes file, it's not necessarily a contradiction.
[13:55] <rbasak> (I'm speculating somewhat but hopefully you see my point)
[14:07] <wgrant> lag: As rbasak says, that part of the email comes from the .changes file that you uploaded, which includes a variant of the most recent changelog entry
[14:09] <lag> wgrant: I did suspect that it was complaining about the changelog not being changed since the last attempted upload - so I bumped the version
[14:09] <lag> wgrant: Same problem
[14:09] <lag> rbasak: -^
[14:13] <wgrant> lag: What's the same problem?
[14:13] <wgrant> Have you confirmed that debian/changelog exists in the tarball?
[14:14] <lag> wgrant: Hmm... it does not
[14:14] <wgrant> See, LP produces accurate error messages that you should trust :)
[14:14] <lag> wgrant: Is this because I symlinked the packaging from another file?
[14:14] <lag> wgrant: Ha ha - maybe this time ;)
[14:15] <lag> s/file/repo/
[14:15] <wgrant> lag: I don't know, you'll need to work out where the file went.
[14:15] <lag> wgrant: I need to find another way of doing that
[14:15] <lag> wgrant: I think it's added the symlinks to debian and debian.master, but not followed them - damn!
[14:15] <lag> wgrant: Thanks for your help - I owe you a beer
[14:40] <lag> wgrant: How does this look to you?  linux (5.0.0-rc5-generic-next-20190206-050000rc5) bionic; urgency=medium
[14:41] <lag> wgrant: Is the Debian version taken after the last or the first '-'?
[14:43] <rbasak> IIRC it's the last '-'
[14:43] <rbasak> That allows upstream versions to contain '-'
[14:44] <rbasak> Probably best to avoid doing that though
[14:44] <rbasak> It just leads to confusion.
[14:44] <rbasak> For example 5.0.0-rc5 will sort after 5.0.0 which is wrong.
[15:18] <lag> rbasak: Right, so in my example the version can be "5.0.0-rc5-generic-next-20190206" which is correct
[15:19] <lag> rbasak: Then Debian can use -050000rc5 which I don't really care about
[18:13] <Eickmeyer> Looks like the build farm might be stuck again.
[18:41] <Eickmeyer> Yep, definitely stuck.
[18:47] <cjwatson> Eickmeyer: should be returning to life, thanks
[18:47] <Eickmeyer> cjwatson: Thanks!
[20:09] <QwertyChouskie> This series cannot be deleted because it has translations.
[20:09] <QwertyChouskie> How do I fix this?
[23:24] <wgrant> QwertyChouskie: You might be able to move the translation templates to another series, or just mark the series as obsolete and leave it harmlessly behind
[23:56] <QwertyChouskie> wgrant: Can I just remove all translation stuff?  The projects has used Transifex for years so any translation stuff is just clutter at this point
[23:56] <QwertyChouskie> The project: https://launchpad.net/stk