Re: python-argcomplete salvaging and possible team (re)join

2022-05-13 Thread Yaroslav Halchenko
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

2022-04-25 Thread Yaroslav Halchenko
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

2022-04-21 Thread Yaroslav Halchenko
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

2021-05-13 Thread Yaroslav Halchenko
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

2021-03-03 Thread Yaroslav Halchenko


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')

2020-12-08 Thread Yaroslav Halchenko
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?)

2019-01-22 Thread Yaroslav Halchenko
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

2018-10-08 Thread Yaroslav Halchenko
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?

2018-09-10 Thread Yaroslav Halchenko


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?

2018-09-10 Thread Yaroslav Halchenko


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

2018-07-18 Thread Yaroslav Halchenko
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?

2018-06-04 Thread Yaroslav Halchenko

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?

2018-06-04 Thread Yaroslav Halchenko
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

2018-04-03 Thread Yaroslav Halchenko

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)

2018-01-15 Thread Yaroslav Halchenko
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)

2017-10-10 Thread Yaroslav Halchenko

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

2017-09-30 Thread Yaroslav Halchenko
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

2017-09-26 Thread Yaroslav Halchenko

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

2017-09-24 Thread Yaroslav Halchenko

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

2017-09-23 Thread Yaroslav Halchenko

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

2017-09-23 Thread Yaroslav Halchenko

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

2017-09-21 Thread Yaroslav Halchenko

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 <deb...@onerussian.com>  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

2017-09-21 Thread Yaroslav Halchenko
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?

2017-06-20 Thread Yaroslav Halchenko

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

2016-12-07 Thread Yaroslav Halchenko
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

2016-12-07 Thread Yaroslav Halchenko
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

2016-04-19 Thread Yaroslav Halchenko
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: pybuild and proxies -- could we make prohibition optional?

2015-07-22 Thread Yaroslav Halchenko

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



pybuild and proxies -- could we make prohibition optional?

2015-07-21 Thread Yaroslav Halchenko
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: pybuild and proxies -- could we make prohibition optional?

2015-07-21 Thread Yaroslav Halchenko
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 pi...@debian.org 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.

Re: Sphinx 1.3 in Debian experimental

2015-05-07 Thread Yaroslav Halchenko

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

2015-05-06 Thread Yaroslav Halchenko

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



who is going to PyCon?

2015-04-03 Thread Yaroslav Halchenko
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?

2014-11-09 Thread Yaroslav Halchenko

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 deb...@onerussian.com  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 moiein2...@gmail.com
+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, char 
*bytesattr.name)
++name = bytesattr.name
++attr.index = glGetAttribLocation(self.program, char *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 m...@kivy.org
+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 = bytesself.uri.encode('utf-8')
+-g_object_set_void(self.playbin, 'uri', c_uri)
++py_uri = bytesself.uri.encode('utf-8')
++g_object_set_void(self.playbin, 'uri', char *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

Re: Trying to build python3 version of scikit-learn, python3-* pkgs come out empty

2014-11-05 Thread Yaroslav Halchenko
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 t...@neuro.debian.net
 Uploaders: Yaroslav Halchenko deb...@onerussian.com, Michael Hanke 
 michael.ha...@gmail.com
 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:Depends}, ${python:Depends}, python-numpy
 Provides: ${python:Provides}
 Description: low-level implementations and bindings for scikit-learn
  This is an add-on package for python-sklearn. It provides
  low-level implementations and custom Python bindings for the LIBSVM
  library.
  .
  This is the Python 2 version.

 Package: python3-sklearn-lib
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}, ${python3:Depends

Re: Trying to build python3 version of scikit-learn, python3-* pkgs come out empty

2014-11-05 Thread Yaroslav Halchenko
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 pi...@debian.org 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: Preventing network access during nose doctest ?

2014-05-12 Thread Yaroslav Halchenko


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 string, line 1, in module
  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: urlopen error [Errno 111] Connection refused

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

2014-04-06 Thread Yaroslav Halchenko

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

2014-04-03 Thread Yaroslav Halchenko
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?

2014-03-31 Thread Yaroslav Halchenko

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 module
  import HTSeq
File /usr/lib/python2.7/dist-packages/HTSeq/__init__.py, line 9,
  in module
  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

2014-02-13 Thread Yaroslav Halchenko

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



pprocess packaging SVN

2013-12-12 Thread Yaroslav Halchenko
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: pprocess packaging SVN

2013-12-12 Thread Yaroslav Halchenko

On Thu, 12 Dec 2013, Dmitry Shachnev wrote:

 On Thu, Dec 12, 2013 at 6:34 PM, Yaroslav Halchenko
 deb...@onerussian.com 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=revisionrevision=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



Re: Trim out Ubuntu entries in d/changelog?

2013-12-07 Thread Yaroslav Halchenko
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 paul...@ubuntu.com 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

2013-11-28 Thread Yaroslav Halchenko
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



PyCon 2013 -- anyone submitted/planing to go?

2013-09-05 Thread Yaroslav Halchenko
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: PyCon 2013 -- anyone submitted/planing to go?

2013-09-05 Thread Yaroslav Halchenko


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



Re: dh-python in unstable

2013-08-02 Thread Yaroslav Halchenko
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

2013-07-09 Thread Yaroslav Halchenko
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 mo...@debian.org wrote:

On Mon, Jul 8, 2013 at 4:10 PM, Scott Kitterman deb...@kitterman.com
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)

