| lag | Is there any way to set the Git 'HEAD branch' in LP? | 09:13 |
|---|---|---|
| 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:17 |
| lag | wgrant: "The information on this page is private." | 09:18 |
| wgrant | lag: Funnily enough you can't edit Launchpad's own repository. It was an example URL | 09:19 |
| 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:20 |
| wgrant | code.launchpad.net or just launchpad.net is the right place | 09:21 |
| lag | wgrant: Ah, in LP - I was trying to navigate via the Git UI | 09:22 |
| lag | wgrant: Thanks | 09:22 |
| 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:29 |
| 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:30 |
| lag | wgrant: Absolutely not - it's exactly the same | 09:31 |
| wgrant | lag: Not even any soname changes in dependencies? | 09:31 |
| 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:32 |
| wgrant | lag: Fair enough then :) | 09:33 |
| wgrant | You are probably good with a binary copy. | 09:33 |
| 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:34 |
| 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:35 |
| lag | Is that wrong? | 09:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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. | 09:50 |
| 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:45 |
| lag | https://paste.ubuntu.com/p/Y7N2xVnqN5/ | 13:46 |
| lag | Something wrong with the formatting? Surely that would be a different error? | 13:46 |
| 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:54 |
| rbasak | (I'm speculating somewhat but hopefully you see my point) | 13:55 |
| 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:07 |
| 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:09 |
| wgrant | lag: What's the same problem? | 14:13 |
| wgrant | Have you confirmed that debian/changelog exists in the tarball? | 14:13 |
| 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:14 |
| 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:15 |
| lag | wgrant: How does this look to you? linux (5.0.0-rc5-generic-next-20190206-050000rc5) bionic; urgency=medium | 14:40 |
| lag | wgrant: Is the Debian version taken after the last or the first '-'? | 14:41 |
| rbasak | IIRC it's the last '-' | 14:43 |
| rbasak | That allows upstream versions to contain '-' | 14:43 |
| 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. | 14:44 |
| lag | rbasak: Right, so in my example the version can be "5.0.0-rc5-generic-next-20190206" which is correct | 15:18 |
| lag | rbasak: Then Debian can use -050000rc5 which I don't really care about | 15:19 |
| Eickmeyer | Looks like the build farm might be stuck again. | 18:13 |
| Eickmeyer | Yep, definitely stuck. | 18:41 |
| cjwatson | Eickmeyer: should be returning to life, thanks | 18:47 |
| Eickmeyer | cjwatson: Thanks! | 18:47 |
| QwertyChouskie | This series cannot be deleted because it has translations. | 20:09 |
| QwertyChouskie | How do I fix this? | 20:09 |
| 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:24 |
| 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 | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
