| codygarver | hey guys, I'm getting this error on a few trusty builds. Anyone know what's up? "dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision" https://launchpadlibrarian.net/157057722/buildlog.txt.gz | 03:15 |
|---|---|---|
| dobey | codygarver: fix your debian/source/format file, or your version string. you are using an invalid version string in debian/changelog for the native format | 03:16 |
| codygarver | dobey, are you sure? It used to build and still builds for saucy and precise. Nothing has changed and it was working for Trusty until a few days ago https://code.launchpad.net/~elementary-os/+recipe/granite-daily | 03:19 |
| codygarver | http://bazaar.launchpad.net/~elementary-os/granite/deb-packaging/view/head:/debian/changelog and the format is not native http://bazaar.launchpad.net/~elementary-os/granite/deb-packaging/view/head:/debian/source/format | 03:21 |
| StevenK | codygarver: Nothing has changed except trusty itself, it's the new dpkg in trusty. | 03:21 |
| StevenK | Ah, a recipe. bzr-builder will override the format to 3.0 (native) if you don't have pristine-tar information. | 03:21 |
| codygarver | StevenK, so the version string is the problem? | 03:22 |
| StevenK | codygarver: You have a solution, which is to use pristine-tar with your orig tarball which will stop bzr-builder overriding the format to 3.0 (native). A workaround is to drop the - from the version string. | 03:24 |
| codygarver | StevenK, how can I provie a pristine-tar with a recipe build? It's also happening with this recipe that's changelog doesn't contain a - https://code.launchpad.net/~elementary-os/+recipe/noise-daily | 03:27 |
| codygarver | provide a pristine-tar* | 03:27 |
| StevenK | codygarver: A version of 0.2.4 should be 3.0 (native), not 3.0 (quilt) | 03:31 |
| StevenK | And that is what is the error is trying to point out. | 03:31 |
| codygarver | ok so that one is not liking that it was expecting patches and didn't find them, got it | 03:32 |
| StevenK | No, it is purely a comparsion of the version, files and format. 3.0 (quilt) is for non-native packages, ie: 1.0-1; 0.2.4 is a native version | 03:32 |
| codygarver | StevenK, oh ok, thanks a lot! | 03:33 |
| codygarver | StevenK, but what about this one https://code.launchpad.net/~elementary-os/+recipe/noise-daily it is not a native version and is quilt with patches? | 03:33 |
| StevenK | noise-daily is the native version | 03:34 |
| StevenK | 0.2.4 is a native version | 03:34 |
| codygarver | StevenK, oh it's complaining about the - in the recipe header? | 03:34 |
| codygarver | {debversion}+r{revno}-0+pkg{revno:packaging} | 03:35 |
| StevenK | Oh, yeah, exactly. | 03:35 |
| dobey | codygarver: you need to change the version in debian/changelog in the packaging branches to be 0.2.4-0elementary1 or something | 03:35 |
| StevenK | Sorry, I was comparing the version in debian/changelog, which the recipe machinery doesn't use. | 03:35 |
| codygarver | now it really all makes sense, thanks dobey and StevenK | 03:35 |
| StevenK | dobey: Still contains a - | 03:35 |
| StevenK | Try again? :-P | 03:35 |
| dobey | StevenK: yes, it should be fine as long as debian/changelog has the thing. dpkg is looking at what's already in debian/changelog | 03:36 |
| StevenK | bzr-builder adds an entry first, no? | 03:36 |
| StevenK | So fix the recipe text and retry | 03:36 |
| dobey | hrmm | 03:37 |
| dobey | StevenK: then it shouldn't matter, since source/format has 3.0 (quilt) | 03:37 |
| dobey | but having the - in debian/changelog apparently doesn't fix it either | 03:38 |
| StevenK | dobey: But bzr-builder overrides the format to 3.0 (native) with no pristine-tar information, which I said earlier. | 03:38 |
| codygarver | I have modified the recipe versioning and requested a build, so we'll see in a few minutes | 03:38 |
| StevenK | codygarver: If it's not already building, link it to me and I'll make it build. | 03:39 |
| codygarver | stgraber, I used a recipe that's not in a somewhat-production environment yet https://code.launchpad.net/~codygarver/+recipe/midori-elementary-daily | 03:39 |
| codygarver | StevenK, ^ | 03:39 |
| dobey | then i guess bzr-builder needs fixing | 03:39 |
| StevenK | Or use pristine-tar, and it won't override. | 03:40 |
| StevenK | It wants to make the exact same orig from just bzr history, it needs something more. | 03:40 |
| dobey | what does it even mean to provide pristine-tar in a source recipe? | 03:45 |
| StevenK | dobey: pristine-tar takes an orig tarball and the repoistory information and creates a diff and commits it. Then you can always reconstruct the *exact same* orig using only bzr history | 03:46 |
| StevenK | dobey: 'man pristine-tar' ? | 03:49 |
| dobey | that doesn't actually tell me anything. nor does it work for sources that have never actually made a tarball release, and seems like it would be unusable for git imports | 03:49 |
| StevenK | dobey: Sorry for not explaining it well -- the DESCRIPTION in the pristine-tar manual page should help, then. | 03:50 |
| dobey | doesn't really help either. it tells me it is not a usable solution, though. | 03:53 |
| wgrant | dobey: Sources that have never made a tarball release have to be native. | 03:55 |
| wgrant | Because non-native implies release tarball. | 03:55 |
| dobey | native implies the package information is part of the source tree; it doesn't necessarily imply tarball | 03:55 |
| StevenK | native also implies a format and version | 03:56 |
| codygarver | it looks like removing the - from the recipe version resolved the issue https://code.launchpad.net/~codygarver/+recipe/midori-elementary-daily | 03:56 |
| codygarver | thanks for your help again | 03:56 |
| wgrant | dobey: Non-native necessarily implies release tarball | 03:57 |
| wgrant | A package is non-native iff it has at least one orig.tar.* | 03:57 |
| dobey | does "debuild -S -sa" in the tree of a non-native package without an orig.tar in the parent directory, fail completely, or ask you to continue anyway, with the new dpkg? | 04:00 |
| StevenK | It will fail completly, I think. | 04:01 |
| wgrant | dobey: If you've specified '3.0 (quilt)' as the format it will fail | 04:01 |
| wgrant | I don't know the behaviour of format 1.0 in the new dpkg | 04:02 |
| dobey | :( | 04:02 |
| wgrant | But it previously would fall back to native, as there was no way to distinguish. | 04:02 |
| wgrant | 3.0 (quilt) without an orig.tar.gz has failed since almost day 1 | 04:02 |
| dobey | since day 1? | 04:03 |
| wgrant | 3.0 (native) with a non-native version has only failed since last week. | 04:03 |
| wgrant | day 1 of the 3.0 formats. | 04:03 |
| dobey | no, it doesn't fail. it asks if you want to make the source anyway | 04:03 |
| wgrant | dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../hello_2.8+fake.orig.tar.{bz2,gz,lzma,xz} | 04:04 |
| wgrant | It asks, but still fails. | 04:04 |
| dobey | oh, ok | 04:07 |
| dobey | can't bzr-builder export the tree to the orig.tar.gz if format is 3.0 (quilt)? | 04:08 |
| dobey | seems like it should do | 04:08 |
| StevenK | It will do so, given pristine-tar information is in the branch. | 04:08 |
| dobey | and generate a giant diff for all changes made since that tarball release? that is silly | 04:10 |
| wgrant | Silly? | 04:11 |
| wgrant | What else can it do? | 04:11 |
| dobey | export the current revision of the tree to the orig.tar? | 04:12 |
| wgrant | That would be the original tarball, though. | 04:13 |
| wgrant | s/would/wouldn't/ | 04:13 |
| dobey | yes it would be | 04:13 |
| wgrant | How? | 04:13 |
| dobey | it would be the original tarball for that revision of the branch. | 04:13 |
| dobey | and it would avoid many other potential failures as a result of not doing that | 04:14 |
| wgrant | What potential failures? | 04:14 |
| dobey | such as binary files in the tree having changed since the last "tarbsll release" | 04:14 |
| wgrant | There shouldn't be binary files in a source tree in the first place :P | 04:15 |
| dobey | yeah, well, good luck with that | 04:15 |
| wgrant | What version would the orig.tar.gz have? | 04:15 |
| wgrant | How do we ensure that it's bit-identical each time? | 04:15 |
| dobey | the same version as the recipe | 04:15 |
| wgrant | 3.0 (quilt) handles changed binaries anyway. | 04:16 |
| wgrant | If it's the same version as the recipe, what value does it provide over a native non-orig.tar.gz/ | 04:16 |
| wgrant | orig.tar.gzs are useful because they can be shared. | 04:16 |
| dobey | making versions strings that are correct for things that aren't native sources | 04:16 |
| dobey | well if you are getting orig.tar.gzs from a PPA to use as "official original tarballs" you've already failed | 04:17 |
| wgrant | There may be some value in being able to construct a bit-identical tarball from just the upstream branch with a version like 1.0+bzr20131122, but it's not entirely clear how that would work, and it's significantly more complicated. | 04:18 |
| dobey | for official archive, sure; for PPAs, many of them aren't maintained by debian developers | 04:18 |
| dobey | "bzr export" isn't complicated | 04:18 |
| wgrant | Daily builds today should either produce a native package with a native version, or produce a non-native package based on some real release tarball for which the branch has pristine-tar metadata, and include changes since the tarball in the debian.tar.gz. | 04:18 |
| dobey | recipes can't use real release tarballs | 04:19 |
| wgrant | dobey: Recipes would need to specify how to construct the upstream tree and then separately how to apply the Debian changes. | 04:19 |
| wgrant | dobey: Why can't they? | 04:19 |
| wgrant | Lots of recipes do. | 04:19 |
| dobey | because people making recipe builds of things don't necessarily have commit priveleges to the things they are packaging to add pristine-tar info to them, even if it made sense to do so | 04:19 |
| wgrant | They could include the pristine-tar metadata in the packaging branch. | 04:19 |
| wgrant | Anyway, those are the two ways it works today. | 04:20 |
| wgrant | If you want to implement the separate upstream branch functionality, by all means. | 04:20 |
| dobey | and pristine-tar doesn't make sense in the recipes; the thing i am packaging isn't the last released tarball with a signficant number of changes in a giant diff. it's trunk. | 04:22 |
| dobey | anyway, i am not in .au time zone, so i should go get some sleep :) | 04:22 |
| wgrant | pristine-tar makes sense in recipes. | 04:22 |
| wgrant | One could argue it makes less sense in *daily build* recipes. | 04:22 |
| wgrant | That's up for debate. | 04:23 |
| dobey | sure, if those recipes are packaging a specific revision of a branch that is exactly the same as the tarball in question :) | 04:23 |
| wgrant | Or recipes composing upstream releases and a Debian branch.l | 04:23 |
| wgrant | Not all recipes are of an ever-changing trunk. | 04:23 |
| === caktux_ is now known as caktux | ||
| dobey | all the ones i care about are :) | 04:24 |
| wgrant | But they are not all the recipes in the world. | 04:24 |
| dobey | no, but they are the ones that are broken by these changes | 04:24 |
| wgrant | Recipes that are daily builds of trunk must today use one of the two solutions I described. | 04:24 |
| dobey | while the others aren't, and wouldn't be broken by changing bzr-builder to deal with the changes in a better way for these sorts of recipes | 04:25 |
| wgrant | If someone wants to implement the third, they can. | 04:25 |
| wgrant | bzr-builder can't simply be magically changed. | 04:25 |
| wgrant | It would require an extension of the recipe format, for example. | 04:25 |
| wgrant | If someone wants to do that, that'd be great. | 04:25 |
| dobey | anyway, sleep for now | 04:25 |
| dobey | later :) | 04:26 |
| wgrant | Night | 04:31 |
| Noskcaj | wgrant, To test if the package builds. If so, it can be synced to ubuntu | 07:07 |
| czajkowski | aloha | 08:47 |
| === eagles0513875_ is now known as eagles0513875 | ||
| philsf | I need help with a recipe for building packages in LP. When I test locally (bzr dailydeb recipe wd), the source package is built. When I request a build in LP, I get the following error: https://launchpadlibrarian.net/157361878/buildlog.txt.gz | 20:23 |
| philsf | how come LP is complaining I didn't set my LP-id, if I'm doing it while logged in? | 20:23 |
| dobey | that has nothing to do with your lp id; you aren't running the recipe, launchpad is, on a build server in a chroot somewhere. it doesn't have your credentials to access or write to things | 20:24 |
| dobey | what is the url for the recipe? | 20:26 |
| philsf | https://code.launchpad.net/~philsf/+recipe/philsf-likes-workstation | 20:29 |
| dobey | so, some stuff in format 0.4 doesn't work on launchpad yet. format 0.3 works fine though. so you need to use something like "{debupstream}+r{revno}" for the version instead of {latest-tag} | 20:31 |
| philsf | dobey, hmm, but this way I can't use a single recipe to track releases from tags, right? that is, unless I request a build whenever I push the revision of a release, am I correct? | 20:32 |
| dobey | what do you mean? {latest-tag} also isn't really a good version number. the tag could be "foo" which isn't a number at all. version numbers have to begin with a digit | 20:37 |
| dobey | philsf: also, the version string in the recipe doesn't control what revision is being checked out in the build | 20:37 |
| philsf | dobey, I always use tags like "0.1.0", or something like that. I thought it was the simplest way to manage releases in LP | 20:38 |
| philsf | dobey, yay, it built now. thanks! I think I'll only use {debversion}, since I don't need a daily build | 20:40 |
| dobey | well, the binary build will fail | 20:41 |
| philsf | why? | 20:46 |
| dobey | because your branch doesn't contain anything but the debian/ directory; so nothing to build or install | 20:47 |
| philsf | I meant {debupstream}, not {debversion}. | 20:47 |
| philsf | debuild builds the binary package fine. what should I do to create a metapackage that makes LP happy, then? | 20:48 |
| dobey | you are trying to make a metapackage? | 20:59 |
| philsf | yup | 20:59 |
| philsf | btw, is there a way NOT to include ~ubuntu13.10.1 or similar in the uploaded package version? | 20:59 |
| dobey | it might work as-is. you'll have to wait 5+ hours to see | 21:00 |
| dobey | no, there isn't | 21:00 |
| dobey | the ubuntu release version is automatically appended to all recipe builds | 21:00 |
| dobey | if you are going to build on multiple versions of ubuntu, it is very necessary | 21:01 |
| philsf | If I want the kind of versioning that is usual in official packages (say, for another project), would I need to use the likes of dput instead of using a recipe? | 21:03 |
| dobey | i'm not sure what you're asking exactly | 21:04 |
| philsf | lol, sorry. say I have a serious project I'm releasing, and want the package version to be 0.1, or 0.1-1, instead of 0.1~ubuntu13.10. How can I accomplish that in LP? | 21:05 |
| philsf | (for an example, I'm working on launchpad.net/~mmrrsim, but that packaging is not finished yet) | 21:06 |
| dobey | well, in a PPA you should always append the ~ubuntu13.10.1 for example | 21:06 |
| dobey | whether it is via dput or a recipe | 21:06 |
| philsf | for this ~mmrrsim project, I intend to ask debian to include it there, then ask ubuntu to include. but I'm using LP as upstream, for both coding and packaging, bugs, questions, etc. | 21:07 |
| dobey | if you want 0.1 (because you're a native package), or 0.1-1 (because you're a non-native package with an orig.tar.gz), or 0.1-0ubuntu1 (because you want it in ubuntu) you should do the requisite work to get it included in debian or ubuntu | 21:08 |
| dobey | PPAs are not the place official debian/ubuntu packages | 21:08 |
| dobey | recipes are easier because they automatically append the ~ubuntu13.10.1 bit | 21:09 |
| dobey | so they are great for making use of PPAs easier | 21:09 |
| philsf | dobey, cool. thanks for clarifying that. I'll do exactly that for my work project. the one I bothered you about is just a little thing to help me keep updated in all my boxes. | 21:09 |
| dobey | philsf: maybe you should look at using oneconf in software-center, instead of a meta package | 21:10 |
| dobey | philsf: it's a feature that allows you to install the same packages as you have installed on another computer on your network | 21:10 |
| philsf | dobey, thanks for the pointer. I was curious about metapackaging, though ;) | 21:11 |
| philsf | it's also a simple way of sharing my base workstation install with coworkers. the rant about the ~ubuntu13.10 is irrelevant, and as you said, useful | 21:12 |
| slackner | wgrant: Hiho. You probably remember our questions recently about moving PPAs to a different user/groups, where we didn't find a good solution. Is it probably possible to put just a symlink / redirection at the original location of the PPA, and reuse the same signing key for a new one, without breaking the installation of our current users? Or alternatively that all packages are copied automatically from one location to the other one? | 22:34 |
| maxb | Automatic copying could be done with a cronjob calling the lp web api | 22:47 |
| wgrant | slackner: Neither of those are possible within Launchpad, but as maxb suggests you could use an API script and cron to keep two PPAs in sync. | 23:09 |
| slackner | wgrant: is it technically not possible, or just not implemented? | 23:10 |
| wgrant | Aliasing PPAs is not supported and difficult to support in the current implementation. We could probably work out a way to transfer a PPA key if you have a good reason to request it. | 23:17 |
| wgrant | slackner: ^^ | 23:17 |
| slackner | wgrant: well, what we would like to have is one central PPA for all package, unfortunately we started with several ones, and we cannot just change it with >10k users | 23:18 |
| slackner | wgrant: transfering PPA keys itself would not be sufficient, as users will need some time to figure out that the old PPA is deprecated | 23:19 |
| slackner | wgrant: does it make sense to fill out feature requests for this (which could be implemented in the next time)? or do we have to use something like the cronjob approach? | 23:20 |
| slackner | wgrant: not sure how everything works internally, but in principle a http redirect and a new ppa with same key should already do the trick (if i don't miss anything) | 23:21 |
| wgrant | slackner: We'd transfer the PPA key manually by hacking the database, but it's unlikely that we'd be able implement PPA redirects within say a year. I'd suggest that using an API cronjob would be your best bet for now. | 23:22 |
| slackner | wgrant: hm, okay.. well, the cronjob method also seems a bit hacky too me, but if there isn't any better solution we'll implement it ^^ thanks! | 23:25 |
| wgrant | slackner: Yeah, it's not ideal, but it should work fine for now. | 23:28 |
| maxb | slackner: there's a script you can use already written, look for lp-promote-ppa in lp:hydrazine | 23:45 |
| slackner | maxb: ah, nice :) | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!