2013-05-19 Thread Yaroslav Halchenko

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

2013-05-07 Thread Yaroslav Halchenko
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!

2013-03-21 Thread Yaroslav Halchenko

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 ~/

2013-02-12 Thread Yaroslav Halchenko
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

2013-02-06 Thread Yaroslav Halchenko
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 ba...@python.org 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

2013-01-19 Thread Yaroslav Halchenko
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

2012-10-02 Thread Yaroslav Halchenko
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/abstract/outline -- feedback plz - v.2

2012-09-28 Thread Yaroslav Halchenko
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

2012-09-28 Thread Yaroslav Halchenko

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

2012-09-28 Thread Yaroslav Halchenko

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

2012-09-28 Thread Yaroslav Halchenko

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 - v.2

2012-09-28 Thread Yaroslav Halchenko

 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 pi...@debian.org
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/description/abstract -- v.3 (submitted)

2012-09-28 Thread Yaroslav Halchenko
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

2012-09-27 Thread Yaroslav Halchenko
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 wag...@fitug.de
 Date: Fri, 7 Aug 1998 09:27:05 +0200
 Message-id: 19980807092705.j25...@beuel.rhein.de
 Reply-to: Hanno Wagner wag...@fitug.de

 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: open



 Have a nice start,

 Ciao, Hanno, one of listmas...@lists.debian.org
 -- 
 |  Hanno Wagner  | Member of the HTML Writers Guild  | Rince@IRC  |
 | Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
 | 74 a3 53 cc 0b 19 - we did it!  |Generation @   |

 #Fachbegriffe der Informatik einfach erklaert, Teil 69

Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz

2012-09-27 Thread Yaroslav Halchenko
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

2012-09-27 Thread Yaroslav Halchenko
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...@onerussian.com



Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2

2012-09-27 Thread Yaroslav Halchenko
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 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

PyCon 2013 -- tentative title/abstract/outline -- feedback plz

2012-09-26 Thread Yaroslav Halchenko
)
python2 (2.0-1) unstable; urgency=low

  * New upstream version. Initial release for python2.

 -- Gregor Hoffleit fli...@debian.org  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 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

Re: python-twitter is not maintained

2012-09-22 Thread Yaroslav Halchenko
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



PyCon 2013 -- anyone going? ideas for the talks?

2012-09-21 Thread Yaroslav Halchenko
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



Re: PyCon 2013 -- anyone going? ideas for the talks?

2012-09-21 Thread Yaroslav Halchenko

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



Re: PyCon 2013 -- anyone going? ideas for the talks?

2012-09-21 Thread Yaroslav Halchenko

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



effects of numpy 1.7.0~b1 on sid

2012-09-05 Thread Yaroslav Halchenko
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

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Yaroslav Halchenko

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



Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Yaroslav Halchenko

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: packaging under SVN and branching (unstable/experimental)

2012-07-16 Thread Yaroslav Halchenko

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



packaging under SVN and branching (unstable/experimental)

2012-07-15 Thread Yaroslav Halchenko
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

