Removing me from Uploader field of html5lib
Hi. Unfortunately, I'm no longer able to dedicate time to help maintaining the html5lib package. Thus I'm requesting that anyone uploading the next version as part of the team, please remove me from the uploaders field. Thanks in advance. Btw, the docs on the wiki documents how to be added/contribue, but not really how to stop ;-) Thanks in any case for all the good work, team. 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)
Re: AsciiDoc in python-pelican
Hi. Yukiharu YABUKI writes: > Hello, there > > I have just started to use pelican which is static HTML generator. > I read getting started[1], settings[2] and issue[3]. > > I checked python-pelican package can generate from > foo.md and bar.rst to static HTML files > > python-pelican package description tells me that it enable to use > AsciiDoc fortmat. I wrote test.asc. but pelican does not understand > test.asc file. It did not report error. It ignored asc file. > > I also install asciidoc package. But nothing to change. > > If anyone knows how to use asciidoc in python-pelican package, please > share your knowledge. > > Thank you for your advice. > Sorry, I have no clue about what the program is supposed to do, but AFAICT, your report looks very much to what may deserve a bug report (see reportbug or https://www.debian.org/Bugs/Reporting for instance). Just my 2 cents, 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: https://lists.debian.org/87d2dz2vsl@inf-11879.int-evry.fr
RDFLib and SPARQLWrapper now in sync with upstream (in experimental): time for more tests
Hi. Just a message for those who may have RDF/Linked-Data apps relying on those Python libraries... I've now uploaded to experimental the latest versions of RDFLib (4.1.2) and SPARQLWrapper (1.6.0) with Python3 support and test suites. So, any testing is very much welcome. Thanks in advance. 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: https://lists.debian.org/87tx8nh5ox@inf-8660.int-evry.fr
DONE : rdflib 4.0.1-3 arrived in unstable - Was: Re: Preparing for a major update of python-rdflib package
Hi. Just in case you had missed it, RDFLib 4.0.1-3 just landed in unstable (http://packages.qa.debian.org/r/rdflib/news/20140513T104042Z.html) Feel free to test and report breakages. Latest upstream (4.1.2) should be in experimental in the next days. Best regards, Olivier Berger writes: > 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: https://lists.debian.org/874n0te6ca@inf-8660.int-evry.fr
Re: Preventing network access during nose doctest ?
Nicolas Dandrimont writes:
> * Olivier Berger [2014-05-12 14:36:17
> +0200]:
>
>> Hi.
>>
>> I'm trying to fix #739222 where tests fail (-> FTBFS) during execution
>> of nose's doctest plugin on something like :
>> >>> import rdflib
>>
>> >>> g = rdflib.Graph()
>> >>> result =
>> g.parse("http://www.w3.org/2000/10/swap/test/meet/white.rdf";)
>>
>> >>> print("graph has %s statements." % len(g))
>> graph has 19 statements.
>>
>> I'm puzzled : I'm invoking the tests run with :
>> PYBUILD_SYSTEM=custom \
>> PYBUILD_TEST_ARGS="{interpreter} run_tests.py" \
>> http_proxy= https_proxy= \
>> dh_auto_test --buildsystem=pybuild
>>
>> where run_tests.py will invoke nose with --with-doctest, but even though
>> the HTTP proxy variables being set, they don't seem to be preventing
>> urllib2 to try to access the file.
Thanks everyone for the hints.
>
> Hi,
>
> Here, you're setting an empty http_proxy variable, which means "don't use a
> proxy". What you really want is to set the proxy to something that errors out,
> e.g. http://127.0.0.1:9/ (the discard port on localhost).
>
> And then, you'll need to disable the tests that need internet access, or
> modify
> them so that they stop needing it.
>
Indeed I was overly confused : I had previously manually set them to
empty values to workaround the proxy setting made by pybuild internally,
so that the build would effectively access the network... and then I
forgot why I had done that... and of course I hadn't documented that ;)
Sorry about the bothering.
But, then there's still the option of maybe mocking the tests so that we
can proxy locally a copy of the document being fetched... but I'll let
that for another day ;)
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: https://lists.debian.org/87ppjjqf8k@inf-8660.int-evry.fr
Preventing network access during nose doctest ?
Hi.
I'm trying to fix #739222 where tests fail (-> FTBFS) during execution
of nose's doctest plugin on something like :
>>> import rdflib
>>> g = rdflib.Graph()
>>> result = g.parse("http://www.w3.org/2000/10/swap/test/meet/white.rdf";)
>>> print("graph has %s statements." % len(g))
graph has 19 statements.
I'm puzzled : I'm invoking the tests run with :
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="{interpreter} run_tests.py" \
http_proxy= https_proxy= \
dh_auto_test --buildsystem=pybuild
where run_tests.py will invoke nose with --with-doctest, but even though
the HTTP proxy variables being set, they don't seem to be preventing
urllib2 to try to access the file.
So there doesn't seem to be a way to notice until the network is really
brought down :-/
Instructions at https://wiki.debian.org/Python/Pybuild suggest that the
variables help, but probably only for pip etc. ?
In any case, an obvious fix here could be to prevent running doctest at
all.
But there might be a smarter way, to fake the existence of such a page
(retrieved through urllib2) so as the tests can be run offline ?
If anyone has suggestions...
Many thanks in advance.
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: https://lists.debian.org/87siofqim6@inf-8660.int-evry.fr
Re: Python CGI sandboxing advice (packaging of Online Python Tutor)
Hi.
Jakub Wilk writes:
> * Jakub Wilk , 2014-02-13, 00:27:
>>>The CGI's code is supposed to be safeguarding against abuse,
>>The protection is not very good. (I'll disclose the details later.)
>
> The exploit I had in mind was:
>
> import re
> from re import sys
> imp = re.sys.modules['imp']
> posix = imp.load_dynamic('', 'posix')
>
> which gives you access to the goodies of the posix module. There's a
> resource limit that prevents you from opening any file, but you can do
> chmod(), chown(), remove(), rename(), kill(), …
>
> Apparently this is now fixed:
> https://github.com/pgbovine/OnlinePythonTutor/commit/eab7cb1c717a
>
> I wouldn't be surprised if there were other clever ways to bypass OPT's
> security restrictions, and upstream doesn't seem to confident about this
> code either.
Thanks for sharing this. I'll have to read about re.sys (WTF ?)...
FWIW, I've put a hold to my tests of packaging OPT, while I was
investigating the use of Docker for sandboxing Web apps in its
containers.
For instance, I've been playing with FusionForge's mediawiki (including
its PostgreSQL and Apache dependencies) in such an environment, and it
seems one possible way...
I'm not sure whether others have similar plans using Docker for
something that could be done "the debian way". Probably deserves another
post.
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: https://lists.debian.org/8738hmveul@inf-8660.int-evry.fr
Bug#734380: retitle 734380 to ITP: pysshmenu -- Menu for quick connections to your remote hosts
retitle 734380 ITP: pysshmenu -- Menu for quick connections to your remote hosts owner 734380 ! thanks Hi. I intent to package pysshmenu (as a replacement for sshmenu, which got removed from testing), as part of PAPT. Description: Menu for quick connections to your remote hosts SSHMenu is a simple GUI app that provides a menu for initiating SSH connections. Select a host from the menu and up pops a new terminal window containing an SSH session to the selected host. . pySSHMenu is a port of SSHMenu to Python and Gtk 3 that runs as an AppIndicator or StatusIcon rather than as an applet. pySSHMenu reads and writes your old SSHMenu configuration files to make transitioning easy. I'd welcome a review of the current state if anyone is interested (https://github.com/olberger/pySSHMenu/tree/debian). If there's no objection, I'll try to inject it in the PAPT SVN soon. Thanks in advance. 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: https://lists.debian.org/1393950743-3301-bts-ober...@debian.org
Re: Python CGI sandboxing advice (packaging of Online Python Tutor)
Hi. I'm looking for advice on how to package the Online Python Tutor's backend server which can execute arbitrary Python scripts submitted by the user. The CGI's code is supposed to be safeguarding against abuse, but I think some sandboxing would be better at the CGI invocation for additional security. I forgot to CC: this list. Any advices (beyond Paul's) ? Thanks in advance. Best regards, Olivier Berger writes: > Hi. > > Paul Wise writes: > >> On Thu, Feb 6, 2014 at 8:43 AM, Paul Wise wrote: >> >>> Which CGI are we talking about? Perhaps we can give more specific advice. >> >> I guess you mean Online Python Tutor (#737732). >> > > Damn BTS ;) Indeed, I was considering OPT. > >> Looking at the git repo, it includes a lot of embedded code copies of >> various JavaScript libraries and other code. As per policy 4.13 those >> should be packaged separately. >> >> https://wiki.debian.org/EmbeddedCodeCopies >> > > Sure. > >> I see some places where it uses os.system(). That should switch to >> using the subprocess module with shell disabled. >> >> The idea of this software is a bit concerning to me, it sounds like it >> runs arbitrary Python code on the server and passes the results back >> to the web. > > Exactly. > >> I would suggest auditing it to ensure that it isn't one >> giant security hole. Please get CVEs for any issues that you find. >> >> http://oss-security.openwall.org/wiki/disclosure/cve >> > > Yes, it is indeed something that might be problematic. > > AFAICS for now, it uses a withelist of python modules that are allowed > (see [0]). > > That looks safe at first sight, but I fear there could be some kind of > exploits if the "safe" modules have flaws... > > I'm not an expert in Python code security so I'd welcome any advices. > > > In this respect, I can see the benefit of running it over a PaaS > solution like Google App Engine (which is advertized by upstream > author's site) in this respect, given that those Python execution > environments may naturally be sandboxed, etc. > > > Maybe a CGI sandboxing solution could be advised, for running over a > "normal" Debian system ? > > Thanks in advance. > > Best regards, > > [0] > https://github.com/pgbovine/OnlinePythonTutor/blob/master/v3/pg_logger.py#L112 -- 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/87ob2fgut3.fsf...@inf-8660.int-evry.fr
Re: Help with packaging of python executable and its modules
Piotr Ożarowski writes: > [Andreas Tille, 2014-02-07] >> On Fri, Feb 07, 2014 at 02:41:10PM +0100, Julian Taylor wrote: >> > I assume this is a python application and not a library? >> >> It is an application including some private modules which I like to be >> compiled into *.pyc. > > please install to /usr/share/package-name/ both the library and the > scripts, then symlink these scripts to /usr/bin - this way you will not > have to patch anything. > > (use /usr/lib/package-name/ if it contains arch-dep. files) What would then be the recommended way to do so ? debian/install, or is dh_python* a way to do that ? May I suggest to update the wiki to reflect such cases, i.e. difference between application-specific modules or generic library modules. Thanks in advance. 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/87bnyg4dp8@inf-8660.int-evry.fr
Re: update of rope
Hi. PICCA Frederic-Emmanuel writes: > > now, I can not afford to learn svn-buildpackage. days are too short... > I use only git-buildpackage... (this is not a troll) this is just that days > are really to short > and I have plenty of other things to do. You might want to harvest hints given in [0] which hopefully allow you to keep gbp and use git-svn. Hope this helps. Best regards, [0] https://lists.debian.org/debian-python/2014/01/msg00023.html -- 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/87eh3c4dzg@inf-8660.int-evry.fr
Anyone experimented with Google App Engine Python SDK packaging for Debian ?
Hi. I'm quitenew to that technology and thought that maybe there would be some more expertise here. Has anyone tried to consider packaging of the Google App Engine Python SDK for Debian ? AFAIU, it allows to develop apps that can be put in production on Google's PaaS platform (yes, not free, so questionable interest), but also allows to run these apps on your server. I think it is free software (Apache license and others). I'm wondering what exact dependency on Google's SDK apps have... it seems at first look that SWGI is involved, so maybe that could work with other Web servers already available in Debian ? I coudn't spot discussions RFP or ITPs, but maybe you would have some pointers ? Thanks in advance. Best regards, P.S.: I was interested in packaging Online Python Tutor (http://pythontutor.com/) initially, which runs over the Google App Engine Python SDK -- 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/871tzkxzfm@inf-8660.int-evry.fr
Re: Multiple copies of timeoutsocket.py in Debian packages
Hi. Jakub Wilk writes: > * 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 Thanks for your suggestions. Filed the following wishlists (planet-venus already addressed in version in experimental) : - python-feedvalidator : #737117 - rawdog : #737116 > >>>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. ;-) > DONE : - plucker : #737114 - spikeproxy : #737113 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/87eh3pk6pp@inf-8660.int-evry.fr
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
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
Multiple copies of timeoutsocket.py in Debian packages
Hi. 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. I don't know if/what to do more on the topic... Anyone willing to try and dig on this issue ? Hth. Best regards, [0] http://codesearch.debian.net/search?q=TimeoutSocket+path%3Atimeoutsocket.py -- 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/87ppnc5d5b@inf-8660.int-evry.fr
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
Barry Warsaw writes: > On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote: > >>I've used git-buildpackage with git-svn on submodules of the DPMT SVN >>repo without too many difficulties so far. > > git-bp OTOH required a specific set of branches inside the repo to stitch > everything together and if those were missing, it failed miserably. I could > be totally wrong about that, or I could have just been using the tool > incorrectly. > It more or less requires only 2 branches : upstream (when you want to track upstream sources) and master (or debian) for the packaging source. But for repos of DPMT which won't track upstream code in the SVN, you only need to manage the debian/ subdir on the master branch which correspons to the trunk, so that means that git svn clone --std-layout basically sets things up for you. Now, if you both want to track upstream sources from origin/master on local upstream/ branch and svn's trunk on local master branch, then, yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges now and then. In any case, reading http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html more or less covers all the cases I've played with so far, AFAICT. YMMV ;-) 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/877ga2v9xj@inf-8660.int-evry.fr
Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
Hi. Alexandre Rossi writes: > Hi, > >>> My goal is to maintain sockjs-twisted (#735154). >> >> the problem is... we don't use git, not yet at least (nobody had time to >> propose a transition) > > The Wiki page[1] suggests there are some git repositories, but I > cannot find/see them. I also found out that some packages maintained > by the team are hosted on alioth in collab-maint (src: bugz, > dajaxice). > > Regarding the transition, the Java packaging team has both git and svn > repositories. Maybe the DPMT can do the same starting with my package > in the path suggested by the Wiki. > > Advice? > > Alex > > [1] https://wiki.debian.org/Teams/PythonModulesTeam/ > Maybe I can share a bit of help by explaining what I've tried to do for some recent contributions of mine. I've used git-buildpackage with git-svn on submodules of the DPMT SVN repo without too many difficulties so far. The command line is usually of this kind : $ gbp buildpackage [--git-verbose] --git-cleaner= --git-overlay --git-export-dir=../build-area/ --git-tarball-dir=../tarballs [--git-pbuilder] [-us -uc --git-ignore-new] This at least allows to work "offline" until the commit graph looks nice with git, and push (dcommit) to SVN when the package has been uploaded (or when you have a consistent state). This may also allow keeping in the same git repo an upstream clone together with the git-svn checkout. I think [0] may offer some more details on that topic. In a summary, we have SVN for some large scale operations and to please the dinausors^Waddicted ones, and the power of git for the comfort of the maintainer testing changes to the package locally. Hope this helps. Best regards, [0] http://honk.sigxcpu.org/con/Using_git_svn_and_git_buildpackage_to_build_packages_maintained_in_Subversion.html -- 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/87k3e2vfzh@inf-8660.int-evry.fr
Re: Problem of ${python:Depends} version in backports - Was: Re: python-django-ldapdb 0.2.0-1~bpo70+1 uninstallable
Hi.
Olivier Berger writes:
> Hi.
>
> I'm a bit puzzled by a Python version issue when backporting
> django-ldapdb to wheezy-backports.
>
> The repo is here :
> http://anonscm.debian.org/viewvc/python-modules/packages/django-ldapdb/branches/wheezy-bpo/
>
> I'm using dh-python and the d/control says :
> Depends: ${misc:Depends}, ${python:Depends}
>
> However, the version in wheezy is older than the generated lower bound
> :-/
>
> Has anyone hints about what could be the problem/culprit ?
>
Me obviously.
I happened to have actually not used --git-pbuilder everytime, and the
last time, obviously :-(
I've re-checked and everything is OK when using
pbuilder/cowbuilder... you just have to pay attention to your shell
history ;)
Sorry about the bothering.
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/87sisr3lct@inf-8660.int-evry.fr
Problem of ${python:Depends} version in backports - Was: Re: python-django-ldapdb 0.2.0-1~bpo70+1 uninstallable
Hi.
I'm a bit puzzled by a Python version issue when backporting
django-ldapdb to wheezy-backports.
The repo is here :
http://anonscm.debian.org/viewvc/python-modules/packages/django-ldapdb/branches/wheezy-bpo/
I'm using dh-python and the d/control says :
Depends: ${misc:Depends}, ${python:Depends}
However, the version in wheezy is older than the generated lower bound
:-/
Has anyone hints about what could be the problem/culprit ?
Thanks in advance.
Best regards,
Andreas Beckmann writes:
> 0m33.4s ERROR: Command failed (status=100): ['chroot',
> '/tmp/piupartss/tmpdoeG7S', 'apt-get', '-y', '-t', 'wheezy-backports',
> 'install', 'python-django-ldapdb']
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>python-django-ldapdb : Depends: python:any (>= 2.7.5-5~) but it is not
> installable
> Depends: python:any (< 2.8) but it is not
> installable
> E: Unable to correct problems, you have held broken packages.
>
>
> $ rmadison python
> python | 2.6.6-3+squeeze7 | squeeze | all
> python | 2.7.3-4+deb7u1 | wheezy | all
> python | 2.7.5-5 | jessie | *
> python | 2.7.5-5 | sid | *
>
>
> --
> To UNSUBSCRIBE, email to debian-backports-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/52d1b833.2080...@debian.org
>
>
--
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/87vbxo2lr7@inf-8660.int-evry.fr
Handling stable backports in DPMT's SVN ?
Hi. Is there any guidance on how to handle versioning of packages for stable backports in the DPMT SVN ? I'm no so sure about best practices with SVN branches anymore, having used too much git these past years ;) Thanks in advance. 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/87zjn7bslc@inf-8660.int-evry.fr
Fwd: Accepted sparql-wrapper-python 1.5.2-1 (source all)
Hi. FYI, I'm adopting python-sparqlwrapper that has just been orphaned by Nacho Barrientos Arias. I've just uploaded to experimental a new package based on latest upstream (see attached mail). I'll let the latest 1.4.1 package propagate to testing before I upload 1.5+ to unstable, hence experimental. I intend to get it maintained as part of DPMT, in case there's the need to update it and someone can help. Feel free to test or comment on the packaging and or usefulness of the package (SemWeb fans out there ? ;). Best regards, --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 30 Dec 2013 15:53:30 +0100 Source: sparql-wrapper-python Binary: python-sparqlwrapper python3-sparqlwrapper Architecture: source all Version: 1.5.2-1 Distribution: experimental Urgency: medium Maintainer: Olivier Berger Changed-By: Olivier Berger Description: python-sparqlwrapper - SPARQL endpoint interface to Python (Python 2) python3-sparqlwrapper - SPARQL endpoint interface to Python (Python 3) Closes: 731361 Changes: sparql-wrapper-python (1.5.2-1) experimental; urgency=medium . * New upstream version (Closes: #731361). * Adopted (obergix), as part of DPMT. Checksums-Sha1: 2f915408385e568a81c1901ed5102e2bc5f60f57 2233 sparql-wrapper-python_1.5.2-1.dsc 7aa674995bdd575aa89685c0f494eb04ff2c5259 24953 sparql-wrapper-python_1.5.2.orig.tar.gz f2d7c087383e3b180e3ce0f235b54989ea950995 4437 sparql-wrapper-python_1.5.2-1.debian.tar.gz a5f5ffca5fded838586d5ca9054f83ae38e38e36 22402 python-sparqlwrapper_1.5.2-1_all.deb 6bfe321f0aedf31859d2c18d7e7f1231cb315de0 20796 python3-sparqlwrapper_1.5.2-1_all.deb Checksums-Sha256: aacb249caa5f050b362854c41ac888a9d46207031407f435f26c67c681b5db26 2233 sparql-wrapper-python_1.5.2-1.dsc 65254c7c3cae093fbd5e6b65e2c725db3ad80ab7402c4aa59d18a9cb8f5695b4 24953 sparql-wrapper-python_1.5.2.orig.tar.gz 31fff0c68bda968bd8ccf2a5da7faa56445b2a822bcaee837c3e51ad2f383d06 4437 sparql-wrapper-python_1.5.2-1.debian.tar.gz f60f5566a4a9fde20d99d499e60fadaab8b978808052145527c7048efd33f057 22402 python-sparqlwrapper_1.5.2-1_all.deb 3661d8171d7e3954560b00b8d0d369c9a279cfbbfcaa07a5fb32bcd0488d93ce 20796 python3-sparqlwrapper_1.5.2-1_all.deb Files: d2b83f8f84bba360026c65e627112100 2233 python optional sparql-wrapper-python_1.5.2-1.dsc dc72e43ee4382dbc3abcb1941ab3e9c0 24953 python optional sparql-wrapper-python_1.5.2.orig.tar.gz 97f4cee60b45a1b824dfe4b7f10caf62 4437 python optional sparql-wrapper-python_1.5.2-1.debian.tar.gz b8378415f4eba2d863e63fa376b18dc8 22402 python optional python-sparqlwrapper_1.5.2-1_all.deb 80e0d2cafa6d344bac065f9d597fbb3e 20796 python optional python3-sparqlwrapper_1.5.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJSwYntAAoJEOlB3tp8W7alvDoQALSqfhQHnHp7oXSa+9GrgKHc wF1uSF0Lu8rENB6b02dCk7eAASXeC9FeSFNBmmNv855b/XbgJCHvB/rc2rrxyRly bJs3c8YNRndP9LrtUz4G0Sl7vwUOIm9wzcug85Ienw3MfAZZJMWl97YMGwv5KEiZ T7ParlH4LWSBLq6KFPictxzN0PrlF7YzGZ3ev7mQgHPO1xtR+unOkrPvQdzEIZUr lnlqvjHyL1ntZe6BVZJSWdrSCf+NdnAgOM93IRBg5ZbCRO2uLgBRkRNRAc6No1nC OtM8spoOCZP0K1MK5ktDzjI+WxHCAtCGXqfFOPvu9zfM41J4EdXwu2w4QPuIlnrs GotJ6TH78QU33PNDmR6yF7DGlLhKA0su9OUOu3VoG7utwbqHx0sUx6DefaLgzGvx alIppuwq5en1U4jq5rik/izsBn8LWdcCv04moHG4NIoqcbltx+KztLk95QIgubFF qV5ARQ7NDrpiQxPilx5gqNH3JQfOf05RSb/zuoWsxeHrPbVlOJWEcXyJH8dBNuGu 5oLXA+M08/kiXUJrnIUE1OG/wI664XW+XhQKwOH5gvXyz7BDgzD96gwcIA+Vza46 Wkc7iiLuA5XS6ZBZ0HroS++OIwojFDsmcVWZtF/T8J03Gc/REXOL4ZbR87g7hcqv 95D7er9HH/t7hHCpg21t =o6Of -END PGP SIGNATURE- --- End Message --- -- 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)
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
Jakub Wilk writes: > * Olivier Berger , 2013-12-16, 13:24: >>- add a python-rdflib-tools package that contains shell scripts of the >>form : >> >> #!/bin/sh >> >> exec /usr/bin/python -m rdflib.tools.csv2rdf $* > > I can't see how that's better than a script with #!/usr/bin/python > shebang... > Well... it's essentially easier than altering the modules to provide them with a sheebang, making them executable and shipping symlinks... whose targets wouldn't be the same in the v2 and v3 package... >>- make this package depend on python-rdflib | python3-rdflib > > /usr/bin/python can't use the modules shipped by python3-rdflib. > Ah, thanks for spotting this... I thought it was a bit too easy indeed ;) Hmmm... Maybe this is better : #!/bin/sh /usr/bin/python3 -c 'import rdflib.tools.csv2rdf' 2>/dev/null if [ "$?" = "0" ] then exec /usr/bin/python3 -m rdflib.tools.csv2rdf $* else exec /usr/bin/python -m rdflib.tools.csv2rdf $* fi What do you think ? 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/87bo0hj5ln@inf-8660.int-evry.fr
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
Hi.
Olivier Berger writes:
> Hi.
>
> I'm working on rdflib whose setup.py comes with :
> entry_points = {
> 'console_scripts': [
> 'rdfpipe = rdflib.tools.rdfpipe:main',
> 'csv2rdf = rdflib.tools.csv2rdf:main',
> 'rdf2dot = rdflib.tools.rdf2dot:main',
> 'rdfs2dot = rdflib.tools.rdfs2dot:main',
> 'rdfgraphisomorpishm = rdflib.tools.graphisomorphism:main',
> ],
>
> So, when building with pybuild with Python2 and Python3, these are
> installed in 2 sets of scripts in each package's /usr/bin/ and only
> differ on their respective shebang.
>
> Lintian detects the conflict OK (binaries-have-file-conflict) but it
> isn't clear to me how to resolve this.
>
> Should I add a python-rdflib-tools package (depending on either versions
> of python-rdflib or python3-rdflib ?), and then avoid installing
> the Python3 version by using a
> PYBUILD_INSTALL_ARGS_python3=--install-scripts=... and some .pyremove ?)
>
> I though maybe of another option, which is to install in each package's
> /usr/share/python[3]-rdflib/tools and only add symlinks for one of the
> packages...
>
> Is there a best practice in this case ?
>
I have seen the answers you provided, thank you.
Also, I forgot to mention that the generated scripts look like the
following :
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'rdflib==4.0.1','console_scripts','csv2rdf'
__requires__ = 'rdflib==4.0.1'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('rdflib==4.0.1', 'console_scripts', 'csv2rdf')()
)
... which leads to problems with (recursive) dependencies mentioned in the
.egg-info that may not be satisfied in Debian :-/
And also, the original rdflib/tools/*.py modules don't have a sheebang
on first line, which prevents a direct symlink option from /usr/bin/...
So... after various experiments, I think I'll go this way :
- get rid of these scripts installed through eazy_install
- add a python-rdflib-tools package that contains shell scripts of the
form :
#!/bin/sh
exec /usr/bin/python -m rdflib.tools.csv2rdf $*
- make this package depend on python-rdflib | python3-rdflib
Thus, I hope we have something basic which works in most cases (I hope I
haven't overlooked some details).
I wonder if this would sound reasonable to add a feature to dh-python or
pybuild so that such "conversions" of 'console_scripts' could be done
automatically...
Comments/remarks much welcome.
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/87fvptj856@inf-8660.int-evry.fr
usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
Hi.
I'm working on rdflib whose setup.py comes with :
entry_points = {
'console_scripts': [
'rdfpipe = rdflib.tools.rdfpipe:main',
'csv2rdf = rdflib.tools.csv2rdf:main',
'rdf2dot = rdflib.tools.rdf2dot:main',
'rdfs2dot = rdflib.tools.rdfs2dot:main',
'rdfgraphisomorpishm = rdflib.tools.graphisomorphism:main',
],
So, when building with pybuild with Python2 and Python3, these are
installed in 2 sets of scripts in each package's /usr/bin/ and only
differ on their respective shebang.
Lintian detects the conflict OK (binaries-have-file-conflict) but it
isn't clear to me how to resolve this.
Should I add a python-rdflib-tools package (depending on either versions
of python-rdflib or python3-rdflib ?), and then avoid installing
the Python3 version by using a
PYBUILD_INSTALL_ARGS_python3=--install-scripts=... and some .pyremove ?)
I though maybe of another option, which is to install in each package's
/usr/share/python[3]-rdflib/tools and only add symlinks for one of the
packages...
Is there a best practice in this case ?
Thanks in advance.
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/871u1g4sp4@inf-8660.int-evry.fr
Upgrading html5lib to 0.99 (in order to add support for Python3)
Hi. I'm interested in upgrading html5lib to 0.99 (currently at 0.95 in Debian), in order to bring Python 3 compatibility (see #729155). This would help making sure that RDFLib will also be available for Python 3, for whose package I'm working too (see #655039 and #702300). Bernd, I'm not sure if you're interested and/or have investigated changes brought by this upgrade already. As I'm new to the team, I though I'd ask before doing much work that could be redundant (who knows...). I've already committed to SVN the basic changes needed, but as usptream code has evolved quite a lot I think there's a need for more work (reviewing changes, updating copyright, adding doc generation, maybe passing upstream tests if possible, etc.). Thus I'll probably work on this during the next days. In case you're interested, please let me know... and anybody else interested in helping or willing to review the package, please, let me know too. Also, I'm not exactly sure how to proceed with reverse dependencies on the library, and whether maintainers of these packages should be notified somehow... Feel free to educate me in case I'm missing some procedures on how to contribute to a packaging that was previously handled by someone else, in the frame of DPMT. Thanks in advance. 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/87mwk6xx88@inf-8660.int-evry.fr
Re: pybuild and not always preventing network connection in auto tests
Barry Warsaw writes: > On Dec 11, 2013, at 05:09 PM, Olivier Berger wrote: > >>Do I need an unexport http_proxy AND an http_proxy='' dh_auto_test ? > > No, all you need to do is unset http_proxy and https_proxy for the duration of > the test command. > OK, just inside the pybuild --test. That will prevent other problems related to import from pypi in other steps, etc. > > So all you should need to do in the above is: > > override_dh_auto_test: > http_proxy= https_proxy= dh_auto_test > > Of course, that means if your test hits the network outside of localhost, you > may get local build successes where buildds without network access would still > fail. Oh well, you'll find out soon enough. ;) > Yeah, well, in due time, yes ;) Thanks for the details. 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/87iouvic5f@inf-8660.int-evry.fr
Re: pybuild and not always preventing network connection in auto tests
Barry Warsaw writes: > On Dec 11, 2013, at 03:34 PM, Dimitri John Ledkov wrote: > >>actually you probably need to set them to empty value; e.g. >>http_proxy="" https_proxy="" dh_auto_test, or export http_proxy\n >>export https_proxy > > Right. That's essentially what I do. > I'm not sure I understand. Do I need an unexport http_proxy AND an http_proxy='' dh_auto_test ? I'm not sure about the behaviour of GNU make wrt env variables, so maybe that'd be obvious... Any clarification much welcome. 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/87mwk7id37@inf-8660.int-evry.fr
pybuild and not always preventing network connection in auto tests
Hi. AFAIU, pybuild prevents accesses to the network. But this can be problematic during auto_tests that will perform HTTP connections on a local HTTP server (I have such an example in rdflib's auto tests [0]). Is there a way to avoid such a protection, possibly on a selective number of tests ? Thanks in advance. Best regards, [0] https://github.com/RDFLib/rdflib/blob/master/test/test_conneg.py -- 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/87r49jif5j@inf-8660.int-evry.fr
override_dh_auto_test and custom system (for Django, for ex.) - Was: Was: Re: pybuild - one to rule^W build them all
Hi.
FWIW, I've tried and find a way to invoke the Django auto tests when
using debhelper and pybuild (i.e. running django-admin test in the build
dir).
I had noticed this mail describing the use of the 'custom' system and
--test-args, but it seems there's a better way :
override_dh_auto_test:
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="cd {build_dir}; django-admin test
--settings=YOURMODULE.test_settings --pythonpath=. [YOURMODULE.tests]" \
dh_auto_test
This should be more robust in the case where pybuild must be called
twice to run the tests with Python 2 and 3, AFAIU.
Sorry if this is obvious to elders, but I hadn't spotted that yet.
I have updated
https://wiki.debian.org/DjangoPackagingDraft#Running_auto_tests_at_build_time
accordingly.
Hope this helps.
Best regards,
Piotr Ożarowski writes:
>
>> 2. unit-testing against built/installed modules (if some env variable
>>provides the command to be invoked)
>
> it already invokes `pythonX.Y setup.py test` (if "test_suite" string is
> detected in setup.py, distutils plugin only) or `pythonX.Y -m unittest
> discover -v` in all other cases, you also can:
>
> override_dh_auto_test:
> pybuild --test --system=custom --test-args 'cd {build_dir}; your
> command'
>
--
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/87lhzx99f8.fsf...@inf-8660.int-evry.fr
Re: Recommending get-orig-source for packages ?
Piotr Ożarowski writes: > [Olivier Berger, 2013-12-03] >> Hi. >> >> I haven't spotted anything recommending a get-orig-source target in >> debian/rules in the team's docs. >> >> I think it could be an interesting recommendation, as since the practice >> seems to be only versioning the contents of the debian/ subdir, it could >> be interesting to document, through that target where to get the orig >> tarball. >> >> I guess most of the time, this could be derived from the debian/watch. > > if there's working debian/watch file, there's no need to add > get-orig-source (and to be honest, I prefer debian/rules without > get-orig-source if debian/watch is available) What's your rationale, Piotr ? I'd understand if there was something in debhelper/dh-python that would automatically handle debian/watch, but that's not the case, AFAICT... so, what harm is there to make things explicit (in case of QA maintenance or other situations where using svn-buildpackage isn't waranted) ? 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/8738m9q5q9@inf-8660.int-evry.fr
Recommending get-orig-source for packages ?
Hi. I haven't spotted anything recommending a get-orig-source target in debian/rules in the team's docs. I think it could be an interesting recommendation, as since the practice seems to be only versioning the contents of the debian/ subdir, it could be interesting to document, through that target where to get the orig tarball. I guess most of the time, this could be derived from the debian/watch. Maybe using something like : https://wiki.debian.org/onlyjob/get-orig-source Any comments ? 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/87d2leos95@inf-8660.int-evry.fr
Team maintenance of git-buildpackage repo cloned from upstream's
Hi. I think this may be a FAQ, but I haven't yet managed to find some hints (or haven't had the ambition to re-read tons of ML archives yet). Sorry in advance if I'm the 10th who asks. Is there prior art of packages maintained by DPMT which use git-buildpackage, in order to track upstream's repo (for instance adding just a 'debian' debian-branch) ? My impression is that until the team has chosen to add a Git repo to the existing SVN (I guess Alioth allows multiple repos in same project now), an option is to host such repos in collab-maint's Git repo... wich means that only DDs could touch eat and not all members of DPMT, IIUC. Thanks in advance. 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/87pppjz3jv@inf-8660.int-evry.fr
Re: Simplified library style guide based on pybuild
Hi. On Tue, 05 Nov 2013, Barry Warsaw wrote: > > There's one little white lie currently: debian/*.pyremove files aren't yet > supported for Python 3 package, but Piotr is going to enable that with the > next upload of dh-python. > May I ask whether there's a quick workaround for this issue, for the moment ? Bts, I've just filed a bug (#730777) to dh-python about the issue, in case one didn't notice your message. I hope no-one takes offense. Thanks in advance. 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/87siufz56f@inf-8660.int-evry.fr
Re: Review of Django-ldapdb package needed
Hi. Olivier Berger writes: > Hi. > > I intend to have it maintained in the team SVN but am still waiting for > a kind sould to add obergix to the alioth project ;) > I've committed the svn-buildpackage-ready debian/ sources to [0]. Thanks in advance for any comments, in particular about the way of packaging such a Django "app". Best regards, [0] https://alioth.debian.org/scm/viewvc.php/packages/django-ldapdb/?root=python-modules -- 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/87r4a2f2em@inf-8660.int-evry.fr
Review of Django-ldapdb package needed
Hi. I Intend To Package django-ldapdb [0] but I'm quite new to Python packaging (incl. Django apps packaging ;). I intend to have it maintained in the team SVN but am still waiting for a kind sould to add obergix to the alioth project ;) In the meantime, I've prepared a git-buildpackage repo in [1] that holds my source package, cloned off the upstream github repo. I'd welcome any comments or suggestions of more experienced team members regarding it. For the records, this could be a needed dependency of the userdir-ldap Django rewrite [2]. I'm a bit unsure how to deal with the upstream provided examples/ app, so tried to add it into /usr/share/doc/python-django-ldapdb/examples/examples/ which then requires a lintian override... Thanks in advance. Best regards, [0] http://bugs.debian.org/730548 [1] http://anonscm.debian.org/gitweb/?p=users/obergix/django-ldapdb.git [2] https://wiki.debian.org/DSA/UserdirLdapRewrite -- 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) pgpPKCq5mL9Ze.pgp Description: PGP signature
