[00:31] hiho [02:51] hello guys [02:51] is there any launchpad admin here? [02:53] Launchpad rejects my debian package [02:54] in my PPA [02:54] I deleted the previous version and reuploaded the same version without success [02:55] "File fritzing_0.3.19b.tar.gz already exists in Fritzing, but uploaded version has different contents." [02:57] SiNiESTrO: The identity of the file is remembered forever. [02:57] You need to change the version. [02:57] But why are you creating a native package? [02:58] wgrant: Can I delete my PPA and create it again with the same name? [02:58] No. [02:58] But you can fix this by not creating a native package. [02:58] but i understand that it is a native package... [02:59] my debian code will be part of the main repository of the project [02:59] It's almost alaways a mistake. [02:59] Even if the debian/ directory is in the main repository (which is generally regarded as a bad idea), it still shouldn't be a native package. [03:00] Because the distribution may need to change things without making a new upstream release. [03:00] Native packaging is for when a package exists solely for the package. [03:00] Er. [03:00] Rather when a *project* exists solely for the packaging, in a single distribution. [03:01] If you think you want a native package, you very probably don't understand the purpose. [03:01] if the distribution needs change things without making a new upstream release, the package will converts in a non-native package, I think.. [03:01] You can't just convert it to non-native. [03:01] You need an upstream tarball for that. [03:01] So you should make it non-native in the first place. [03:03] uhm... [03:04] The mere fact that you tried to upload the same version twice suggests that it shouldn't be native. [03:04] Since you changed the packaging without changing the upstream version number. [03:05] so... where can i place my debian code if it can't to be together with the project of upstream code in Launchpad? [03:05] For my main project, I have a separate branch of trunk with debian/ in it. [03:06] When I want to push out a release of the package, I produce an orig.tar.gz from trunk, merge trunk into the debian-packaging branch, add a new changelog entry, then build the source package. [03:09] It means I can keep a nice distinction between the upstream stuff and the distribution stuff. [03:10] And have sane version numbers. [03:11] I don't know why we can't place the debian code with the upstream code if we can create our own branches to make a new upstream release. [03:12] I think that everything can be together [03:12] Upstream packaging is often broken, because upstream is an upstream developer, and not normally a distribution developer. [03:12] So it's handy for distributions to be able to insert their own packaging, without having to reverse the brokenness of the upstream packaging. [03:13] But even if you do choose to keep the packaging in trunk, that's still no rationale for creating a native package. [03:13] Having packaging in trunk is a reasonable decision that you can make. [03:13] Creating a native package is simple incorrect. [03:13] Ahem. simply. [03:15] ok, i understand... [03:19] do I need necessarily a tarball? [03:19] Do you have another distribution method? [03:20] lintian complains that i'm trying to create a native package even i set non-native versions of package [03:20] You need to create a tarball of an upstream release. [03:20] And name if $PACKAGE_$VERSION.orig.tar.gz [03:20] ok [03:21] Is there a wat to automate that? [03:21] I mean... [03:21] automate the creation of new tarballs if there is a new upstream release [03:22] Upstream should be publishing tarballs for their releases. [03:22] Are they not? [03:24] yes, but the tarballs has not a $PACKAGE_$VERSION.orig.tar.gz name [03:25] Right, they'd normally be $PACKAGE-$VERSION.tar.gz. [03:25] and I mean to automate wget's and rename's within dpkg-buildpackage [03:25] But a simple rename or symlink fixes that. [03:25] You could use 'uscan' to help with that. [03:26] But the workflow combining that with bzr branches is probably not optimal. [03:26] I normally rename it manually. [03:27] ok, I seen uuscan but I was not sure of its usefulnes. [03:28] In the watch file you normally specify an upstream URL and a URL pattern to look for. It will identify the latest tarball and its version, grab the tarball, and rename it appropriately. [03:28] All from just running 'uscan'. [03:31] great [03:31] thanks for your help wgrant [03:32] np [03:33] erh... a last question, how should I name my branch in Launchpad? [03:33] there is any conventions to create branchs for debian packages? [03:34] *branches [03:37] I think that ~ehbello/fritzing/debpackage is correct... [11:20] as some of you may remember I used to have a problem with lp not importing my hg repo, since we switched to bitbucket this problem disappeared, however, I now get a KeyError, is there a way for me to tell what is wrong? === fta_ is now known as fta [12:45] bartbes, can you provide more information about the error? [14:05] jml: http://launchpadlibrarian.net/50983132/love-devs-love-main.log [14:06] bartbes, that looks like a bug in bzr-hg. I would recommend filing a bug at https://bugs.edge.launchpad.net/bzr-hg [14:06] that's the second time hg imports fail.. [14:06] I hate bzr-hg.. [17:01] * abogani2 waves [17:01] My PPA upload is stuck on the last bit... [17:02] Anyone know what is the problem? Perhaphs because it is a big package (~85MB). [17:02] Or there are other reasons? [18:47] I'm a member of ~motu, and I'm trying to upload to https://edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/memtest86+/maverick , but i don't seem to have the permissions. Shouldn't this branch be uploadable by MOTUs? [18:48] oops, it's in main. [19:07] What's the difference between a team and a project? [19:07] They seem to do the same thing. [19:07] what do you mean? [19:08] teams are groups of people, projects are things [20:02] Hi, I tried to upload a few packages to my PPA. dput showed no errors. So why doesn't launchpad show that there are packages in my repo? https://launchpad.net/~seysayux/+archive/libsylph (PS I think it's strange that it didn't ask me for a password while uploading) [20:04] SeySayux: did you got a mail from LP that you upload got accepted or rejected? [20:05] geser: nope, no mail [20:06] SeySayux: did you use the same for signing of the package that you added your LP profile? [20:06] s/same/same gpg key/ [20:06] geser: I didn't sign my package at all. Could that be a problem? [20:06] yes [20:07] it has to be signed [20:07] and LP only sends mail to the key that signed the package [to avoid spamming folk] [20:08] okay, I seem to have a key on LaunchPad... However, i don't think I've got the private key anymore, and you probably can't recover it without brute forcing... Can I just use another key, and do I have to sign the CoC again? [20:12] yes, brute force is the only option; yes, you can use an other key [20:17] Okay, I got my new key to launchpad... Now i need to decrypt that stupid message [20:22] Okay, so far, so good... [20:32] Okay, it rebuilt the package, it asked me for my gpg keyphrase, I entered it, it said it was sigh^Hning my package, and created a dsc file. But dput now starts complaining my package is unsigned! wtf? [20:37] Okay, it seems to work now, will check if it works, thanks guys [21:03] Hmm, my project failed to build on launchpad, while it works for me... What could be the problem? [21:03] Relevant part of the log: http://pastebin.com/vBbLeXnP [21:08] oh, 64 bits right... Hmm, I'll check this later... Strange... === Philip6 is now known as Philip5