2012-07-12 Thread Yaroslav Halchenko
 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 none  (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 none  (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 none  (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

2012-07-11 Thread Yaroslav Halchenko

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]

2012-06-12 Thread Yaroslav Halchenko

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)

2012-05-30 Thread Yaroslav Halchenko

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 d...@ubuntu.com  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



python3.2 'MODLIBS' includes -lffi (but not in Ubuntu)

2012-05-22 Thread Yaroslav Halchenko
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

2012-05-04 Thread Yaroslav Halchenko

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: Double build failures

2012-05-04 Thread Yaroslav Halchenko

On Fri, 04 May 2012, Jakub Wilk wrote:

 * Yaroslav Halchenko deb...@onerussian.com, 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: PyPI to Debian repository converter (GSoC 2012 project)

2012-04-30 Thread Yaroslav Halchenko

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

2012-04-23 Thread Yaroslav Halchenko

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

2012-04-21 Thread Yaroslav Halchenko

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: Numpy dh_python2

2012-03-15 Thread Yaroslav Halchenko
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



Re: python-tornado Python 3

2012-03-13 Thread Yaroslav Halchenko
Thank you guys!

pushed very minor change for my own sanity ;)

I will upload (to Debian sid/unstable) shortly if I would not run into any 
showstopper

Cheers!

On 13 March 2012 21:40, Julian Taylor [1]jtaylor.deb...@googlemail.com
wrote:

  thanks for the patch, I have applied it to the team repository along
  with some more minor fixes to other parts of the package.
  
 [2]http://anonscm.debian.org/viewvc/python-modules/packages/python-tornado/trunk/

Great, thanks Julian.
�

  I think its ready for an upload.

Is that something I should do? Where does it get uploaded to?

Best wishes,
Thomas

 References

Visible links
1. mailto:jtaylor.deb...@googlemail.com
2. 
 http://anonscm.debian.org/viewvc/python-modules/packages/python-tornado/trunk/

-- 
=--=
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/20120313220609.gr16...@onerussian.com



Re: python-tornado Python 3

2012-03-12 Thread Yaroslav Halchenko
well -- it might be beneficial meanwhile to share your changes one way
or another (patch, git, mentors) so someone could review them

Thanks, Yaroslav,

On 9 March 2012 14:31, Yaroslav Halchenko [1]deb...@onerussian.com
wrote:

  the best way would be �to join Debian Python Modules Team and help
  maintaining this library in Debian by directly committing to team's SVN
  repository and then seeking review/sponsorship.

I'll try to follow this route. I've got an alioth account, and applied for
membership of DPMT - do I need to do anything to get the membership
approved, or is it just a question of waiting until someone has time for
it?

Best wishes,
Thomas

 References

Visible links
1. mailto:deb...@onerussian.com

-- 
=--=
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/20120312144917.gt16...@onerussian.com



Re: python-tornado Python 3

2012-03-09 Thread Yaroslav Halchenko
Hi Thomas,

the best way would be  to join Debian Python Modules Team and help
maintaining this library in Debian by directly committing to team's SVN
repository and then seeking review/sponsorship.

Meanwhile, you could upload your packaging to mentors.debian.org and
seek review/sponsorship.  Alternatively, you could seek review by
pushing your changes into GIT on top of my git-svn'ed official
python-tornado package SVN at
http://github.com/yarikoptic/tornado-debian
but I hope you would choose the 'best way'

Cheers

Hello,

