| matjam | hey guys, packages successfully builds, but it's stuck "Pending" https://launchpad.net/~chrome/+archive/ubuntu/magnum.graphics/+packages | 08:21 |
|---|---|---|
| matjam | can anyone help? | 08:21 |
| cjwatson | It's Sunday morning so there's a long-running maintenance job. Give it a while longer. | 09:15 |
| * enyc prods and pokes the PPA system ;p you know you want to build my package! | 14:12 | |
| cjwatson | enyc: Hm? Build queues look nice and clear. | 14:13 |
| enyc | cjwatson: yes quite iv'e now discovered the rejection emails ;p sorting it =) | 14:16 |
| enyc | cjwatson: are there any articles on version-number-additions with ~ and whot-have-you for -backports, -updates, PPA, etc versions? | 14:17 |
| enyc | ~0ubuntu0 ~0-xenial-ppa etc etc all of that | 14:17 |
| cjwatson | enyc: It's mostly convention and a lot of it is up to you, but https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage | 14:18 |
| cjwatson | I'd advise against "~0-xenial-ppa" for multiple reasons though. | 14:19 |
| enyc | cjwatson: yes where are these 'conventions' listed, and what is best if something is to be considered for -backports or -updates anyway? | 14:19 |
| cjwatson | If you're doing anything fancy, consult Debian policy. | 14:20 |
| cjwatson | You should understand what each part of the version number means. | 14:20 |
| cjwatson | Hyphens are special and you should normally only have at most one in your version number, to separate the upstream version number from the packaging revision. Using any more hyphens than that is asking for trouble. | 14:21 |
| cjwatson | Also, using "xenial" is a bad idea; all components of the version number should be sortable, so "16.04" is preferable to "xenial" (because otherwise xenial > bionic ...) | 14:21 |
| cjwatson | For things like -updates, I recommend https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging | 14:22 |
| enyc | hrrrrrrrrrrrrrrm now when i"ve seen backports in debian they like using ~bpo ... because the ~ has special meaning to produce a'less than' version... so that a xenial-backport will then get updated to a bionic version upon do-release-upgrade | 14:24 |
| enyc | ~ubuntu16.04.1 semes to be used | 14:25 |
| cjwatson | That's a reasonable convention, yes | 14:25 |
| enyc | and a reosnably one to start off with in a xenial-ppa ? | 14:26 |
| cjwatson | It depends what you're starting from. | 14:26 |
| cjwatson | If what you mean is "build version 1.1.0-1 for xenial", then 1.1.0-1~ubuntu16.04.1 is a reasonable version | 14:26 |
| enyc | debian pkg already in ubuntu with no ubuntu specific changes/addons at all, to ubuntu versioninig at all | 14:26 |
| cjwatson | Also, if you have no Ubuntu-specific changes, you can just use "backportpackage" and it'll do it all for you. | 14:27 |
| enyc | lol didn't know that one =) | 14:27 |
| cjwatson | And, indeed, "~" means "sort just before the version you get if you truncate the version at the ~" | 14:29 |
| cjwatson | So is generally very useful for backports. Not so much if there are substantive changes, as is usually the case in -updates | 14:29 |
| cjwatson | You can't lump -backports and -updates into one approach here. | 14:30 |
| * cjwatson out | 14:31 | |
| enyc | cjwatson: right yes that makes sense... thaknyou | 14:31 |
| matjam | cjwatson: its ok now, thanks, was thinking it was something I was doing wrong lol | 14:32 |
| matjam | can anyone see why https://launchpadlibrarian.net/372058539/buildlog_ubuntu-xenial-amd64.magnum-plugins_2018.04-1ppa3~ubuntu16.04_BUILDING.txt.gz is failing? Depends: libfreetype6-dev but it is not going to be installed .. its a package thats available | 15:03 |
| enyc | matjam: hrrm if you had access to chroot yourserf i'd be "apt-get install libfreetype6-dev" and then see what its triyng to remove etc... | 16:01 |
| enyc | matjam: I would look on https://packages.ubuntu.com/libfreetype6-dev BUT the packages-website is devoid of trusty/xenial inforamtion at the moment [grr!] | 16:01 |
| matjam | enyc: I'm starting from clean working control file, I think I fat fingered something | 16:02 |
| matjam | had this stuff working last night | 16:02 |
| matjam | then my packages wouldn't publish | 16:02 |
| matjam | sigh | 16:02 |
| matjam | I feel like the failed build count is like a mark against my honor | 16:26 |
| cjwatson | matjam: The transition to libpng1.6 hadn't finished in xenial yet. As a result, when you build-depend on libpng16-dev | libpng-dev, libfreetype6-dev, the following happens: | 17:08 |
| matjam | cjwatson: I got it all to build https://launchpad.net/~chrome/+archive/ubuntu/magnum.graphics | 17:08 |
| cjwatson | matjam: (1) apt marks the immediate build-dependencies for installation, including libpng16-dev and libfreetype6-dev. (It would only try to fall back to some other provider of libpng-dev if libpng16-dev were entirely absent.) | 17:08 |
| matjam | I have libpng-dev|libpng16-dev in dependencies | 17:09 |
| cjwatson | matjam: (2) apt tries to satisfy all the broken dependencies, and since libfreetype6-dev depends on libpng-dev (whose only provider is libpng12-dev) that results in a conflict. | 17:09 |
| matjam | ahh | 17:10 |
| cjwatson | matjam: libpng12-dev | libpng-dev would have been a technically more correct fix for xenial, I believe, but yours will do. | 17:10 |
| matjam | makes sense | 17:10 |
| matjam | I'll make note for next time | 17:10 |
| cjwatson | Unfortunately apt isn't terribly helpful about this until you ask it some slightly more probing questions. | 17:10 |
| matjam | I wasn't able to make a build chroot for 16.04 on my 18.04 machine (doing it wrong, I'm sure) so I was only able to test locally on 18.04 | 17:11 |
| cjwatson | I recommend chdist, from the devscripts package. | 17:11 |
| matjam | oh, that looks nice | 17:12 |
| cjwatson | You don't need a full chroot for this kind of thing; you just need an environment where you can do simulated runs of apt (without actually installing any packages, but just running the dependency resolution algorithm). | 17:12 |
| matjam | right | 17:12 |
| cjwatson | chdist gives you that. (Of course if you try to actually install packages that way you will have a bad time.) | 17:12 |
| matjam | yeah that would have sorted me out | 17:12 |
| matjam | superseded packages get deleted after a while, right? | 17:13 |
| cjwatson | Yes. | 17:14 |
| matjam | neato | 17:14 |
| matjam | thanks for the advice, appreciated | 17:14 |
| cjwatson | They stop being published (and hence counted against your quota) after a day or so; they get deleted entirely after about a week. | 17:15 |
| cjwatson | IIRC | 17:15 |
| matjam | took me a few iterations to get the build right | 17:15 |
| matjam | upstream had done most of the work with the packaging they just didn't want to do the PPA stuff, so I took care of it | 17:16 |
| cjwatson | It can take a few goes sometimes, yes. I normally prefer to iterate locally with sbuild. | 17:20 |
| matjam | yeah I think that would be preferable | 17:20 |
| matjam | the wait time between builds on lp makes it intolerable when you have packages with interdependencies | 17:21 |
| matjam | and I am new to it so wasn't aware that sundays there's a long running batch job that stops things from being published :P | 17:21 |
| cjwatson | It's literally just a couple of find | xargs to clean up empty directories, but the PPA tree is kinda huge | 17:23 |
| cjwatson | Should really just integrate it into the normal publisher | 17:25 |
| matjam | ok my job is done, packages published, upstream PRs created | 17:35 |
| physkets | Hi! | 17:46 |
| physkets | I need help with pulling code from launchpad | 17:46 |
| physkets | specifically, this repo: | 17:46 |
| physkets | https://code.launchpad.net/~armagetronad-dev/armagetronad/0.4-armagetronad-work | 17:47 |
| physkets | How do I do it? | 17:47 |
| cjwatson | What have you tried, and what didn't work? | 17:47 |
| physkets | armagetronad/0.4::bzr+https://code.launchpad.net/~armagetronad-dev/armagetronad/0.4-armagetronad-work/ | 17:47 |
| physkets | Will this work? | 17:47 |
| cjwatson | Uh, I mean, in what context? That's not a Unix command | 17:48 |
| physkets | oh sorry, | 17:48 |
| physkets | in an Arch(linux) PKGBUILD | 17:48 |
| cjwatson | I'm not exactly an Arch expert. Can you point to some general docs about what it expects? | 17:48 |
| physkets | for ge: | 17:48 |
| physkets | https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=etude-bzr | 17:48 |
| physkets | look at the source() line | 17:49 |
| cjwatson | I think armagetronad::bzr+https://bazaar.launchpad.net/+branch/armagetronad/0.4 ought to work | 17:50 |
| physkets | so how do I test that? | 17:50 |
| cjwatson | The +branch shortcut saves you from hardcoding what that alias happens to point at | 17:50 |
| physkets | But what you posted is very different from the link... | 17:51 |
| physkets | how did you get from: | 17:51 |
| physkets | https://code.launchpad.net/~armagetronad-dev/armagetronad/0.4-armagetronad-work | 17:52 |
| physkets | to that? | 17:52 |
| cjwatson | Ah, needs to be code not bazaar I think | 17:52 |
| cjwatson | armagetronad::bzr+https://code.launchpad.net/+branch/armagetronad/0.4 | 17:52 |
| cjwatson | You could use armagetronad::bzr+https://code.launchpad.net/~armagetronad-dev/armagetronad/0.4-armagetronad-work if you prefer - I just optimised it | 17:52 |
| physkets | okay, but how do I check if it is pulling the code fine? | 17:52 |
| physkets | I mena, does wget work on that? | 17:53 |
| cjwatson | I got to +branch/armagetronad/0.4 by observing the lp:armagetronad/0.4 bit at the top of the page, and having insider knowledge | 17:53 |
| cjwatson | "bzr branch https://code.launchpad.net/+branch/armagetronad/0.4 armagetronad" works fine | 17:53 |
| cjwatson | Beyond that, you need somebody who has any idea whatsoever about Arch | 17:53 |
| physkets | oh | 17:53 |
| physkets | THanks! | 17:54 |
| cjwatson | It's possible that armagetronad::bzr+lp:armagetronad/0.4 would work too, but that's even more shorthand and it depends on how the thing that handles PKGBUILD is implemented | 17:54 |
| cjwatson | If it just strips off the VCS prefix and then passes it to bzr branch, then that would be all you'd need | 17:55 |
| physkets | I see... let me try that | 17:56 |
| physkets | cjwatson: Dosen't the part before the :: have to be "armagetronad/0.4" ? | 17:57 |
| physkets | oh nevermind | 17:57 |
| cjwatson | I wouldn't have thought so | 17:58 |
| cjwatson | That's a local directory name, right? | 17:58 |
| physkets | SO what exactly does the part before the :: denote? | 17:58 |
| cjwatson | physkets: That's an Arch question, not a Launchpad one. | 18:00 |
| physkets | oh | 18:00 |
| cjwatson | physkets: But see https://www.archlinux.org/pacman/PKGBUILD.5.html#VCS | 18:00 |
| physkets | ah | 18:02 |
| physkets | cjwatson: Is there somehow I can get the code and calculate it's sha1 sum? | 18:04 |
| cjwatson | What does that even mean? A directory of files checked out by a version control system doesn't have an obvious checksum. | 18:05 |
| physkets | oh... ya | 18:06 |
| cjwatson | You can get the code as indicated in the "Get this branch:" section of the web page you started from, but otherwise the question isn't well-defined. | 18:06 |
| physkets | cjwatson: THanks for your help!! | 18:42 |
| physkets | that short version works! :) | 18:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!