to ITP hatch -- any takers?
Hi Team & Stefano in particular, There is RFP from Stefano https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072818 for hatch https://hatch.pypa.io/latest/ which is gaining more and more popularity. I wondered if anyone has free cycles to ITP and package it quickly it for the team maintenance? If not, I will try (according to Stefano no initial problems detected; and my codespell run did not even find any typos ;) ). Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Bug#1072640: ITP: fscacher -- Python package for caching results of operations on heavy file trees
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: fscacher Version : 0.4.1 Upstream Contact: Yaroslav Halchenko * URL : https://github.com/con/fscacher * License : MIT/X Programming Lang: Python Description : Python package for caching results of operations on heavy file trees fscacher is a Python module which provides a cache and decorator for memoizing functions whose outputs depend upon the contents of a file argument. . If you have a function 'foo()' that takes a file path as its first argument, and if the behavior of 'foo()' is pure in the *contents* of the path and the values of its other arguments, 'fscacher' can help cache that function. It caches the outputs of 'foo()' will be cached for each set of input arguments and for a "fingerprint" (timestamps and size) of each 'path'. If 'foo()' is called twice with the same set of arguments, the result from the first call will be reused for the second, unless the file pointed to by 'path' changes, in which case the function will be run again. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
Bug#1021619: RFP: python3-lazy-loader -- load subpackages and functions on demand
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python3-lazy-loader Version : 0.1 Upstream Author : Jarrod Millman * URL : https://github.com/scientific-python/lazy_loader * License : BSD-3 Programming Lang: Python-3 Description : load subpackages and functions on demand lazy_loader makes it easy to load subpackages and functions on demand. I was told that used in skimage and networkx already. Checked that introduced in networkx networkx-2.7rc1~42 bundled inside the source code. In debian we still have 2.6.3, so with the next update it would get it. lazy-loader is considered for adoption in other projects which would eventually get into Debian as well.
Bug#1014890: RFP: python3-looseversion -- Version numbering for anarchists and software realists
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python3-looseversion Version : 1.0.1 Upstream Author : Chris Markiewicz * URL : https://github.com/effigies/looseversion * License : Python Programming Lang: Python Description : Version numbering for anarchists and software realists A backwards/forwards-compatible fork of distutils.version.LooseVersion, for times when PEP-440 isn't what you need. . The goal of this package is to be a drop-in replacement for the original LooseVersion. It implements an identical interface and comparison logic to LooseVersion. The only major change is that a looseversion.LooseVersion is comparable to a distutils.version.LooseVersion, which means tools should not need to worry whether all dependencies that use LooseVersion have migrated. . If you are simply comparing versions of Python packages, consider moving to packaging.version.Version, which follows PEP-440. LooseVersion is better suited to interacting with heterogeneous version schemes that do not follow PEP-440. This package would be useful as we plan for adding support for Python 3.12 which would remove distutils.version.LooseVersion and some packages would need to "adjust" somehow. In our DataLad project we likely would just go the way of using this LooseVersion instead of coming up with some "more proper" solution.
Re: python-argcomplete salvaging and possible team (re)join
Hi Marco, Marc and the Team,
I have just uploaded to --delayed 5 a workaround fix for #1010941
(FTBFS). The diff is attached
I have a clone at https://salsa.debian.org/yoh/python-argcomplete
with Marc's NMU imported, and my NMU changes on top. So could be a good
starting point to update packaging to a new release ;)
would also be nice to add tags (may be original from Marco?) for prior
upstream/debian releases.
Cheers,
On Wed, 27 Apr 2022, Marc Dequènes (duck) wrote:
> Quack,
> python-argcomplete has not been actively maintained and I did a NMU last
> year that got unacknowledged. I intend to salvage it. I think it would make
> sense to maintain it under the team's umbrella, which leads me to…
> I was part of the "Python Modules Team" between 2006 and 2009 but since then
> did not maintain Python packages except for some sponsoring (mainly
> postfix-mta-sts-resolver and dico related packages but not team-maintained
> although wikitrans was in the Python Modules Team as the Maintainer field
> attest). I'd be glad to rejoin if you would allow me. I don't know if I
> would have time to work on other team packages but occasionally I should be
> able to give a hand.
> I have read and agree to the policy on:
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> I am not familiar with gbp-pq but I looked at the doc and it seems quite
> interesting. The rest of the workflow is is almost identical to what I'm
> used to and should not be a problem.
> Regards.
> \_o<
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW: http://www.linkedin.com/in/yarik
diff -Nru python-argcomplete-1.12.3/debian/changelog python-argcomplete-1.12.3/debian/changelog
--- python-argcomplete-1.12.3/debian/changelog 2021-09-28 10:29:56.0 -0400
+++ python-argcomplete-1.12.3/debian/changelog 2022-05-13 13:07:30.0 -0400
@@ -1,3 +1,12 @@
+python-argcomplete (1.12.3-0.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/rules
+- provide workaround for tests to not fail (Closes: #1010941).
+ Upstream issue: https://github.com/kislyuk/argcomplete/issues/337
+
+ -- Yaroslav Halchenko Fri, 13 May 2022 13:07:30 -0400
+
python-argcomplete (1.12.3-0.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru python-argcomplete-1.12.3/debian/rules python-argcomplete-1.12.3/debian/rules
--- python-argcomplete-1.12.3/debian/rules 2021-09-28 10:29:56.0 -0400
+++ python-argcomplete-1.12.3/debian/rules 2022-05-13 13:07:30.0 -0400
@@ -26,6 +26,17 @@
cp debian/$$i.1 debian/python3-argcomplete/usr/share/man/man1/$${i}3.1; \
done
+# Workaround
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010941
+# https://github.com/kislyuk/argcomplete/issues/337#issuecomment-771835184
+override_dh_auto_test:
+ echo "set enable-bracketed-paste off" > .inputrc
+ INPUTRC=$(CURDIR)/.inputrc dh_auto_test
+
+override_dh_auto_clean:
+ rm -f .inputrc
+ dh_auto_clean
+
generate_manpages:
VERSION=$$(./setup.py -V) ; \
for file in \
signature.asc
Description: PGP signature
Bug#1010168: RFP: python3-pytest-fail-slow -- pytest plugin for making tests fail that take too long to run
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python3-pytest-fail-slow Version : 0.1.0 Upstream Author : John Thorvald Wodder II * URL : https://github.com/jwodder/pytest-fail-slow/ * License : MIT/X Programming Lang: Python Description : pytest plugin for making tests fail that take too long to run pytest-fail-slow is a pytest plugin for making tests fail that take too long to run. It adds a --fail-slow DURATION command-line option to pytest that causes any & all otherwise-passing tests that run for longer than the given duration to be marked as failures, and it adds a @pytest.mark.fail_slow(DURATION) marker for making an individual test fail if it runs for longer than the given duration. If --fail-slow is given and a test has the @fail_slow() marker, the duration given by the marker takes precedence for that test. It will likely be necessary for testing the next (0.17) release of DataLad package.
Bug#1009985: RFP: memray -- memory profiler for Python
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: memray Version : 1.0.3 Upstream Author : Bloomberg LP * URL : https://github.com/bloomberg/memray * License : Apache 2.0 Programming Lang: Python Description : memory profiler for Python Memray is a memory profiler for Python. It can track memory allocations in Python code, in native extension modules, and in the Python interpreter itself. It can generate several different types of reports to help you analyze the captured memory usage data. While commonly used as a CLI tool, it can also be used as a library to perform more fine-grained profiling tasks. It was open-sourced only recently, LICENSE with Apache 2.0 was added only 12 days ago.
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
FWIW, if might come handy in the future, my 4c: > * What do we provide for scientific / data scientist use cases? - https://snapshot.debian.org/ is the unique service allowing to "go back in time" or just "freeze" the environment given a date. Very handy for reproducibility, collab, etc. Not possible AFAIK on pypi or even conda unless researcher prepared a full exhaustive list of frozen package==version@build nd_freeze from neurodebian-freeze assists in making use of that feature. I just stick it at the top of my Dockerfile/Singularity file recipes to make container itself as reproducible as possible, so later on I could add another component less likely affecting already existing ones. - wider arch support for extensions and non-python libraries/tools. ppc64el is gaining some momentum AFAIK in sci computing - better guarantees to achieve desired installation goal. examples of pip/conda failing to resolve depends are more numerous AFAIK. - integration and downstream testing at package build time and via https://ci.debian.net/ anyone who cares to not only "get it running" but have some assurance of correct operation (not junk-in-junk-out) should appreciate that. pypi has no concerns on that at all. conda is doing quite good job and does allow for some downstream testing. But it remains "more fluid", unlike a clear cut releases of debian with better guarantees for correct operation -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Need a Python 3.8 virtual environment
On Tue, 02 Mar 2021, Steven Robbins wrote: > Hi, > I'm trying to use a (non-Debian) python system built on python 3.8. Debian's > default is currently 3.9 so I am advised to use a virtual environment. > Being > a newbie, I searched around and found a writeup covering several different > virtualization tools [1]. Note I am using Debian 'sid'. I know that it is not a "proper" Debian answer, but in such cases I just quickly install miniconda with a needed python version. I keep a miniconda installation with conda environments for different Pythons for such cases. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')
FWIW those were reported "upstream" https://github.com/nipy/nipy/issues/466 unfortunately I had no time to look at them (again :-/) On Tue, 08 Dec 2020, Andreas Tille wrote: > Control: tags -1 pending > Control: tags -1 help > Hi, > I've updated nipy Git[1] to version 0.4.3~rc1 which solves the > originally reported issue. However, there are some remaining failures > in the build time test: -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: Build time test failures for seaborn 0.9 (Was: seaborn - update to 0.9 - where is debian folder on salsa?)
Quick one takes exactly 1 argument (0 given) suggests that bay be upstream switched from nose to pytest and started to use it's magical fixtures. Try using -m pytest instead of -m nose On January 22, 2019 2:35:50 PM EST, Andreas Tille wrote: >Hi, > >On Tue, Jan 22, 2019 at 08:03:22PM +0100, Andreas Tille wrote: >> >> > IgDiscover needs it in a version different from 0.8 to circumvent a >> > bug that the testing of their plot routine triggers >> > https://github.com/NBISweden/IgDiscover/issues/78. I somewhat >happily >> > address the update to 0.9. > >I tried to upgrade seaborn to version 0.9 in Git[1]. Unfortunately >the build time test suite throws a lot of errors: > > > debian/rules override_dh_auto_test >make[1]: Entering directory '/build/seaborn-0.9.0' >xvfb-run --auto-servernum --server-num=20 dh_auto_test >override_dh_auto_test >I: pybuild base:217: cd >/build/seaborn-0.9.0/.pybuild/cpython2_2.7_seaborn/build; python2.7 -m >nose -v. >Test that bootstrapping gives the right answer in dumb cases. ... ERROR >Test that we get a bootstrap array of the right shape. ... ERROR >... >== >ERROR: Test that bootstrapping gives the right answer in dumb cases. >-- >Traceback (most recent call last): >File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in >runTest >self.test(*self.arg) >TypeError: test_bootstrap() takes exactly 1 argument (0 given) > >> begin captured logging << >matplotlib: DEBUG: >$HOME=/build/seaborn-0.9.0/.pybuild/cpython2_2.7_seaborn >matplotlib: DEBUG: matplotlib data path /usr/share/matplotlib2/mpl-data >matplotlib: DEBUG: loaded rc file >/build/seaborn-0.9.0/build/matplotlibrc >matplotlib: DEBUG: matplotlib version 2.2.3 >matplotlib: DEBUG: interactive is False >matplotlib: DEBUG: platform is linux2 >matplotlib: DEBUG: loaded modules: ['email.MIMEAudio', >'numpy.core.info', 'nose.plugins.doctest', 'nose.plugins.tempfile', >'ctypes.os', 'hotshot.warnings', 'runpy', 'gc', 'pkg_resources >File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in >runTest >self.test(*self.arg) >TypeError: test_bootstrap() takes exactly 1 argument (0 given) > >> begin captured logging << >matplotlib: DEBUG: >$HOME=/build/seaborn-0.9.0/.pybuild/cpython2_2.7_seaborn >matplotlib: DEBUG: matplotlib data path /usr/share/matplotlib2/mpl-data >... >matplotlib.font_manager: DEBUG: createFontDict: >/usr/share/matplotlib2/mpl-data/fonts/afm/phvbo8an.afm >matplotlib.font_manager: DEBUG: createFontDict: >/usr/share/matplotlib2/mpl-data/fonts/pdfcorefonts/Courier-BoldOblique.afm >matplotlib.font_manager: INFO: generated new fontManager >matplotlib.backends: DEBUG: backend agg version v2.2 >- >> end captured logging << - > >== >ERROR: Test that we get a bootstrap array of the right shape. >-- >Traceback (most recent call last): >File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in >runTest >self.test(*self.arg) >TypeError: test_bootstrap_length() takes exactly 1 argument (0 given) > >== >ERROR: Test that boostrapping a random array stays within the right >range. >-- >Traceback (most recent call last): >File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in >runTest >self.test(*self.arg) >TypeError: test_bootstrap_range() takes exactly 1 argument (0 given) >... >== >FAIL: >seaborn.tests.test_regression.TestRegressionPlots.test_three_point_colors >-- >Traceback (most recent call last): >File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in >runTest >self.test(*self.arg) >File >"/build/seaborn-0.9.0/.pybuild/cpython2_2.7_seaborn/build/seaborn/tests/test_regression.py", >line 589, in test_three_point_colors >(1, 0, 0)) >File >"/usr/lib/python2.7/dist-packages/numpy/testing/_private/utils.py", >line 568, in assert_almost_equal >return assert_array_almost_equal(actual, desired, decimal, err_msg) >File >"/usr/lib/python2.7/dist-packages/numpy/testing/_private/utils.py", >line 980, in assert_array_almost_equal >precision=decimal) >File >"/usr/lib/python2.7/dist-packages/numpy/testing/_private/utils.py", >line 796, in assert_array_compare >raise AssertionError(msg) >AssertionError:. >Arrays are not almost equal to 7 decimals > >(mismatch 100.0%) > x: array([0.4 , 0.7607843, 0.6470588]) > y: array([1, 0, 0]) > >-
Re: Bug#909990: Stange import error for nibabel when trying to import from .pybuild
Thank you Andreas for looking into it 2.3.1 bugfix is around the corner https://github.com/nipy/nibabel/pull/667 so I will aim to make sure the #909990 is fixed within it (for starters - I do not think I observed this exception when building from current RC branch) On Mon, 08 Oct 2018, Andreas Tille wrote: > Hi, > to see what I can do about bug #909990 I've imported the latest version > into the packaging Git[1]. When beeing inside the main dir of the Git > repository I can easily do > neurodebian-team/pynifti(debian) $ python3 > Python 3.6.6 (default, Jun 27 2018, 14:44:17) > [GCC 8.1.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import nibabel > However, if I try inside the .pybuild dir I get: > /build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build# python3.6 > Python 3.6.7rc1 (default, Sep 27 2018, 09:51:25) > [GCC 8.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import nibabel > Traceback (most recent call last): > File "", line 1, in > File > "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/__init__.py", > line 45, in > from .loadsave import load, save > File > "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/loadsave.py", > line 18, in > from .imageclasses import all_image_classes > File > "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/imageclasses.py", > line 16, in > from .minc1 import Minc1Image > File > "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/minc1.py", > line 20, in > from .deprecated import FutureWarningMixin > ImportError: cannot import name 'FutureWarningMixin' -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: How to disable tests for Python2 only?
On Mon, 10 Sep 2018, Andreas Tille wrote: > On Mon, Sep 10, 2018 at 10:54:02AM -0400, Yaroslav Halchenko wrote: > > Outstanding few issues so far are reported/dealt with upstream: > > https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker > > updating packaging is in debian-0.20 branch at > > http://github.com/yarikoptic/scikit-learn > ... sorry to repeat myself but having team maintained packages on > github is not inviting to others. Is there any reason not to > use Salsa? yeap, let's make a repo on salsa. Would you be ok to retain my weird "based on upstream git" setup? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: How to disable tests for Python2 only?
On Mon, 10 Sep 2018, Andrey Rahmatullin wrote: > On Mon, Sep 10, 2018 at 04:33:21PM +0200, Andreas Tille wrote: > > Hi, > > looking at the bug log of scikit-learn[1] it seems to be a simple means to > > do > > --- a/debian/control > > +++ b/debian/control > > @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, > > python3-pytest, > > python3-matplotlib, > > python3-joblib (>= 0.9.2), > > + python3-distributed , > > libsvm-dev (>= 2.84.0), > > libatlas3-base, > > Build-Depends-Indep: > I don't think that's how build profiles work. > > However, it seems that due to the fact that this package uses > > --buildsystem=python_distutils > Which is already a problem, as it doesn't support py3. > There is a lot of strange hacks in this rules file. I'm especially > interested in "dh_autoreconf debian/rules -- clean_generated" but that's a > question for another discussion. many hacks might be left overs for historical (age of the package) + backports (hence cythonize rule, allows to provide backports for older debian/ubuntu via neurodebian) reason. Would be nice to review/remove those no longer needed, but attention should be taken care not to break backportability. So far built/tested fine even for jessie (8) and ubuntu xenial (16.04). > > Are there any other ways to exclude some tests for Python2 to make this > > package build again? > rules call nosetests directly so I guess find out how to do that with > nosetests. overall, as I've just noted in the bugreport, I think it is better to concentrate on making upcoming 0.20 (will use pytest not nose among other things) into debian. Outstanding few issues so far are reported/dealt with upstream: https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker updating packaging is in debian-0.20 branch at http://github.com/yarikoptic/scikit-learn -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way
Fwiw asciinema is quite handy! We use it for our demos (generate them automatically from our *cast scripts, along with possible narrated videos, actual scripts, or just interactive demonstrations where people get blown away at "my" typing speed/stability), see eg those asciinemas at http://datalad.org/for/reproducible-science So I would appreciate if someone takes care about this valuable package... if there would be nobody, please buzz me, I will keep it afloat Cheers On July 18, 2018 7:48:56 PM EDT, gustavo panizzo wrote: >Hi >On Thu, Jul 19, 2018 at 12:06:58AM +0200, Hilmar Preuße wrote: >>Am 18.07.2018 um 21:55 teilte gustavo panizzo mit: >> >>Hi Gustavo, >> >>>Forget screen recording apps and blurry video. Enjoy a lightweight, >>>purely text based approach to terminal recording. >>>This package provides a command line recorder for asciinema.org >>>service or other instance of asciinema server. >>> >>At first the dumb question: what main features does this application >>have, I can't find in script [1]? Well, except the upload feature. > >the playback always works, this was my motivation to use (and package) >asciinema, since it does not depend on what console do you use to play >it back it always works (and people with windows can play the >recordings) >when i started with it, we used asciinema and an internal server to >record trainings and play them back to students > > >but i changed jobs and stop using it some time ago, that's why RFA >> >>Thanks! >> >>H. >> >>[1] http://man.openbsd.org/script.1 >>-- >>#206401 http://counter.li.org -- Sent from a phone which beats iPhone.
Re: pybuilder help -- why no python3- pkg proper build/tests?
On Tue, 05 Jun 2018, Andrey Rahmatullin wrote: > On Mon, Jun 04, 2018 at 03:38:09PM -0400, Yaroslav Halchenko wrote: > > I am trying to make our DataLad package to be bi-python finally, but I > > cannot make pybuilder > It's "pybuild". yeah ;-) > > neither populate python3-datalad package, nor > > to run tests (using nose) during the build against python3 (runs only > > against python2). > It doesn't work with py3 because you B-D only on py2 packages. "и на старуху бывает проруха" Thank you Andrey! -- I will give it a shot right away. I would've expected some info or error message though (since I do request python3 explicitly in the call to dh), although may be it is there and I've missed it. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik signature.asc Description: PGP signature
pybuilder help -- why no python3- pkg proper build/tests?
Dear Debian Pythonistas, I am trying to make our DataLad package to be bi-python finally, but I cannot make pybuilder neither populate python3-datalad package, nor to run tests (using nose) during the build against python3 (runs only against python2). It does invoke dh_python3 at the end though... Here is my current (trimmed, temp state) version of packaging (rules/control): https://github.com/yarikoptic/datalad/blob/debian/debian/rules https://github.com/yarikoptic/datalad/blob/debian/debian/control and a sample build log: http://www.onerussian.com/tmp/datalad_0.10.0~rc4+git167-g88f3ea8f-1_amd64.build I am probably missing something obvious -- please help me see it ;-) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: setup.py sdist permissions
On Wed, 04 Apr 2018, Brian May wrote: > Hello, > As an upstream maintainer of certain packages on pypi, it has come to my > attention that my packages have files in the source package with > permission 600 or 700 (and my owner and group). This is most likely > because my umask is set to 077, because in general I prefer not having > all my private files world/group readable. > * Is this actually a problem for users? > * Shouldn't sdist be ignoring my umask considering it is generating > packages for public consumption? > It seems like the only known solution is to manually set umask to 022 > before calling sdist, something I am likely to forgot to do on a > continued basis. > Any ideas? just anecdotal support: my umask is 077 as well, have been doing uploads to pypi for a while, never had report from the users about any problem. The reasons could be either it indeed doesn't matter or nobody uses my projects ;-) Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: If there is no response in debian-python then debian-science might be the right team (Was: Packaging python-aws-xray-sdk to fullfil a dependency for python-moto)
I don't mind helping to maintain it under any of those teams. Thank you Andreas for taking care about this new dependency. I will look into updating pandas package On January 15, 2018 3:37:53 AM EST, Andreas Tille wrote: >Hi again, > >is it correct to assume that Debian Python Modules Team do not want to >see this precondition for a scientific oriented package in its scope >and >I should move it to Debian Science? > >Kind regards > > Andreas. > >On Fri, Jan 12, 2018 at 05:01:53PM +0100, Andreas Tille wrote: >> Hi, >> >> the Debian Science team needs to update python-pandas sooner or later >> and the new version of pandas needs python-moto. I had a look into >this >> and realised it needs python-aws-xray-sdk[1]. I've created a local >Git >> packaging repository which I would like to push to salsa.debian.org >since >> I'm stumbling about issues I need some help for. >> >> I think Debian Python team would be a good team for this package >since >> it is not really science related. Is this OK to push the package >into >> Debian Python team repository? If yes did you start the migration to >> salsa.debian.org? Otherwise I could push it to alioth but may be its >> better if not so many projects end up there once the migration will >be >> done. >> >> Kind regards >> >>Andreas. >> >> [1] https://github.com/aws/aws-xray-sdk-python >> >> -- >> http://fam-tille.de >> >> -- Sent from a phone which beats iPhone.
Re: skimage (was: Re: Bug#729956: Python 3 Statsmodels & Pandas)
On Tue, 10 Oct 2017, Yuri D'Elia wrote: > On Sat, Sep 16 2017, Yuri D'Elia wrote: > > Looking at python3-skimage-lib (which also requires a rebuild), it seems > > that the package failed to pass some tests. > > Bug #868582 even includes a patch to update to 0.13 [and disables some > > test failures]. > Has anyone had a chance to look at skimage btw? my bad will look into updating skimage now. thanks for the buzz -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: pycharm package in debian
Fwiw I have made a pycharm-community-sloppy package available from NeuroDebian - just wrapped their distribution. Btw seems to work with open jdk just fine. Packaging for Debian proper would need some Java verse maintainer. On September 30, 2017 8:22:56 AM EDT, kamaraju kusumanchi wrote: >Are there any plans to make a debian package of pycharm that is part >of official debian? I used their community edition on windows 7 and it >is awesome. > >thanks -- Sent from a phone which beats iPhone.
Re: Python 3 Statsmodels & Pandas
Thanks for digging into this and sorry I have missed that. I typically add export http*_proxy to prevent any network interactions but I guess didn't get that far with statsmodels. FWIW, for dipy package I now ask upstream to provide me e.g. dipy_0.12.0.orig-doc-examples.tar.gz where there are examples, which require lengthy computation to produce doc pieces To resolve this issue quickly, I might have also simply patched/excluded those examples/docs which require external datasets (especially with incompatible terms), from building. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Sun, 24 Sep 2017, Andreas Tille wrote: > Hi Yaroslav, > On Sat, Sep 23, 2017 at 10:00:35AM -0400, Yaroslav Halchenko wrote: > > > I would prefer to move pandas to Debian Science or Debian Python. I > > > fail to see the specific use in NeuroDebian field. > > I ould repeat that I don't mind having it moved under -science or > > -python teams maintenance. But it shouldn't make it more difficult for > > me to maintain it. > Thanks for the permission to move the package. Could you please be more > verbose what exactly might make your maintenance more difficult? Its > about changing Vcs-Fields and Maintainer field - is this in some way > making things harder for you? nah, VCS field(s) is a non issue. making package non-backportable automatically, introducing new patch management mechanisms (dpq or whatnot) which I am not too familiar with -- such things could make things more difficult. If just a matter of moving a repository -- that is all ok as long as I know where to find a new one and could contribute ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Sun, 24 Sep 2017, Andreas Tille wrote: > On Sun, Sep 24, 2017 at 11:24:10AM -0700, Diane Trout wrote: > > Status with statsmodels almost done > > Trying to deal with jquery. > > leaving command > > -rm ./build/html/_static/jquery.js > > causes a build failure now. > Without checking the source: I'm usually doing something like > override_dh_install: > dh_install > find debian -name jquery.js -delete > This should avoid build failures. FTR not sure how that could have caused a build failure since leading '-' in makefile means "ignore the failure" -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Fri, 22 Sep 2017, Andreas Tille wrote: > > diff -Nru pandas-0.20.3/debian/changelog pandas-0.20.3/debian/changelog > > --- pandas-0.20.3/debian/changelog 2017-07-10 20:00:59.0 -0400 > > +++ pandas-0.20.3/debian/changelog 2017-09-21 16:11:29.0 -0400 > > @@ -1,3 +1,14 @@ > > +pandas (0.20.3-2) unstable; urgency=medium > > + > > + * debian/control > > +- boosted policy to 4.0.0 (I think we should be ok) > Current is 4.1.0 (despite lintian claims 4.0.0) yeap, noted > > I could also add you to pkg-exppsy team under which we still have the > > "active" > > vcs for pandas. > I would prefer to move pandas to Debian Science or Debian Python. I > fail to see the specific use in NeuroDebian field. I ould repeat that I don't mind having it moved under -science or -python teams maintenance. But it shouldn't make it more difficult for me to maintain it. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Fri, 22 Sep 2017, Piotr Ożarowski wrote: > [Diane Trout, 2017-09-21] > > I made larger changes to statsmodels, by using pybuild instead of the > > previous multiple targets in debian/rules. > you can simplify it even further by using pybuild's --ext-dest-dir: > (I didn't test as this branch FTBFS for me) how recent is that feature? one of the concerns of mine to be paid attention to is being able to easily backport this package for older debian/ubuntus (we could patch, by per-release patching is somewhat tedious) for the upload to NeuroDebian. Current state of things (I will now upload that fresh -2 build now for where it built) is at http://neuro.debian.net/pkgs/python-pandas.html -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Thu, 21 Sep 2017, Diane Trout wrote: > On Thu, 2017-09-21 at 17:56 -0400, Yaroslav Halchenko wrote: > > If you could allow to review would be great. > > Thanks for all the work. > > I was btw also trying to build with the patch you shared yesterday > Once I have all the changes for pandas would you like me to put them on > a branch on alioth? Or should I send them via format-patch somewhere? I could work with either. I will upload now -2 (sorry if we duplicated some efforts) with following changes (diff for changelog): diff -Nru pandas-0.20.3/debian/changelog pandas-0.20.3/debian/changelog --- pandas-0.20.3/debian/changelog 2017-07-10 20:00:59.0 -0400 +++ pandas-0.20.3/debian/changelog 2017-09-21 16:11:29.0 -0400 @@ -1,3 +1,14 @@ +pandas (0.20.3-2) unstable; urgency=medium + + * debian/control +- boosted policy to 4.0.0 (I think we should be ok) +- drop statsmodels from build-depends to altogether avoid the circular + build-depends (Closes: #875805) + * Diane Trout: +- Add dateutil-2.6.1-fixed-ambiguous-tz-dst-be.patch (Closes: #875807) + + -- Yaroslav Halchenko Thu, 21 Sep 2017 16:11:29 -0400 I could also add you to pkg-exppsy team under which we still have the "active" vcs for pandas. > Also it looked to me like you were changing debian/changelog with each > change? (Some people just use the git log and then apply all the > updates to d/changelog in one go with git buildpackage. I prefer indeed reflecting each change in a changelog with a commit and using debcommit to commit it ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
If you could allow to review would be great. Thanks for all the work. I was btw also trying to build with the patch you shared yesterday On September 21, 2017 5:48:58 PM EDT, Diane Trout wrote: > >> If my poor opinion counts: For the moment we should run those tests >> in >> the build process than can be easily be run. Everything else should >> probably be sorted out later (in autopkgtest or another later upload >> if >> somebody has a clue how we can solve the circular depenendecies). >> >> We somehow need to get some working spatstats to continue with other >> packages. >> > >Status: > >[X] Pandas builds with nocheck, nodoc >[X] Statsmodels builds with Python 3 using above pandas >[X] Pandas tests pass with statsmodels for Python 2 & 3 installed. >[ ] Pandas builds docs with statsmodels installed > >My most recent build error was about pandoc not being available. > >Unfortunately the tests take a long time enough that I can write this >email before I know if adding pandoc fixed the problem. > >dh_auto_tests run Python 2.7, 3.5, 3.6 tests, and then autopkgtests >runs them again. > >I posted the larger fixes to pandas I've done to the appropriate bugs > >#875807 python3-pandas FTBFS: 3 timezone unit tests fail >#875805 python3-pandas: Please break circular dependency > >There's a few more minor patches on my laptop that I haven't attached >to a bug for pandas. > >* Updating standards version >* using debhelper 10 >* switching sphinx doc build to use python3 >* and deleting a few more build files in dh_clean target. > >I made larger changes to statsmodels, by using pybuild instead of the >previous multiple targets in debian/rules. > >All of those changes are currently on alioth in detrout-python3. > >When all these tests pass, shall I add myself to uploaders and release? >or does someone else want to review first? > >Diane -- Sent from a phone which beats iPhone.
Re: python3 statsmodels?
On Tue, 20 Jun 2017, Sandro Tosi wrote: > On Tue, Jun 20, 2017 at 12:18 AM, kamaraju kusumanchi > wrote: > > I see that there is no statsmodels package for python3 in Stretch. > > % apt-cache search statsmodels python3 > > python3-seaborn - statistical visualization library > statsmodels is maintained by Debian science team > (https://tracker.debian.org/pkg/statsmodels) so i suggest to contact > them directly (CCed them here) yeap -- would be lovely to have python3 build... debian/rules is quite ad-hoc/elaborate but somewhat inline with how things are done for pandas as well... I might look into it at some point (but not within upcoming 2 weeks) but would even more appreciate help from the team mates or outside contributors ;) Cheers -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Bug#846228: Random FTBFS failures of joblib and what about team maintenance
As for this particular issue -- I think I have complained upstream and it was addressed: https://github.com/joblib/joblib/issues/428 I will now see to build/upload current upstream snapshot -- codebase seems largely in maintenance mode ATM On Wed, 07 Dec 2016, Andreas Tille wrote: > Hi Yaroslav, > I just want to make some noise amongst Python experts about bug #846228. > I admit I have no idea - but since there was no response for 10 days now > several packages git a testing removal notice. > I think python-joblib has several rdepends and thus it would IMHO be > better maintained in DPMT than in a private Github repository. What > do you think? > Kind regards > Andreas. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Random FTBFS failures of joblib and what about team maintenance
On December 7, 2016 6:09:56 AM EST, Andreas Tille wrote: >Hi Yaroslav, > >I just want to make some noise amongst Python experts about bug >#846228. >I admit I have no idea - but since there was no response for 10 days >now >several packages git a testing removal notice. > >I think python-joblib has several rdepends and thus it would IMHO be >better maintained in DPMT than in a private Github repository. What >do you think? > >Kind regards > > Andreas. I don't mind - anyone interested helping to move? Do you have a patch in mind by any chance for this specific issue?
JOB: for a Debian Pythonista to work with others alike
Hi All, Hopefully you wouldn't throw way too many stones for such an OT, but I thought to ask since the audience is right! ;) if you are looking for a job ATM, there might be the one for you within NSF-supported DataLad project at Dartmouth College, NH, USA, working with DDs like yours truly, Michael Hanke, and the legendary Joey Hess. More info and where/how to apply: https://searchjobs.dartmouth.edu/postings/36530 Feel free to email me with any question Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Autopkgtest smoke test for Python libraries
On Wed, 02 Mar 2016, Ben Finney wrote: > This belongs IMO in an existing “build Debian packages for Python” tool. > As it stands, I'll need to manually add a bundle of files to every > Python package I maintain. > Who can recommend a way to make this a more automated part of the Debian > Python package build workflow? sorry if I came late to the discussion and missing the point, but pybuild/dh-python already has some tests discovery mechanisms and runs the tests if finds them while allowing for fine-tuning via its options. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Bug#798999: transition: python3.5 supported
On Sat, 26 Sep 2015, Scott Kitterman wrote: > > On Thu, Sep 24, 2015 at 22:19:20 -0400, Scott Kitterman wrote: > > > I have the python3-defaults upload to enable python3.5 as a supported > > > python3 version prepared and ready to upload when I get an ack from the > > > release team. > > ack. > > Cheers, > > Julien > Thanks. I've uploaded python3-defaults, so once it's built/installed > python3.5 is supported. is round of binNMUs scheduled already? since now nothing depending on python3-numpy at build time would build: # python3.5 -c 'import numpy' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 170, in from . import add_newdocs File "/usr/lib/python3/dist-packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/usr/lib/python3/dist-packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/usr/lib/python3/dist-packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 6, in from . import multiarray ImportError: cannot import name 'multiarray' -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: pybuild and proxies -- could we make "prohibition" optional?
On Wed, 22 Jul 2015, Piotr Ożarowski wrote: > [Yaroslav Halchenko, 2015-07-21] > > As I have mentioned some tools might not be smart about empty values > > in http_proxy, try e.g. git-annex under such settings > ah, sorry, I only quickly scanned you email. > I already followed Dimitri's suggestion to add no_proxy=localhost and > will add your PYBUILD_FAKE_PROXY later today awesome! feel free to tune the name to whatever you feel more appropriate. Just an additional piece of support to allow simply disabling automatic assignment of fake proxies and that no_proxy doesn't work for some libs/packages: Daniel Stender tried export no_proxy=localhost on pytest-tornado without success. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20150722134501.gq28...@onerussian.com
Re: pybuild and proxies -- could we make "prohibition" optional?
As I have mentioned some tools might not be smart about empty values in http_proxy, try e.g. git-annex under such settings On July 21, 2015 4:16:11 PM EDT, "Piotr Ożarowski" wrote: >> So, long story short... would it be ok if I propose/commit a change >like > >no need, if you want to disable it, just set https_proxy to empty >string > >f.e. if you want to enable it only in tests: > > override_dh_auto_test: >http_proxy='' dh_auto_test >-- >Piotr Ożarowski Debian GNU/Linux Developer >www.ozarowski.pl www.griffith.cc www.debian.org >GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- Sent from a phone which beats iPhone.
pybuild and proxies -- could we make "prohibition" optional?
talking about this ;-) :
$> grep -A3 http_proxy pybuild
if 'http_proxy' not in env:
env['http_proxy'] = 'http://127.0.0.1:9/'
if 'https_proxy' not in env:
env['https_proxy'] = 'https://127.0.0.1:9/'
which is overall GREAT since now I can drop off all those manual http*_proxy
exports in debian/rules where I know that the application has nothing to do
with the network. BUT such settings forbid e.g. running any tests even if
those start/use local server specifically initiated for testing. This is not
forbidden AFAIK by the policy and the only concern is our buildd farm which
says that even local interface might not be available. Some
tools/libraries are smart enough to not try accessing proxy if http_proxy is
set but empty, but some don't.
So, long story short... would it be ok if I propose/commit a change like
diff --git a/pybuild b/pybuild
index d7bd35a..4edc175 100755
--- a/pybuild
+++ b/pybuild
@@ -50,10 +50,12 @@ def main(cfg):
env = environ.copy()
if 'LC_ALL' not in env:
env['LC_ALL'] = 'C.UTF-8'
-if 'http_proxy' not in env:
-env['http_proxy'] = 'http://127.0.0.1:9/'
-if 'https_proxy' not in env:
-env['https_proxy'] = 'https://127.0.0.1:9/'
+
+if environ.get('PYBUILD_FAKE_PROXY', '1') == '1':
+if 'http_proxy' not in env:
+env['http_proxy'] = 'http://127.0.0.1:9/'
+if 'https_proxy' not in env:
+env['https_proxy'] = 'https://127.0.0.1:9/'
if cfg.system:
certainty = 99
to enable testing when it is feasible to do it without external interactions
etc?
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20150721191750.ga24...@onerussian.com
Re: Sphinx 1.3 in Debian experimental
On Thu, 07 May 2015, Dmitry Shachnev wrote: > > so -- there is quite a few of new FTBFS. I will report more whenever it is > > done > Thanks a lot for running the rebuild! > How can I access the build logs? The files given in that table are not > available via HTTP on that server. yeah, sorry -- I will upload whenever they all are done, ok? > I will look at the logs and file bugs for those that are real issues and > not bugs in Sphinx itself. > Don't know when I have time for that, but I hope I'll be able to do that > this week. hopefully it would be done by then ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20150507142102.gb17...@onerussian.com
Re: Sphinx 1.3 in Debian experimental
On Sun, 03 May 2015, Dmitry Shachnev wrote: > Hi all, > I have finally managed to finalize Sphinx 1.3 upload for experimental. > There are many new features and some incompatible changes, please see the > changelog [1] for the full list of changes. > If your package has Sphinx documentation, please test it with the new > version and make sure it builds and works fine. I am going to do a mass > rebuild at some point and file bugs for packages that FTBFS. Hi Dmitry, thanks for maintaining sphinx and for uploading 1.3!!! I am not sure if you got time to do rebuild but meanwhile I ran it on my box... runs serially and box is getting aged so it is still running but here is a current summary of things: http://www.onerussian.com/tmp/sphinx_1.3.1-1_amd64.testrdepends.debian-sid.summary first column is for a build with prev version of sphinx in sid and the last one with status of build and pointer to log if failed so -- there is quite a few of new FTBFS. I will report more whenever it is done Cheers! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20150506235540.go17...@onerussian.com
Re: who is going to PyCon?
On Fri, 03 Apr 2015, Paul Tagliamonte wrote: > I'll be there On Fri, Apr 3, 2015 at 2:02 PM, Barry Warsaw wrote: > I'll be there for the whole ball of wax. We should have a Debian Python BOF. > Maybe we can talk about big plans for Stretch. great! yeah -- we can find topics to talk about! ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20150403184209.gp29...@onerussian.com
who is going to PyCon?
Just wondered -- I will be there for the duration of the main conference (from Thu till Sun). I would be pleased to hangout/lunch/chat at some point(s) together with other Debian Python folks! Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20150403175532.go29...@onerussian.com
Re: Could you take over my package Kivy?
On Sun, 09 Nov 2014, Bastian Venthur wrote:
> I'm currently unable to maintain the kivy package properly, as I am
> busy writing my Ph.D. Could I kindly ask you to take over this package?
> https://packages.qa.debian.org/k/kivy.html
I would not be able to take over and/or spend more time on migration, but I
am preparing upload addressing those fixes necessary for compatibility
with cython 0.21.1-1 and could request unblock
would it be ok meanwhile if I upload the NMU without delay?
PS good luck with the dissertation
here is the debdiff
diff -Nru kivy-1.8.0+dfsg/debian/changelog kivy-1.8.0+dfsg/debian/changelog
--- kivy-1.8.0+dfsg/debian/changelog2014-02-28 03:48:43.0 -0500
+++ kivy-1.8.0+dfsg/debian/changelog2014-11-09 10:23:02.0 -0500
@@ -1,3 +1,12 @@
+kivy (1.8.0+dfsg-2.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fixing FTBFS against cythoin 0.21.1 by cherry-picking upstream fix
+debian/patches/0001-Fix-cython-python-temp-coercion-exception.patch
+(Closes: #768828)
+
+ -- Yaroslav Halchenko Sun, 09 Nov 2014 10:11:22 -0500
+
kivy (1.8.0+dfsg-2) unstable; urgency=medium
* Provide python3-kivy package. The patch for that was provided by Vincent
diff -Nru
kivy-1.8.0+dfsg/debian/patches/0001-Fix-cython-python-temp-coercion-exception.patch
kivy-1.8.0+dfsg/debian/patches/0001-Fix-cython-python-temp-coercion-exception.patch
---
kivy-1.8.0+dfsg/debian/patches/0001-Fix-cython-python-temp-coercion-exception.patch
1969-12-31 19:00:00.0 -0500
+++
kivy-1.8.0+dfsg/debian/patches/0001-Fix-cython-python-temp-coercion-exception.patch
2014-11-09 10:16:01.0 -0500
@@ -0,0 +1,34 @@
+From 827bd6c7b7d04ec72cb3bdbf0ffcd90630d90008 Mon Sep 17 00:00:00 2001
+From: Matthew Einhorn
+Date: Thu, 17 Jul 2014 16:37:42 -0400
+Subject: [PATCH] Fix cython 'python temp coercion' exception.
+
+---
+ kivy/graphics/shader.pyx | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/kivy/graphics/shader.pyx b/kivy/graphics/shader.pyx
+index eab0f42..39c449a 100644
+--- a/kivy/graphics/shader.pyx
b/kivy/graphics/shader.pyx
+@@ -421,6 +421,7 @@ cdef class Shader:
+ cdef void bind_vertex_format(self, VertexFormat vertex_format):
+ cdef unsigned int i
+ cdef vertex_attr_t *attr
++cdef bytes name
+
+ # if the current vertex format used in the shader is the current one,
do
+ # nothing.
+@@ -445,7 +446,8 @@ cdef class Shader:
+ attr = &vertex_format.vattr[i]
+ if attr.per_vertex == 0:
+ continue
+-attr.index = glGetAttribLocation(self.program, attr.name)
++name = attr.name
++attr.index = glGetAttribLocation(self.program, name)
+ glEnableVertexAttribArray(attr.index)
+
+ # save for the next run.
+--
+2.1.1
+
diff -Nru kivy-1.8.0+dfsg/debian/patches/0001-Fixes-for-Cython-0.21.patch
kivy-1.8.0+dfsg/debian/patches/0001-Fixes-for-Cython-0.21.patch
--- kivy-1.8.0+dfsg/debian/patches/0001-Fixes-for-Cython-0.21.patch 1969-12-31
19:00:00.0 -0500
+++ kivy-1.8.0+dfsg/debian/patches/0001-Fixes-for-Cython-0.21.patch 2014-11-09
10:36:13.0 -0500
@@ -0,0 +1,36 @@
+From 90ddebab3f56c06175dd99b153383990434b9514 Mon Sep 17 00:00:00 2001
+From: Mathieu Virbel
+Date: Tue, 16 Sep 2014 10:11:23 +0200
+Subject: [PATCH] Fixes for Cython 0.21
+
+---
+ kivy/lib/gstplayer/_gstplayer.pyx | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/kivy/lib/gstplayer/_gstplayer.pyx
b/kivy/lib/gstplayer/_gstplayer.pyx
+index f07af0b..aa29c11 100644
+--- a/kivy/lib/gstplayer/_gstplayer.pyx
b/kivy/lib/gstplayer/_gstplayer.pyx
+@@ -207,7 +207,7 @@ cdef class GstPlayer:
+ self.eos_cb()
+
+ def load(self):
+-cdef char *c_uri
++cdef bytes py_uri
+
+ # if already loaded before, clean everything.
+ if self.pipeline != NULL:
+@@ -256,8 +256,8 @@ cdef class GstPlayer:
+
+ # configure playbin
+ g_object_set_int(self.pipeline, 'async-handling', 1)
+-c_uri = self.uri.encode('utf-8')
+-g_object_set_void(self.playbin, 'uri', c_uri)
++py_uri = self.uri.encode('utf-8')
++g_object_set_void(self.playbin, 'uri', py_uri)
+
+ # attach the callback
+ # NOTE no need to create a weakref here, as we manage to grab/release
+--
+2.1.1
+
diff -Nru kivy-1.8.0+dfsg/debian/patches/series
kivy-1.8.0+dfsg/debian/patches/series
--- kivy-1.8.0+dfsg/debian/patches/series 2014-02-28 03:38:07.0 -0500
+++ kivy-1.8.0+dfsg/debian/patches/series 2014-11-09 10:36:42.0 -0500
@@ -0,0 +1,2 @@
+0001-Fix-cython-python-temp-coercion-exception.patch
+0001-Fixes-for-Cython-0.21.patch
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research
Re: Trying to build python3 version of scikit-learn, python3-* pkgs come out empty
That is great... eventually I would switch. I am still providing backports for supported debian ubuntu releases through NeuroDebian, so I would need compatible version of pybuild for those releases. Pandas though might switch earlier since they started to demand recentish numpy, so backports aren't possible anyways. On November 5, 2014 4:48:27 PM EST, "Piotr Ożarowski" wrote: >[Yaroslav Halchenko, 2014-11-05] >> I would recommend to look into rules of pandas package where I with >> Julian's initiative have somewhat "harmonized" (although it is >> still quite ugly) building both python2 and python3 with moving .so >to >> -lib packages . > >pybuild can do that for you (--ext-dest-dir or >PYBUILD_EXT_DEST_DIR_python2 and PYBUILD_EXT_DEST_DIR_python3) -- Sent from a phone which beats iPhone. -- 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/35f7bc5f-be8f-499e-a839-0bcca5240...@email.android.com
Re: Trying to build python3 version of scikit-learn, python3-* pkgs come out empty
I would recommend to look into rules of pandas package where I with
Julian's initiative have somewhat "harmonized" (although it is
still quite ugly) building both python2 and python3 with moving .so to
-lib packages .
I know that MDP's author is also eager to get python3-sklearn package so
it would be great if you join the effort... changes -- better send as a
PR against git://github.com/yarikoptic/scikit-learn.git -- would be
easier to review/merge
cheers!
On Tue, 04 Nov 2014, Zack Weinberg wrote:
> The scikit-learn packaging only builds python2 packages, even though
> upstream does support python3 (this is bug #730532). I happen to need
> scikit with python3 so I tried to update the packaging using the
> instructions at https://wiki.debian.org/Python/Pybuild , but I
> consistently get a python3-sklearn package containing only
> /usr/share/doc. Can anyone suggest what I might have done wrong? In
> the build log, it appears that pybuild did build both v2 and v3
> versions of the software, but then only v2 got copied into appropriate
> subdirectories of debian/ to be picked up by dpkg-deb.
> I'm attaching my modified debian/control and debian/rules. I already
> know that commenting out the override_dh_python2 block broke something
> *else* -- that's not the immediate problem.
> zw
> [-- octet-filter file type: "ASCII text" --]
> Source: scikit-learn
> Section: python
> Priority: optional
> Maintainer: NeuroDebian Team
> Uploaders: Yaroslav Halchenko , Michael Hanke
>
> Build-Depends: debhelper (>= 8), dh-autoreconf, dh-python,
>python-all-dev (>= 2.6.6-3~),
>python3-all-dev (>= 3.4),
>cython (>= 0.12~),
>python-setuptools,
>python3-setuptools,
>python-numpy, python-scipy,
>python3-numpy, python3-scipy,
>libsvm-dev (>= 2.84.0),
>python-nose, python-matplotlib, python-joblib (>= 0.4.5),
>python3-nose, python3-matplotlib, python3-joblib (>= 0.4.5),
>gfortran, libatlas3-base, libatlas-dev, libblas-dev,
> liblapack-dev
> Build-Depends-Indep:
>python-sphinx (>= 1.0), python-imaging, graphviz,
> Standards-Version: 3.9.4
> X-Python-Version: >= 2.6
> X-Python3-Version: >= 3.4
> Homepage: http://scikit-learn.sourceforge.net
> Vcs-Browser: http://github.com/yarikoptic/scikit-learn
> Vcs-Git: git://github.com/yarikoptic/scikit-learn.git
> Package: python-sklearn
> Replaces: python-scikits-learn (<< 0.9~)
> Breaks: python-scikits-learn (<< 0.9~)
> Architecture: all
> Depends: ${misc:Depends}, ${python:Depends}, python-numpy, python-scipy,
> python-sklearn-lib(>= ${source:Version}),
> python-joblib (>= 0.4.5),
> Provides: ${python:Provides}
> Recommends: python-nose, python-matplotlib
> Suggests: python-dap, python-scikits-optimization, python-sklearn-doc, ipython
> Enhances: python-mvpa2, python-mdp
> Description: Python modules for machine learning and data mining
> scikit-learn is a collection of Python modules relevant to
> machine/statistical learning and data mining. Non-exhaustive list of
> included functionality:
> - Gaussian Mixture Models
> - Manifold learning
> - kNN
> - SVM (via LIBSVM)
> .
> This is the Python 2 version.
> Package: python3-sklearn
> Architecture: all
> Depends: ${misc:Depends}, ${python3:Depends}, python3-numpy, python3-scipy,
> python3-sklearn-lib(>= ${source:Version}),
> python3-joblib (>= 0.4.5),
> Provides: ${python3:Provides}
> Recommends: python3-nose, python3-matplotlib
> Suggests: python3-dap, python3-scikits-optimization, python3-sklearn-doc,
> ipython
> Enhances: python3-mvpa2, python3-mdp
> Description: Python modules for machine learning and data mining
> scikit-learn is a collection of Python modules relevant to
> machine/statistical learning and data mining. Non-exhaustive list of
> included functionality:
> - Gaussian Mixture Models
> - Manifold learning
> - kNN
> - SVM (via LIBSVM)
> .
> This is the Python 3 version.
> Package: python-sklearn-doc
> Conflicts: python-scikits-learn-doc
> Replaces: python-scikits-learn-doc
> Architecture: all
> Section: doc
> Depends: ${misc:Depends}, libjs-jquery
> Suggests: python-sklearn, python3-sklearn
> Description: documentation and examples for scikit-learn
> This package contains documentation and example scripts for
> python-sklearn.
> Package: python-sklearn-lib
> Conflicts: python-scikits-learn-lib
> Replaces: python-scikits-learn-lib
> Architecture: any
> Depends: ${misc:Depends}, ${shlibs:De
Re: Preventing network access during nose doctest ?
On Mon, 12 May 2014, Olivier Berger wrote:
> 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.
should work AFAICT:
$> python -c '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.
$> http_proxy=http://127.0.0.1:9/ python -c '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))'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/rdflib/Graph.py", line 886, in parse
source = self.prepare_input_source(source, publicID)
File "/usr/lib/python2.7/dist-packages/rdflib/Graph.py", line 692, in
prepare_input_source
input_source = URLInputSource(location)
File "/usr/lib/python2.7/dist-packages/rdflib/URLInputSource.py", line 21, in
__init__
file = urlopen(req)
File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.7/urllib2.py", line 404, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 422, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1214, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
raise URLError(err)
urllib2.URLError:
make sure you exported them in debian/rules:
export http_proxy=http://127.0.0.1:9/
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20140512124702.gh8...@onerussian.com
Re: Pycon 2014
On Sun, 06 Apr 2014, Barry Warsaw wrote: > Hi folks, > I'll be heading up to Montreal for the Python conference on Tuesday April 8th > and will be there until the 18th. If you're also going to the conference, it > would be great to meet up, sign keys, and chat about Python on Debian. +1 see you there (heading off to on Thu, heading back Sun) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20140407013847.gl8...@onerussian.com
Bug#743499: RFP: oct2py -- GNU Octave to Python bridge
Package: wnpp Severity: wishlist * Package name: oct2py Version : 1.3.0 Upstream Author : Steven Silvester * URL : http://blink1073.github.io/oct2py/docs/ * License : MIT/X Programming Lang: Python Description : GNU Octave to Python bridge Oct2Py is a means to seamlessly call M-files and Octave functions from Python. It manages the Octave session for you, sharing data behind the scenes using MAT files. New release of IPython 2.0 could make use of it. -- 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/20140403133048.1445.31160.report...@novo.onerussian.com
Re: recommended numpy dependency ranges?
On Mon, 31 Mar 2014, Diane Trout wrote:
> Hi,
> I have a small package the depends on numpy and it recently stopped working.
> > Traceback (most recent call last):
> > File "/usr/local/lib/R/site-
> library/DEXSeq/python_scripts/dexseq_prepare_annotation.py",
> > line 33, in
> > import HTSeq
> > File "/usr/lib/python2.7/dist-packages/HTSeq/__init__.py", line 9,
> > in
> > from _HTSeq import *
> > File "numpy.pxd", line 155, in init HTSeq._HTSeq (src/_HTSeq.c:33074)
> > ValueError: numpy.dtype has the wrong size, try recompiling
> I'm pretty sure a recompile will fix it, the question I have is how often
> does
> numpy break binary compatibility?
> Should set your numpy dependencies to something like:
> python-numpy (>= 1.8, < 1.9)
do not "hard code" -- add calls to dh_numpy (dh_numpy3) to your
rules and make sure you have ${python:Depends} in your Depends
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20140331153746.gi8...@onerussian.com
Re: Python coding help: Has anybody seen this syntax
On Thu, 13 Feb 2014, Andreas Tille wrote: > which ends up in > File "/usr/share/spades/pyyaml3/__init__.py", line 284 > class YAMLObject(metaclass=YAMLObjectMetaclass): that is the python3 way to say class YAMLObject: __metaclass__ = YAMLObjectMetaclass in python2 -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20140213164918.gg5...@onerussian.com
Re: pprocess packaging SVN
On Thu, 12 Dec 2013, Dmitry Shachnev wrote: > On Thu, Dec 12, 2013 at 6:34 PM, Yaroslav Halchenko > wrote: > > declared svn repository at > > svn://svn.debian.org/python-modules/packages/pprocess/trunk/ > > svn co svn://svn.debian.org/python-modules/packages/pprocess/trunk/ > > pprocess ... > > svn: URL 'svn://svn.debian.org/python-modules/packages/pprocess/trunk' > > doesn't exist > > checkout failed (the command above returned a non-zero exit code) > You may want to restore those paths from r17893 instead of creating > them again, so that history is kept. > See: > http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=17894 Ah right... mighty SVN -- forgotten about your pros ;) Thank you Dmitry. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20131212163140.gr6...@onerussian.com
pprocess packaging SVN
Hi Sandro, It is unfortunate that I 1. have forgotten to add pprocess to pymvpa* packages' Recommends 2. have missed the pprocess RM bug I would like to reincarnate the package, may be at least for NeuroDebian unless someone needs it in stock Debian, since we still use it in NeuroDebian and it needs a slight bugfix (amazing how well it served us without a hassle for years). But original SVN is gone and I can't find it on the servers -- is it anywhere or should I just recreate it from the snapshots? $> debcheckout pprocess declared svn repository at svn://svn.debian.org/python-modules/packages/pprocess/trunk/ svn co svn://svn.debian.org/python-modules/packages/pprocess/trunk/ pprocess ... svn: URL 'svn://svn.debian.org/python-modules/packages/pprocess/trunk' doesn't exist checkout failed (the command above returned a non-zero exit code) On Tue, 19 Jul 2011, Debian FTP Masters wrote: > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > pprocess | 0.5-1 | source > python-pprocess | 0.5-1 | all > --- Reason --- > ROM; unused > -- > Note that the package(s) have simply been removed from the tag > database and may (or may not) still be in the pool; this is not a bug. > The package(s) will be physically removed automatically when no suite > references them (and in the case of source, when no binary references > it). Please also remember that the changes have been done on the > master archive (ftp-master.debian.org) and will not propagate to any > mirrors (ftp.debian.org included) until the next cron.daily run at the > earliest. > Packages are usually not removed from testing by hand. Testing tracks > unstable and will automatically remove packages which were removed > from unstable when removing them from testing causes no dependency > problems. The release team can force a removal from testing if it is > really needed, please contact them if this should be the case. > We try to close Bugs which have been reported against this package > automatically. But please check all old bugs, if they where closed > correctly or should have been re-assign to another package. > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 634...@bugs.debian.org. > The full log for this bug can be viewed at http://bugs.debian.org/634189 > This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@debian.org. > Debian distribution maintenance software > pp. > Alexander Reichle-Schmehl (the ftpmaster behind the curtain) > ___ > Python-modules-team mailing list > python-modules-t...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20131212143431.ga8...@onerussian.com
Re: Trim out Ubuntu entries in d/changelog?
I usually include all logs which lead to the state of packaging to be uploaded, regardless of the distribution (or even at times UNRELEASED). Paul Tagliamonte wrote: >On Sat, Dec 07, 2013 at 02:04:22PM -0500, Barry Warsaw wrote: >> I've been working with gtimelog's upstream maintainer Marius, and >with the >> permission of the old gtimelog Debian maintainers, have added it to >PAPT. >> Please note that gtimelog was removed from Debian a while ago, but >remained in >> Ubuntu, and now the plan is to add the latest upstream version back >to >> Debian. I've put myself as Maintainer and PAPT as uploaders. >> >> Here's my question though: the d/changelog in PAPT svn has a bunch of >entries >> from the times it was updated in Ubuntu ahead of Debian. There's >useful >> information in there, but I'm wondering if I should trim d/changelog >to just >> the changes that occurred in Debian. E.g. dropping everything >between >> 0.0+svn88-3 (last squeeze version) to 0.9.1-1 which will be the new >upload. >> OTOH, I suppose it doesn't hurt that much to keep all the Ubuntu >changelog >> entries in the file. >> >> Anybody have strong opinions either way? > >In the past, I've treated them as "NMUs" to the package, and just >included it in the changelog. There's no real harm in my mind, at >least. > >I've even written "Acknowledge Ubuntu uploads" almost like ack'ing >NMUs. > >My 2c, > Paul > > >-- >:wq -- Sent from a phone which beats iPhone.
Re: Simplified library style guide based on pybuild
somewhat an inappropriate question for the mailing list but: are there backports of dh-python for existing/recent supported Ubuntu releases? thanks for the backport to wheezy btw. Cheers! On Tue, 05 Nov 2013, Barry Warsaw wrote: > Today I migrated the enum34 package to use pybuild. Win! > Based on that, I've done a pass through the library style guide, which I was > able to greatly simplify. > https://wiki.debian.org/Python/LibraryStyleGuide > Please take a look, edit as necessary or follow up here for more discussion. > 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. > I didn't update the AppStyleGuide. > Cheers, > -Barry -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20131128234606.ga12...@onerussian.com
Re: PyCon 2013 -- anyone submitted/planing to go?
On Thu, 05 Sep 2013, Barry Warsaw wrote: > On Sep 05, 2013, at 08:37 AM, Yaroslav Halchenko wrote: > >Since next year PyCon is in the neighborhood (just 3h drive away), I am > >planing to submit the Debian talk again. Quite probable is that it > >would not get accepted again but I think it is worth trying. Before > >going to refurbish the abstract I wanted to check if anyone already > >considering/working to submit to PyCon on a Debian-related topic? > I'm definitely planning on going, and thought it would be a good idea to > submit Something. Can you remind us what your talk is about? not sure if that was the final version I sent last time (yet to check etc)... it is yet to be adjusted for the last year advances ;) Propelling Python to the masses with the universal OS Python has found appreciation not only among professional developers but also among students, scientists and programming novices due to its scripting nature, "batteries included", good collection of 3rd party libraries, and ability to interface to libraries written in other languages and computing environments (e.g. R). To conveniently deliver such a versatile Python platform to users (and their humble system administrators), the community have been distilling the ultimate Python distribution utilities and bundling pre-built Python and core 3rd party libraries and modules for the distribution on proprietary systems. Meanwhile nearly for two decades Python has been a part of the largest community-driven software distribution platform -- Debian. The Debian project delivers a complete operating system with tens of thousands of FOSS projects available on 11 hardware architectures and 3 different kernels (Linux, HURD, kFreeBSD). Being a binary distribution Debian guarantees safer -- free of build-errors -- installations and seamless upgrades. Coupled with the standardized specification of build and run-time dependencies, it made it easy to build, verify, or simply deploy projects of nearly arbitrary complexity of inter-dependencies and varying implementation origins. Such agnosticism to the origins of the software made Python-based products a 1st citizen in this heterogeneous distribution ecosystem, assuring that Python works well with the rest of it. Recent advances in hardware virtualization support, followed in tandem with the explosion of cloud solutions, made Debian systems popular not only among Linux "fan-boys" but for various, especially scientific and community-driven, deployments. The ease with which thousands of Python-based FOSS became available and maintainable made Debian the Python distribution with "**all** batteries (and virtualenv) included". In this talk I would like to briefly present the history of Python in Debian (which can be traced to nineties with Python 1.4), outline benefits Debian provides for Python users/developers and present what to expect in upcoming stable (wheezy) release of Debian. To familiarize listeners with Python-in-Debian ecosystem I will then overview core package naming, versioning, and modularization conventions in Debian and ongoing QA efforts (build-time testing, full-archive rebuilds, etc). I will briefly present the "Debian packaging" helper tools, including recent GSOC project aiming to provide automatic packaging of the packages on PyPI. To facilitate the synergy between Python and Debian communities, I will accent on common sense practices (following PEPs, clean and exhaustive legal terms, CI, etc.) which would make any Debian packaging and maintainership more efficient and benefit upstream developers. I am planing to conclude by presenting few easy ways on how to start using Debian. As the outcome of the talk, I expect listeners to become more familiar with the Debian project goals, standards and principles, become aware of integration aspects involved in delivering such plethora of Python FOSS solutions, and become intrigued enough to try Debian on their systems or in the cloud. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130905131002.gz11...@onerussian.com
PyCon 2013 -- anyone submitted/planing to go?
Since next year PyCon is in the neighborhood (just 3h drive away), I am planing to submit the Debian talk again. Quite probable is that it would not get accepted again but I think it is worth trying. Before going to refurbish the abstract I wanted to check if anyone already considering/working to submit to PyCon on a Debian-related topic? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130905123753.gx11...@onerussian.com
Re: dh-python in unstable
This left me puzzling for a bit: $> sudo apt-get install dh-python ... The following packages have unmet dependencies: dh-python : Depends: python3 (>= 3.2.3-3~) but it is not going to be installed E: Unable to correct problems, you have held broken packages. $> apt-cache policy python3 python3: Installed: 3.2.3-7 Candidate: 3.3.2-3 Version table: 3.3.2-11 0 300 http://debian.lcs.mit.edu/debian/ experimental/main amd64 Packages 3.3.2-4 0 600 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages 3.3.2-3 0 900 http://debian.lcs.mit.edu/debian/ jessie/main amd64 Packages *** 3.2.3-7 0 100 /var/lib/dpkg/status 3.2.3-6 0 100 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages $> dpkg --compare-versions 3.2.3-3~ lt 3.2.3-7 && echo "yes - yarik is sane" || echo "go to the doctor" yes - yarik is sane Until I have looked at apt-cache show: Replaces: python3 (<< 3.3.2-10~) Depends: python3 (>= 3.2.3-3~) Breaks: python3 (<< 3.3.2-10~) Probably it is also worth complaining against apt regarding the message, but may be Depends here could/should be boosted to the same version of python3? Do you think it would be feasible to have a backport of dh-python e.g. for wheezy with corresponding diverts avoiding conflicts here or indeed python3 (>= 3.2.3-3~) is required for some functionality (haven't looked inside)? On Fri, 02 Aug 2013, Piotr Ożarowski wrote: > dh-python is already in unstable \o/ > To build/install python3-foo or pypy-foo binary packages, > you can use this in debian/rules: > %: > dh $@ --with python2,python3,pypy --buildsystem=pybuild > or if you don't want to play with .install files: > export PYBUILD_DESTDIR_python2=debian/python-foo/ > export PYBUILD_DESTDIR_python2-dbg=debian/python-foo-dbg/ > export PYBUILD_DESTDIR_python3=debian/python3-foo/ > export PYBUILD_DESTDIR_python3-dbg=debian/python3-foo-dbg/ > export PYBUILD_DESTDIR_pypy=debian/pypy-foo/ > %: > dh $@ --with python2,python3,pypy --buildsystem=pybuild > See pybuild(1) and dh_pypy(1) for more info. > Note that adding dh-python to Build-Depends enables multiarch support in > dh_python2 -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130802195759.gd17...@onerussian.com
Re: Inconsistency in source package naming for python modules
Another rule of thumb I use is that if a project is not just about python module but also provides some GUI or CUI interface which might be used by users without realizing presence of a python behind I do not prefix with python-, eg psychopy. Sandro Tosi wrote: >On Mon, Jul 8, 2013 at 4:10 PM, Scott Kitterman >wrote: >> There is no policy on this either way, so there's no "mistake". >Personally, I >> tend to use the upstream name for the source package name and >> python-$modulename (per Python policy) for the binary. > >I'm using the same same rule, with just one exception: I'm calling >source package python-X if X is too generic (see python-psutil, where >upstream is calling the project psutil, too close to psutils). I don't >feel there's anything to "fix" here, or to write a policy for source >package name. > >Regards, >-- >Sandro Tosi (aka morph, morpheus, matrixhasu) >My website: http://matrixhasu.altervista.org/ >Me at Debian: http://wiki.debian.org/SandroTosi -- Sent from a phone which beats iPhone. -- 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/89e4a6bb-fc21-4c30-a1d7-b08808406...@email.android.com
Re: Request to Join Project Python Modules Packaging Team from Vincent Cheng (vincentc-guest)
On Sun, 19 May 2013, Jakub Wilk wrote: > You might want to try run the tests under xvfb. Hopefully that > should allow running more of them than currently. just so it might come handy for others: to enable GLX support under Xvfb, here is the line I have suggested to be used (upstream just adopted it ;) ) for impressive build time testing: xvfb-run -s "-screen 0 640x480x24 -ac +extension GLX +render -noreset" COMMAND seems to work fine (besides on Ubuntu 12.10 for unknown to me yet reason). It seems thought that you would also need build-depends on libgl1-mesa-dri to make it work ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130520012706.gg8...@onerussian.com
Re: python3.3 status
Thanks Jakub, FWIW: > cython produces broken code #681697 update WiP (for some reason did not build using python-dbg at all thus dh_install failed... will troubleshoot shortly) > nuitka FTBFS TODO I believe fixed upstream -- if not -- will be, i.e. nothing to worry for the team -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130507124212.ge9...@onerussian.com
Re: statsd + voluptuous packaged!
On Thu, 21 Mar 2013, Antoine Musso wrote: > I guess that is what happens when newbie joins. They do mistake, so do > I. I must confess I have only looked at packages.debian.org :/ Will > remember about wnpp, thanks for the tip! FWIW the fastest way imho is > sudo apt-get install devscripts > wnpp-check statsd node-statsd (RFP - #688662) python-statsd (ITP - #703613) python-statsdpy (ITP - #699411) -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130322015249.gm2...@onerussian.com
Re: Package upgrade needs deletion of config file in ~/
fresh entry in debian/NEWS and probably debian/changelog ? On Tue, 12 Feb 2013, Andreas Noteng wrote: > Hello. What is the preffered way of handling situations where a > configuration file in ~/ needs to be deleted upon package upgrade? > Regards > Andreas Noteng -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130212150407.ga8...@onerussian.com
Re: Setting http_proxy in debian/rules
what about something like ifeq (,$(findstring get-orig-source, $(MAKECMDGOALS))) export http_proxy=http://127.0.0.1:9/ endif so unless called with get-orig-source -- it would get defined... ? On Wed, 06 Feb 2013, Piotr Ożarowski wrote: > [Dmitrijs Ledkovs, 2013-02-06] > > On 5 February 2013 17:48, Barry Warsaw wrote: > > > http://mail.python.org/pipermail/catalog-sig/2013-February/004831.html > > I should add a hook to export that for the build & binary stages of > FTR: pybuild does that by default (http_proxy=http://127.0.0.1:9/) > it probably should be changed to not overwrite existing http_proxy (if set) > or to make it possible to disable it. -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130207024443.gu8...@onerussian.com
Re: pybuild - one to rule^W build them all
wow -- looks cool -- that already should take a bit of burden away from copy/pasting debian/rules of my packages from one to another I wonder if it could also "support" (just throwing against the wall to see if anything sticks): 1. -lib packages to ship extensions in separate packages to reduce impact on archives 2. unit-testing against built/installed modules (if some env variable provides the command to be invoked) 3. building/installing sphinx-based documentation + replacing all the java script libraries with symlinks to sytemwide once from the packages wouldn't it make more sense to ship it in a separate package since it is relevant not only for python3? then it would also make possible to provide backport packages Cheers! On Sat, 19 Jan 2013, Piotr Ożarowski wrote: > [debhelper's #538978 and #597105 bugs BCCed] > Hi, > FYI: python3 package in experimental (3.3.0-2) contains pybuild tool > with dh command sequencer integration. > You can build modules/extensions for Python 2.X *and* Python 3.X with > this debian/rules file: > #!/usr/bin/make -f > %: > dh $@ --with python2,python3 --buildsystem=pybuild -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20130120001606.gh19...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Hi Nicolas, Thanks for the feedback -- valid concerns and besides first 3 points indeed you give the answers I am usually give people: that is why we provide NeuroDebian VM which is used by quite a few users who either have admin access on their boxes or just pursuade IT personnel to do just 1 custom installation for them -- VirtualBox ;-) As for chroot'ing -- it is underused/under-marketed solution IMHO ATM although I have been using it myself quite a bit and even at times advocating it as a workaround for some deployment problems [1]. Also I haven't played with fakechroot yet, which if possible to perfect, could serve as an ultimate resolution for people without admin access. As for the developers/production: first indeed VM still might be a better choice, second -- we still provide all the Pythonic tools for virtualization/isolation, and after all I decided to position the talk more toward users so I hope not to fall into this debate ;) [1] http://neuro.debian.net/blog/2011/2011-12-12_schroot_fslview.html > PS: by the way, would anyone know of a way to use chroot or something > similar to allow any user to have any number of virtual environments > that use apt-get to install stuff and fall-back to the system if > something is not installed in the virtualenv ? what is your use case? chrootting does allow 'arbitrary' number of virtual environments but I am not sure what kind of fall-back you need. Usually I used chroots in the opposite way, but supplementing main system with tools ran in chroots (see [1] above ;) ) Cheers On Tue, 02 Oct 2012, Nicolas Chauvat wrote: > Hi Yaroslav, > On Wed, Sep 26, 2012 at 11:40:58AM -0400, Yaroslav Halchenko wrote: > > To not be too ambitious and to not invest too much time I have decided to > > submit only a talk. Here follows a perspective title, abstract and some > > notes/outline which will not be a part of submission. I would really > > appreciate (and of cause would acknowledge in the slides) any feedback, > > ideas, > > comments, etc. > I suggest you would also try to describe the differences between The > Complete Python Distribution On Debian and the others ways there are > to install Python packages. > When I say "I do not need all this easy_install, pip, virtualenv, > distribute/packaging, buildout, /etc/ for I have Debian!", I am > usually told: > - but we have to work on Windows > - but we are not root on the computer we are using and can't run apt-get > - but I want a newer version of X than the one included in Debian > - but I am not doing deployment/production and for development I need the > latest versions of these modules because this component I rely on > says so > - I am preparing things for production, so I need everything to be > reproducible independently of the underlying system > - etc. > I think being prepared to answer these questions and maybe address > some of these issues directly in your slides would help make clear > what Debian is a good solution for. > Possible answers are: > - windows: if it hurts, stop doing it and install virtualbox :p > - not root: try a virtual machine (or maybe a variant of chroot?) > - newer: are you ready to handle all the compatibility/dependency > problems on your own ? > - dev: packaging python modules is easier than getting a full > distribution to work right, take a look at the > GSoC project that packages PyPI/*, your new-and-shiny stuff is > probably there > - prod: you want a chroot or a virtual machine. > - etc. > Hope this helps, > PS: by the way, would anyone know of a way to use chroot or something > similar to allow any user to have any number of virtual environments > that use apt-get to install stuff and fall-back to the system if > something is not installed in the virtualenv ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20121002125445.gr26...@onerussian.com
Re: PyCon 2013 -- tentative title/description/abstract -- v.3 (submitted)
Thanks everyone who helped with the submission! Just for the reference -- here is the submitted version ( I believe it will be possible to change it later on as well ): Submitted by Yaroslav Halchenko Category Packaging # I guess it was the closest to "distribution" Audience Level Intermediate Extreme? No Duration I prefer a 45 minute slot Description Debian delivers a complete operating system with a rich collection of Python modules and extensions as its integral part. Such "*all* batteries included" approach allows anyone to safely dive into using Python without being exposed to possible internal complexity of build- and run-time requirements. This talk will present the Python world of Debian with its offerings, standards and QA efforts. Abstract Python has found appreciation not only among professional developers but also among students, scientists and programming novices due to its scripting nature, "batteries included", good collection of 3rd party libraries, and ability to interface to libraries written in other languages and computing environments (e.g. R). To conveniently deliver such a versatile Python platform to users (and their humble system administrators), the Python community have been developing the ultimate Python distribution utilities and bundling pre-built Python and core 3rd party libraries and modules for distribution on proprietary systems. Meanwhile nearly for two decades Python has been a part of the largest community-driven software distribution platform -- Debian. The Debian project delivers a complete operating system with tens of thousands of FOSS projects available on 11 hardware architectures and 3 different kernels (Linux, HURD, kFreeBSD). Being a binary distribution Debian guarantees safer -- free of build-errors -- installations and seamless upgrades. Coupled with the standardized specification of build and run-time dependencies, it makes it easy to build, verify, or simply deploy projects with complicated interdependencies and using a variety of technologies. Since Debian attempts to support all technologies equally well, Python-based products are first class citizens in this heterogeneous distribution ecosystem, ensuring that Python works well with the rest of it. Recent advances in hardware virtualization support, followed in tandem with the explosion of cloud solutions, has made Debian systems popular not only among Linux "fan-boys" but for various, especially scientific and community-driven, deployments. The ease with which thousands of Python-based FOSS have been made available and maintainable through Debian have made it the Python distribution with all batteries included, even those like virtualenv which also address package and dependency management. In this talk I would like to briefly present the history of Python in Debian (which can be traced back to the 1990s with Python 1.4), outline the benefits Debian provides for Python users/developers and present what to expect in the upcoming stable (wheezy) release of Debian. To familiarize listeners with the Python-in-Debian ecosystem I will then give an overview of core package naming, versioning, and modularization conventions in Debian and ongoing QA efforts (build-time testing, full-archive rebuilds, etc). I will briefly present the "Debian packaging" helper tools, including a recent GSOC project aiming to provide automatic packaging of the packages on PyPI. To facilitate the synergy between Python and Debian communities, I will emphasize on common sense practices (following PEPs, thoroughly tracking contributions and licensing, continuous integration testing, etc.) which would make any Debian packaging and maintainership more efficient and benefit upstream developers. I am planning to conclude by presenting few easy ways on how to start using Debian. As the outcome of the talk, I expect listeners to become more familiar with the Debian project goals, standards and principles, become aware of integration aspects involved in delivering such a plethora of Python FOSS solutions, and become intrigued enough to try Debian on their systems or in the cloud. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120928211358.gu26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2
> >I could start with this one of cause ;) but I hope they all know about > >it by now. On a related note though: __file__ -- are we all friends > >again ? ;) > Not sure what you mean about enmity with __file__, but note that as of the > acceptance of PEP 420 (namespace packages), in Python 3.3, __file__ is > completely optional as an attribute of module objects. I just vaguely remember that there were problems in some projects relying on __file__ (some times opportunistically with os.path.realpath) to deduce the path to other components of the project, which might had been symlinked elsewhere ;-) and that is what dh_python has addressed: Date: Fri, 15 Jan 2010 11:58:56 +0100 From: Piotr Ożarowski To: debian-python@lists.debian.org Subject: Re: new dh_python proposal ... * broken modules that use __file__ incorrectly will work without problems, -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120928165309.gn26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On Fri, 28 Sep 2012, Paul Wise wrote: > > ^^ this is a great idea. It'd be nice if we could prototype a flake8 / > > pyflakes run against the archive, and filter for serious errors > We did do that at one point with pyflakes: > http://qa.debian.org/daca/pyflakes/sid/ > Unfortunately no-one has been working on DACA recently, hint hint ;) if only it was reincarnated... then we could also wrap it into a nice matrix form with summary counts of warnings/errors etc -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120928135342.gk26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On Fri, 28 Sep 2012, Paul Tagliamonte wrote: > > The Python conference scene seems to love testing, so if you can make a > > case > > for Debian and quality assurance, and Debian has done things popular with > > this crowd for years like automated builds and the use of very strict > > package > > building tools that won't let you build without a precise specification of > > the build dependencies, then that may appeal to some people. > ^^ this is a great idea. It'd be nice if we could prototype a flake8 / > pyflakes run against the archive, and filter for serious errors I thought to provide stats on how many packages do have build-time testing... then depending on the number of them may be do some analysis to see if I could state that build-time tested packages have less bug reports filed/opened (accounting at the same time against popularity). > Clearly, this idea is *insane*, but it's the sort of solution most > hardcore pythonistas I know would go for, which would make us > happy(ish), and them happy(ish). > btw -- let's not do this. it's insane. ;) > > I don't think you should worry too much about flames. My impression is that > > the packaging people are trying to scale back their ambitions and just get > > everyone to do the basic things like write decent metadata, mostly because > > I > > think the process of delivering a comprehensive solution is deadlocked once > > again, and I think that people do see the need to hear from distributions > > and > > to try and get as much input from them as possible. > I just don't want a good discussion to get deraled by a few people > saying globally installing modules results in a bad dependency hell, and > we're tainting their whatever. yeah -- I would try to avoid discussion by simply stating that it works in many cases and Debian is a clear example for that, so there is no point to disguss it any further. > > Paul > - Other Paul -- Yarik, just Yarik -- 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/20120928135224.gj26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2
On Fri, 28 Sep 2012, Piotr Ożarowski wrote: > no, but please make sure to bind a key that (when pressed) shows a > screen with these PEP numbers... and hit it every time you do a short > break to catch a breath or drink water ;) ;) I do bind keys to important slides in impressive... now I will have 1 more -- what shortcut key would you recommend -- "Enter"? ;) yeah -- I guess it would be nice to get some 'cheat slide' with the most important links to condition people over and over again happen there is a break ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120928134409.gi26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2
Thanks Piotr! On Fri, 28 Sep 2012, Piotr Ożarowski wrote: > [Yaroslav Halchenko, 2012-09-28] > > In this talk I would like to briefly present the history of Python in > > Debian (which can be traced to nineties with Python 1.4), outline > > benefits Debian provides for Python users/developers and present what > > to expect in upcoming stable (wheezy) release of Debian. To > > familiarize listeners with Python-in-Debian ecosystem I will then > > overview core package naming, versioning, and modularization > > conventions in Debian and ongoing QA efforts (build-time testing, > about conventions... please, please, please mention with pleasure ... but do you think it is worth listing (some of) them in the abstract? > PEP386 this one is my favorite (giving significant amount of suffer ;) ) > PEP396, Status: Draft Barry, was there any progress? it would be cool if it was somewhat coupled with recipes for different VCS. I know a few projects which go few extra steps to automate unique version assignments for the GIT archive exports etc. e.g. http://anonscm.debian.org/gitweb/?p=pkg-exppsy/pynifti.git;a=blob;f=setup.py;hb=HEAD > PEP390 Status: Draft seems needs to make friends with PEP396 regarding version information dependencies specs are indeed would be valuable > PEP384? I guess I need to digest it more to explain how/if it is relevant for Debian maintenance. > PEP8? I could start with this one of cause ;) but I hope they all know about it by now. On a related note though: __file__ -- are we all friends again ? ;) > or documents like http://wiki.debian.org/UpstreamGuide it would of cause be worthwhile of at least mentioning > - maybe it's not directly related to your talk, but any occasion > is good to try to convince developers to follow conventions. that is part of the aim indeed ;) > > full-archive rebuilds, etc). I will briefly present the "Debian > > packaging" helper tools, including recent GSOC project aiming to > > provide automatic packaging of the packages on PyPI. To facilitate > even today Natalia committed some changes related to exporting build/test > logs, statistics will follow soon, I hope :). We still need a server to > set this up, though - I'll try to arrange a webserver to host generated > repo/logs, but we still need access to a buildd (or a server where we > can set one up) to do the building part - Natalia's tool is prepared to > be invoked in cron and build (using f.e. sbuild) only new packages / for > new architectures or new distributions). yeah -- without such at least a demo repository project felt somewhat incomplete to me. > > As the outcome of the talk, I expect listeners to become more familiar > > with the Debian project goals, standards and principles, become aware > > of integration aspects involved in delivering such plethora of Python > > FOSS solutions, and become intrigued enough to try Debian on their > > systems or in the cloud. > you can also advertise https://buildd.debian.org/status/package.php > (for those who want to see build logs from different architectures > of their libraries - we try to enable more and more tests during build) right! I also had in mind pointing to http://packages.qa.debian.org as the ultimate 'developer-oriented' page, where upstream could get to the logs, subscribe to notifications (email, RSS), etc -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120928130416.gg26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2
ok -- here is my next take trying to make at least the title and introduction more user oriented and mention those aspects which might be be of interest for developers... As a result it probably became even less English and now exercises working memory even harder ;) Propelling Python to the masses with the universal OS Python has found appreciation not only among professional developers but also among students, scientists and programming novices due to its scripting nature, "batteries included", good collection of 3rd party libraries, and ability to interface to libraries written in other languages and computing environments (e.g. R). To conveniently deliver such a versatile Python platform to users (and their humble system administrators), the community have been distilling the ultimate Python distribution utilities and bundling pre-built Python and core 3rd party libraries and modules for the distribution on proprietary systems. Meanwhile nearly for two decades Python has been a part of the largest community-driven software distribution platform -- Debian. The Debian project delivers a complete operating system with tens of thousands of FOSS projects available on 11 hardware architectures and 3 different kernels (Linux, HURD, kFreeBSD). Being a binary distribution Debian guarantees safer -- free of build-errors -- installations and seamless upgrades. Coupled with the standardized specification of build and run-time dependencies, it made it easy to build, verify, or simply deploy projects of nearly arbitrary complexity of inter-dependencies and varying implementation origins. Such agnosticism to the origins of the software made Python-based products a 1st citizen in this heterogeneous distribution ecosystem, assuring that Python works well with the rest of it. Recent advances in hardware virtualization support, followed in tandem with the explosion of cloud solutions, made Debian systems popular not only among Linux "fan-boys" but for various, especially scientific and community-driven, deployments. The ease with which thousands of Python-based FOSS became available and maintainable made Debian the Python distribution with "**all** batteries (and virtualenv) included". In this talk I would like to briefly present the history of Python in Debian (which can be traced to nineties with Python 1.4), outline benefits Debian provides for Python users/developers and present what to expect in upcoming stable (wheezy) release of Debian. To familiarize listeners with Python-in-Debian ecosystem I will then overview core package naming, versioning, and modularization conventions in Debian and ongoing QA efforts (build-time testing, full-archive rebuilds, etc). I will briefly present the "Debian packaging" helper tools, including recent GSOC project aiming to provide automatic packaging of the packages on PyPI. To facilitate the synergy between Python and Debian communities, I will accent on common sense practices (following PEPs, clean and exhaustive legal terms, CI, etc.) which would make any Debian packaging and maintainership more efficient and benefit upstream developers. I am planing to conclude by presenting few easy ways on how to start using Debian. As the outcome of the talk, I expect listeners to become more familiar with the Debian project goals, standards and principles, become aware of integration aspects involved in delivering such plethora of Python FOSS solutions, and become intrigued enough to try Debian on their systems or in the cloud. On Fri, 28 Sep 2012, Paul Boddie wrote: > On Friday 28 September 2012 00:23:10 Yaroslav Halchenko wrote: > > Thank you Paul ;-) > > Good comments -- once again, arguments seems to be oriented mostly > > toward developers... I guess I should explicitly guide the > > abstract more toward 'user-' and "sysadmin-" use cases: people > > in need to have easy and uniform paths for software installation and > > maintenance of the heterogeneous system. In scientific users domain it > > becomes even more fun with heavier reliance on computational and I/O > > libraries (blas/atlas, hdf5, etc) building and maintaining which might > > be quite a bit of a hassle. > Yes, I had cause to build NumPy from scratch recently, and it was quite > intimidating. It did happen to involve a fairly low-performance device with > fairly severe memory constraints, and the experience really pushed me towards > looking harder at Debian and the packaging work that I knew would have been > done to potentially solve some of the issues I was experiencing, one of which > being modularisation of the library, although I'm not sure how much this is > actually done with NumPy in Debian. > > Few inline comments. > > > I was going to give some feedback more as the kind of person who has gone > > > to Python conf
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Thank you Paul ;-) Good comments -- once again, arguments seems to be oriented mostly toward developers... I guess I should explicitly guide the abstract more toward 'user-' and "sysadmin-" use cases: people in need to have easy and uniform paths for software installation and maintenance of the heterogeneous system. In scientific users domain it becomes even more fun with heavier reliance on computational and I/O libraries (blas/atlas, hdf5, etc) building and maintaining which might be quite a bit of a hassle. Few inline comments. > I was going to give some feedback more as the kind of person who has gone to > Python conferences, and certainly, if you want a native speaker to give > feedback on the phrasing of your proposal, I'd be happy to make some > suggestions. I would appreciate "native speaker" feedback! since "accepting all types of proposals through September 28, 2012", I guess I have the whole tomorrow to revise and submit. I hope to find some time later today to revise my abstract and will post it again for further phrasing suggestions That is true... Somewhat offtopic -- that is why with neuro.debian.net we pretty much serve an unofficial backports repository for a good portion of Python modules we maintain. Besides immediate benefit for users, benefit from backporting for developers has been build-time testing across various releases of Debians and Ubuntus, picking out problems with specific versions of the core libraries... So, may be I should add an accent that availability in Debian doesn't only guarantee ease of installation (for users) but provides a good test bed for the developers to preclude problems with future deployments on Debian-based platforms... ? > Python packaging has become somewhat insular over the years with > Python-centric solutions that work across different systems rather than > solutions that work well with the rest of the software on particular systems. > However, people appear to like things like virtualenv, especially the Web > crowd that makes up a lot of the audience at events like this, because it > lets them set up relatively cheap configurations for separate Web > applications or for experimenting. virtualenv is indeed great for the reasons you guys point out AND indeed, it is very Python-centric and maintenance of a configured virtualenv might become cumbersome for projects with lots of 3rd party dependencies and for regular users who would not want to care to switch among different virtualenvs etc. I guess I should revise abstract to aim a listener wondering "why should I care about Debian if there is virtualenv" WITHOUT explicitly pointing to its pros to not cause any flames. And not sure I would be able to convince hard-core Python-ians, so I might not even try and orient it more toward users/admins. > I have advocated solutions based on fakechrooted debootstrapped installations btw -- how is it working out for you? i.e. are you still pushing it forward? > if only because you can manage the libraries below the Python modules and > extensions as well as the stuff that supports things like distutils and > setuptools. However, the people who can change this situation don't see the > need or the point: it's either "but I have root!" or "they can always build many (users on managed boxes) -- don't, so I would have pushed these approaches for them as well ;) > from source!" No wonder people use stuff like virtualenv instead. It is in > this area where I feel that the Debian community could do more to meet others > half-way. > > People don't care about API stability or anything like that, so I think > > you might have to try to frame this in a way that doesn't provoke a > > virtualenv-vs-apt battle -- because, frankly, neither side will win and > > it'll just become a bit murky. > > I'd be happy to help you prepare / do more interactive work with folks > > at PyCon (I should likely be there) :) > The one case that many language-focused groups ignore, and where > distributions > do well, is the case where a range of different technologies needs to be > managed and where administrators just wouldn't be able to keep up with Python > eggs, Ruby gems, CPAN, and the language-specific technology of the week. > Persuading the Python community to feed packages into Debian so that they > become a safer choice for people who routinely use or know other technologies > is definitely a worthwhile cause. indeed safer and more accessible choice. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120927222310.gj5...@onerussi
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
Thank you Paul, On Thu, 27 Sep 2012, Paul Tagliamonte wrote: > I can see this becoming a flamefest. oh no... I hoped to simply present our work and not cause flamefests ;-) > Most "hardcore" pythonistas (and the types to be at PyCon) refuse to > allow apt to install libs globally, and use virtualenv(wrapper) to > isolate deps for a few reasons -- the big ones being: > - more "up to date" > - isolates dependency hell > which (frankly) apt-get / Debian stable can't really address. Sometimes > Python packages in sid are out of date as well. That is true... Somewhat offtopic -- that is why with neuro.debian.net we pretty much serve an unofficial backports repository for a good portion of Python modules we maintain. Besides immediate benefit for users, benefit from backporting for developers has been build-time testing across various releases of Debians and Ubuntus, picking out problems with specific versions of the core libraries... So, may be I should add an accent that availability in Debian doesn't only guarantee ease of installation (for users) but provides a good test bed for the developers to preclude problems with future deployments on Debian-based platforms... ? > People don't care about API stability or anything like that, so I think > you might have to try to frame this in a way that doesn't provoke a > virtualenv-vs-apt battle -- because, frankly, neither side will win and > it'll just become a bit murky. I think, as Paul pointed out (reply to his email will follow shortly) that it might be worth to orient the talk more toward the users who per se pretty much need to take care about the whole system -- regular mortals and sysadmins. > I'd be happy to help you prepare / do more interactive work with folks > at PyCon (I should likely be there) :) Thanks in advance... let's see first if I would be going anywhere ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/2012092713.gd26...@onerussian.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
not a single comment... bad... I guess I need to work on the text more if even hardcore Debian people do not feel 'moved' ;-) On Wed, 26 Sep 2012, Yaroslav Halchenko wrote: > To not be too ambitious and to not invest too much time I have decided to > submit only a talk. Here follows a perspective title, abstract and some > notes/outline which will not be a part of submission. I would really > appreciate (and of cause would acknowledge in the slides) any feedback, ideas, > comments, etc. > [originally in emacs org-mode] > * Title > Debian -- (rich) Python distribution for the bare metal > Alternatives: > The universal Python distribution or build your own stack > Debian & Python -- a happy couple with a character > Propelling Python to the masses with the universal OS > * Abstract > Through the years Python community strives to distill the ultimate > Python distribution utilities. Meanwhile, to overcome the problems of > the core Python and 3rd party FOSS Python projects distribution, > various free and commercial distribution bundles of Python appeared. > They made Python, as an environment with a pre-selected set of Python > modules, conveniently available (primarily) on proprietary systems. > What is rarely known is that for decades Python has been a part of the > largest in the world software distribution platform: Debian project > delivers a complete operating system with thousands of FOSS projects > making them available on 11 hardware architectures and 3 different > kernels (Linux, HURD, kFreeBSD). In the Linux world, Debian is known > as the most popular base distribution due its openness, ease of use, > versatility, and stability. By delivering a well integrated and > tested versatile OS, with a plethora of core libraries necessary for > nearly any field of endeavor, it became an ideal base for the > **complete** Python distribution. Majority of Python projects are > either already packaged for Debian or provide 1-2 lines instructions > on how to install necessary dependencies and build/install the product > on Debian-based systems. Recent advances in hardware virtualization > support followed in tandem with the explosion of cloud solutions, made > Debian systems popular not only among Linux "fan-boys" but for > various, especially scientific and community-driven, deployments. The > ease with which thousands of Python-based FOSS became installable and > maintainable made Debian the Python distribution with "**all** > batteries included". > In this talk I would like to briefly present the history of Python in > Debian (which can be traced to nineties with Python 1.4) and outline > benefits Debian provides for Python users and developers, keeping in > mind upcoming stable Debian release (wheezy). To familiarize > listeners with Python-in-Debian ecosystem I will then overview core > package naming, versioning, and modularization conventions in Debian, > and briefly present the "Debian packaging" helper tools, including > recent GSOC project aiming to provide automatic packaging of the > packages on PyPI. To facilitate the synergy between Python and Debian > communities, I will accent on common sense practices (following PEPs, > clean and exhaustive legal terms, CI, etc.) which would make any > Debian packaging and maintainership more efficient. I am planing to > conclude by presenting few easy ways on how to start using Debian. > As the outcome of the talk, I expect listeners to become more familiar > with the Debian project's standards and principles, become aware of > integration aspects involved in delivering such plethora of Python > FOSS solutions, and be intrigued enough to try Debian on their systems > or in the cloud. > Just NOTES: > * Python-in-Debian History > ** Upstream: Python 1.0 - January 1994, Python 1.5 - December 31, 1997 > ** debian-python ML > https://lists.debian.org/debian-python/1998/08/msg0.html > To: debian-python@lists.debian.org > Cc: hoffl...@mathi.uni-heidelberg.de, lore...@argon.roma2.infn.it > Subject: Welcome to debian-python > From: Hanno Wagner > Date: Fri, 7 Aug 1998 09:27:05 +0200 > Message-id: <19980807092705.j25...@beuel.rhein.de> > Reply-to: Hanno Wagner > Good morning gentlemen, > this is the initial posting for debian-python, the > mailinglist is running now. > Here is the description for the mailinglist: > debian-python@lists.debian.org > Description : Discussion of issues related to Python on Debian > systems with an stress on packaging standards. > Therefore relevant for maintainers of Python related > packages. > Moderated : no > Subscription: o
PyCon 2013 -- tentative title/abstract/outline -- feedback plz
gelog (Python 2.0 was released on 16 October 2000) python2 (2.0-1) unstable; urgency=low * New upstream version. Initial release for python2. -- Gregor Hoffleit Mon, 11 Dec 2000 22:39:46 +0100 * For the "users" very convenient environment to install, update, remove. ** Statistics on the covered packages XXX Python modules/extensions (tagcloud?) XXX Python bindings for C/C++ libraries *** By domains web-frameworks: gluon, web2py, turbogeats, django, pyjamas... scientific Python: numpy, scipy, ... * For the "developers" ** Rich development environment multiple-supported versions -- smooth-ed migration IDEs: python*-dbg virtualenv ** Q: How do I keep my finger on the beat of my baby in Debian? Subscribe to announcements on http://packages.qa.debian.org ** Q: How popular am I? popcon.debian.org Show numpy proliferation on Debian deployments * (?) Python-in-core-Debian Which core Debian tools are Python-based - reportbug - git-buildpackage * Python-in-Debian internals - In 99% it is not 'Bureaucracy' -- it is evolving open standards ;) Python modules policy is not carved in stone (i.e. not part of the official main Debian policy) - Binary packages naming/modularization conventions or "WTF they have done with my module..." - python-* -- Python modules/extensions - might be split into python-X arch:all and python-core/-lib/-bin - might be complemented with -dbg -- package (built against python-dbg) -doc -- documentation - python*-numpy-a[bp]i* packages - How package is built - source vs binary package - dh + dh_python2 (python-central/python-support -- deprecated) - pkg build time testing TODO: stats -- how many, test in-place, test against built/installed - no build-time testing for arch:all packages (built ones/uploaded + QA rebuilds) - helpers: - stdeb -- http://github.com/astraw/stdeb (python-stdeb package) - GSOC 2012 -- pypi2deb -- PyPI to Debian converter https://gitorious.org/pypi2deb - Debian versioning - Python2/3 Debian peculiarities - TODO * What do we ask developers about - standard deployment schemes (setup.py install) - follow PEPs: - PEP XXX -- versioning implemented only in python3, but at least rely on distutils.version.LooseVersion - is there PEP on testing, Barry? - clean(er) separation of code and data - clear and exhaustive LICENSE/COPYRIGHTs - unittests - tag ones requiring network access or better -- provide fixtures - exercise against minimal supported versions (of Python itself, and 3rd party libraries) * How to get started with Debian - install (dual-boot, ...) - other Linuxes: chroot - lightweight virtualization (debootstrap, schroot) - VM, e.g. http://neuro.debian.net/vm.html - cloud On Fri, 21 Sep 2012, Yaroslav Halchenko wrote: > Hi everyone, > Since the deadline for the submission of talks/tutorials for the PyCon > 2013 is approaching (28th of Sep) I thought to check if anyone from the > 'team' will be attending (Barry?) and may be someone already is > planing to give a talk or might be even a tutorial? > Debian-based systems become de-facto "the community Linux" in the > Python world due to the simplicity of maintenance and deployment of > Python software. But I think we still are far behind at promoting > ourselves, so I thought it would be nice if "Debian" appears at PyCon > (some corporate Linux-related entities are already among sponsors where > Debian is unlikely to be listed). I am not sure yet if I would get any > funds to attend but I am thinking about submitting two proposals for > 1. talk on "The universal Python distribution or build your own stack" >in many fields of endeavor people talk about stacks and python >distributions which make easy to build/deploy suck stacks. So I >thought that we should not be shy and present Debian as the best >platform for anyone -- either ran on bare metal (preferable) or in a >VM (for new adopters). But then we might have released wheezy which >would be a good base for the talk -- present what fresh release has >brought to the community in this stable environment. >Previously I have done a similar talk with an accent on a scientific >Python stack in Debian [1] which I thought was quite well accepted. > 2. tutorial on "Debian packaging of Python modules/software" >since tutorials are separate from the main registration (i.e. require >separate payment if I got it right) I am not quite sure how many >people would be interested to attend it. But I guess it should not >hurt to submit one and for the committee to decide. > Also it might be worth asking for a table/booth space (I think I saw > that somewhere on pycon website) for the Debian project. > I would be
Re: python-twitter is not maintained
thanks ;-) On Sun, 23 Sep 2012, Koichi Akabe wrote: >2012/09/22 13:01 "Koichi Akabe" <[1]vbkaise...@gmail.com>: >> Can I take over this package? >I received the answer from the maintainer [1]. He lost interest about this >package, so I'll take over it. >[1] [2]http://lists.debian.org/debian-devel/2012/09/msg00563.html >Thanks. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120923003549.gi5...@onerussian.com
Re: PyCon 2013 -- anyone going? ideas for the talks?
On Fri, 21 Sep 2012, Thomas Kluyver wrote: > >Previously I have done a similar talk with an accent on a scientific > >Python stack in Debian [1] which I thought was quite well accepted. > We're having a big discussion on scipy-user at the moment about > formalising a scientific Python stack under the name Pylab. thanks -- I will check it out. I am subscribed only to scipy-dev so haven't spotted it (but there was an echo of it on numfocus ML) But now I have mentioned that I have forgotten to actually post [1]: [1] Halchenko, Y. O. (2011). π’s in Debian or Scientific Debian: NumPy, SciPy and beyond. Talk given at EuroScipy 2011, Paris, France. http://neuro.debian.net/_files/Halchenko_EuroScipy11_3_14s_in_Debian.pdf > > 2. tutorial on "Debian packaging of Python modules/software" > That reminds me: I'm doing a talk (~ 1/2 hour) at my local Python user > group on this topic, so I'd be interested to see any tutorials anyone > has already prepared. I'm not sure I'm really qualified to expound on > it, but I hope that I can give people some kind of mental map of > what's involved. eh -- I cannot recommend any specific tutorial, especially tailored toward Python (yet). Lucas' packaging-tutorial is quite nice but IMHO for 1/2 hour introduction into packaging tutorial should be more concise and more specific toward common situations with Python modules/extensions/apps packaging. But I would advise to repeat a few times that the first pre-requisite toward easy packaging is for the project to follow the standard procedures, i.e. using distutils (setuptools) and having a working setup.py, having clear specification of copyright/license terms and dependencies. Additional benefit -- having a good collection of unittests to be enabled at build time. With those ideas in the pocket, in 90% of the cases the basic packaging would be quite easy thanks to dh+dh_python[23] bundle. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120921181322.ge5...@onerussian.com
Re: PyCon 2013 -- anyone going? ideas for the talks?
On Fri, 21 Sep 2012, Barry Warsaw wrote: > >2. tutorial on "Debian packaging of Python modules/software" > I submitted something like this as one of three talk submissions last year, > though it was rejected (no reason given). That shouldn't deter you though, > because my submission probably sucked anyway and yours will be better! ;-) would you mind sharing yours? It might be of help to structure mine and to spot points desiring improvement ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120921165858.gy5...@onerussian.com
PyCon 2013 -- anyone going? ideas for the talks?
Hi everyone, Since the deadline for the submission of talks/tutorials for the PyCon 2013 is approaching (28th of Sep) I thought to check if anyone from the 'team' will be attending (Barry?) and may be someone already is planing to give a talk or might be even a tutorial? Debian-based systems become de-facto "the community Linux" in the Python world due to the simplicity of maintenance and deployment of Python software. But I think we still are far behind at promoting ourselves, so I thought it would be nice if "Debian" appears at PyCon (some corporate Linux-related entities are already among sponsors where Debian is unlikely to be listed). I am not sure yet if I would get any funds to attend but I am thinking about submitting two proposals for 1. talk on "The universal Python distribution or build your own stack" in many fields of endeavor people talk about stacks and python distributions which make easy to build/deploy suck stacks. So I thought that we should not be shy and present Debian as the best platform for anyone -- either ran on bare metal (preferable) or in a VM (for new adopters). But then we might have released wheezy which would be a good base for the talk -- present what fresh release has brought to the community in this stable environment. Previously I have done a similar talk with an accent on a scientific Python stack in Debian [1] which I thought was quite well accepted. 2. tutorial on "Debian packaging of Python modules/software" since tutorials are separate from the main registration (i.e. require separate payment if I got it right) I am not quite sure how many people would be interested to attend it. But I guess it should not hurt to submit one and for the committee to decide. Also it might be worth asking for a table/booth space (I think I saw that somewhere on pycon website) for the Debian project. I would be glad to get any feedback (i.e. "not worth the money/time spent", "you might like better to ...", ...) and recommendations on how to get funds for the trip (I will apply for the "financial aid" but more ideas e.g. "kickstarter project?", "I think my company might be interested to cover...", etc) ;) Cheers, -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120921131832.gs5...@onerussian.com
effects of numpy 1.7.0~b1 on sid
Thank you Sandro for pushing a fresh beta numpy to experimental. I have ran my scriptie to check what effects would that version have on build-dependees in sid (which currently might be well not the latest and greatest versions of packages): http://www.onerussian.com/Linux/deb/logs/python-numpy_1.7.0~b1-1_amd64.testrdepends.debian-sid/python-numpy_1.7.0~b1-1_amd64.testrdepends.debian-sid.summary first FAILED/ok column is when building against sid numpy version 1.6.2-1 and the second one is against 1.7.0~b1. Testing builds against python-numpy_1.7.0~b1-1.dsc aster_10.6.0-1-4.dscFAILED FAILED aster_10.6.0-1-4_amd64.build avogadro_1.0.3-5.dscFAILED ok babel_1.4.0.dfsg-8.dsc ok ok basemap_1.0.3+dfsg-2.dsc ok ok biosig4c++_1.3.0-2.dsc ok ok brian_1.3.1-1.dsc ok ok cfflib_2.0.5-1.dsc ok ok cmor_2.8.0-2.dsc ok ok connectomeviewer_2.1.0-1.dsc ok ok cython_0.15.1-2.dscok FAILED http://www.onerussian.com/Linux/deb/logs/python-numpy_1.7.0~b1-1_amd64.testrdepends.debian-sid/cython_0.15.1-2_amd64.build dballe_5.18-1.dsc ok ok dipy_0.5.0-3.dsc ok ok dolfin_1.0.0-7.dsc FAILED ok flann_1.7.1-4.dsc ok ok fonttools_2.3-1.dscok ok gamera_3.3.3-2.dsc ok ok gdal_1.9.0-3.dsc ok ok getfem++_4.1.1-10.dsc FAILED ok gnudatalanguage_0.9.2-4.dscok ok gnuradio_3.6.1-1.dscFAILED ok guiqwt_2.1.6-4.dsc FAILED ok h5py_2.0.1-2.dsc ok ok joblib_0.6.4-3.dsc ok ok lazyarray_0.1.0-1.dsc ok ok libfreenect_0.1.2+dfsg-6.dsc ok ok libgetdata_0.7.3-6.dsc ok ok libmpikmeans_1.5-1.dsc ok ok libvigraimpex_1.7.1+dfsg1-3.dscok FAILED http://www.onerussian.com/Linux/deb/logs/python-numpy_1.7.0~b1-1_amd64.testrdepends.debian-sid/libvigraimpex_1.7.1+dfsg1-3_amd64.build lintian_2.5.10.1.dscFAILED ok magics++_2.14.11-4.dsc ok ok mathgl_1.11.2-14.dscFAILED ok matplotlib_1.1.1~rc2-1.dsc FAILED ok mayavi2_4.1.0-1.dsc FAILED ok mdp_3.2+git78-g7db3c50-3.dsc ok ok mgltools-bhtree_1.5.6~rc3~cvs.20120206-1.dsc ok ok mgltools-dejavu_1.5.6~rc3~cvs.20120206-1.dsc ok ok mgltools-geomutils_1.5.6~rc3~cvs.20120601-1.dscok ok mgltools-gle_1.5.6~rc3~cvs.20120601-1.dsc ok ok mgltools-molkit_1.5.6~rc3~cvs.20120206-1.dsc ok ok mgltools-opengltk_1.5.6~rc3~cvs.20120601-1.dsc ok ok mgltools-pyglf_1.5.6~rc3~cvs.20120601-1.dscok ok mgltools-sff_1.5.6~rc3~cvs.20120601-1.dsc ok ok mgltools-utpackages_1.5.6~rc3~cvs.20120601-1.dsc ok ok mgltools-vision_1.5.6~rc3~cvs.20120601-1.dsc ok ok mgltools-visionlibraries_1.5.6~rc3~cvs.20120601-1.dsc ok ok mlpy_2.2.0~dfsg1-2.dsc ok ok mmass_5.2.0-2.dsc ok ok model-builder_0.4.1-6.dsc ok ok mpi4py_1.3+hg20120611-1.dscok ok mypaint_1.0.0-1.dscok ok necpp_1.5.0+cvs20101003-2.1.dscok ok neo_0.2.0-1.dscok ok nexus_4.2.1-svn1614-1.dsc FAILED ok nibabel_1.2.2-1.dscok ok nipy_0.2.0-1.dsc ok FAILED http://www.onerussian.com/Linux/deb/logs/python-numpy_1.7.0~b1-1_amd64.testrdepends.debian-sid/nipy_0.2.0-1_amd64.build nitime_0.4-2.dsc ok ok nlopt_2.2.4+dfsg-2.dsc ok ok numexpr_2.0.1-3.dsc FAILED FAILED http://www.onerussian.com/Linux/deb/logs/python-numpy_1.7.0~b1-1_amd64.testrdepends.debian-sid/numexpr_2.0.1-3_amd64.build numm_0.4-1.dsc FAILED ok opencv_2.3.1-11.dscok ok openmeeg_2.0.0.dfsg-5.dsc FAILED ok openopt_0.38+svn1589-1.dsc ok ok pandas_0.8.1-1.dsc ok ok pdb2pqr_1.8-1.dsc ok ok pebl_1.0.2-2.dsc ok ok plplot_5.9.9-5.dsc FAILED ok psignifit3_3.0~bet
Re: packaging under SVN and branching (unstable/experimental)
On Sun, 15 Jul 2012, Jakub Wilk wrote: > >question: is there any agreement/policy on how to handle (branch > >naming convention etc) if we are to maintain multiple versions > >(e.g. for stable/unstable/experimental). > Me, myself and I :P all agree that branches should be named after > version numbers, e.g.: > $ svn ls > svn://svn.debian.org/svn/python-modules/packages/python-docutils/branches/ > 0.5/ > 0.8.1/ ok -- since no other voice was raised -- I would follow the majority of 3 of you: I looked into python-docutils, trunk now tracks the experimental and I guess versioned branches would be dedicated to corresponding fixes to be uploaded to unstable/stable whatever... So I just followed your scheme and postponed any fancy branching -- just progressed the trunk to 0.16-1 uploaded to experimental ;) now will wait for dcommit to finish and will tag it... > However, using codenames (e.g. lenny, squeeze, squeeze-backports) > seems to be more popular amongst people who are not me. :) when I added "branches fetches" for my cython's git-svn it found some elderly squeeze branch from Piotr ;) Cheers -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120716161231.gf21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
On Mon, 16 Jul 2012, Scott Kitterman wrote: > OK. python-nipy depends on python-nipy-lib. Makes sense. > Is python-nipy-lib useful on it's own? nope -- moreover it might be somewhat detrimental -- module might appear to be "installed" while only extensions are there. That is the only disadvantage of such an approach. > It seems odd to me that it doesn't at > least Suggest python-nipy. and that is where I think circular dependencies are coming -- although I do not remember details and why I haven't had Suggest -- it clearly worth adding -- may be it is ok now ;-) ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120716150659.gd21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
On Mon, 16 Jul 2012, Scott Kitterman wrote:
> >> 1. python{3}-foo which is arch all and follows the current naming
> >convention
> >> of foo being the name you import. It would depend on the arch any
> >python-foo-
> >> ext package.
> >all -> any package dependencies are often icky, if you want them to be
> >strictly versioned. Probably not a showstopper, but something to be
> >aware of.
> Right now I'd just like to understand what is being proposed.
look at any of mine python-* packages having corresponding -lib package.
e.g.
$> apt-get source python-nipy
...
$> grep -e Package: -e Architecture:
nipy-0.2.0\~rc2+git27-g7b9b5a5/debian/control
Package: python-nipy
Architecture: all
Package: python-nipy-lib
Architecture: any
Package: python-nipy-lib-dbg
Architecture: any
Package: python-nipy-doc
Architecture: all
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20120716142418.gy21...@onerussian.com
packaging under SVN and branching (unstable/experimental)
may be it is still RTFM-level of question but I could not spot anything relevant on http://python-modules.alioth.debian.org/python-modules-policy.html and probably I have forgotten intrinsic details of svn-buildpackage (I am working with cython's repository under GIT via git-svn): question: is there any agreement/policy on how to handle (branch naming convention etc) if we are to maintain multiple versions (e.g. for stable/unstable/experimental). I am about to upload to experimental but later on there might be commits for previous version in unstable/wheezy -- would those changes go into a dedicated branch or just exercise the "branchy" nature of SVN tags and continue to work in the "tag" branch? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/2012071518.gp21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
> can we agree on a common suffix for such¹ packages and add a suggestion
> to Debian Python Policy?
> I use -ext (python-sqlalchemy-ext) but now I see that there are also
> -accel (python-reportlab-accel) and -lib (python-guppy-lib)
good idea... Now I somewhat like -ext more than -lib -- it is more Pythonic --
but I guess I am the biggest abuser with the -lib (codespeak is not mine).
Also -lib might actually be more factual -- it is not necessarily native
Pythonic extensions which would be provided there but might be other .so's
(native dynamic libraries etc -- just look inside python-numpy since
python-numpy-ext is apparently a transitional package since 2007 I found on my
drive ;) )
$> dpkg -l python-*-{lib,ext,accel}
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++--=-=-==
ii python-brian-lib 1.3.1-1+b1amd64 simulator for
spiking neural networks -- extensions
ii python-bson-ext 2.2-2 amd64 C-coded
extension to the python-bson package
un python-codespeak-lib (no
description available)
ii python-dipy-lib 0.5.0-3 amd64 toolbox for
analysis of MR diffusion imaging data -- e
un python-guppy-lib (no
description available)
ii python-mlpy-lib 2.2.0~dfsg1-2+b1 amd64 low-level
implementations and bindings for mlpy
ii python-mvpa-lib 0.4.8-1 amd64 low-level
implementations and bindings for PyMVPA
ii python-mvpa2-lib 2.1.0-1 amd64 low-level
implementations and bindings for PyMVPA v. 2
ii python-numpy-ext 1:1.3.0-3 all NumPy adds a
fast array facility to the Python languag
ii python-pandas-lib0.8.0-1 amd64 low-level
implementations and bindings for pandas
ii python-pymongo-ext 2.2-2 amd64 C-coded
extension to the python-pymongo package
ii python-reportlab-accel 2.5-1.1 amd64 C coded
extension accelerator for the ReportLab Toolki
un python-scikits-learn-lib (no
description available)
ii python-skimage-lib 0.6-1 amd64 Optimized
low-level algorithms for scikits-image
ii python-sklearn-lib 0.11.0-2 amd64 low-level
implementations and bindings for scikit-lear
ii python-sqlalchemy-ext0.7.8-1 amd64 SQL toolkit
and Object Relational Mapper for Python -
ii python-statsmodels-lib 0.4.0-2 amd64 low-level
implementations and bindings for statsmodels
On Thu, 12 Jul 2012, Piotr Ożarowski wrote:
> [Yaroslav Halchenko, 2012-07-11]
> > since our works were mentioned ;) -- yes, we generally split out python
> > extensions (and anything else arch-dep) into python-*-lib packages
> [¹] packages with split out (optional?) Python extensions
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20120713033030.gu21...@onerussian.com
Re: dh_python2 and large /usr/share/pyshared
On Tue, 10 Jul 2012, Scott Kitterman wrote: > >>>I: python-astropy: arch-dep-package-has-big-usr-share 4137kB 87% > >>> How do I create an arch independend package that contains these > >files? > >> [...] I'd rather not do that. You will likely end up with either > >> dependency loop or a package that is not useful for anything when > >> installed alone. > >Debian Developer's Reference section 6.7.5 (Architecture-independent > >data) recommends to do so, and I would just trust Lintian's > >recommendation here. > >Or are they outdated with todays disk capacities? > Neither devref nor Lintian are suicide pacts. It's good general advice, but > not to the point of creating dependency loops or broken packages. since our works were mentioned ;) -- yes, we generally split out python extensions (and anything else arch-dep) into python-*-lib packages primarily to minimize impact on the archive where we could achieve that -- we have a dozen of ports, so any MB makes ten-fold impact (and then do not forget snapshot.d.o). To overcome any dependency loop, arch:all depends on arch:any -lib and "broken packages" indeed could happen with annoying one when arch:any is installed without arch:all package. Then module is 'visible' since all the paths leading there present but most probably would not be importable/usable. It is easily resolvable (through installation of the corresponding arch:all package) and I rarely hear about it this from users. That is why I keep following this scheme for any new package of such kind despite that it requires a bit of ad-hoc actions in debian/rules. Hope this of some help ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120711141651.go21...@onerussian.com
Re: RFS: numpydoc/0.4-1 [RFP/ITP 559916]
On Tue, 12 Jun 2012, Denis Laxalde wrote: > >>Policy-compliant package name would be "python-numpydoc", but that > >>could be easily confused with "python-numpy-doc". So I agree with > >>your assessment: "python-numpydoc-sphinx" is a better for the binary > >>package. > >if it wouldn't be "convention compliant" anyways -- may be > >python-sphinx-numpydoc? there is already python-sphinx-issuetracker ... > But the namespace is numpydoc not sphinx, so it's even more > confusing, isn't it? that was just my .1 cents ;) yes, probably having namespace first with some kind of qualifier (-sphinx) is more logical. I just wondered if we could reach some unification for 'python-sphinx' related packages. ah -- we also have python-repoze.sphinx.autointerface providing /usr/share/pyshared/repoze/sphinx/autointerface.py -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120612181413.gb15...@onerussian.com
Re: RFS: numpydoc/0.4-1 [RFP/ITP 559916]
On Tue, 12 Jun 2012, Jakub Wilk wrote: > Policy-compliant package name would be "python-numpydoc", but that > could be easily confused with "python-numpy-doc". So I agree with > your assessment: "python-numpydoc-sphinx" is a better for the binary > package. if it wouldn't be "convention compliant" anyways -- may be python-sphinx-numpydoc? there is already python-sphinx-issuetracker ... actually it got renamed later on into python-sphinxcontrib.issuetracker. It might be worth checking with numpydoc people if they do not have plans on placing numpydoc under sphinxcontrib namespace just my .1 cents -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120612132716.gw15...@onerussian.com
Re: python3.2 'MODLIBS' includes -lffi (but not in Ubuntu)
On Mon, 28 May 2012, Jakub Wilk wrote:
> >while with python2 and python3.2 under Ubuntu 12.04 does not
> >include -lffi .
> Are you sure?
> $ dpkg-deb -x python3.2-minimal_3.2.3-0ubuntu1_i386.deb .
> $ grep LOCALMODLIBS.*ffi usr/lib/python3.2/config/Makefile
> LOCALMODLIBS= -lssl -lcrypto -lssl -lcrypto-lffi
> -L$(exec_prefix)/lib -lz -lexpat
now I am sure:
root@head2:/# python3.2 -c "from distutils.sysconfig import get_config_var;
print(get_config_var('MODLIBS'))"
-lssl -lcrypto -lssl -lcrypto-L/usr/lib -lz -lexpat
root@head2:/# dpkg -l python3.2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Description
+++-=-=-==
ii python3.2 3.2.3-0ubuntu3
Interactive high-level object-oriented language
(version 3.2)
so a reasonable "guess" that it is due to
python3.2 (3.2.3-0ubuntu3) precise-proposed; urgency=low
* Build _ctypes as an extension, not a builtin. LP: #909292.
* Mark symbols defined in the _ctypes extension as optional.
-- Matthias Klose Thu, 03 May 2012 13:20:08 +0200
and LP#909292 said to be the same as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665359
which is still open in Debian... heh
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20120531031252.gi11...@onerussian.com
Re: Current versions of Python on Debian Stable
FWIW -- if you don't find a cleaner way -- you could also bootstrap entire wheezy/sid in a chroot, install whatever you need to use there and then just provide a convenience wrapper /usr/local/bin/python2.7 in your stable installation which would invoke python2.7 from within the chroot. for a related example see http://neuro.debian.net/blog/2011/2011-12-12_schroot_fslview.html On Thu, 31 May 2012, ode wrote: > I would like to run Python 2.7 and 3.2 on Debian stable. They are > not in squeeze-backports. I would rather not install them from > Unstable as I do not want a mixed system. Do I have to compile them > myself or do you know of another trusted source that has backported > them to Squeeze. > Many Thanks -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120531030421.gh11...@onerussian.com
Re: python3.2 'MODLIBS' includes -lffi (but not in Ubuntu)
On Mon, 28 May 2012, Jakub Wilk wrote:
> >>python3.2 -c "from distutils.sysconfig import get_config_var;
> >>print(get_config_var('MODLIBS'))"
> >-lssl -lcrypto -lssl -lcrypto-lffi -L/usr/lib -lz -lexpat
> >while with python2 and python3.2 under Ubuntu 12.04 does not
> >include -lffi .
> Are you sure?
I was quite sure -- I logged into a clean 12.04 chroot and ran the
command and cut/pasted output -- could not go wrong! ;)
> $ dpkg-deb -x python3.2-minimal_3.2.3-0ubuntu1_i386.deb .
> $ grep LOCALMODLIBS.*ffi usr/lib/python3.2/config/Makefile
> LOCALMODLIBS= -lssl -lcrypto -lssl -lcrypto-lffi
> -L$(exec_prefix)/lib -lz -lexpat
now I am not 100% sure but ... I also got an email from MK confirming
that it is a bug and it would be fixed with the next upload (whenever that
would be)
> >Maybe some one has a ready answer?
> Does "do not use (LOCAL)MODLIBS" count as an answer? :)
;-) gygy -- thanks for such an in-depth answer since it works!
indeed such a blunt patch
--- a/setup.py
+++ b/setup.py
@@ -235,7 +235,7 @@ def executables():
for var in ('LIBDIR', 'LIBPL'):
library_dirs += split_quoted(cfgDict.get(var, ''))
for var in ('LDFLAGS',
-'LIBS', 'MODLIBS', 'SYSLIBS',
+'LIBS', 'SYSLIBS',
'LDLAST'):
link_args += split_quoted(cfgDict.get(var, ''))
# MPI-enabled Python interpreter
helps even with other failures and seems to not cause any new ;) Below
is the diff from unpatched build and patched build... hopefully within few days
I could wrap my head around WTF... or may be Bradley (CCed who was helping
with this package and pushed python3 packaging) could confirm that this is a
logical thing to do ;) (I have pushed the patch for now to alioth's git)
@@ -203,30 +182,7 @@
building 'python2.7-mpi' executable
/usr/bin/mpicc.openmpi -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -I/usr/include/python2.7 -c src/python.c -o
build/temp.linux-x86_64-2.7/src/python.o
creating build/exe.linux-x86_64-2.7
-/usr/bin/mpicc.openmpi -Wl,-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.7/src/python.o -L/usr/lib/python2.7/config
-lpython2.7 -o build/exe.linux-x86_64-2.7/python2.7-mpi -Wl,-z,relro -lpthread
-ldl -lutil -lssl -lcrypto -lssl -lcrypto -L/usr/lib -lz -lm
-/usr/lib/libmpi.so: undefined reference to `MPL_trid'
-/usr/lib/libmpi.so: undefined reference to `MPL_trvalid'
-/usr/lib/libmpi.so: undefined reference to `MPL_env2int'
-/usr/lib/libmpi.so: undefined reference to `MPL_trrealloc'
-/usr/lib/libmpi.so: undefined reference to `MPL_trspace'
-/usr/lib/libmpi.so: undefined reference to `MPL_trDebugLevel'
-/usr/lib/libmpi.so: undefined reference to `MPL_TrSetMaxMem'
-/usr/lib/libmpi.so: undefined reference to `MPL_trlevel'
-/usr/lib/libmpi.so: undefined reference to `MPL_trmalloc'
-/usr/lib/libmpi.so: undefined reference to `MPL_putenv'
-/usr/lib/libmpi.so: undefined reference to `MPL_env2bool'
-/usr/lib/libmpi.so: undefined reference to `MPL_env2range'
-/usr/lib/libmpi.so: undefined reference to `MPL_trcalloc'
-/usr/lib/libmpi.so: undefined reference to `MPL_trfree'
-/usr/lib/libmpi.so: undefined reference to `MPL_env2str'
-/usr/lib/libmpi.so: undefined reference to `MPL_trstrdup'
-/usr/lib/libmpi.so: undefined reference to `MPL_trdump'
-/usr/lib/libmpi.so: undefined reference to `MPL_trinit'
-collect2: ld returned 1 exit status
-warning: build_exe: building extension "python2.7-mpi" failed
-
-warning: build_exe: command '/usr/bin/mpicc.openmpi' failed with exit status 1
-
+/usr/bin/mpicc.openmpi -Wl,-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.7/src/python.o -L/usr/lib/python2.7/config
-lpython2.7 -o build/exe.linux-x86_64-2.7/python2.7-mpi -Wl,-z,relro -lpthread
-ldl -lutil -lm
: # Build for Python 3
set -e; for v in 3.2; do \
python$v setup.py build \
@@ -319,13 +275,7 @@
building 'python3.2-mpi' executable
/usr/bin/mpicc.openmpi -fPIC -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-I/usr/include/python3.2mu -c src/python.c -o
build/temp.linux-x86_64-3.2/src/python.o
creating build/exe.linux-x86_64-3.2
-/usr/bin/mpicc.openmpi -Wl,-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-3.2/src/python.o -L/usr/lib/python3.2/config-3.2mu
-lpython3.2 -o build/exe.linux-x86_64-3.2/python3.2-mpi -Wl,-z,relro -lpthread
-ldl -lutil -lssl -lcrypto -lssl -lcrypto -lffi -L/usr/lib -lz -lexpat -lm
-/usr/bin/ld: cannot find -lffi
-collect2: ld returned 1 exit status
-warning: build_exe: building extension "python3.2-mpi" failed
-
-warning: build_exe: command '/usr/bin/mpicc.openmpi' failed with exit status 1
-
+/usr/bin/mpicc.openmpi -Wl,-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-3.2/src/python.o -L/usr/lib/python3.2/config-3.2mu
-lpython3.2 -o build/exe.linux-x86_64-3.2/python3.2-mpi -Wl,-z,relro -lpthr
python3.2 'MODLIBS' includes -lffi (but not in Ubuntu)
Since it is getting late I decided to just ask
Bradley M. Froehle is helping out with python3-mpi4py and we ran into an
interesting effect that clean chroot fails to build under Debian sid due
to -lffi (while libffi-dev is nohow pulled in through build-depends)
> python3.2 -c "from distutils.sysconfig import get_config_var;
> print(get_config_var('MODLIBS'))"
-lssl -lcrypto -lssl -lcrypto-lffi -L/usr/lib -lz -lexpat
while with python2 and python3.2 under Ubuntu 12.04 does not include
-lffi . Those are defined in
> grep LOCALMODLIBS= "/usr/lib/python3.2/config-3.2mu/Makefile"
LOCALMODLIBS= -lssl -lcrypto -lssl -lcrypto-lffi -L$(exec_prefix)/lib
-lz -lexpat
which is
> head "/usr/lib/python3.2/config-3.2mu/Makefile"
# Generated automatically from Makefile.pre by makesetup.
# Top-level Makefile for Python
...
but I haven't checked where it gets those libraries listing from and why
it picks up ffi exclusively in Debian sid. Maybe some one has a ready answer?
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20120523024209.gb11...@onerussian.com
Re: Double build failures
On Fri, 04 May 2012, Jakub Wilk wrote:
> * Yaroslav Halchenko , 2012-05-04, 13:29:
> >>>Most of the time, the failures are because of the created egg
> >>>directory that is not cleaned up by the clean target of
> >>>setup.py. While I could add the appropriate bits to each clean
> >>>target in debian/rules, it seems better to fix the problem
> >>>either in dh_python2 or in setuptools. Any thoughts?
> >>IMHO it is a better fit in dh_auto_clean (python_distutils
> >>buildsystem) and or dh_clean.
> >+100 for dh_auto_clean ;-)
> #652617
> But... Have you read python_distutils.pm source? I did and then
> couldn't sleep for a few nights. ;) So I can't second the idea of
> adding even more dubious logic to it.
LOL
I just don't know perl (un)fortunately to provide a clean patch... nor out of
my ignorance I am sure on the purpose of distributing .egg-info/ by
upstreams
$> zgrep .egg-info deb/docs/Contents-sources.gz | f1 | uniq | wc -l
365
so the question would also be either they get modified at package build-time so
that original versions would need to be placed aside (similar to what
dh_autoreconf does?) and then reverted back upon clean. So general resolution
could go a bit aside of just 'cleaning' through
* preserve present .egg-info somewhere (where below find would not find ;) )
* add to sub clean
$this->doit_in_sourcedir('find', '.', '-name', '*.egg-info', '-exec', 'rm',
'-rf', '{}', ';');
* bring them back and destroy the original copy
or if nothing get modified just remembering the list of them and
excluding them from clean up procedure
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20120504183023.gq9...@onerussian.com
Re: Double build failures
On Fri, 04 May 2012, Dmitrijs Ledkovs wrote: > > Most of the time, the failures are because of the created egg directory > > that is not cleaned up by the clean target of setup.py. While I could > > add the appropriate bits to each clean target in debian/rules, it seems > > better to fix the problem either in dh_python2 or in setuptools. Any > > thoughts? > IMHO it is a better fit in dh_auto_clean (python_distutils buildsystem) > and or dh_clean. +100 for dh_auto_clean ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120504172943.ge9...@onerussian.com
Re: PyPI to Debian repository converter (GSoC 2012 project)
additional few cents which might come handy if you decide to go that way 1. I would recommend to override matplotlib backend to Agg before running tests 2. set HOME to build/ (or some other temp directory) to prevent common problems for those projects which use matplotlib in some of the tests if interested in how I do it, here would be an example: https://github.com/neurodebian/pandas/blob/debian/debian/rules#L54 On Mon, 30 Apr 2012, Yaroslav Halchenko wrote: > > will appear. One of challenges will be determining dependencies > > required during build process. > With such a massive automated "packaging" it would be great if from day > 0 you would think about adding build-time testing into the > pipeline. It should be quite easy to discover if module carries any > unittests (grep for unittest ;) ) and what should be the way to run them > (many modules provide .test(), or are testable with 'nosetest module'). > It would provide you assurance that generated packages are usable by the > users, thus reduce future frustration / bug reports about broken > packages. > Just my .1 cents. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20120430161358.gy9...@onerussian.com
Re: PyPI to Debian repository converter (GSoC 2012 project)
On Mon, 30 Apr 2012, Natalia Frydrych wrote: > Please note, that the tool that I intend to write, will be designed to > convert as many PyPI packages as possible and making them available in > a deb repository (for the selected version of Debian), and then update > them when new versions of existing libraries or brand new libraries > will appear. One of challenges will be determining dependencies > required during build process. With such a massive automated "packaging" it would be great if from day 0 you would think about adding build-time testing into the pipeline. It should be quite easy to discover if module carries any unittests (grep for unittest ;) ) and what should be the way to run them (many modules provide .test(), or are testable with 'nosetest module'). It would provide you assurance that generated packages are usable by the users, thus reduce future frustration / bug reports about broken packages. Just my .1 cents. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20120430150405.gs9...@onerussian.com
Re: autopkgtest'ing against multiple Python versions
On Mon, 23 Apr 2012, Jakub Wilk wrote: > Maybe it was not a good example after all. :) I just realized that, > according to adt-run, the tests were failed. I didn't notice this > before because there was nothing at the end of adt-run's output that > would indicate that something went awry. > The “failures” was caused by the following misfeature of the > specification: “if a test […] prints to stderr, it is considered to > have failed.” But nosetests does print stuff to stderr even if > everything is all right (see bug #460242). yikes -- doesn't it fail if underlying "test command" returns with non-0 exit code? IMHO that should be the criterion, not catching stderr, which might have some spurious output from tests which might be testing either application handles erroneous cases correctly (where it might output to stderr). -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20120423131730.gq9...@onerussian.com
Re: autopkgtest'ing against multiple Python versions
Cool, Jakub, 3 (enhanced with Recommends) sounds like a perfect solution to me as well... if only someone hacked it up for autopkgtest? would you also mind pointing to the 'best of the breed' package fro which you have created an autopkgtest pkg? > (since then you do want to install python-all). This issue could be > fixed if autopkgtest supported weak dependencies, e.g.: > Tests: test-installed > Depends: python-pet-module > Recommends: python-all -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20120421232425.gz9...@onerussian.com
Re: Packaging python-mocker and cloud-init in Debian ?
Indeed would be neat to get those into Debian. FWIW python-mocker seems to be already in experimental since A WHILE ( 02 Sep 2010 ), needs some TLC and push into unstable I guess ;-) I haven't looked into packaging of cloud-init, just blindly built it and lintianed: W: cloud-init source: missing-file-from-potfiles-in grub.templates W: grub-legacy-ec2: binary-without-manpage usr/sbin/grub-set-default W: grub-legacy-ec2: binary-without-manpage usr/sbin/grub-set-default-legacy-ec2 W: grub-legacy-ec2: binary-without-manpage usr/sbin/update-grub-legacy-ec2 W: cloud-init: binary-without-manpage usr/bin/cloud-init W: cloud-init: binary-without-manpage usr/bin/cloud-init-cfg W: cloud-init: binary-without-manpage usr/bin/cloud-init-per N: 3 tags overridden (2 errors, 1 warning) Would you guys (Scott and Rodney) be interested to polish up packaging a bit so it complies with standards I think I could review/sponsor your uploads into Debian.Rudimentary manpages might come useful... or may be enabling those scripts to handle --help gracefully and just use help2man to generate the manpages "for free" Cheers, -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20120319023331.gl22...@onerussian.com
Re: Numpy & dh_python2
preceeding comment kinda describes it all: # GIGANTIC HACK - add back libnpymath.a # get the file names, generate the new location, create the dir if missing, copy # the file and then add it to the public list so it just adds those few trailing lines with libnpymath.a . I am really not an expert in dh_pysupport but .public files seems to serve per-package registry of supported Python versions and public modules and extensions so pysupport would know what to compile/symlink in its /usr/sbin/update-python-modules. So, my blunt guess would be that with dh_python2 you would not need this and just would need to place the .a appropriately. > I was looking at packaging numpy for Python 3 (bug #601593, LP > #795605). As a step towards this, I was trying to convert it from > pysupport to dh_python2, following the 'transition to dh_python2' > guide. But I hit a section that I don't really understand, in > override_dh_pysupport: > # add to public modules list ;\ > echo $$installedfile >> > ./debian/python-numpy/usr/share/python-support/python-numpy.public ;\ > What's the significance of the public modules list? Is there an > equivalent for dh_python2? > Thanks, > Thomas -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20120315124513.gr16...@onerussian.com