Using the recently posted style guide for Python libraries
([1]http://wiki.debian.org/Python/LibraryStyleGuide), I've updated the
packaging of python-tornado to build a python3-tornado package as well.
This is a test case, and I hope to do the same for other packages once I'm
comfortable with the process. Can someone point me to the best way to
submit the packaging change to Debian, bearing in mind that I'm not really
familiar with the procedures and terminology around Debian?

Thanks,
Thomas Kluyver

 References

Visible links
1. http://wiki.debian.org/Python/LibraryStyleGuide

-- 
=--=
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/20120309143122.gr16...@onerussian.com



Re: packaging pyreport

2012-03-03 Thread Yaroslav Halchenko
so -- if you are keen on pretty much developing a fork further and
maintaining existing codebase...

packaging -- there is a bulk of tutorials on packaging (e.g. apt-get
install packaging-tutorial), and you can kick start your packaging
simply by adopting debian/ of another simple python module of your
choice.

Hi Yaroslav,

Thanks for your reply.
I had asked Ga�l some time ago (less than one year I think) what his plans
for pyreport were. He had replied that he did not have any time to develop
it anymore.
However, I think that i have some ideas to maintain pyreport and I'm
currently trying to add some features to repyreport, but this is not worth
commiting them for the moment.

Jean
-- 
=--=
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/20120303183742.gu16...@onerussian.com



Re: packaging pyreport

2012-03-01 Thread Yaroslav Halchenko
Hi Jean, Hi Gael,

I would recommend first to check with Gael (CCed) on what is his plans
toward pyreport... with the availability of ipython notebook I think he
might not be considering developing/maintaining pyreport any further.
Gael?

 Hi,

 I have been using pyreport for some time now and I would like it to be
 a part of Debian.
 As the official website says:
 pyreport is a program that runs a python script and captures its
 output, compiling it to a pretty report in a pdf or an html file. It
 can display the output embedded in the code that produced it and can
 process special comments (literate comments) according to markup
 languages ( rst or LaTeX ) to compile a very readable document.

 You can find a complete description and some examples at:
 http://gael-varoquaux.info/computers/pyreport/

 I would like to package this application but I do not have any skills
 in the packaging process yet. So if some people would be ready to give
 some advices, help or just write that they are currently using
 pyreport, that would be very nice !
 I will send an ITP email and begin to create the package very soon.

 Thanks,

 Jean Felder
-- 
=--=
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/20120301164741.gm16...@onerussian.com



Re: RFS nuitka

2012-01-02 Thread Yaroslav Halchenko

On Mon, 02 Jan 2012, Kay Hayen wrote:
 ii (somewhat preferable). remove scons from within .orig.tar.gz
 (optionally add +dfsg or .dfsg suffix to the version making it
 0.3.17~pre2+dfsg-1)
 Done that. Although it was kind of hurtful to integrate. :-) Is
 there really nobody who has a tool to take upstream tars and remove
 files from it? For starters tar --delete hates to work on
 compressed archives...

well, AFAIK there is no standard tool but there is plenty of crafty ways

* git-import-orig (from git-buildpackage) has options to specify which
  ones to prune while importing a new upstream tarball (so it is not
  preferable way for you since you are upstream ;-) )

* once I had wrote a little helper for myself
  http://anonscm.debian.org/viewvc/pkg-exppsy/tools/dh_wraporig?view=markup
  which I had used for many cases like this, it was also autogenerating
  README.Debian-source
  which summarized the changes

* custom get-orig-source rule in debian/rules -- most popular way to
  automate things of this kind ;)


since you are using git, you might also like simply to tune up
.gitattributes to exclude undesired pieces from the generated by git
archive tarball


 That was a lot of work, but I believe it's now good. It's a pity
 that the tool seems to not integrate with debian/copyright file.

the structure of it wasn't standardized before so it was nearly
impossible... now with DEP-5 something like that could be done and I
believe there were some recent discussions

 across releases (and architectures if anyone rebuilds it there ;) )
 I have added it. They are now run at build time.
 ...
 Actually I believe that Squeeze (6.x) is not supposed to work. And
 also Ubuntu 11.04 isn't, although with lesser certainty. They won't
 work due to missing dependencies I b lieve.

 Maybe it is because Nuitka was not run as part of the build process
 yet. 

I think so too... meanwhile, here
http://www.onerussian.com/tmp/nuitka-logs.tgz
fetch build logs for your most recent package (fails everywhere
now -- thanks to tests ;) )

it would be great if for every upload you verify that package builds
fine in a clean chroot ;-)

 The control file is having:

 Build-Depends: debhelper (= 7.4.3), python (= 2.6.6-3)
 Depends: g++-4.6 (= 4.6.1), scons (=2.0.1), ${misc:Depends},
 ${python:Depends}

 I was thinking that the run time dependency would also be checked at
 build time. And now I believe, that the new package will fail for
 you due to that, so I added them for the next upload.

 Is there a generic way to achieve that? I mean other than to copy
 them to both? For now I copied them over (it's only 2), but I am
 curious if there is a better way.

AFAIK (would be great if someone corrects me) -- besides some
somewhat over-engineered ways to generate debian/control from
debian/control.in or smth like that, there is no good way, so specifying
them both in depends and build-depends is what I have been doing.

-- 
=--=
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/20120102213417.gr16...@onerussian.com



Re: RFS nuitka

2012-01-02 Thread Yaroslav Halchenko

On Tue, 03 Jan 2012, Kay Hayen wrote:

 * custom get-orig-source rule in debian/rules -- most popular way to
automate things of this kind ;)
 That's just where to put it, not what to put there?

