Re: Multiple copies of timeoutsocket.py in Debian packages
Hi. Thanks for your responses. Jakub Wilk writes: > * Olivier Berger , 2014-01-28, 16:39: >>A quick search on http://codesearch.debian.net reports many hits for >>the timeoutsocket.py library. >> >>I think it would be better to have a distinct package, then (hence a >>RFP: #736935). >> >>However I don't have a clue whether this is really used by these >>packages, if multiple versions co-exist, etc. I haven't played with >>sockets in Python yet. >> >>I'm tempted to think that it may even no longer be needed at all, >>judging from http://bugs.python.org/issue555085 if the feature was >>added to Python's standard library. > > Yeah, timeoutsocket.py looks like something that should have died a > decade ago. In Python ≥ 2.3 you can set default timeout or a per-socket > timeout without help of this library. > > planet-venus, python-feedvalidator and rawdog already use the proper > Python interfaces, and only fall back to timeoutsocket when they are not > available: > http://sources.debian.net/src/python-feedvalidator/0~svn1022-2/feedvalidator/__init__.py#L8 > http://sources.debian.net/src/planet-venus/0~git9de2109-1/planet/spider.py#L378 > http://sources.debian.net/src/rawdog/2.13.dfsg.1-1/rawdoglib/feedparser.py#L103 > I'm wondering, in similar cases, if there is anything that should be done for these packages, like patching the code to remove the embedded copy and get rid of the import check, since our Python versions in Debian are recent enough ? This would eliminate uncertainty... or maybe things should just be kept in the current state... Maybe that's not worth the worry in general. > plucker and spikeproxy would have to be ported to the “new” API. > I guess that would be worth a bug report, then ? Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- 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/877g9jyw9w@inf-8660.int-evry.fr
Re: git (was: Making packaging Python modules fun again)
On Jan 27, 2014, at 10:11 AM, W. Martin Borgert wrote: >About git: This needs clarification, e.g. will we settle on gbp? >Shall our branch be "master" (gpbs default) or "debian" (more >intuitive when one works with upstream)? Will we use the >pristine-tar branch or pristine tar files? Etc. That all remains to be seen. I'd personally like to see some sample packages with both alternatives so that we can play with them, and try to garner consensus. -Barry -- 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/20140129160528.14f0f202@anarchist
Re: Multiple copies of timeoutsocket.py in Debian packages
* Olivier Berger , 2014-01-29, 10:25:
Yeah, timeoutsocket.py looks like something that should have died a
decade ago. In Python ≥ 2.3 you can set default timeout or a
per-socket timeout without help of this library.
planet-venus, python-feedvalidator and rawdog already use the proper
Python interfaces, and only fall back to timeoutsocket when they are
not available:
http://sources.debian.net/src/python-feedvalidator/0~svn1022-2/feedvalidator/__init__.py#L8
http://sources.debian.net/src/planet-venus/0~git9de2109-1/planet/spider.py#L378
http://sources.debian.net/src/rawdog/2.13.dfsg.1-1/rawdoglib/feedparser.py#L103
I'm wondering, in similar cases, if there is anything that should be
done for these packages, like patching the code to remove the embedded
copy and get rid of the import check, since our Python versions in
Debian are recent enough ? This would eliminate uncertainty...
I would remove the embedded copy from Debian binary packages, and then
poke upstream to drop the obsolete code…
or maybe things should just be kept in the current state... Maybe
that's not worth the worry in general.
… but others' laziness may vary. :-P
plucker and spikeproxy would have to be ported to the “new” API.
I guess that would be worth a bug report, then ?
I'm glad you volunteered to file them. ;-)
Beware that spikeproxy's copy is slightly modified; see the attached
diff.
--
Jakub Wilk
--- plucker-1.8/parser/python/PyPlucker/helper/timeoutsocket.py 2002-10-10 23:57:45.0 +0200
+++ spkproxy-1.4.8/timeoutsocket.py 2003-04-08 17:22:38.0 +0200
@@ -286,6 +286,8 @@
if self._blocking:
r,w,e = select.select([],[sock],[], self._timeout)
if not w:
+#no raising for me!
+return 0
raise Timeout("Send timed out")
return sock.send(data, flags)
# end send
@@ -295,6 +297,8 @@
if self._blocking:
r,w,e = select.select([sock], [], [], self._timeout)
if not r:
+#I don't want to raise anything
+return ""
raise Timeout("Recv timed out")
return sock.recv(bufsize, flags)
# end recv
Preparing for a major update of python-rdflib package
Hi. I'm contacting you as maintainers of reverse dependencies of python-rdflib. Maybe some python folks (CC-ed) will be interested too if RDF echoes somehow to their ears ;-) I'm basing this email on my system's testing telling me : $ apt-rdepends -r python-rdflib Reading package lists... Done Building dependency tree Reading state information... Done python-rdflib Reverse Depends: buxon (0.0.5-4) Reverse Depends: python-feedvalidator (0~svn1022-2) Reverse Depends: python-sparqlwrapper (1.4.1-2) Reverse Depends: swaml (0.1.1-2) buxon python-feedvalidator python-sparqlwrapper Reverse Depends: swaml (0.1.1-2) swaml I've been working on updating the Debian package of the Python RDFLib [0] in recent weeks, improving the work initiated by Christian M. Amsüss (see ITA #702300). I've just uploaded an updated package to experimental (pending review in the NEW queue [2]). RDFLib 2.4.2 in Debian was really old and buggy for modern RDF applications, so I hope the situation will be much better with a much more recent version appearing in Debian (4.0.1-1), but I expect quite some impact on your packages which still depend on the old version (enjoy reading [3]). I even think this may have a consequence on the presence of some of your packages in Debian, which may become obsolete if they can't run with a recent RDFLib :-/ Note that for python-sparqlwrapper, I've already tested a bit the transition, as both packages are depending on each-other (and the appearance of python3-rdflib will make python3-feedparser's transition to testing happy ;) I hope the python-rdflib / python3-rdflib packages will appear soon in experimental, but in the meantime, they could be tested from rebuilding from the package sources (see [1]). Feel free to report and/or ask for more details. Of course more help in improving RDFLib's packaging would be great, and I'm sure Christian won't object, as the goal has been to try and do team maintenance (even if the Git / SVN issue re. DPMT made it to appear in collab-maint for the moment). Looking forward to reading from your bugs, Best regards, Obergix [0] http://packages.qa.debian.org/r/rdflib.html [1] http://anonscm.debian.org/gitweb/?p=collab-maint/rdflib.git;a=shortlog;h=refs/heads/debian [2] https://ftp-master.debian.org/new/rdflib_4.0.1-1.html [3] https://github.com/RDFLib/rdflib/blob/4.0.1/CHANGELOG.md -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- 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/87fvo6scig@inf-8660.int-evry.fr
