| === jgeboski is now known as Miranda | ||
| === Miranda is now known as jgeboski | ||
| 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:51 |
| 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 | 00:52 |
| 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:18 |
| 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:19 |
| crass | wgrant: thanks! looking into that now | 01:47 |
| crass | wgrant: so I can't use non-native versions for automatic builds from bzr repos imported from other vcs types? | 01:50 |
| 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:54 |
| crass | wgrant: this seems to make daily build package versioning unworkable | 01:55 |
| 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:56 |
| 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:57 |
| crass | thanks for point out this work around | 01:58 |
| 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 | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| crass | hmm or not, in my scheme the rDDD after the '-' is for the packaging revision, which doesn't modify the source | 02:07 |
| crass | since the upstream is from an arbitrary revision there is not upstream release / tarball | 02:08 |
| 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 | 02:10 |
| seb128 | hey | 09:55 |
| seb128 | could somebody mark https://code.launchpad.net/~gerardo-santana/gnome-control-center/gnome-control-center/+merge/109335 as rejected | 09:55 |
| 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:01 |
| arun_ | hello guys , how can we host a ppa repo in launchpad ? | 10:18 |
| 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:27 |
| 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:28 |
| wgrant | arun__: Have you tried using a PPA? | 10:31 |
| 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:37 |
| arun__ | wgrant: sorry for the disconnection | 10:38 |
| arun__ | wgrant: hello are u ther? | 10:42 |
| wgrant | arun__: Does a PPA suit your needs? | 10:48 |
| 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:49 |
| 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:50 |
| wgrant | dch: bzr branch lp:ubuntu/couchdb | 10:51 |
| wgrant | arun__: Is there some issue you'r ehaving with using a PPA? | 10:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 ... | 10:59 |
| wgrant | A PPA would probably work for you, then. | 11:00 |
| 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:10 |
| arun__ | wgrant: yaa, so I need to 1st upload my codes to the bazar yaa | 11:12 |
| 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:15 |
| arun__ | wgrant: oh using the bzr ?? | 11:16 |
| arun__ | wgrant: oh how?? | 11:16 |
| arun__ | wgrant: should I upload the codes also or can just upload the binary ? | 11:17 |
| arun__ | wgrant: *need | 11:18 |
| arun__ | wgrant: should I need upload the codes also or can just upload the binary ? | 11:18 |
| wgrant | arun__: Read through https://help.launchpad.net/Packaging/PPA/Uploading | 11:30 |
| wgrant | Launchpad only accepts source uploads; you cannot upload binaries. | 11:30 |
| arun__ | wgrant: and how will that be converted to the deb file ?? | 11:35 |
| arun__ | wgrant: will you do that dude? | 11:35 |
| wgrant | arun__: Launchpad builds the source package into a binary. | 11:37 |
| arun__ | wgrant: oh ok sounds cool !!! thanks bro !!! | 11:37 |
| AlanBell | is there any API access to the mailing list bit of launchpad? | 12:35 |
| AlanBell | or a search facility? | 12:35 |
| wgrant | AlanBell: Theres no built-in search facility or API, but general Web search engines do a pretty good job. | 12:41 |
| AlanBell | ok | 12:47 |
| === 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 | ||
| shadeslayer_ | whoa | 17:37 |
| shadeslayer_ | just 1 builder for amd64? | 17:37 |
| shadeslayer_ | and 41 for i386? | 17:37 |
| cjwatson | they're pooled now | 17:42 |
| cjwatson | it's just that the queue length displays don't quite understand that yet | 17:42 |
| 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:44 |
| cjwatson | in fact, 41 pooled between i386/amd64/armel/armhf | 17:45 |
| cjwatson | or partly so anyway | 17:45 |
| shadeslayer_ | ah makes sense | 17:53 |
| * shadeslayer_ was scared for a bit :P | 17:54 | |
| === jalcine- is now known as jalcine | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!