yeap... what could indeed be either a call to dh_wraporig or just a
tandem of two tar commands (one to extract, another one to compress
again with a set of --exclude  options). 

N.B. I am somewhat surprised that tar itself doesn't have an option
 to filter a tar archive applying --exclude to a stream from STDIO


 Yeah yeah. :-)

 I had installed the pbuilder stuff and things, but honestly,
 normally I don't see much point, once it will be working again.
 Mostly because the binary package contains no binaries and the tame
 dependencies.

;-)  you would be surprised ...   there is dozen of reasons not to
mention that some (e.g. me) make it a requirement for sponsored
uploads... here is few:

- since upload happens to debian sid (AKA unstable) it might have newer
  versions that what you have on your system, thus building in an
  up-to-date sid chroot would be beneficial to spot fresh
  incompatibilities/problems earlier than later

- building in a clean environment also provides better
  assurance that package would build for anyone trying to build it later
  on


 And I even predicted it, but couldn't fix it anymore. I knew it was
 flawed, but mentors.debian.net won't let me upload any -2 ever,
 presumably due to the changed orig source.

yeap -- .orig for a given upstream version, once uploaded must
not change ;-), thus shouldn't even be uploaded in general for -2, -3,
... debian revisions.  

-- 
=--=
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/20120102235824.gs16...@onerussian.com



Re: RFS nuitka

2012-01-01 Thread Yaroslav Halchenko
Happy New Year!

so let's begin ;)

1. version
0.3.17pre2-1

if 'pre' means  prior 0.3.17, then make it 0.3.17~pre2-1 otherwise
it would sort after (use dpkg --compare-versions  in cmdline if you want
to check for sure how versions get sorted)

2.  debian/copyright

a. separate main copyright statement into separate paragraph (separated
with empty line) with

Files: *

b. nuitka/build/static_src/arm_ucontext_src/getcontext.asm

you should copy that MIT style license verbatim into debian/copyright
and also that file contains 1 more copyright/license for some snippets
in the code of that file

3.  debian/patches/remove-inline-scons

removing scons with patch like this is not quite the right way... two
possibilities

i. don't remove scons but just (minimalistic patch) make system wide
used

  then you would need still to add its copyright/license into
  debian/copyright, just add a comment that those are not used

ii (somewhat preferable). remove scons from within .orig.tar.gz
(optionally add +dfsg or .dfsg suffix to the version making it
0.3.17~pre2+dfsg-1)


4. go through the output of licensecheck -r --copyright .
and fill entries for them in debian/copyright: e.g. I find things like

./tests/benchmarks/pybench/pybench.py: UNKNOWN
  [Copyright: , 2000-2006, eGenix.com Software GmbH (i...@egenix.com) / , 
1997-2006, Marc-Andre Lemburg (m...@lemburg.com) / assignment to the code, or 
in the]

5. you do have unittests, why don't excercize them during build time
(override_dh_auto_test)?  that would assure that it functions correctly
across releases (and architectures if anyone rebuilds it there ;) )

sorry -- now family time 

otherwise FWIW package seems to build nicely across most of recent
debian/ubuntu releases:

