[00:31] <ad-530> hiho
[02:51] <SiNiESTrO> hello guys
[02:51] <SiNiESTrO> is there any launchpad admin here?
[02:53] <SiNiESTrO> Launchpad rejects my debian package
[02:54] <SiNiESTrO> in my PPA
[02:54] <SiNiESTrO> I deleted the previous version and reuploaded the same version without success
[02:55] <SiNiESTrO> "File fritzing_0.3.19b.tar.gz already exists in Fritzing, but uploaded version has different contents."
[02:57] <wgrant> SiNiESTrO: The identity of the file is remembered forever.
[02:57] <wgrant> You need to change the version.
[02:57] <wgrant> But why are you creating a native package?
[02:58] <SiNiESTrO> wgrant: Can I delete my PPA and create it again with the same name?
[02:58] <wgrant> No.
[02:58] <wgrant> But you can fix this by not creating a native package.
[02:58] <SiNiESTrO> but i understand that it is a native package...
[02:59] <SiNiESTrO> my debian code will be part of the main repository of the project
[02:59] <wgrant> It's almost alaways a mistake.
[02:59] <wgrant> 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] <wgrant> Because the distribution may need to change things without making a new upstream release.
[03:00] <wgrant> Native packaging is for when a package exists solely for the package.
[03:00] <wgrant> Er.
[03:00] <wgrant> Rather when a *project* exists solely for the packaging, in a single distribution.
[03:01] <wgrant> If you think you want a native package, you very probably don't understand the purpose.
[03:01] <SiNiESTrO> 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] <wgrant> You can't just convert it to non-native.
[03:01] <wgrant> You need an upstream tarball for that.
[03:01] <wgrant> So you should make it non-native in the first place.
[03:03] <SiNiESTrO> uhm...
[03:04] <wgrant> The mere fact that you tried to upload the same version twice suggests that it shouldn't be native.
[03:04] <wgrant> Since you changed the packaging without changing the upstream version number.
[03:05] <SiNiESTrO> 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] <wgrant> For my main project, I have a separate branch of trunk with debian/ in it.
[03:06] <wgrant> 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] <wgrant> It means I can keep a nice distinction between the upstream stuff and the distribution stuff.
[03:10] <wgrant> And have sane version numbers.
[03:11] <SiNiESTrO> 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] <SiNiESTrO> I think that everything can be together
[03:12] <wgrant> Upstream packaging is often broken, because upstream is an upstream developer, and not normally a distribution developer.
[03:12] <wgrant> 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] <wgrant> But even if you do choose to keep the packaging in trunk, that's still no rationale for creating a native package.
[03:13] <wgrant> Having packaging in trunk is a reasonable decision that you can make.
[03:13] <wgrant> Creating a native package is simple incorrect.
[03:13] <wgrant> Ahem. simply.
[03:15] <SiNiESTrO> ok, i understand...
[03:19] <SiNiESTrO> do I need necessarily a tarball?
[03:19] <wgrant> Do you have another distribution method?
[03:20] <SiNiESTrO> lintian complains that i'm trying to create a native package even i set non-native versions of package
[03:20] <wgrant> You need to create a tarball of an upstream release.
[03:20] <wgrant> And name if $PACKAGE_$VERSION.orig.tar.gz
[03:20] <SiNiESTrO> ok
[03:21] <SiNiESTrO> Is there a wat to automate that?
[03:21] <SiNiESTrO> I mean...
[03:21] <SiNiESTrO> automate the creation of new tarballs if there is a new upstream release
[03:22] <wgrant> Upstream should be publishing tarballs for their releases.
[03:22] <wgrant> Are they not?
[03:24] <SiNiESTrO> yes, but the tarballs has not a $PACKAGE_$VERSION.orig.tar.gz name
[03:25] <wgrant> Right, they'd normally be $PACKAGE-$VERSION.tar.gz.
[03:25] <SiNiESTrO> and I mean to automate wget's and rename's within dpkg-buildpackage
[03:25] <wgrant> But a simple rename or symlink fixes that.
[03:25] <wgrant> You could use 'uscan' to help with that.
[03:26] <wgrant> But the workflow combining that with bzr branches is probably not optimal.
[03:26] <wgrant> I normally rename it manually.
[03:27] <SiNiESTrO> ok, I seen uuscan but I was not sure of its usefulnes.
[03:28] <wgrant> 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] <wgrant> All from just running 'uscan'.
[03:31] <SiNiESTrO> great
[03:31] <SiNiESTrO> thanks for your help wgrant
[03:32] <wgrant> np
[03:33] <SiNiESTrO> erh... a last question, how should I name my branch in Launchpad?
[03:33] <SiNiESTrO> there is any conventions to create branchs for debian packages?
[03:34] <SiNiESTrO> *branches
[03:37] <SiNiESTrO> I think that ~ehbello/fritzing/debpackage is correct...
[11:20] <bartbes> 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?
[12:45] <jml> bartbes, can you provide more information about the error?
[14:05] <bartbes> jml: http://launchpadlibrarian.net/50983132/love-devs-love-main.log
[14:06] <jml> 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] <bartbes> that's the second time hg imports fail..
[14:06] <bartbes> I hate bzr-hg..
[17:01]  * abogani2 waves
[17:01] <abogani2> My PPA upload is stuck on the last bit...
[17:02] <abogani2> Anyone know what is the problem? Perhaphs because it is a big package (~85MB).
[17:02] <abogani2> Or there are other reasons?
[18:47] <lfaraone> 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] <lfaraone> oops, it's in main.
[19:07] <Muscovy> What's the difference between a team and a project?
[19:07] <Muscovy> They seem to do the same thing.
[19:07] <tsimpson> what do you mean?
[19:08] <tsimpson> teams are groups of people, projects are things
[20:02] <SeySayux> 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] <geser> SeySayux: did you got a mail from LP that you upload got accepted or rejected?
[20:05] <SeySayux> geser: nope, no mail
[20:06] <geser> SeySayux: did you use the same for signing of the package that you added your LP profile?
[20:06] <geser> s/same/same gpg key/
[20:06] <SeySayux> geser: I didn't sign my package at all. Could that be a problem?
[20:06] <lifeless> yes
[20:07] <lifeless> it has to be signed
[20:07] <lifeless> and LP only sends mail to the key that signed the package [to avoid spamming folk]
[20:08] <SeySayux> 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] <geser> yes, brute force is the only option; yes, you can use an other key
[20:17] <SeySayux> Okay, I got my new key to launchpad... Now i need to decrypt that stupid message
[20:22] <SeySayux> Okay, so far, so good...
[20:32] <SeySayux> 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] <SeySayux> Okay, it seems to work now, will check if it works, thanks guys
[21:03] <SeySayux> Hmm, my project failed to build on launchpad, while it works for me... What could be the problem?
[21:03] <SeySayux> Relevant part of the log: http://pastebin.com/vBbLeXnP
[21:08] <SeySayux> oh, 64 bits right... Hmm, I'll check this later... Strange...