DPMT/PAPT PET no longer updated
Hi, I just remembered we had 2 PET instances for our teams, but looking at them at http://python-modules.alioth.debian.org/cgi-bin/qareport.cgi http://python-apps.alioth.debian.org/cgi-bin/qareport.cgi they are severely outdated (since ~1 year). Does anyone have some information about them (how PET works, where to look to fix it) so we can maybe re-enable this quite interesting service? Alternatively, we can decide we no longer use PET and so we can simply remove them (no information is better then wrong information). Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cab4xwxxup-a7yjsy7+hnq8vhiebsy3wrqz1rpjr7x3qt8tq...@mail.gmail.com
Re: RFS: python3-dateutil
On 4 April 2012 22:14, Jakub Wilk wrote: > Hmm, didn't help here: No bright ideas. What uscan version do you have? $ uscan --version This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1 > I took a closer look at your watch file: I've followed all of your suggestions, and checked that it still works. Previously, I'd just copied the watch file from python-dateutil; evidently it wasn't as good an example as I had hoped. Thanks, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caovn4qiv6bw0syaqcgkfwi4e5zd4ajos3x+wcrblhocksyr...@mail.gmail.com
Re: RFS: python3-dateutil
* Thomas Kluyver , 2012-04-03, 20:57: Your get-orig-source target tries to support being invoked from any directory, but this doesn't work: You're right. I've used `pwd` now instead of . and it appears to work. Hmm, didn't help here: $ ../trunk/debian/rules get-orig-source py3versions: error parsing Python-Version attribute uscan --noconf --force-download --rename --download-current-version --destdir=`pwd` ../trunk/debian//.. make: *** [get-orig-source] Error 1 I took a closer look at your watch file: "uversionmangle=s/\.(tar.*|tgz|zip|gz|bz2)$//i" - why put this stuff to upstream version in the first place? [*] "dversionmangle=s/[-.+~]?(cvs|svn|git|snapshot|pre|hg|dfsg)(.*)$//i" - stripping dfsg is correct, but stripping cvs, svn etc. parts is wrong. dversionmangle is supposed to map Debian version to upstream version. But if you packaged a VCS snapshot, then no upstream version corresponding to Debian version exist. Stripping "pre" (or more generally: ~) is even worse, because it's fooling uscan into thinking that Debian version is newer than it actually is. "pasv" - this makes no sense for HTTP. (Even for FTP, I don't believe there's much point in putting this option to debian/watch.) "-?_?" - this should have probably been "[-_]". "([\d+\.]+|\d+)" is equivalent to much simpler "([\d+.]+)". Though maybe you actually meant "((\d+\.)+|\d+)", which is something different. "(tar.*|tgz|zip|gz|bz2|)" - you should use non-capturing (?:...) here to fix [*]. Also, I don't see any point in keeping "gz", "bz2" or an empty string in the alternative. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404211405.ga...@jwilk.net
Re: py.test is not in debian anymore
Hi Tiziano, On Mon, Apr 02, 2012 at 03:39:31PM +0200, Tiziano Zito wrote: > here a couple of short comments: > > - why do you build for all python versions and then only install > for the default versions? > > - in override_dh_auto_test, it would probably be better not to > introduce your own ENABLE_TESTS flag. you should rely on the > DEB_BUILD_OPTIONS variable. something like this should do: > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) Well, actually it was to disable the tests by default for the first upload, since py.test isn't in the archive. Nonetheless, it is a good idea to add support for DEB_BUILD_OPTIONS, I suppose I can just comment out the whole section as well. > - why did you choose to rename the py.test script for python3 to > py3.test? I think the upstream convention of having > py.test-2.6, py.test-2.7, py.test-3.2, etc., seems > more sensible and also consistent with other packages (see for > example ipython: ipython2.6 ipython2.7 ...) > at the end one could have a py.test link to point to the > py.test-2.x where x is the default (probably 7 for wheezy), and > same thing for the python3 version, where py.test-3 may point to > py.test-3.2 on wheezy. I began to do so in my first attempts, but I didn't want the package to depend on non-default Python versions, which it would have if I provided every script because of the strict shebangs. Incidentally, the build for all version comes from this attempt, I've forgotten to clean it up. In any case, it doesn't cost much to build for every available version and prevents any syntax error. For the py3.test, I cannot remember why I used that name. The reason must not have been a good one if I've forgotten it, though ;-). py.test-3 is fine as well. IMHO there is three alternatives: * Provide the scripts for all Python versions available, py.test[-3] pointing to the default Python version. It would mean that the package would depend on python-all and python3-all because of the shebang. I strongly dislike this one. * Only provide the default Python version scripts. This is what I do now. If the users want to use different Python versions, they can always use "python$VERSION -m pytest" (since 2.0). * Do it the ipython way: use the python scripts for py.test and py.test-3, and use a shell script that detects the Python version to use based on the script name, and fails graciously if it isn't available. I hadn't thought about the third alternative until you mentioned ipython, but it seems a rather good approach. I'll take a shot at it shortly. Cheers, Simon signature.asc Description: Digital signature