nuitka_0.3.17pre2-1_amd64.build OK  0:39.27 real, 23.32 user, 11.13 sys, 337464 
out
nuitka_0.3.17pre2-1~nd50+1_amd64.build  FAILED  0:10.87 real, 3.24 user, 2.25 
sys, 55704 out
nuitka_0.3.17pre2-1~nd60+1_amd64.build  OK  0:35.42 real, 19.53 user, 9.62 sys, 
220960 out
nuitka_0.3.17pre2-1~nd70+1_amd64.build  OK  0:40.50 real, 24.46 user, 10.47 
sys, 326920 out
nuitka_0.3.17pre2-1~nd+1_amd64.buildOK  0:40.20 real, 24.28 user, 10.22 
sys, 325848 out
nuitka_0.3.17pre2-1~nd08.04+1_amd64.build   FAILED  0:13.14 real, 4.48 user, 
3.13 sys, 63792 out
nuitka_0.3.17pre2-1~nd09.10+1_amd64.build   FAILED  0:13.52 real, 3.88 user, 
3.03 sys, 69544 out
nuitka_0.3.17pre2-1~nd10.04+1_amd64.build   FAILED  0:19.92 real, 5.42 user, 
4.86 sys, 83824 out
nuitka_0.3.17pre2-1~nd10.10+1_amd64.build   FAILED  0:14.55 real, 5.64 user, 
3.40 sys, 94560 out
nuitka_0.3.17pre2-1~nd11.04+1_amd64.build   OK  0:59.51 real, 35.69 user, 16.09 
sys, 211232 out
nuitka_0.3.17pre2-1~nd11.10+1_amd64.build   OK  0:50.39 real, 30.28 user, 14.37 
sys, 369608 out




On Sat, 31 Dec 2011, Kay Hayen wrote:


 Dear Debian Python Team,

 I am out of review comments for the package of mine:

  * Package name: nuitka
Version : 0.3.17pre2-1
Upstream Author : Kay Hayen kayha...@gmx.de
  * URL : http://nuitka.net
  * License : GPLv3
Section : python

 It builds those binary packages:

 nuitka - Python compiler with full language support and CPython
 compatible

 To access further information about this package, please visit the
 following URL:

   http://mentors.debian.net/package/nuitka

 Alternatively, one can download the package with dget using this command:

   dget -x 
 http://mentors.debian.net/debian/pool/main/n/nuitka/nuitka_0.3.17pre2-1.dsc

 I would be glad if someone uploaded this package for me. I believe
 it relatively is simple package. No real compile time dependencies.
 Pure Python. Lintian clean. Closes an ITP bug, etc.

 At Python compile time, it uses g++ and Scons, but without the user
 noticing. Esp. Nuitka is not itself build with Scons, nor needs the
 user use it, etc. There is a inline copy of Scons in Nuitka, which
 is removed for Debian of course, and not in the binary build.

 I am willing to be a good upstream, and have so far made all known
 modifications to fit better into Debian. My intention is to become a
 Debian Maintainer for this package.

 Thanks in advance,
 Kay Hayen
-- 
=--=
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/2012010125.gh16...@onerussian.com



the logo

2011-12-30 Thread Yaroslav Halchenko
Hi Everyone,

I have lingered long enough and had no excuse to make the logo available
properly.  So, due to PSF regulation we could not use any logo
containing the derivative of the official python logo.

So, blue yellow Debian-in-a-Python won by voting, I have moved it the
source .svg under accessibly by you GIT repository:

ssh://git.debian.org//git/git/python-modules/misc/python-debian-artwork.git

and gave a little kick to

http://wiki.debian.org/Python

I hope noone minds and everyone is welcome to improve (my artistic and
wiki skills are not that high ;) )

Happy New Year!

Yours,
Yarik

On Wed, 14 Sep 2011, Yaroslav Halchenko wrote:

 Hi Everyone Alike,

 Do we have a logo for our Python-In-Debian effort(s) (was needing one
 for a recent talk but failed to deliver in time)?  What about
 having one?  I am not a designer and possibly lacking any taste, so
 please do not judge wildly.  What would be your choice among the
 following 6:

  http://www.onerussian.com/tmp/pydebian-red_tuned/

 ?  choice 0 == do not like any
-- 
=--=
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/20111230161510.ga3...@onerussian.com



Re: Request for packaging - Nuitka the Python Compiler

2011-10-11 Thread Yaroslav Halchenko
Hi Kay,

Not sure if may be there were replies in private... nuitka looks like an
interesting project -- thanks!  and thanks for using Debian ;-)

Since everyone seems to be busy and since you are an experienced Debian
user -- would you consider trying to package it yourself?  it is really
not a rocket science

and since you are on a Debian system start right away with

reportbug wnpp

and file an ITP (or at least RFP if not planing to work on packaging)
for it.

