=== jgeboski is now known as Miranda === Miranda is now known as jgeboski [00:51] 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] I see that for this build: https://launchpadlibrarian.net/157850442/buildlog.txt.gz [00:52] however, the source/format for that build should be "3.0 (quilt)", not native [00:52] is this an issue with trusty? its the first time I've seen it [01:18] crass: A recent change in trusty's dpkg-source causes it to reject non-native versions for native packages. [01:18] 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] It's done that conversion for just about ever, but dpkg-source previously didn't complain that the version was invalid. [01:19] 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] wgrant: thanks! looking into that now [01:50] wgrant: so I can't use non-native versions for automatic builds from bzr repos imported from other vcs types? [01:54] 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] wgrant: this seems to make daily build package versioning unworkable [01:56] there is no pristine tarball for a dailybuild [01:56] you could create one, but that seems to defeat the purpose [01:56] crass: You can't directly use a 1.0.0+bzr1234-0ppa1~ubuntu12.04.1 version any more, no. [01:57] You could use 1.0.0+bzr1234+0ppa1~ubuntu12.04.1, or 1.0.0-bzr1234+0ppa1~ubuntu12.04.1, though [01:57] 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] why is it illegal? what is the restrictions on the revision? [01:58] thanks for point out this work around [01:59] crass: The final hyphen delineates the boundary between the upstream version and Debian revision. [01:59] I'm trying to think of what if any side-effects would be to changing the - to a + [01:59] A native package by definition has no upstream version. [01:59] Yeah, there are some side-effects [02:00] Because the version is not compared as a single element, but as a tuple of (epoch, upstream, debian) [02:00] that would seem to say that version comparison between native and non-native doesn't make sense [02:00] In the case of a native package, upstream is now enforced to be null. [02:01] oh, so it will never be seen as upgradable? [02:01] Ah actually, technically a native package is all upstream version, not all Debian version. [02:01] For that reason. [02:01] ok, that's what I'd expect [02:01] I misremembered. [02:01] So the Debian version is everything after the final hyphen. [02:01] Rather than the upstream version being everything before the final hyphen. [02:02] right, but it makes the most sense to put the extra stuff in the version in the debian revision, no? [02:02] ok, I think I see why not [02:03] I'd probably use 1.0.0+bzr1234blahblahblah to create a native tarball each time [02:03] 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] But I'd normally prefer the former, I think [02:04] yeah, I think that achieves the same results as the former behavior [02:04] ok, so that does make sense then [02:07] hmm or not, in my scheme the rDDD after the '-' is for the packaging revision, which doesn't modify the source [02:08] since the upstream is from an arbitrary revision there is not upstream release / tarball [02:10] 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] hey [09:55] could somebody mark https://code.launchpad.net/~gerardo-santana/gnome-control-center/gnome-control-center/+merge/109335 as rejected [10:01] (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] hello guys , how can we host a ppa repo in launchpad ? [10:27] hello guys , how can we host a ppa repo in launchpad ? [10:27] wgrant: are u there/. [10:27] arun__: Hello. [10:28] wgrant: hi how are u >? [10:28] 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] arun__: Have you tried using a PPA? [10:37] 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] wgrant: sorry for the disconnection [10:42] wgrant: hello are u ther? [10:48] arun__: Does a PPA suit your needs? [10:49] 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] hey, I’ve started work on upgrading (& maintaining going forward) the official couchdb ppa, at lp/couchdb [10:50] 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] I’m new to lp & bzr, so a bit lost despite reading all the docs. [10:51] dch: bzr branch lp:ubuntu/couchdb [10:51] arun__: Is there some issue you'r ehaving with using a PPA? [10:52] dch: Are you intending to use a recipe to create a daily build PPA? [10:52] 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] wgrant: so shouldn't I need to host a ppa repo ? [10:53] dch: PPAs contain packages, not actual branches. [10:53] 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] You can use a recipe to create a package directly from a branch [10:53] wgrant: We wanted a repo for our Distro [10:53] Or upload a source package to Launchpad over (S)FTP [10:53] wgrant: then , in binary format how will it be transformed?? [10:54] 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] wgrant: thanks, I’ll look at recipes this afternoon. [10:55] 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] 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] 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] arun__: How do you normally host the packages for your distro? [10:57] Is it just an additional set of packages on top of the main Ubuntu archive? [10:59] 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] A PPA would probably work for you, then. [11:10] 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] wgrant: yaa, so I need to 1st upload my codes to the bazar yaa [11:15] seb128: Done [11:15] wgrant, thanks [11:15] arun__: You can just upload a package directly; you don't need to use bzr [11:16] wgrant: oh using the bzr ?? [11:16] wgrant: oh how?? [11:17] wgrant: should I upload the codes also or can just upload the binary ? [11:18] wgrant: *need [11:18] wgrant: should I need upload the codes also or can just upload the binary ? [11:30] arun__: Read through https://help.launchpad.net/Packaging/PPA/Uploading [11:30] Launchpad only accepts source uploads; you cannot upload binaries. [11:35] wgrant: and how will that be converted to the deb file ?? [11:35] wgrant: will you do that dude? [11:37] arun__: Launchpad builds the source package into a binary. [11:37] wgrant: oh ok sounds cool !!! thanks bro !!! [12:35] is there any API access to the mailing list bit of launchpad? [12:35] or a search facility? [12:41] AlanBell: Theres no built-in search facility or API, but general Web search engines do a pretty good job. [12:47] ok === geser_ is now known as geser === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:37] whoa [17:37] just 1 builder for amd64? [17:37] and 41 for i386? [17:42] they're pooled now [17:42] it's just that the queue length displays don't quite understand that yet [17:44] 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] the "40 hours" is a total lie right now :-) [17:45] in fact, 41 pooled between i386/amd64/armel/armhf [17:45] or partly so anyway [17:53] ah makes sense [17:54] * shadeslayer_ was scared for a bit :P === jalcine- is now known as jalcine