=== Nigel_ is now known as G [02:08] how do you set the name of the package with stdeb if I want to create separate packages for python2 and python3? [02:09] I want X to be renamed python-X and python3-X [02:12] adoniscik: I'd examine the manual and/or code of stdeb, and then ask in #ubuntu-packaging if you still can't work it out. [02:12] That's not really anything to do with Launchpad. [02:13] okay, I will ask there. [02:17] adoniscik: export PYBUILD_NAME=X \n %: \n \t dh $@ --with python2,python3 --buildsystem=pybuild [02:22] cool, xnox That looks like it's intended for pybuild. How does it relate to stdeb? [07:49] dput refuses to upload a deleted package that it believes "has already been uploaded" [08:11] adoniscik: You need to change the version if you change the package. [08:12] wgrant, I deleted the package instead since it never built properly in hte first place. I don't see the package but dput seems to think it is there. Should I still increment the version? [08:12] adoniscik: That dput check is local and can be overridden with -f, but Launchpad will reject a reuse of the same version even if you've deleted it. [08:12] You must change the version if you change the package. [08:13] where is that set, Standards-Version? [08:15] adoniscik: debian/changelog [08:16] And you should always use dch to manipulate that. [08:16] It sounds like you should read the Ubuntu packaging guide. [08:23] I edited the changelog and ran debuild again, but launchpad rejected the package because it said the file already exists. I added a letter to the version, which the rejection email indicated in the title, but ignored in the body. Weird... [08:29] adoniscik: What exactly did you change it to, and what was the exact text of the error message? [08:30] from "foo (version) dist; urgency=low" to "foo (versiona) dist; urgency=low" [08:31] then I dput the new changes file, which launchpad successfully received. The email noted the new version in the title, but the old file name in the body [08:31] Exact text of the error message :) [08:32] Was it the orig.tar.gz? [08:32] foo_0.1.2.orig.tar.gz [08:32] Also ensure you've read and understood https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version [08:32] Right. [08:32] " The version number of a package. The format is: [epoch:]upstream_version[-debian_revision] " [08:32] The orig.tar.gz is the upstream tarball, and that has the upstream version. [08:33] That is anything before the final -. [08:33] The orig.tar.gz is meant to be as the name suggests: the original tarball as released by upstream, bit-identical. [08:33] How did upstream's release tarball change without changing the version number? [08:35] sorry, I am not sure I follow. I merely tagged an "a" to 0.1.2-1, making it 0.1.2-1a. If I follow you, this does not really constitute a version change, so it rejected it? [08:36] It is a version change, but it's not an upstream version change. [08:37] And it sounds like you changed the upstream tarball, so you need to change the upstream version. [08:37] But how did the upstream tarball change? That normally indicates that something else has gone wrong. [08:37] In your new version, upstream_version=0.1.2, debian_revision=1a. [08:37] and the old? [08:37] because I reran debuild after changing the changelog? [08:38] I thought that was how I would reflect the updated changelog [08:38] The old version was upstream_version=0.1.2, debian_revision=1 [08:38] Running debuild won't have changed your orig.tar.gz. [08:38] Debian tools don't touch it, normally, since it's meant to be identical to the one you downloaded from the upstream author. [08:39] I have 1 orig.tar.gz, and two debian.tar.gz [08:39] two source.builds [08:39] Yes. [08:39] that's good, right? [08:39] But if Launchpad rejected it because the orig.tar.gz conflicted, you must have changed the contents of the orig.tar.gz without changing the orig.tar.gz's version. [08:40] well it did say the file exists and "uploaded version has different contents" [08:41] The upstream md5sum is 0a9c0986d9b6c1d3f88135afa3da2230 [08:41] That doesn't match the one you uploaded to Launchpad before. [08:41] Does it match the one you have on disk now? [08:42] of the tgz? [08:43] the orig.tgz is b7532f1be6f7e034a9f04a6e47759bbb [08:44] the modified debian.tgz is 99d9aa3fc63361a73d517f1a63e61b05 [08:45] adoniscik: That doesn't match either the one you uploaded to Launchpad or the one on PyPI. How did you construct the two orig.tar.gzs? [08:47] i downloaded it from pypi, extracted it, ran "python setup.py --command-packages=stdeb.command sdist_dsc", edited the rules file to use pybuild, etc. [08:48] sorry for the trouble, I am trying to upload my first package :) [08:49] I've not used stdeb. [08:49] But if it generates an orig.tar.gz itself then that's pretty weird. [08:49] In future, use the upstream-provided tar.gz instead. [08:49] I also used debuild [08:50] you mean from pypi? [08:50] Yes. [08:50] In this case you'll still have to change the version, since the real upstream version's filename had a bad tarball behind it. [08:51] So, I would grab the orig.tar.gz from pypi, and name it something like FOO_1.2.3+upstream1.orig.tar.gz [08:51] Then add a new changelog entry for version 1.2.3+upstream1-1 [08:51] (the "+upstream1" is just an arbitrary string to make the version larger than the old one, while also suggesting what happened) [08:52] I didn't know I could directly upload those archives. so I just need to put a copy of the tgz from pypi and rename it to foo.orig.tar.gz (i.e., add the orig) [08:52] When 1.2.4 is released, ensure that you use the orig.tar.gz from PyPI instead of anything generated by stdeb. [08:52] A normal Debian source package is composed of an orig.tar.gz, and debian.tar.gz, and a dsc. [08:52] The orig.tar.gz is traditionally exactly the upstream release tarball. [08:53] THe debian.tar.gz just contains the debian/ directory of your source package. debuild (well, dpkg-buildpackage, called by debuild) generates it by tarring up the debian/ directory. [08:53] The dsc just provides metadata and the hashes of the orig.tar.gz and debian.tar.gz. [08:53] You generate none of those files yourself, and debuild generates all except the orig.tar.gz. [08:54] debuild works out which orig.tar.gz to use based on the latest version in debian/changelog. [08:54] So if your changelog starts with "foo (1.0) trusty; urgency=low", it'll use foo_1.0.orig.tar.gz in the parent directory. [08:55] cheers, I'll try again. most informative. [08:57] (note that some older or native Debian source packages have a different set of files, but none you're likely to run into) [09:28] so the package built, but only for python3, presumably since that's what I ran stdeb with. I suppose I need to run it again with python2. If I wanted to create separate packages, should I just edit the changelog to rename foo to python-foo or python3-foo? [09:29] thanks for your patience, wgrant [09:31] adoniscik: AFAICR stdeb just generates debian/* from metadata in setup.py. You would normally do that once, trim any unnecessary bits, then edit the autogenerated files to meet your needs. [09:31] One of those needs might be support for multiple Python versions. [09:32] There's no reason to have a separate source package; it's normal and common for a single source to generate python-foo and python3-foo. [09:32] See the example debian/rules that xnox gave earlier, but you'll also need to add a new Package stanza to debian/control. [09:42] oh good. where does debian/control get the contents of ${python:Depends}? I created a new stanza renaming the package and ${python3:Depends} [09:46] adoniscik: https://wiki.debian.org/Python/Packaging is probably of interest. [09:48] But ${python:Depends} is a "substvar". Check the dh_python2 manpage for details of the substvars it provides. === lifeless_ is now known as lifeless === mwhudson_ is now known as mwhudson