Then start off with dh_make and snaking at tutorials (apt-get install
packaging-tutorial) and other packages.  Whenever packages becomes ready
(lintian-free, builds in clean environment with pbuilder or cowbuilder)
-- you could seek for sponsorship here and that would be easier to get
than complete packaging (usually DDs package what they use themselves
first ;) )

1 tiny comment: Nuitka.py script better looses its suffix (.py) if you
are planing to have it installed under /usr/bin (and I would even
suggest to make it all lower-cased -- nuitka -- although not strictly
enforced but advised: imagine if all the tools g++, Python, cython, LDD,
Make had inconsistent casing)

Cheers

On Mon, 10 Oct 2011, Kay Hayen wrote:


 Hello,

 I am the upstream developer of Nuitka and am seeking somebody to
 package Nuitka for Debian.

 It's a Python compiler with near complete and unprecedented compatibility:

 http://www.nuitka.net/blog/nuitka-a-python-compiler/what-is-nuitka/

 I have recently adopted a git flow model, where I now support a
 stable release, plus generally the project is nearing the point of
 being useful.

 Check it out from here:

 git clone http://git.nuitka.net/Nuitka.git

 The develop branch is further ahead with documentation, otherwise it
 is supposed to be useful.

 I am willing to make changes as you indicate necessary. I had the
 chance to talk with Jan Dittberner during recent PyCON DE and he
 encouraged me to post here.

 Please have a look, let me know what problems you see, and feel free
 to point me to solutions.

 I currently only expect troubles from my use of environment
 variables over __file__ relativeness. I have no idea how Nuitka or
 any code should access files nearly, so I am using environment
 variables to find their directory.

 Let me say, that I am now a developer using Debian for more than 10
 years and thrilled at the perspective to myself as an upstream.

 I do my development work on Debian Testing and I will be more than
 willing to apply changes to make the packaging easy. That is also
 why I would ask you to use the develop branch, because that's
 where I can make these changes.

 Thanks in advance,
 Kay
-- 
=--=
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/20111011131355.gz31...@onerussian.com



Re: [Python-apps-team] may be a logo?

2011-09-16 Thread Yaroslav Halchenko
Somehow I have missed this one (probably it never reached the list due
to attachment size?) so I went ahead and cooked that one up -- it is the
last in the chain now (I kinda like it too; not sure if tongue is
necessary and what color to make it then):

http://www.onerussian.com/tmp/pydebian-red_tuned/


On Thu, 15 Sep 2011, M.-A. Lemburg wrote:
 Adam wrote:
  Paul Wise wrote:
  Very nice logos. I favour #2.

  An alternative suggestion is #6 in the colors blue and yellow (let's
  call it #6by). It is attached (changes done with Gimp's fill tool).

-- 
=--=
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/20110916143619.gf5...@onerussian.com



Re: Fw: [psf-trademarks] [PSF-Board] may be a logo?

2011-09-16 Thread Yaroslav Halchenko
ah evil you Adam -- quoted public the honorable PSF committee
email without their explicit consent! ;-)

Long story short -- we can't use any of the 1-5 logos. Indeed leaving us
with #6 and #7 -- please vote!

I will drop a question to debian-legal (and Zack CCed) about use
of openlogo -- just to make sure that at least on our side we are safe
;)

NB a friend of mine stated that this Python head (taken from
   openclipart[1]) is more of a Viper head... but oh well ;-) should be
   fine for our purpose.

[1] http://www.openclipart.org/detail/86317/python-by-asrafil

On Fri, 16 Sep 2011, Adam wrote:

 Just noticed that this didn't get sent to the lists. Guess this leaves
 one design in two different colors (#6 and #7). I don't have a strong
 preference between the two.

 --Adam

-- 
=--=
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/20110916151622.gj5...@onerussian.com



may be a logo?

2011-09-14 Thread Yaroslav Halchenko
Hi Everyone Alike,

Do we have a logo for our Python-In-Debian effort(s) (was needing one
for a recent talk but failed to deliver in time)?  What about
having one?  I am not a designer and possibly lacking any taste, so
please do not judge wildly.  What would be your choice among the
following 6:

 http://www.onerussian.com/tmp/pydebian-red_tuned/

?  choice 0 == do not like any

-- 
=--=
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/20110914194128.gw5...@onerussian.com



  1   2   >