[00:51] <crass> Anyone know the cause of the error: "dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision"?
[00:51] <crass> I see that for this build: https://launchpadlibrarian.net/157850442/buildlog.txt.gz
[00:52] <crass> however, the source/format for that build should be "3.0 (quilt)", not native
[00:52] <crass> is this an issue with trusty? its the first time I've seen it
[01:18] <wgrant> crass: A recent change in trusty's dpkg-source causes it to reject non-native versions for native packages.
[01:18] <wgrant> crass: But bzr-builder is converting the package to 3.0 (native) because it can't find pristine-tar metadata to reconstruct the orig tarball.
[01:19] <wgrant> It's done that conversion for just about ever, but dpkg-source previously didn't complain that the version was invalid.
[01:19] <wgrant> You'll need to either switch to a native version string or inject appropriate pristine-tar metadata into the branch (eg. using bzr import-upstream)
[01:47] <crass> wgrant: thanks! looking into that now
[01:50] <crass> wgrant: so I can't use non-native versions for automatic builds from bzr repos imported from other vcs types?
[01:54] <wgrant> crass: You might be able to do it by telling the recipe to merge a separate branch that just has the pristine-tar tags in it, but I'm not entirely sure.
[01:55] <crass> wgrant: this seems to make daily build package versioning unworkable
[01:56] <crass> there is no pristine tarball for a dailybuild
[01:56] <crass> you could create one, but that seems to defeat the purpose
[01:56] <wgrant> crass: You can't directly use a 1.0.0+bzr1234-0ppa1~ubuntu12.04.1 version any more, no.
[01:57] <wgrant> You could use 1.0.0+bzr1234+0ppa1~ubuntu12.04.1, or 1.0.0-bzr1234+0ppa1~ubuntu12.04.1, though
[01:57] <wgrant> 1.0.0+bzr1234-0ppa1~ubuntu12.04.1 for a native package doesn't make sense and is illegal, but dpkg didn't previously reject it.
[01:57] <crass> why is it illegal? what is the restrictions on the revision?
[01:58] <crass> thanks for point out this work around
[01:59] <wgrant> crass: The final hyphen delineates the boundary between the upstream version and Debian revision.
[01:59] <crass> I'm trying to think of what if any side-effects would be to changing the - to a +
[01:59] <wgrant> A native package by definition has no upstream version.
[01:59] <wgrant> Yeah, there are some side-effects
[02:00] <wgrant> Because the version is not compared as a single element, but as a tuple of (epoch, upstream, debian)
[02:00] <crass> that would seem to say that version comparison between native and non-native doesn't make sense
[02:00] <wgrant> In the case of a native package, upstream is now enforced to be null.
[02:01] <crass> oh, so it will never be seen as upgradable?
[02:01] <wgrant> Ah actually, technically a native package is all upstream version, not all Debian version.
[02:01] <wgrant> For that reason.
[02:01] <crass> ok, that's what I'd expect
[02:01] <wgrant> I misremembered.
[02:01] <wgrant> So the Debian version is everything after the final hyphen.
[02:01] <wgrant> Rather than the upstream version being everything before the final hyphen.
[02:02] <crass> right, but it makes the most sense to put the extra stuff in the version in the debian revision, no?
[02:02] <crass> ok, I think I see why not
[02:03] <wgrant> I'd probably use 1.0.0+bzr1234blahblahblah to create a native tarball each time
[02:03] <wgrant> But in some cases it's possible preferable to use 1.0.0-bzr1234 or similar, to have all the changes since 1.0.0 in a patch
[02:04] <wgrant> But I'd normally prefer the former, I think
[02:04] <crass> yeah, I think that achieves the same results as the former behavior
[02:04] <crass> ok, so that does make sense then
[02:07] <crass> hmm or not, in my scheme the rDDD after the '-' is for the packaging revision, which doesn't modify the source
[02:08] <crass> since the upstream is from an arbitrary revision there is not upstream release / tarball
[02:10] <crass> it would be nice if bzr-builder could create a pristine tarball if one didn't exist, but the version format would have to be assumed
[09:55] <seb128> hey
[09:55] <seb128> could somebody mark https://code.launchpad.net/~gerardo-santana/gnome-control-center/gnome-control-center/+merge/109335 as rejected
[10:01] <seb128> (or get me out of the reviewer list, it's annoying that random people can put stuff in your +activereviews that you can't get out then)
[10:18] <arun_> hello guys , how can we host a ppa repo in launchpad ?
[10:27] <arun__> hello guys , how can we host a ppa repo in launchpad ?
[10:27] <arun__> wgrant: are u there/.
[10:27] <wgrant> arun__: Hello.
[10:28] <arun__> wgrant: hi how are u >?
[10:28] <arun__> wgrant: brother, I am thinking of hosting a repo for updates for our Distro , i would like if Launchpad will be able to help us !!!
[10:31] <wgrant> arun__: Have you tried using a PPA?
[10:37] <arun__> wgrant: brother, I am thinking of hosting a repo for updates for our Distro , i would like if Launchpad will be able to help us !!!
[10:38] <arun__> wgrant: sorry for the disconnection
[10:42] <arun__> wgrant: hello are u ther?
[10:48] <wgrant> arun__: Does a PPA suit your needs?
[10:49] <arun__> wgrant: I think so, We just need to provide updates to our distro and softwares that are binary forms .... , and I think PPA can be done
[10:49] <dch> hey, I’ve started work on upgrading (& maintaining going forward) the official couchdb ppa, at lp/couchdb
[10:50] <dch> what I *want* to do is to clone the current work in trusty, and work from there. But I can’t see where/how to clone an existing lp branch, any suggestion?
[10:50] <dch> I’m new to lp & bzr, so a bit lost despite reading all the docs.
[10:51] <wgrant> dch: bzr branch lp:ubuntu/couchdb
[10:51] <wgrant> arun__: Is there some issue you'r ehaving with using a PPA?
[10:52] <wgrant> dch: Are you intending to use a recipe to create a daily build PPA?
[10:52] <dch> wgrant: aha! so I grab the branch (not a copy option in gui) treat it like a git repo, and when I’m happy, push it back to our ppa then?
[10:53] <arun__> wgrant: so shouldn't I need to host a ppa repo ?
[10:53] <wgrant> dch: PPAs contain packages, not actual branches.
[10:53] <dch> wgrant: in mid term that would be even better, yes. For the moment (next 2 weeks) I just want to provide a known latest formal release build for each of the supported ubuntus
[10:53] <wgrant> You can use a recipe to create a package directly from a branch
[10:53] <arun__> wgrant: We wanted a repo for our Distro
[10:53] <wgrant> Or upload a source package to Launchpad over (S)FTP
[10:53] <arun__> wgrant: then , in binary format how will it be transformed??
[10:54] <dch> wgrant: I think creating from a branch makes more sense, then its all happy src control. One of the other packages is built from a single diff against couchdb-0.1.1 which as you can imagine is pretty unweildy.
[10:54] <dch> wgrant: thanks, I’ll look at recipes this afternoon.
[10:55] <wgrant> dch: Well, you have to create a package, branch or not. A recipe can automate that for you within Launchpad, if it fits your situation.
[10:55] <wgrant> arun__: I'm not quite sure what you mean. What exactly do you want to do? Have you read through https://help.launchpad.net/Packaging/PPA and tried creating a PPA?
[10:56] <arun__> wgrant: no I haven't  I wanted to ask you that, is PPA suitable for us to host the binary packages to provide upates and software packages for our Distro ?
[10:57] <wgrant> arun__: How do you normally host the packages for your distro?
[10:57] <wgrant> Is it just an additional set of packages on top of the main Ubuntu archive?
[10:59] <arun__> wgrant:  yes !! it uses the Ubuntu repo as well, we wanted to updates for our software center, update packages , our software package owned by us ...
[11:00] <wgrant> A PPA would probably work for you, then.
[11:10] <seb128> wgrant, hey, could you mark https://code.launchpad.net/~gerardo-santana/gnome-control-center/gnome-control-center/+merge/109335 as rejected (or remove me from the reviewer list)
[11:12] <arun__> wgrant: yaa, so I need to 1st upload my codes to the bazar yaa
[11:15] <wgrant> seb128: Done
[11:15] <seb128> wgrant, thanks
[11:15] <wgrant> arun__: You can just upload a package directly; you don't need to use bzr
[11:16] <arun__> wgrant: oh using the bzr ??
[11:16] <arun__> wgrant: oh how??
[11:17] <arun__> wgrant: should I upload the codes also or can just upload the binary ?
[11:18] <arun__> wgrant: *need
[11:18] <arun__> wgrant: should I need upload the codes also or can just upload the binary ?
[11:30] <wgrant> arun__: Read through https://help.launchpad.net/Packaging/PPA/Uploading
[11:30] <wgrant> Launchpad only accepts source uploads; you cannot upload binaries.
[11:35] <arun__> wgrant: and how will that be converted to the deb file ??
[11:35] <arun__> wgrant: will you do that dude?
[11:37] <wgrant> arun__: Launchpad builds the source package into a binary.
[11:37] <arun__> wgrant: oh ok sounds cool !!! thanks bro !!!
[12:35] <AlanBell> is there any API access to the mailing list bit of launchpad?
[12:35] <AlanBell> or a search facility?
[12:41] <wgrant> AlanBell: Theres no built-in search facility or API, but general Web search engines do a pretty good job.
[12:47] <AlanBell> ok
[17:37] <shadeslayer_> whoa
[17:37] <shadeslayer_> just 1 builder for amd64?
[17:37] <shadeslayer_> and 41 for i386?
[17:42] <cjwatson> they're pooled now
[17:42] <cjwatson> it's just that the queue length displays don't quite understand that yet
[17:44] <cjwatson> it's actually 41 pooled between i386 and amd64, and one extra for amd64 as a temporary workaround so that amd64 doesn't vanish from the queue length displays entirely
[17:44] <cjwatson> the "40 hours" is a total lie right now :-)
[17:45] <cjwatson> in fact, 41 pooled between i386/amd64/armel/armhf
[17:45] <cjwatson> or partly so anyway
[17:53] <shadeslayer_> ah makes sense
[17:54]  * shadeslayer_ was scared for a bit :P