Tim Ansell pisze: > On Thu, 2007-08-16 at 00:13 +0200, Krzysztof Sobolewski wrote: >> I heard that Debian packagers (re-)appeared so I hope they won't mind that >> I'm overstepping their responsibilities :) > > We are all learning together. > > Try building using "build-deb.sh" script. Ultimately I think the stuff > in that should be merged into the ./debian/rules file? > > It does things like makes sure you are building from a clean tree and > also "fixes" the version.py file (so when you install it the git info > isn't lost).
I think most this stuff is already implemented by Debian's maintainer scripts, like pdebuild (whuch builds in a clean chroot, that's how I found those missing Build-Depends: and such). pdebuild also doesn't modify the working tree (but clean in debian/rules should work anyway). The rest could be folded into debian/rules, yes... >> For Python packages I'm not sure if I should use dh_pysupport or >> dh_pycentral or both and what is really necessary... I'm a Java guy, you >> know ;) > > http://wiki.debian.org/DebianPython/NewPolicy > The main principles of this policy are shared by many people, > however there's no consensus on the best tool to implement it. > That's the reason why you will have to choose between > python-central and python-support. We have done our best to make > it easy to switch from one to the other and their usage is very > similar from the maintainer's point of view. Either tool should > support any package; maintainers should choose the tool with the > interface that they prefer. > > So I don't think we need the addition of dh_pysupport in the patches you > sent. Ah, OK, I was too confused to remember to look for the Python Policy :) >> * libtpproto-py - seems OK too, but there's a problem with >> tp.netlib.discover.LocalBrowser (tpclient-pywx won't see it - does it need >> Avahi, or something?) > > It will try "python-avahi", then "python-bonjour" then use it's internal > (customised pyZeroconf) implementation. So this should be added to dependencies then... But it doesn't seem to work with the internal impl. if none of those packages are installed... > tpclient-pywx-0003-Fix-indents-spaces-in-extra-wxFloatCanvas-Arro.patch > Merged with slightly less dramatic comment (not this file isn't > actually used at the moment). > http://git.thousandparsec.net/gitweb/gitweb.cgi?p=tpclient-pywx.git;a=commit;h=6516e1038b6d09ca30eaa942e2c8473eb3fdb988 I found this because all Python files are being compiled upon installation (some packages do it in postinst, some during build)... And I'm on the tabs side of the spaces-tabs debate, so this dramatic comment ;) > tpclient-pywx-0005-Fix-executable-symlink-not-to-point-to-build-tempora.patch > I'm not quite sure this patch is correct. From what I > understand, symlinks in debs should always be absolute. I'm not sure too, but I looked at my /usr/bin and found at least one relative symlink, so I thought it was OK. The problem is that the symlink has to point to the location as it will be after installation, even during build (when it will be broken). But AFAICS the build can be told where to install and it thinks it's the final location, which is not. The relative symlink solves this for both locations (temporary and final), but I'd be glad to know how it's done by professionals :) >> Of course there are lots of problems, lintian errors and such... Anywa, hope >> that helps :) >> -KS > > How do you get lintian errors and such? I have never used those tools... There are lintian and linda packages in Debian, you can point them at the *.changes file generated by build and they will point out problems. Very useful :) -KS
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
