Re: Bug#701194: RFS: dparser-1.29-1 [ITP] -- a scannerless GLR parser generator
Hi, upstream released 1.30 and incorporated 4 of 7 patches I used to apply for the release before that. I've adjusted my package and uploaded to mentors, please see: http://mentors.debian.net/package/dparser On 02/24/2013 09:37 PM, Jakub Wilk wrote: > * Markus Wanner , 2013-02-24, 21:07: >>> W: dparser source: out-of-date-standards-version 3.9.3 (current is >>> 3.9.4) I corrected that as well. >>> e: python-dparser: string-exception usr/share/pyshared/dparser.py:215 >>> e: python-dparser: string-exception usr/share/pyshared/dparser.py:233 >>> e: python-dparser: string-exception usr/share/pyshared/dparser.py:236 >>> e: python-dparser: string-exception usr/share/pyshared/dparser.py:260 >> While these are correctly detected - and I agree it's bad practice - >> do these warrant a patch? > > It's not only about bad practice. String exception no longer work in > Python >= 2.6: Thanks for clarifying this, I wasn't aware. I'll discuss that with upstream, next. Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Re: Bug#701194: RFS: dparser-1.29-1 [ITP] -- a scannerless GLR parser generator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jakub, thanks for your feedback. On 02/22/2013 09:09 PM, Jakub Wilk wrote: > Lintian emits: > > W: dparser source: out-of-date-standards-version 3.9.3 (current is > 3.9.4) Hm.. I'm wondering why I don't get this from lintian. My initial thought was that I'd have to use a newer lintian version from sid, rather than wheezy. But I can't get lintian to produce this warning even on sid. Anyway, I corrected the package. (No changes were necessary to comply.) > lintian4python emits: > > e: python-dparser: string-exception > usr/share/pyshared/dparser.py:215 e: python-dparser: > string-exception usr/share/pyshared/dparser.py:233 e: > python-dparser: string-exception usr/share/pyshared/dparser.py:236 > e: python-dparser: string-exception > usr/share/pyshared/dparser.py:260 While these are correctly detected - and I agree it's bad practice - do these warrant a patch? Especially considering that it leads to a difference in error handling compared to upstream. > e: python-dparser: pyflakes-undefined-name > usr/share/pyshared/dparser.py:98: i Interesting, this looks like a typo. I'll contact upstream. For now, I've added a patch. > Is "export DH_OPTIONS" in debian/rules needed for anything? I > don't think it is. Must be some copy'n'paste stupidity that I didn't dare to clean up. Thanks for catching this. Removed. I've uploaded a new version of the package to mentors. Regards Markus Wanner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQQcBAEBCgAGBQJRKnLxAAoJEOhoLRs/MemzjncgAL9HTxbMKhaPYg8z1/Pngj8n T0MbCofw2ON+8jUzhyCPYY5arUdQUFEnDU8vXNkSJo4x0UnB90I9wXeXOso+Ix1o 8c52uIOYvuK5BMKmbXkxprmZT7aGPeE7LEIL9y2pla9oMQejEsQ4o43N5Ui4aeNU K1EJnI0t8qBQO9kTYs0jxBLGyS8d7BM7GykeEWyQ9+b/ASRl3/Ejk701rvl/l7Km 02JItN9OeoW/AG63OfABsq1xj2vpgZsEVeTwRq87U7pjFkgjHI4GGBuOFVuPiI7E zXmDa+165wCEkJMQRi5BVqan8FErh0k8xYa/6831NC8mkne6BhWeRjsqqtxVjpO3 59SLntfQM8teHy/EEE6iFltRyrP7wnIWNory7J3gDL8icMa3/9aJ+Irb+5wmgarq 7Jd2zlH4d+WqbQNEW/5xwLDdRVGxNCes2yvj2JAA9qOnwKeyBN/G/g/tAL1JBClz d6s4qJjU9qNi2XAD58Hv44utj6BPR45bIBiB1ZUA6fKdgAdbgCl1bw82wLLR6ATx 8U1oh2XXVcuK+t4e7fvDrjq7VcgBY54tlHkEoRz71v7eY1Ef7exgHWFFux7xmLiI khXnZk+E5HfIWdccZAgbuzTNexuolk2mWGvK6R4NDHpOW0kV57UuPNwK5md3PvTj xMwcMaDoquCvb5u4DryfP6vLYP3mR0GORt+YSf6pmQrsZ8FREN3zITCYjOl2qvLQ ttCAWpQ5yJfVGEtQE/fN0kOd34BV6wHgNZXDJ0X6bTSo9/kT29gYL442AEgMrGBb qfYlW2LDyUT1qH96ltaM9SE884x0Nxdj2qY0EaQQytA88Pc+GPkZy1kPLEGHrSWJ AFWwZLnI95X25uRuLWSYRDFq6Y2ZCz1CR4aCs+PhjzNRc2SmzhQzBfayh5l5NH6n +GqRmsHeDdW29J7GmSpaDYXM7oD6LfR4NqlPHT1AoG14V4CuDB5dbbN1YIsPcn1z H7dPeM6zFIznatVC689XEM4Ixf4u16Muu8i4EYNITduAGryVM34ublnZbcl3BsYG w2T1GD6VGvvZHdU5waj4FWyL4MwTvshaR6OufvbjZDFuRDXmRx+gqhtu+cXgSTK4 71OuNYvpdDB7Sd6qXXYvNxf8E8pycnsiEAem0CVviUBtc3KMmWE0lfldwcpFEVYn 7aFTZGI5AzHQ46ZnroLmu0tDHdXe0h/TDCFwN5vV7ALVmpQ4BOSrrLP6Bm6ohZmQ jDzyO6LSGcV587YPC0ocKBZ3GhUqJSUi2HTWjI32sTjhuE5CmdL7eJiKBXSW9vmc W6aD0u2HigzqCD+FgVlZpP47ie5GfHV0pqsaiMxQcvCFLlq06rg0dzKggRBnSlw= =xTPP -END PGP SIGNATURE- -- 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/512a72f2.2010...@bluegap.ch
Bug#701194: RFS: dparser-1.29-1 [ITP] -- a scannerless GLR parser generator
X-Debbugs-Cc: debian-python@lists.debian.org Package: sponsorship-requests Severity: wishlist Dear mentors, dear python gurus, I am still looking for a sponsor for my package "dparser", now upgraded from 1.26 to 1.29. * Package name: dparser Version : 1.29-1 Upstream Author : John Bradley Plevyak * URL : http://dparser.sourceforge.net/ * License : mostly BSD-3-clause, one file GPL Section : devel Programming Lang: C and Python It builds those binary packages: dparser - scannerless GLR parser generator dparser-doc - documentation for dparser python-dparser - Python bindings for dparser To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dparser Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.29-1.dsc Jakub Wilk reviewed (the earlier 1.26 version of) the package. I think all issues have been addressed, see ITP bug #668556. I realize we are in deep freeze, I just want to renew my offer to maintain the dparser package. Regards Markus Wanner -- 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/512797e4.4090...@bluegap.ch
Bug#668966: Re: RFS: dparser-1.16-1 [ITP] -- a scannerless GLR parser generator
X-Debbugs-Cc: jw...@debian.org
X-Debbugs-Cc: debian-python@lists.debian.org
Hello Jakub,
On 04/16/2012 11:35 PM, Jakub Wilk wrote:
> I don't intend to sponsor this package, but here's my review:
Thanks again for the review. I've adjusted 1.26-1 and uploaded a
corrected variant to mentors.debian.org. All changes are documented
inline below.
> base-makefile-fixes.patch removes this line: LIBS += -lm But this is
> explained neither in the patch description nor in the changelog.
Hm.. I removed it to avoid a warning about a useless dependency.
Arguably, I'm not sure this works on all platforms, but a quick check at
least revealed that math.h isn't included anywhere (from the source
tarball).
> The fix-python-makefile patch will break if Python version is longer
> than 3 characters. (I know, unlikely, but it still bothers me. ;P)
> You could query distutils directly for the build directory using the
> following code:
>
> python -c 'from distutils.command.build import build; from
> distutils.core import Distribution; b = build(Distribution());
> b.finalize_options(); print b.build_platlib'
Thanks, that looks much less prone to error, yes. Replaced.
> More importantly, the fix-python-makefile patch violates Policy
> §4.6.
Agreed. I think I fixed that now: all unit tests are concatenated with
'&&' and a proper result line gives a status hint.
Additionally, the Makefile now checks if the above python code returned
an existing directory and emits a more helpful error before even trying
to run the unit tests (instead of just failing on them).
> Oh, and please don't add commented-out code, thanks.
That slipped my attention, sorry. Cleaned up.
> Have you forwarded the manpage-hyphen-correction patch upstream?
Yeah, I forwarded all of the patches and a notification. Unfortunately,
I didn't hear back from the upstream author, yet. I'll ping him, again.
> Why priority extra? I'd use optional.
Agreed. "Extra" sounded optional enough to me, so I didn't bother
checking. Did some RTFM and degraded to "optional".
> I'd rather not use ${python:Provides}. See:
> http://lists.debian.org/20110324164804.ga5...@jwilk.net
Okay, sounds reasonable, removed. (I have to admit I didn't gain a
thorough understanding of this issue, yet).
> In debian/copyright, you need to either add newlines (escaped by
> dots) between list items or indent the whole list by an extra space.
> (License uses the same rules as Description in debian/control; see
> Policy §5.6.13 for details.)
Oh, I see, this gets word-wrapped differently, if I don't add newlines
between the points. Fixed.
> Please honour DEB_BUILD_OPTIONS=nocheck.
>
> Please honour DEB_BUILD_OPTIONS=noopt.
I naively expected debhelper 3 to take care of these things. Both should
be respected, now. The later by using dpkg-buildflags, which also helps
with hardening options.
(I tried, but couldn't figure out how to enable parallel builds, yet.
But that looks less important that the above two).
> This part of upstream makefile:
>
> ifeq ($(ARCH),x86_64) CFLAGS += -fPIC endif
>
> smells like a violation of Policy §10.2.
Yeah, dropped that in favor of always adding -fPIC. I didn't have a
chance to test on anything other than x86_64, though.
> The package fails to build in a minimal environment:
>
> python2.6 setup.py build make[2]: python2.6: Command not found
> make[2]: *** [all] Error 127
I started using pbuilder, which allowed me to reproduce that, yes.
First of all, I had the value "python-all-dev" under "Section" instead
of "Build-Depends" (?!?). I corrected that and put python-dparser in
section "python" and made it build-depend on python-all-dev. Running
this under pbuilder now looks fine to me.
> I see lots of make[3]: svnversion: Command not found in the build
> log. Is that intentional?
Well, the upstream makefile is trying to determine the SCM version the
build is originating from. I now replaced that with simply reading the
revision from file BUILD_VERSION, which is the provided fall-back. To
me, that seems saner for a Debian package.
> What is debian/dparser-doc.install for?
No idea where I got that from; dropped.
> Version declared in setup.py is 1.9. Shouldn't that be 1.26?
Good catch. Corrected (in yet another patch).
Jakub explicitly stated he doesn't intend to sponsor this package, so
I'm still looking for one.
Regards
Markus Wanner
--
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/4fe8cd79.8060...@bluegap.ch
RFS: dparser-1.16-1 [ITP] -- a scannerless GLR parser generator
Package: sponsorship-requests Severity: wishlist Dear mentors, dear python gurus, I am looking for a sponsor for my package "dparser" * Package name: dparser Version : 1.26-1 Upstream Author : John Bradley Plevyak * URL : http://dparser.sourceforge.net/ * License : mostly BSD-3-clause, one file GPL Section : devel Programming Lang: C and Python It builds those binary packages: dparser - scannerless GLR parser generator dparser-doc - documentation for dparser python-dparser - Python bindings for dparser To access further information about this package, please visit the following URL. It took me some attempts to get lintian clean, so please only look at the top-most, most recent version http://mentors.debian.net/package/dparser Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.26-1.dsc There has been some discussion about the long description of the package already, see the ITP bug #668556. I'd especially appreciate review and comments about the python module that comes with it. Regards Markus Wanner -- 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/4f8bb210.2070...@bluegap.ch
