[03:15] <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:16] <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:19] <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:21] <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:22] <codygarver> StevenK, so the version string is the problem?
[03:24] <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:27] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <dobey> hrmm
[03:37] <dobey> StevenK: then it shouldn't matter, since source/format has 3.0 (quilt)
[03:38] <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:39] <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:40] <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:45] <dobey> what does it even mean to provide pristine-tar in a source recipe?
[03:46] <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:49] <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:50] <StevenK> dobey: Sorry for not explaining it well -- the DESCRIPTION in the pristine-tar manual page should help, then.
[03:53] <dobey> doesn't really help either. it tells me it is not a usable solution, though.
[03:55] <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:56] <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:57] <wgrant> dobey: Non-native necessarily implies release tarball
[03:57] <wgrant> A package is non-native iff it has at least one orig.tar.*
[04:00] <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:01] <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:02] <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:03] <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:04] <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:07] <dobey> oh, ok
[04:08] <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:10] <dobey> and generate a giant diff for all changes made since that tarball release? that is silly
[04:11] <wgrant> Silly?
[04:11] <wgrant> What else can it do?
[04:12] <dobey> export the current revision of the tree to the orig.tar?
[04:13] <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:14] <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:15] <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:16] <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:17] <dobey> well if you are getting orig.tar.gzs from a PPA to use as "official original tarballs" you've already failed
[04:18] <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:19] <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:20] <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:22] <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:23] <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.
=== caktux_ is now known as caktux
[04:24] <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:25] <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:26] <dobey> later :)
[04:31] <wgrant> Night
[07:07] <Noskcaj> wgrant, To test if the package builds. If so, it can be synced to ubuntu
[08:47] <czajkowski> aloha
=== eagles0513875_ is now known as eagles0513875
[20:23] <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:24] <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:26] <dobey> what is the url for the recipe?
[20:29] <philsf> https://code.launchpad.net/~philsf/+recipe/philsf-likes-workstation
[20:31] <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:32] <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:37] <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:38] <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:40] <philsf> dobey, yay, it built now. thanks! I think I'll only use {debversion}, since I don't need a daily build
[20:41] <dobey> well, the binary build will fail
[20:46] <philsf> why?
[20:47] <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:48] <philsf> debuild builds the binary package fine. what should I do to create a metapackage that makes LP happy, then?
[20:59] <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?
[21:00] <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:01] <dobey> if you are going to build on multiple versions of ubuntu, it is very necessary
[21:03] <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:04] <dobey> i'm not sure what you're asking exactly
[21:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <philsf> dobey, thanks for the pointer. I was curious about metapackaging, though ;)
[21:12] <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
[22:34] <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:47] <maxb> Automatic copying could be done with a cronjob calling the lp web api
[23:09] <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:10] <slackner> wgrant: is it technically not possible, or just not implemented?
[23:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:25] <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:28] <wgrant> slackner: Yeah, it's not ideal, but it should work fine for now.
[23:45] <maxb> slackner: there's a script you can use already written, look for lp-promote-ppa in lp:hydrazine
[23:46] <slackner> maxb: ah, nice :)