Re: Any input for some talk about usage of Debian in HPC

[Yaroslav Halchenko]

Hi Andreas,

Debian is/can be present on HPC natively (to deploy and manage such
cluster, many examples will be given) or via containerization
(increasingly more relevant), in particular with singularity. And
scientific computing is not just about HPC but also reproducibility
IMHO, here Debian has some to offer too. A few bullet points on
both

- there is https://wiki.debian.org/HighPerformanceComputing which lists
  a number of packages which relate to HPC computing, although seems
  missing
  https://packages.debian.org/sid/environment-modules
  which is pretty much "the" solution across many HPCs to provide
  flexibility in environments people need/use
  and give some semblance of "reproducibility" to them.

- there is https://lists.debian.org/debian-hpc/

- since advent of singularity (singularity-container package in debian
  due to conflict), you might discover more of "Debian" being used on
  HPC within containers providing specific computing environments and
  setups

  - that further improves flexibility and reproducibility of compute on the 
cluster

- re reproducibility, here is an example from another fella DD 
  Michael Hanke et al
  https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8917149/
  FAIRly big: A framework for computationally reproducible processing of 
large-scale data

- their cluster at https://www.fz-juelich.de/en/inm/inm-7 is running
  Debian

- with reproducible builds, https://snapshot.debian.org/ (and our
  http://snapshot-neuro.debian.net/) and with/without
  https://packages.debian.org/search?keywords=neurodebian-freeze
  it becomes easy to establish reproducible containers -- so you have
  some guarantee that your container still builds in the future without
  divergence.


Cheers,

On Sun, 19 May 2024, Andreas Tille wrote:

> Hi,

> I have an invitation to have some talk with the title

>Debian GNU/Linux for Scientific Research

> Abstract:

>Over the past decade, Enterprise Linux has dominated large-scale
>research computing infrastructure. However, recent developments have
>sparked increased interest in community-led alternatives. Debian
>GNU/Linux, a long-standing choice among researchers for supporting
>scientific work, is experiencing a renewed interest for High-Throughput
>Computing (HTC) and High-Performance Computing (HPC) applications.  This
>presentation will provide an overview of how Debian is being utilized to
>support scientific research and will include a case study showcasing the
>migration of HTC operations from Enterprise Linux 7 (EL7) to Debian.

> While I could talk about Debian Science and Debian Med in general it
> would be cool to reference to some real life examples where Debian is
> used in Science and what might be the reason to use Debian.

> I personally would like to stress the "we package what we use" aspect
> and the "we mentor upstream to merge competence of the program with
> packaging skills" idea.  Any input would be welcome to cover more ideas.

> Kind regards
> Andreas.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Re: Still interested to maintain seaborn package?

[Yaroslav Halchenko]

Dear Nilesh

yes, feel welcome to drop -- I have not touched it for way too long

Cheers and thanks!

On Sun, 24 Mar 2024, Nilesh Patra wrote:

> Hi Michael, Yaroslav,

> I have been the only person fixing bugs and updating seaborn
> since almost 4 years by now. From what I can see from the upload
> history, your last upload for the package was in 2016.

> Are you still interested to maintain this package?

> If not, in order to reflect the uploaders realistically, is it OK if
> I drop you from the uploaders field in d/control?

> Best,
> Nilesh



-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Re: Bug#1065841: Taking over datalad to either Debian Med or Debian Science team

[Yaroslav Halchenko]

Hi Andreas,

Let's keep DataLad under our (NeuroDebian) umbrella for now, since we
are also upstream there and project is active.  We are also
working with Vasyl (CCed) to experiment with some semi-automation for
package updates/backports (for neurodebian) and datalad (and some of its
ecosystem) packages are the target.  Packaging will be on salsa.  We
might move them under larger Med or Science teams, but not just yet.

Re #1065841 specifically -- while trying to build updated package I
experienced some odd side-effect (pip started to try to install
tqdm) and didn't see immediate reason.I will see how well it goes on
debian infra after source only upload (did now).

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Re: Offer to take over openpyxl / request for DM permissions

[Yaroslav Halchenko]

Please take over! Thank you!!!

On October 8, 2023 10:24:48 AM EDT, Nilesh Patra  wrote:
>On Sun, Oct 08, 2023 at 12:55:28PM +0100, Rebecca N. Palmer wrote:
>> Hence, if nobody objects I intend to take over maintenance of this package.
>> I will need either DM permissions or sponsorship to upload it.
>
>I have processed this bit for you, HTH.
>
>$ dcut dm --uid rebecca_pal...@zoho.com --allow openpyxl  
>Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
>Picking DM Rebecca N. Palmer  with fingerprint 
>618FD7C96C313F4A11FC3D66524DD2227A5017ED
>Uploading nilesh-1696774956.dak-commands to ftp-master
>
>Best,
>Nilesh

transfer vowpal-wabbit under debian-science team?

[Yaroslav Halchenko]

Dear Team,

would someone be interested to move
https://packages.debian.org/sid/vowpal-wabbit under team maintenance and
update (current upstream release is 8.9.0 and we have only 8.6.1
from 2018)?

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Re: How to run graphic test within debian/rules

[Yaroslav Halchenko]

On Tue, 17 Dec 2019, Ondrej Novy wrote:

>Hi,

>try this:
>https://codesearch.debian.net/search?q=xvfb+path%3Adebian%2Frules
+1
even GLX is possible: I did for
https://github.com/neurodebian/afni/blob/debian/18.0.05%2Bgit24-gb25b21054_dfsg.1-1/tests/xvfb-driver#L41

xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 -ac 
+extension GLX +render -noreset" "$@"

in the "test driver", worked nicely!

-- 
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: moving mpi4py to Debian Science

[Yaroslav Halchenko]

+100 on that, please go ahead.

On July 14, 2019 3:24:46 AM EDT, Drew Parsons  wrote:
>mpi4py has been lagging badly behind upstream. The Debian version
>hasn't 
>been updated since 2017 with 2.0.0-3.  Upstream is now up to 3.0.2.
>
>I propose moving mpi4py into the Debian Science team. It will fit there
>
>alongside mpich, h5py, petsc4py, etc.
>
>If there is any reason for keeping mpi4py at version 2.0.0 then please 
>let me know.
>
>Drew

Re: Pandas

[Yaroslav Halchenko]

never mind -- I was the one too late:

Version check failed:   

  
Your upload included the source package statsmodels, version 0.8.0-8,   

  
however unstable already has version 0.8.0-8. 

;-)  thanks!

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

Re: Pandas

[Yaroslav Halchenko]

On Fri, 01 Mar 2019, Yaroslav Halchenko wrote:


> On Wed, 27 Feb 2019, Rebecca N. Palmer wrote:

> > Any comment (and preferably upload) on statsmodels?  That needs to be
> > uploaded by the 2nd (in testing by the 12th) if at all, as it has changes
> > that wouldn't be allowed under full freeze.

> lots of great work there -- thanks again. would be shame to miss it.
> looks good - building/testing now

Hi Rebecca,

I've uploaded the build, and was trying to push the release changelog
change + tag, but found some on salsa already... was that
version/tag uploaded as well/before me?

Please advice on how to proceed -- I would've just force pushed mine as
the version actually uploaded (if yours wasn't).

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

[Yaroslav Halchenko]

On Wed, 27 Feb 2019, Rebecca N. Palmer wrote:

> Any comment (and preferably upload) on statsmodels?  That needs to be
> uploaded by the 2nd (in testing by the 12th) if at all, as it has changes
> that wouldn't be allowed under full freeze.

lots of great work there -- thanks again. would be shame to miss it.
looks good - building/testing now

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

[Yaroslav Halchenko]

On Wed, 27 Feb 2019, Andreas Tille wrote:

> Dear Rebecca,

> On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote:
> > On 27/02/2019 07:00, Andreas Tille wrote:
> > > Dear Rebecca,
> > > I do not think that there is any
> > > need for a separate branch.  Just stick to the debian branch.

> > It's needed because the debian branch contains the attempt at packaging 0.24
> > described earlier in this thread, which it's now too late for.

> You are right.  Considering the branching jungle (Yaroslav, could you possibly

for someone jungle is a sweet sweet home! ;)

$> git br -a | grep salsa | grep -e bf- -e enh- -e cythoned | while 
read b; do git push salsa :${b//*salsa\//}; done
To salsa.debian.org:science-team/pandas.git
 - [deleted] __tent/debian-cythoned-quilt
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-cython
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-i386
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-native-endianness
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-skips
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-unser
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-versions-etc
To salsa.debian.org:science-team/pandas.git
 - [deleted] enh-tests-compat-pytables-2.1

and will try to not forget to not push them again ;)

$> git br -a | grep salsa # -- with my annotations
  remotes/salsa/master -- some upstream's point of master -- could 
also be removed if you like
  remotes/salsa/releases   -- linear progression of upstream releases
  remotes/salsa/debian -- sits on top of releases and carries 
packaging
  remotes/salsa/debian-experimental -- the one for uploads to 
experimental

better now?

> cleanup branches that are not used any more?) I'd prefer if you would move the
> 0.24 packaging to some separate branch (debian-experimental is covered but may
> be debian-0.24 or something like this?) and keep branch debian for what we are
> really releasing.

well "releasing" is a loaded term. I guess you are talking about uploading to
unstable so it manages to get into buster.  Since "debian" branch already got
its 0.24, what about starting debian-buster branch off debian/0.23.3-1 ?

otherwise -- I am ok to hard-reset and force push debian to the debian/0.23.3-1
state -- everyone should just beware of it, and then progress
debian-experimental to current state of debian (v0.24.1-972-g1cfbd07c7)

your call

> Thanks again for your work on this

yeap, Thank you Rebecca!

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

[Yaroslav Halchenko]

Sorry for being allow to respond... Please do what you need to do

On February 13, 2019 5:47:41 PM EST, "Rebecca N. Palmer" 
 wrote:
>On 13/02/2019 09:10, Andreas Tille wrote:
>> Any volunteer to backport the relevant changes I pushed to Git right
>now
>> to 0.8.0?
>
>I intend to try tomorrow, if the uploaders don't say anything first.
>
>> I'm actually wondering why the package did not got any removal
>> from testing warning (or did I missed something)?
>
>statsmodels is considered a key package (i.e. can't be autoremoved) 
>because of the statsmodels -> seaborn -> sphinx-gallery -> matplotlib 
>build-dependency chain.
>
>The autoremoval list (sorted by maintainer/team) is
>https://udd.debian.org/cgi-bin/autoremovals.cgi
>
>> PS: As a general note: We probably need more people dedicated to
>Debian
>> Science QA work.
>
>I guess that's sort of what I do (and if statsmodels and/or pandas were
>
>to become available, they are at least things I use).

Re: Pandas new version

[Yaroslav Halchenko]

On Wed, 06 Feb 2019, Yaroslav Halchenko wrote:
...
> = ERRORS 
> ==
> _ ERROR collecting 
> tests/indexes/datetimes/test_tools.py __
> /usr/lib/python2.7/dist-packages/pluggy/hooks.py:284: in __call__
> return self._hookexec(self, self.get_hookimpls(), kwargs)
> /usr/lib/python2.7/dist-packages/pluggy/manager.py:67: in _hookexec
> return self._inner_hookexec(hook, methods, kwargs)
> /usr/lib/python2.7/dist-packages/pluggy/manager.py:61: in 
> firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
> /usr/lib/python2.7/dist-packages/_pytest/python.py:224: in 
> pytest_pycollect_makeitem
> res = list(collector._genfunctions(name, obj))
> /usr/lib/python2.7/dist-packages/_pytest/python.py:409: in _genfunctions
> self.ihook.pytest_generate_tests(metafunc=metafunc)
> /usr/lib/python2.7/dist-packages/pluggy/hooks.py:284: in __call__
> return self._hookexec(self, self.get_hookimpls(), kwargs)
> /usr/lib/python2.7/dist-packages/pluggy/manager.py:67: in _hookexec
> return self._inner_hookexec(hook, methods, kwargs)
> /usr/lib/python2.7/dist-packages/pluggy/manager.py:61: in 
> firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
> /usr/lib/python2.7/dist-packages/_pytest/python.py:133: in 
> pytest_generate_tests
> metafunc.parametrize(*marker.args, **marker.kwargs)
> /usr/lib/python2.7/dist-packages/_pytest/python.py:973: in parametrize
> param_index,
> /usr/lib/python2.7/dist-packages/_pytest/python.py:841: in setmulti2
> self._checkargnotcontained(arg)
> /usr/lib/python2.7/dist-packages/_pytest/python.py:825: in 
> _checkargnotcontained
> raise ValueError("duplicate %r" % (arg,))
> E   ValueError: duplicate 'box'

Seems one seems to relate to pytest version -- with the most
recent 4.? (installed via pip) it disappears

if I add --continue-on-collection-errors to pytest invocation, I am
ending up with ~50 failing tests :-( and 3 errors.

pushed my changes and now waiting for another "cleanish" run where I
actually store full output since I ran out of terminal buffer to get all
those errors for analysis.

I think part of the problem is upstream chasing bleeding edges for
pytest/numpy/etc in their CI setups and thus loosing idea on how well
pandas behaves on existing deployments. E.g. this pytest 4.0 issue -
versioned dependency  was boosted solely to speed up conda's
dependencies resolution... heh heh

-- 
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: Pandas new version

[Yaroslav Halchenko]

l__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python2.7/dist-packages/pluggy/manager.py:67: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python2.7/dist-packages/pluggy/manager.py:61: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python2.7/dist-packages/_pytest/python.py:224: in 
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python2.7/dist-packages/_pytest/python.py:409: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python2.7/dist-packages/pluggy/hooks.py:284: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python2.7/dist-packages/pluggy/manager.py:67: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python2.7/dist-packages/pluggy/manager.py:61: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python2.7/dist-packages/_pytest/python.py:133: in pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python2.7/dist-packages/_pytest/python.py:973: in parametrize
param_index,
/usr/lib/python2.7/dist-packages/_pytest/python.py:841: in setmulti2
self._checkargnotcontained(arg)
/usr/lib/python2.7/dist-packages/_pytest/python.py:825: in _checkargnotcontained
raise ValueError("duplicate %r" % (arg,))
E   ValueError: duplicate 'box'
__ ERROR collecting tests/resample/test_base.py 
___
In test_resample_empty_dataframe_all_ts: function uses no argument 
'_index_factory'
! Interrupted: 2 errors during collection 
!
=== 3 skipped, 778 deselected, 2 error in 37.76 
seconds ===
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":99"
  after 11 requests (8 known processed) with 0 events remaining.
make[1]: *** [debian/rules:128: python-test2.7] Error 2
make[1]: Leaving directory '/build/pandas-0.24.1'
make: *** [debian/rules:67: binary] Error 2
```



On Wed, 06 Feb 2019, Yaroslav Halchenko wrote:


> On Wed, 06 Feb 2019, Ole Streicher wrote:

> > Yaroslav Halchenko  writes:
> > >> And it also does not solve the problem that updating can introduce
> > >> regressions in reverse dependencies, which is not the best thing we can
> > >> do just before freeze. But finally you are the maintainer, if you think
> > >> that updating is the way to go, just do it ;-)

> > > Is there any other commit you would like to push on top of your recent
> > > 721fcf98d4b79d146a92a8d8def8dee1daecb4c0
> > > ?

> > No; I don't have time to look into this until tomorrow night. If you are
> > going to fix, I will enjoy a free evening ;-)

> ok, let's see where I would get, I will keep pushing
-- 
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: Pandas new version

[Yaroslav Halchenko]

On Wed, 06 Feb 2019, Ole Streicher wrote:

> Yaroslav Halchenko  writes:
> >> And it also does not solve the problem that updating can introduce
> >> regressions in reverse dependencies, which is not the best thing we can
> >> do just before freeze. But finally you are the maintainer, if you think
> >> that updating is the way to go, just do it ;-)

> > Is there any other commit you would like to push on top of your recent
> > 721fcf98d4b79d146a92a8d8def8dee1daecb4c0
> > ?

> No; I don't have time to look into this until tomorrow night. If you are
> going to fix, I will enjoy a free evening ;-)

ok, let's see where I would get, I will keep pushing
-- 
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: Pandas new version

[Yaroslav Halchenko]

On Wed, 06 Feb 2019, Ole Streicher wrote:

> Yaroslav Halchenko  writes:
> > On Tue, 05 Feb 2019, Ole Streicher wrote:
> >> "Rebecca N. Palmer"  writes:
> >> > Has anyone checked whether this would break pandas' reverse dependencies?

> >> I didn't yet. I just tried to update the packaging to 0.24, which
> >> however has a number of test failures, which would need to be discussed
> >> with upstream first.

> > if not sever - I guess could be patched to be skipped for now and then
> > patches picked up to address them?  or it was too many/too deep?

> If you want: please do it as you like. My own workflow is to first
> discuss all failures with upstream, especially when I can't estimate
> the impact - sometimes it may be even fault of the package. There were

it is the same approach I am taking usually

> about ten failures, which makes this already quite an effort. Especially
> since I did not work closely with upstream so far (so I don't know them
> well, and they don't know me) -- this communication should IMO be done
> by the regular maintainer. And, as I wrote, the package rules are a bit
> complicated, so I don't want to touch them before they are simplified
> (which would add more efforts on top of that). Bringing the other stuff
> to gbp standards (pristine-tar etc.) even more.

I have been using gbp for it for long time, and there is debian/gbp.conf
with all needed settings. pristine-tar is just an option, and I kept
burning myself with it too often to rely on it, original author (Joey
Hess) even recommended abandoning it at some point in the past.

> And it also does not solve the problem that updating can introduce
> regressions in reverse dependencies, which is not the best thing we can
> do just before freeze. But finally you are the maintainer, if you think
> that updating is the way to go, just do it ;-)

Is there any other commit you would like to push on top of your recent
721fcf98d4b79d146a92a8d8def8dee1daecb4c0
?
-- 
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: Pandas new version

[Yaroslav Halchenko]

On Tue, 05 Feb 2019, Ole Streicher wrote:

> "Rebecca N. Palmer"  writes:
> > Has anyone checked whether this would break pandas' reverse dependencies?

> I didn't yet. I just tried to update the packaging to 0.24, which
> however has a number of test failures, which would need to be discussed
> with upstream first.

if not sever - I guess could be patched to be skipped for now and then
patches picked up to address them?  or it was too many/too deep?




-- 
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: Pandas new version

[Yaroslav Halchenko]

On Tue, 05 Feb 2019, Andreas Tille wrote:

> On Tue, Feb 05, 2019 at 08:48:09AM +0100, Ole Streicher wrote:

> > On a longer term, it would be good to clean this package up (removing
> > f.e. the special Cython handling) -- Yaroslav, how much do you still
> > these things? Since Panda is one of the universal packages, it would be
> > good to have it as standard as possible to make team maintenance simple.

> I agree that we should settle with a simple standard and even the last
> say 5 Ubuntu versions will be able to cope with this.  So may be there
> is just historic stuff in the packaging and nobody minded to clean it
> up.  Yaroslav, if you do not contradict with this we need to assume that
> I'm correct with my assumption and whoever might do the upgrade should
> make packaging as simple and easily understandable as possible.

Is special cython handling too much to handle?  if not - I would beg to
keep it.  I thought it is modular enough to not be a sore point -- if
helps, feel welcome to move those rules down in the file.  Having it
greatly simplifies  backporting to older debian/ubuntus which
might lack up to date cython and providing cython backport itself would
be too destructive (causing other FTBFS etc).  May be you see a better
way?

For the same reason of backports I would ask to not strip all the
python2 support in there prematurely.

otherwise, I would wholeheartedly welcome simplifications as long as
pandas builds seamlessly also at least on debian stable (or soon
oldstable) and some recent ubuntus.

-- 
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: scikit-learn status (Team maintenance)

[Yaroslav Halchenko]

Thank you Ole!

Indeed taking an attempt at having them actually fixed is preferable, otherwise 
those bugs tend to accumulate. Cheers

On January 26, 2019 8:38:16 AM EST, Ole Streicher  wrote:
>Ole Streicher  writes:
>> since some time, scikit-learn is in danger to be removed from testing
>> (#907806), but fails to migrate now due to several test failures on
>> non-intel architectures (#919918). I opened an upstream issue
>>
>> https://github.com/scikit-learn/scikit-learn/issues/13036
>>
>> which suggests that some of the test failures are simple to fix, some
>> others however seem to be serious. There are some packages depending
>on
>> scikit-learn, that's why I would like to push this forward a bit. So,
>I
>> would like no to just disable all failing tests to ensure the package
>> migrates. We can re-enable these tests once they are fixed upstream.
>>
>> Any objections? Specific ideas how to fix one or the other failure
>> without disabling it?
>
>Since upstream reports that some of them are fixed with 0.20.2, I would
>at first attempt to upgrade to that version tonight.
>
>Cheers
>
>Ole

-- 
Yaroslav O. Halchenko (mobile version)
Center for Open Neuroscience   http://centerforopenneuroscience.org
Dartmouth College, NH, USA

Re: Build time test failures for seaborn 0.9 (Was: seaborn - update to 0.9 - where is debian folder on salsa?)

[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#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

Dear Yangfl and other Debian-science folks

could you please have a look at the scikit-learn packaging, which was
heavily tuned up recently and I have little to no clue how to
augment it reliably back or to avoid parallel build and its gotchas.
See http://bugs.debian.org/911830 for more details

-- 
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: New version of statsmodels is out possibly fixing important bug - any volunteer

[Yaroslav Halchenko]

On Fri, 26 Oct 2018, Andreas Tille wrote:

> Hi Yarislav,

> On Sun, Aug 12, 2018 at 02:40:28PM -0400, Yaroslav Halchenko wrote:
> > Fwiw I will look into updating soon unless someone beats me to it

> I guess this went out of your focus.  I tried my best to update Git[1] to
> version 0.9.0.  The package build process stumbles about doc creation:

THANKS!

> ...
> copying images... [ 97%] savefig/var_fevd.png
> copying images... [100%] savefig/dvar_forecast.png

> copying static files... done
> copying extra files... done
> dumping search index in English (code: en) ... done
> dumping object inventory... done
> build succeeded, 33 warnings.

> The HTML pages are in build/html.
> Copying rendered example notebooks
> mkdir -p build/html/examples/notebooks/generated
> cp source/examples/notebooks/generated/*html 
> build/html/examples/notebooks/generated
> #../tools/examples_rst.py
> ../tools/fold_toc.py build/html/index.html
> Traceback (most recent call last):
>   File "../tools/fold_toc.py", line 12, in 
> doc = open(filename, encoding='utf8').read()

so the script now is python3. adjust shebang?
alternative might work to patch it with smth like

  from io import open

-- 
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#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 01 Oct 2018, Andreas Tille wrote:

> Hi Yaroslav,

> was this helpful for you?

sorry -- didn't look into scikit-learn yet. BTW - 0.20 release was
posted, so we should update and try again.  Will you have time or should
I ?

-- 
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#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 24 Sep 2018, Andreas Tille wrote:

> Probably due to racing condition since I migrated the repository before
> your pushes.

> > > either needed to be imported as quilt patches or alternatively you can
> > > use git mode in d/watch which creates a new tarball for you
> > > incorporating the latest state of upstream Git (I doubt that would be a
> > > sensible solution in the current case).

> > if we are to stay with my non conventional setup of sitting straight on
> > top of the upstream git repo, then we would just need to merge
> > debian-0.20 branch into debian branch (might be a fast-forward) whenever
> > we are ready to upload that beast. 

> I confirm that there are cases where this workflow makes sense.  We need
> to outweight pros and cons.

To say the truth, I am no longer sure since it is possible to still have
regular upstream repo as a remote and dedicated branches for them in the
same git repo (locally), so I could still cherry pick etc.  Pretty much
what I do eg for cython etc.

That is why I am agreeing to go "standard" so to make life easier for
others as well.

My only concern with the "standard" workflow ATM is that pristine-tar is
not as reliable as needed to be. # of open issues manifests to that
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=pristine-tar;dist=unstable
and Joey himself moved from using it to dgit AFAIK.  But anyways it is
unrelated to this discussion, sorry for bringing it up ;(

> > ...
> > If we are to convert to the more conventional gbp workflow (I am ok with
> > that now ;)) , I guess the best would be to just reimport from the
> > snapshots entire history of the package and proceed from there.  Then
> > commits in debian-0.20 would need to be rebased (or cherry picked or
> > your suggested format-patch+am) to stay on top of the "master"
> > branch 

> I hope I will find the time tomorrow or the day after tomorrow.

thanks

> > and picking any needed changes, would be appreciated.  I will adjust ;)

> I'll check what might be the easier solution and will come back once I
> did so.  Hopefully you will have solved the ssh issue meanwhile. 

I will try again later today, and when home (different network/provider)

-- 
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#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 24 Sep 2018, Andreas Tille wrote:

> > > When you talked about new upstream version:  Do you want to give 0.20rc1

> > I did give it a try...

> > From the now empty list of
> > https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it
> > might be that all of the ones I've filed are addressed by now, BUT I do not 
> > see
> > them in

> > $> git lg 0.20rc1..origin/0.20.X   
> > * c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) 
> > [Joel Nothman]
> > * 17f8016c5 - Bugfix release of joblib that also restores PyPy support 
> > (#12012) (3 weeks ago) [Olivier Grisel]
> > * c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel 
> > Nothman]
> > * 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman]
> > * 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) 
> > [Joel Nothman]
> > * 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel 
> > Nothman]

> > so might have been fixed in master, and not backported yet, which indeed
> > might be the case:
> > https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493

> You asked me to clone http://github.com/yarikoptic/scikit-learn to
> https://salsa.debian.org/science-team/scikit-learn which I did.  In

cool

> *your* packaging repository is no branch 0.20rc1 those commits would be

indeed salsa clone is missing the
https://github.com/yarikoptic/scikit-learn/tree/debian-0.20 branch which
sits on top of debian branch and the 0.20rc1 upstream tag (pushed
now to my fork on github)

> either needed to be imported as quilt patches or alternatively you can
> use git mode in d/watch which creates a new tarball for you
> incorporating the latest state of upstream Git (I doubt that would be a
> sensible solution in the current case).

if we are to stay with my non conventional setup of sitting straight on
top of the upstream git repo, then we would just need to merge
debian-0.20 branch into debian branch (might be a fast-forward) whenever
we are ready to upload that beast. 

> I have no trouble with accessing the repository on Salsa.

> > Meanwhile, debian-0.20 branch is on
> > http://github.com/yarikoptic/scikit-learn

> I admit I'm not sure what you want me to do next.  It somehow smells


> like using git mode in debian/watch and try to extract your commits to
> debian/ dir via `git format-patch` and import these into Debian Science
> repository via `git am`.  However, I do not see this as very promising

If we are to convert to the more conventional gbp workflow (I am ok with
that now ;)) , I guess the best would be to just reimport from the
snapshots entire history of the package and proceed from there.  Then
commits in debian-0.20 would need to be rebased (or cherry picked or
your suggested format-patch+am) to stay on top of the "master"
branch 

> since I'm not sure whether you are really in favour to migrate to Debian
> Science or rather stick to your workflow.  

I am ok with either way now, as long as the package stays easy to
backport (so cythonize in debian/rules etc stays)

> So before I start spending
> time into this it would be helpful if you confirm that you can

>gbp clone g...@salsa.debian.org:science-team/scikit-learn.git

as I said, smth is finicky with ssh for me for salsa:

$>gbp clone g...@salsa.debian.org:science-team/scikit-learn.git 
gbp:info: Cloning from 'g...@salsa.debian.org:science-team/scikit-learn.git'
gbp:error: Git command failed: Error running git clone: ssh: connect to host 
salsa.debian.org port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

$> sudo tcptraceroute salsa.debian.org 22
Running:
traceroute -T -O info -p 22 salsa.debian.org 
traceroute to salsa.debian.org (209.87.16.44), 30 hops max, 60 byte packets
 1  _gateway (10.31.176.1)  1.733 ms  2.085 ms  2.620 ms
 2  berry1-crt.border1-rt.dartmouth.edu (129.170.1.42)  2.598 ms  2.074 ms  
2.060 ms
 3  i2-cleveland.border1-rt.dartmouth.edu (129.170.9.241)  6.170 ms  6.151 ms  
6.155 ms
 4  et-3-1-0.4079.rtsw.clev.net.internet2.edu (162.252.70.93)  15.175 ms  
15.531 ms  15.542 ms
 5  ae-1.4079.rtsw.eqch.net.internet2.edu (162.252.70.131)  25.121 ms  25.082 
ms  24.325 ms
 6  et-7-0-0.4079.rtsw.minn.net.internet2.edu (162.252.70.107)  31.915 ms  
32.184 ms  31.981 ms
 7  et-7-0-0.4079.rtsw.miss2.net.internet2.edu (162.252.70.59)  55.142 ms  
57.452 ms  55.346 ms
 8  et-4-1-0.4079.rtsw.seat.net.internet2.edu (162.252.70.1)  65.376 ms  65.717 
ms  65.842 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *


I can clone though via https:// (just can't push changes via ssh)

> and we both agree about the method how we want to inject the upstream
> source there.  Debian Science policy says this is done via

>gbp import-orig --pristine-tar 

> while the upstream tarball is obtained via 

Re: Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 24 Sep 2018, Andreas Tille wrote:

> When you talked about new upstream version:  Do you want to give 0.20rc1

I did give it a try...

From the now empty list of
https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it
might be that all of the ones I've filed are addressed by now, BUT I do not see
them in

$> git lg 0.20rc1..origin/0.20.X   
* c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) 
[Joel Nothman]
* 17f8016c5 - Bugfix release of joblib that also restores PyPy support (#12012) 
(3 weeks ago) [Olivier Grisel]
* c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel 
Nothman]
* 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman]
* 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) [Joel 
Nothman]
* 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel 
Nothman]

so might have been fixed in master, and not backported yet, which indeed
might be the case:
https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493

> a try or do you want to wait for 0.20?

regarding push to salsa:

something is funky with salsa or with my network?

(git)hopa:~deb/scikit-learn[debian-0.20]
$> git remote add salsa g...@salsa.debian.org:science-team/scikit-learn.git

$> git fetch salsa
ssh: connect to host salsa.debian.org port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Meanwhile, debian-0.20 branch is on
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: How to disable tests for Python2 only?

[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?

[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: Taking over scikit-learn into Debian Science team maintenance

[Yaroslav Halchenko]

meanwhile may be let me just take care about this tiny issue myself

On Sun, 08 Apr 2018, Yaroslav Halchenko wrote:

> Ok. Go ahead. Thanks.
>  But indeed please keep it in a shape so it could be easily backported.

> On April 8, 2018 1:59:53 AM EDT, Andreas Tille <andr...@fam-tille.de> wrote:
> >Hi Yaroslav and Michael,

> >as I did in the past with other scientific packages I would like to
> >take
> >over scikit-learn into Debian Science team maintenance to fix bug
> >#894526.  As I understood you in those cases you are OK with this as
> >long as backportability is given.

> >Please let me know until tomorrow if you do not like it.

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


signature.asc
Description: PGP signature

Re: Taking over scikit-learn into Debian Science team maintenance

[Yaroslav Halchenko]

Ok. Go ahead. Thanks.
 But indeed please keep it in a shape so it could be easily backported.

On April 8, 2018 1:59:53 AM EDT, Andreas Tille  wrote:
>Hi Yaroslav and Michael,
>
>as I did in the past with other scientific packages I would like to
>take
>over scikit-learn into Debian Science team maintenance to fix bug
>#894526.  As I understood you in those cases you are OK with this as
>long as backportability is given.
>
>Please let me know until tomorrow if you do not like it.
>
>Kind regards
>
>   Andreas.

Re: pandas -- I think we should drop BE platforms

[Yaroslav Halchenko]

That is why I cross posted original email to their mailing lists.
Pandas builds are lengthy, codebase complex, I do not remember (m)any patches 
(besides disabling tests) coming up for those architectures, pretty much for 
every release we ended up filling RM requests for those architectures.
I really do not see the point of wasting computational resources by building on 
those architectures

On February 24, 2018 3:16:49 PM EST, Julien Puydt  
wrote:
>Hi,
>
>Le 24/02/2018 à 21:08, Sébastien Villemot a écrit :
>> No, leave "Architecture: any". Then the builds will fail on those
>> arches. This is what porters generally prefer, because they have a
>> clear information about what is wrong with the package on their
>> arch (and possibly they can act and send patches).
>
>>From the original mail, it doesn't look like porters have been helpful
>yet. Perhaps a better suggestion would be : get in touch the porters
>before you decide to let things down...
>
>Snark on #debian-science

-- 
Sent from a phone which beats iPhone.

pandas -- I think we should drop BE platforms

[Yaroslav Halchenko]

Hi The Team,

"Maintaining" pandas builds on big endians (and some others, but let's
concentrate on BE for now) was always problematic.  Upstream does not
support them and I am somewhat tired of pestering them with failures on
them. Only once or twice test failures on those platforms pointed
to genuine bugs (iirc in numpy or scipy) which just were not revealed on
x86.

Selectively skipping the tests on those platforms is just hiding the
bugs away and pretending that it is all working correctly AFAIK.  The
worst thing which I think we could do to the users on those platforms
(if there are any) is to make their results knowingly incorrect,
while no alarm is raised.

As to me, the most logical step would be to stop pretending to support
BE builds for pandas and drop support of all big endian builds
altogether.   

1. remove all patches which disable tests on big endians (I would have
even patched to remove upstream skips on those archs, so we do not fall
into the trap of missing smth)

2. Please correct me if I am wrong, but I do not think that there
is some flag to say smth like

Architecture: any [!big-endian]

so we would need to unlist them explicitly

Architecture: any [!s390x, !powerpc, !mips]

(or powerpc is not BE?)

Let me know what you think and  either I have missed anything.  If
someone wants to step up and jump into maintaining on BEs, please do so
now.  If not, I will proceed as planned above.

-- 
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 properly define version number of a package using git+COMMITID in the version?

[Yaroslav Halchenko]

FWIW -- you might like my helper
http://git.onerussian.com/?p=etc/bash.git;a=blob;f=.bash/bashrc/30_aliases_sh;h=196f98ab0b87519ab326b26674d8f2c720195ebc;hb=HEAD#l347

so my typical workflow for such usecases

git fetch origin
git checkout debian  # where packaging lives
git merge origin/master
dch_gitrev -i origin/master 

to get something like this in case of datalad:

$> dch_gitrev -i origin/master
new entry
D: mbase is 'c1e438708ad29293eb2853f5e9cd0b7743d362f0'
D: Got new_entry='1', upstream ver of last entry 0.9.1 and
624-gc1e43870.  So should be 0.9.1+git624-gc1e43870-1
diff --git a/debian/changelog b/debian/changelog
index e49a4f7b..fbc3902e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+datalad (0.9.1+git624-gc1e43870-1) UNRELEASED; urgency=medium
+
+  * New upstream snapshot from origin/master at 0.9.1-624-gc1e43870
...

note that the "beauty" is that git still understands that version (strip
debian suffix):

$> git describe 0.9.1+git624-gc1e43870  
0.9.1-624-gc1e43870

Cheers

On Fri, 02 Feb 2018, Christophe Trophime wrote:

>Hi,
>I would like to update a package feelpp from its latest release 0.103.2 to
>a more recent development version.
>I've tried to define the newest version as: 0.103.3+gitREVNUMBER with
>REVNUMBER the id of the git commit
>The trouble is that when trying to update locally my package which are
>stored in a local repo
>apt still wants to install 0.103.2 version instead of the
>newest 0.103.3+gitREVNUMBER
>What do I miss to get the dev version to be installed?
>Thanks for your answers
>Best
>Christophe TROPHIME
>Research Engineer
>CNRS - LNCMI
>25, rue des Martyrs
>BP 166
>38042 GRENOBLE Cedex 9
>FRANCE
>Tel : +33 (0)4 76 88 90 02
>Fax : +33 (0) 4 76 88 10 01
>Office U 19
>M@il : christophe.troph...@lncmi.cnrs.fr

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

[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: Export of alioth mailing list archive not working

[Yaroslav Halchenko]

And please share your findings. We got the same behavior iirc on our 
NeuroDebian etc mailing lists, but haven't dealt with it yet (at least got 
subscribers)

On January 10, 2018 6:12:57 AM EST, "Sébastien Villemot"  
wrote:
>On Wed, Jan 10, 2018 at 11:43:25AM +0100, Tobias Hansen wrote:
>
>> due to the deprecation of Alioth I now want to ask for a replacement
>of
>> debian-science-sagem...@lists.alioth.debian.org on lists.debian.org.
>I would
>> like the archive to be imported and followed the instructions on [1]
>to
>> export the mbox file, but it didn't work:
>> 
>> thansen@moszumanska:~$ sudo /usr/local/bin/export-list
>debian-science-sagemath > output.tar.gz
>> Mailbox
>(/var/lib/mailman/archives/public//debian-science-sagemath.mbox/debian-science-sagemath.mbox)
>not found or empty - continuing anyway (trying to export subscribers)
>> 
>> I got a file containing the list of subscribers. Does anybody know
>how to do
>> it? Am I missing permissions?
>
>The very same command worked for me for another list. So I guess your
>problem
>is related to something specific about debian-science-sagemath@. You
>should
>probably contact the Alioth admins.

-- 
Sent from a phone which beats iPhone.

Re: Scikit-learn: Move to Debian Science?

[Yaroslav Halchenko]

On Tue, 05 Dec 2017, Ole Streicher wrote:

> Dear Yaroslav,

> can we move scikit-learn to Debian Science as well please? This is
> another package currently maintained by NeuroDebian, but in a bad state
> since months. Since it is used in general science, it would be good if
> that could be fixed by Debian Science maintainers (specifically, I will
> have a look) as a team upload and direct commit to the repository.

> If you agree, I would try to create a standard Debian repository
> (master, upstream, pristine tar) on alioth based on your github repo,
> and change the maintainer to Debian-Science.

"Bad state" was a single failing unittest on exotic platforms AFAIK --
or am I missing something?  That test could have been dealt efficiently
via NMU, but noone did.  Anyways -- I've uploaded a fixed up
package to the archive earlier today.  Let's see how it goes.

Although in general I do not mind moving packages under Debian Science,
I do not see it as a panacea... quite often in my case it leads to me
spending more time working around adjusting my workflow and to provide
backports which we do for NeuroDebian.  So unless I see that there is an
immediate benefit overweighting the cons in this case, I would
prefer to keep it as is for now. Sorry

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: [Help] Exclusion did not worked (Was: Bug#877419: Bug#877700: RM: pandas [arm64 armel armhf mips mips64el mipsel s390x] ...)

[Yaroslav Halchenko]

On Sun, 15 Oct 2017, Andreas Tille wrote:

> Hi,

> for arm64 the method I uploaded has seemed to work but for mips and
> s390x it ends up in

> ...

>  ERRORS 
> 
>  ERROR collecting 
> debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/io/test_stata.py 
> ../debian/tmp/usr/lib/python2.7/dist-packages/pandas/tests/io/test_stata.py:27:
>  in 
> raise nose.SkipTest("known failure of test_stata on non-little endian")
> E   NameError: name 'nose' is not defined

sounds like there is no "import nose" above in test_stata.py

-- 
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: [Help] Exclusion did not worked (Was: Bug#877419: Bug#877700: RM: pandas [arm64 armel armhf mips mips64el mipsel s390x] ...)

[Yaroslav Halchenko]

On Sat, 14 Oct 2017, Ghislain Vaillant wrote:

> On 14/10/17 07:54, Andreas Tille wrote:
> > On Fri, Oct 13, 2017 at 08:00:36PM +0200, Andreas Tille wrote:
> > ...
> > pandas_datareader: None
> > usage: pytest.py [options] [file_or_dir] [file_or_dir] [...]
> > pytest.py: error: unrecognized arguments: --exclude
> >inifile: /<>/setup.cfg
> >rootdir: /<>
> > debian/rules:109: recipe for target 'python-test2.7' failed
> > ...

> > I confirm that I have not found the --exclude option for pytest.

> > I'm not that experienced with pytest.  From some short research I had
> > the idea to quilt patch some "slow" markers for the failing tests and
> > for the affected architectures ignore those "slow" tests.

> > Any better technical idea?

> Indeed you could use a custom "slow" marker for it. The corresponding patch
> should be upstreamable too if appropriately motivated.

FWIW my 1c to make someone pay 1$ (in proportion of time to be spent to
actually do it):

yeah, with nosetests it was possible to exclude in the command line...  on a
quick google I didn't find for pytest (not that it doesn't exist), but
started to wonder if indeed would be better to provide a patch (to upstream)
for tests which are known to be failing on specific architectures, something
like

@known_to_fail_on(archs=['armel', ...])
@known_to_fail_on_bigendian
@known_to_fail_on_nonx32

see https://docs.pytest.org/en/latest/skipping.html#id1 on how to
establish those for now based on skipif .  "For now", since ideally there
should be an easy way to trigger another behavior -- test which tests
known to fail before now pass.  (we have got something like that in
datalad now for demarkating tests which fail atm with v6 of git-annex
repo)

upstream actually already has some tests marked up:

pandas/tests/indexes/test_interval.py:
@pytest.mark.skipif(compat.is_platform_32bit(),
pandas/tests/io/json/test_pandas.py:@pytest.mark.skipif(is_platform_32bit(),
pandas/tests/io/json/test_ujson.py:
@pytest.mark.skipif(compat.is_platform_32bit(),
pandas/tests/io/json/test_ujson.py:
@pytest.mark.skipif(compat.is_platform_windows() and not compat.PY3,

# and here comes a demo of the cool  -p  switch for git grep:

$> git grep -p skip.*endian pandas
pandas/tests/frame/test_constructors.py=class 
TestDataFrameConstructors(TestData):
pandas/tests/frame/test_constructors.py:pytest.skip("known failure 
of test on non-little endian")
pandas/tests/io/test_pickle.py=def test_pickles(current_pickle_data, version):
pandas/tests/io/test_pickle.py:pytest.skip("known failure on non-little 
endian")

-- 
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#877419: Bug#877700: RM: pandas [arm64 armel armhf mips mips64el mipsel s390x] -- ROM; Some build time tests are failing on specific architectures

[Yaroslav Halchenko]

On Fri, 13 Oct 2017, Andreas Tille wrote:

>1. proceed as I suggested here:
>   https://lists.debian.org/debian-science/2017/10/msg1.html
>...
> Is there anybody who is no happy about this?

sorry to be the pain, I am ... And first of all -- thanks for taking
care about pandas!

I would disagree on the complete disabling of the tests.  Selective
annotation of failed tests at least allows maintainer's judgement on
either any particular failure of critical importance.  Disabling ALL
tests would let a completely broken package into the Debian for that
architecture (not to mention that we did have failures on big-endians
signal generic problems in the code, which just weren't triggered on
x86s)... then why to have it there in that architecture at all?

If ftp masters and porters insist on "better to have a broken one than
none", I would argue that unlike typical software, where bugs are usually
"obvious" to the user (things just fail), in scientific/data oriented
software bugs are more inconspicuous  -- you just place data in and get
some garbage out possibly without realizing it.  

In summary my 1c: I am ok with RM for those archs (again), or
partial disabling of the tests, but not  ok with overall disabling of
the test suite

>2. Upload after migrating the package to Debian Science as
>   we previously agreed upon.

do you mean migrating of a Vcs?

-- 
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: skimage (was: Re: Bug#729956: Python 3 Statsmodels & Pandas)

[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: new iproposal: a specific OS for psychologist

[Yaroslav Halchenko]

On Tue, 10 Oct 2017, Andreas Tille wrote:

> I never assumed this. :-)

> > and since it may be it
> > would be of interest for some debian-science folks, I am happy to
> > present you the other collective baby of ours: http://datalad.org .  You
> > can treat as a Debian on git and git-annex steroids for data ;) A
> > sample, primarily neurosciency (but there is little to nothing
> > neuroscience specific in the guts of it, "data distribution" is
> > here: http://datasets.datalad.org/  . Soon we should provide a "Debian
> > apt repository" view of it for easy apt-get'ing whatever is needed.

> Sounds really cool.  Also here my (frequently repeated) suggestion
> applies: Try to integrate better into Debian, find friends working on
> the same goal.  (In other words: Think Blend-ish to get more people
> involved.)

DataLad blend? ;)

we have a datalad package... 

that repository already contains what will be hundreds (if not
thousands) packages; not sure if it would be feasible to even
contemplate introducing them into stock debian... so how to "integrate"?

the only thing which comes to mind:

- similar to the neurodebian package via debconf adding apt
  line(s) for neurodebian repo, we could have datasets-datalad  package
  which would do similar thing

-- 
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: new iproposal: a specific OS for psychologist

[Yaroslav Halchenko]

On Tue, 10 Oct 2017, Andreas Tille wrote:
> > Since all of those components are available already, what particular
> > features are you looking for?  You could just take plain Debian (or
> > NeuroDebian, e.g. our virtualbox image) image of any kind, install
> > all those apps and "be done".

> The comparison with SkoleLinux/DebianEdu makes me wonder whether
> NeuroDebian would become a real official Blend.

eh heh, no time has left for Blending ;)

So that you do not think that we are lazy booms, and since it may be it
would be of interest for some debian-science folks, I am happy to
present you the other collective baby of ours: http://datalad.org .  You
can treat as a Debian on git and git-annex steroids for data ;) A
sample, primarily neurosciency (but there is little to nothing
neuroscience specific in the guts of it, "data distribution" is
here: http://datasets.datalad.org/  . Soon we should provide a "Debian
apt repository" view of it for easy apt-get'ing whatever is needed.

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: new iproposal: a specific OS for psychologist

[Yaroslav Halchenko]

On Mon, 09 Oct 2017, Joost van Baal-Ilić wrote:
> > Hi, My name is Francisco Montero, I would like to ask you if it is possible 
> > to develop an OS based on Debian (similar to SkoleLinux/DebianEdu) specific 
> > for psychologist (both applied psychologist and researcher psychologist) 
> > built with a set of predetermine tools such as pspp (data analysis), 
> > neurodebian, zotero (citation manager), bibus (connection to data base 
> > provider) pgp tools for confidential reports about patients,...

Since all of those components are available already, what particular
features are you looking for?  You could just take plain Debian (or
NeuroDebian, e.g. our virtualbox image) image of any kind, install
all those apps and "be done".

NB NeuroDebian was initially created to cover psychological research,
hence we still have repositories and mailing lists on alioth as 'exppsy'
-- Experimental Psychology

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

[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

[Yaroslav Halchenko]

On Sun, 24 Sep 2017, Andreas Tille wrote:

> Hi Yaroslav,

> On Sat, Sep 23, 2017 at 10:00:35AM -0400, Yaroslav Halchenko wrote:

> > > I would prefer to move pandas to Debian Science or Debian Python.  I
> > > fail to see the specific use in NeuroDebian field.

> > I ould repeat that I don't mind having it moved under -science or
> > -python teams maintenance.  But it shouldn't make it more difficult for
> > me to maintain it.

> Thanks for the permission to move the package.  Could you please be more
> verbose what exactly might make your maintenance more difficult?  Its
> about changing Vcs-Fields and Maintainer field - is this in some way
> making things harder for you?

nah, VCS field(s) is a non issue.  making package non-backportable
automatically, introducing new patch management mechanisms (dpq or
whatnot) which I am not too familiar with -- such things could make
things more difficult.  If just a matter of moving a repository -- that
is all ok as long as I know where to find a new one and could contribute
;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Re: Python 3 Statsmodels & Pandas

[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

[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

[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

[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

[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: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Yaroslav Halchenko]

On Sun, 02 Apr 2017, Andreas Tille wrote:

> Hi Yaroslav,

> On Tue, Mar 28, 2017 at 11:52:43AM -0400, Yaroslav Halchenko wrote:

> > > I have filed another bug for that (#858881); it would be nice if that
> > > could be fixed as well.

> > what matters ATM is that it (package) built fine 
> > https://buildd.debian.org/status/logs.php?pkg=pandas=0.19.2-5=amd64

> Rebecca N. Palmer has kindly provided a patch that fits the discussion
> inside the bug (thanks a lot Rebecca).  It worked for me and thus I
> uploaded (having a pristine-tar branch in Git would have been convient).

> Yaroslav, would you mind forwarding the patch upstream?

seems was already applied just few days back:

commit b6d405d695249980aa2f93d58998412b4b81dcf3
Author: Jeff Reback <j...@reback.net>
Date:   Thu Mar 30 16:42:23 2017 -0400

TST: incorrect localization in append testing

and when ``pytz`` version changes our tests break because of this
incorrect (old) method, which works when you *dont'* have a tz change,
but fails when the tz's actually change.

Author: Jeff Reback <j...@reback.net>

Closes #15849 from jreback/localize and squashes the following commits:

d43d088 [Jeff Reback] TST: incorrect localization in append testing

diff --git a/pandas/tests/test_multilevel.py b/pandas/tests/test_multilevel.py
index fd5421abc..5584c1ac6 100755
--- a/pandas/tests/test_multilevel.py
+++ b/pandas/tests/test_multilevel.py
@@ -83,9 +83,9 @@ class TestMultiLevel(Base, tm.TestCase):
 # GH 7112
 import pytz
 tz = pytz.timezone('Asia/Tokyo')
-expected_tuples = [(1.1, datetime.datetime(2011, 1, 1, tzinfo=tz)),
-   (1.2, datetime.datetime(2011, 1, 2, tzinfo=tz)),
-   (1.3, datetime.datetime(2011, 1, 3, tzinfo=tz))]
+expected_tuples = [(1.1, tz.localize(datetime.datetime(2011, 1, 1))),
+   (1.2, tz.localize(datetime.datetime(2011, 1, 2))),
+   (1.3, tz.localize(datetime.datetime(2011, 1, 3)))]
 expected = Index([1.1, 1.2, 1.3] + expected_tuples)
 tm.assert_index_equal(result, expected)
 
@@ -103,9 +103,9 @@ class TestMultiLevel(Base, tm.TestCase):
 
 result = midx_lv3.append(midx_lv2)
 expected = Index._simple_new(
-np.array([(1.1, datetime.datetime(2011, 1, 1, tzinfo=tz), 'A'),
-  (1.2, datetime.datetime(2011, 1, 2, tzinfo=tz), 'B'),
-  (1.3, datetime.datetime(2011, 1, 3, tzinfo=tz), 'C')] +
+np.array([(1.1, tz.localize(datetime.datetime(2011, 1, 1)), 'A'),
+  (1.2, tz.localize(datetime.datetime(2011, 1, 2)), 'B'),
+  (1.3, tz.localize(datetime.datetime(2011, 1, 3)), 'C')] +
  expected_tuples), None)
 tm.assert_index_equal(result, expected)
 



-- 
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: [Neurodebian-devel] Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Yaroslav Halchenko]

On Tue, 28 Mar 2017, Andreas Tille wrote:

> > - I have already stated many times that if you want to move any of the
> >   core packages under bigger (-med, -science, etc) maintenance -- I
> >   don't mind.  But it shouldn't complicate my own work on those
> >   packages.  Someone's "mess" might as well be my "consistency" and I
> >   often can't afford spending time figuring out how this are now. And
> >   even worse time "fixing" up packaging (e.g. re-enabling testing,
> >   re-introducing dropped patches, etc) to make it as "messy" as it
> >   was before ;)

> It might be interesting to know what part of the "mess" is important to
> you.  

itemize "mess"y aspects (I was not the one to provide this
qualification) and I will let you know.  Could as well happen that
the answer will be "none"

> For instance it might help to know in advance if you are fine with
> the gbp layout specified by the packaging policy of the target team. :-)

yes -- it is fine.  I use gbp as well

> I fully agree that a migration of packaging to a team VCS should not
> include changing / dropping any patches in the first place.

good

> > - so far I still see only myself as the one who took care about pandas
> >   even after I cried out loud for help.  So helping instead of
> >   complaining (again) would be more helpful (I started reading
> >   this with an idea that we are talking about tzdata issue, but
> >   apparently we are just making water harder)

> While I know that you always was cooperating when we started discussing
> about some issue this discussion used to start only after rdepends of
> one of the Neurodebian packages were affected by removal from testing
> warnings.  When checking the bug log no response to those RC bugs was
> logged.  This is simply frustrating since this means a time delay of at
> least 10 days until somebody starts reacting while beeing totally
> unclear whether some work was done or not.  I fully understand if you
> are swamped with more important things but responding to an RC bug by
> tagging it help and forwarding the mail to interested parties - in this
> case Debian Science for instance - would help a lot.

would be great indeed

> May be you consider all this making water harder, but I consider not
> responding to RC bugs (without an appropriate VAC message) in times of
> freeze not responsible maintenance.  

yeah, agree.  In the long run, I may indeed need to shorten the list of
packages I maintain.  I am NOT on VAC virtually ever but indeed
seems getting short of time to provide adequate oversight at times.
Again -- actual help is welcome.

> I'd like to repeat here that I
> would not say so if there would be *any* message crying for help.  Since
> I also personally have no idea about Pandas and this issue I simply took
> some action and involved tzdata maintainers.  This could have happened
> 10 days ago and this is my main point.  (And sorry if I'm to German
> here. :-P )

it is ok -- I like Germans in general ;-)

> > - regarding original tzdata issue -- since we are just expressing
> >   sentiments here -- it would have been cool if maintainers of
> >   core packages would do 'reverse depends testing' before uploading (as
> >   I am trying to do in such cases) so we stop running after a gone train
> >   [see e.g. our ad-hoc messy helper
> >   
> > https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends
> >   which I usually use successfully when preparing next uploads for
> >   cython, nibabel, etc]

> Perfectly valid argument, yes.  This again shows that you are doing
> really cool stuff in NeuroDebian which I totally appreciate.
> Unfortunately this does not make its way where it IMHO belongs like for
> instance at debian...@lists.debian.org.  Well, you wrote some helpful
> tool and have hidden it nicely out of reach for those people who are
> obviously in need of this.

apt-get install neurodebian-dev

I have pointed to it multiple times.
I think there is a (possibly better) alternative now

$> apt-cache show ratt
Package: ratt
...
Description-en: Rebuild All The Things!
 ratt (“Rebuild All The Things!”) operates on a Debian .changes file of 
a
 just-built package, identifies all reverse-build-dependencies and 
rebuilds
 them with the .debs from the .changes file.
 .
 The intended use-case is, for example, to package a new snapshot of
 a Go library and verify that the new version does not break any other
 Go libraries/binaries.

but I haven't tried it so YMMV.

You can help leading the initiative to promote it/them to debian-qa@ or
-devel@ or any other appropriate in your opinion channel.  I would
really appreciate!

> > - outdated (not pushed) git on github or alioth is all the same -- just
> >   me forgetting to push.  "Fixed now" (thanks) - and present on
> >   both github and alioth git://git.debian.org/git/pkg-exppsy/pandas.git
> Thanks.
> > Thanks 

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Yaroslav Halchenko]

On Tue, 28 Mar 2017, Ole Streicher wrote:

> Yaroslav Halchenko <deb...@onerussian.com> writes:
> > it would have been cool if maintainers of core packages would do
> > 'reverse depends testing' before uploading

> Wouldn't have helped here -- pandas are failing in CI since ages:
> https://ci.debian.net/packages/p/pandas/unstable/amd64/

> I have filed another bug for that (#858881); it would be nice if that
> could be fixed as well.

what matters ATM is that it (package) built fine 
https://buildd.debian.org/status/logs.php?pkg=pandas=0.19.2-5=amd64

CI runs are cool but separate from buildprocess and I guess 
I have missed to adjust debian/tests for some skips/env variables

help is welcome ... ideally -- if we could run autopkgtests within
package build time to replace my manual execution of those within
debian/rules ... but that is not for stretch

-- 
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: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Yaroslav Halchenko]

On Tue, 28 Mar 2017, Ghislain Vaillant wrote:

> On 28/03/17 10:37, Andreas Tille wrote:
> > PS: Yaroslav, you know my opinion about using Vcs outside of debian.org and
> > deriving from policies that are widely established.  Currently
> >   git://github.com/neurodebian/pandas.git
> > is not even featuring the latest uploads - last changelog entry is

> > pandas (0.19.2-2) unstable; urgency=medium

> >   * Exclude a number of tests while running on non-amd64 platforms
> > due to bugs in numpy/pandas

> >  -- Yaroslav Halchenko <deb...@onerussian.com>  Wed, 11 Jan 2017 12:13:05 
> > -0500


> > I'm sorry to repeat myself but you are not creating a welcoming
> > environment for people who intend to help.

> This sentiment is shared on my side too.

> It was very disappointing to discover that nipype will not be part of
> Stretch due to an RC, which looks like many of those the team fixed during
> the Numpy 1.12 migration [1]. Besides, the packaging repository is quite
> frankly a mess [2] and is outdated.

> Looking at the other packages maintained by NeuroDebian and affected by RCs
> [3] (which include nipy, dipy and pandas), the repository layout is
> inconsistent from one package to the next [4, 5, 6]. IMO, as an experienced
> packager who has contributed to many different teams, this completely
> cancels out the benefits of having packages team-maintained in the first
> place.

> I am wondering whether NeuroDebian should instead be focusing on maintaining
> high-quality backports of neuroimaging software for supported Debian and
> Ubuntu releases (a goal it currently fulfills very well), and leave the main
> packaging effort to other Debian packaging teams (Science, Med, Python...).

I will try to be short

- I have already stated many times that if you want to move any of the
  core packages under bigger (-med, -science, etc) maintenance -- I
  don't mind.  But it shouldn't complicate my own work on those
  packages.  Someone's "mess" might as well be my "consistency" and I
  often can't afford spending time figuring out how this are now. And
  even worse time "fixing" up packaging (e.g. re-enabling testing,
  re-introducing dropped patches, etc) to make it as "messy" as it
  was before ;)

- so far I still see only myself as the one who took care about pandas
  even after I cried out loud for help.  So helping instead of
  complaining (again) would be more helpful (I started reading
  this with an idea that we are talking about tzdata issue, but
  apparently we are just making water harder)

- regarding original tzdata issue -- since we are just expressing
  sentiments here -- it would have been cool if maintainers of
  core packages would do 'reverse depends testing' before uploading (as
  I am trying to do in such cases) so we stop running after a gone train
  [see e.g. our ad-hoc messy helper
  
https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends
  which I usually use successfully when preparing next uploads for
  cython, nibabel, etc]

- outdated (not pushed) git on github or alioth is all the same -- just
  me forgetting to push.  "Fixed now" (thanks) - and present on
  both github and alioth git://git.debian.org/git/pkg-exppsy/pandas.git

Thanks in advance for your help!

-- 
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: Thanks for sagemath!

[Yaroslav Halchenko]

On Tue, 24 Jan 2017, Jan Medlock wrote:

> Dear debian-science-maintainers,
> Thanks for the sagemath package!  I've watched the packaging effort for
> 7+ years now and can only imagine all of the hard work that went into
> the packaging.

+1  on Jan's KUDOs -- thank you Debian Science Maintainers for all your
help all around!

and thank you Jan for taking time for expressing your gratitude!

-- 
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: Please enable Debian Science team easier access to your Python packages with scientific scope

[Yaroslav Halchenko]

On Mon, 23 Jan 2017, Andreas Tille wrote:

> On Fri, Jan 20, 2017 at 07:32:43AM -0500, Yaroslav Halchenko wrote:
> > move of a package (pandas iirc) under another team didn't magically 
> > resolved outstanding issues.

> Just for the record: It worked (non-magically) again.

> So it would help to keep those packages that several package depend from
> at places where more than two people have direct access to.  Extra
> points for following a common policy - I have not yet read good reasons
> to derive from Debian Science policy.

Great -- thank you guys!

-- 
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: Please enable Debian Science team easier access to your Python packages with scientific scope

[Yaroslav Halchenko]

On Fri, 20 Jan 2017, Ole Streicher wrote:

> Yaroslav Halchenko <y...@onerussian.com> writes:
> > Re repositories - I welcome nmus, patches and PRs on github. So far in
> > an example move of a package (pandas iirc) under another team didn't
> > magically resolved outstanding issues.

> It did. I fixed skimage and statsmodels after you allowed them to move
> to debian-science, so that they could stay in/move to testing. The level
> of interaction, also with upstream and dependencies would have made the
> work much more difficult if I had no direct access to the repository,
> and my motivation would have been less.

ok, point taken . Thank you Ole!
-- 
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: Please enable Debian Science team easier access to your Python packages with scientific scope

[Yaroslav Halchenko]

On January 20, 2017 4:39:30 AM EST, Andreas Tille  wrote:
>Hi Neurodebian team,
>
>recently I stumbled about several reverse dependencies which are
>affecting packages of Debian Med that are Python packages with
>scientific background, maintained by NeuroDebian team but on Github.  I
>think I explained the drawbacks of this in the past and do not like to
>repeat myself.  The recent example is seaborn (bugs #849368, #850999).
>
>I'd like to ask you for permission to move any such package with RC
>bugs over to Debian Science Git to bring it to a wider audience and
>enable some effective cooperation between all involved people.
>
>I learned that Yaroslav prefers a different Git repository layout than
>it is specified in Debian Science policy.  While I personally do not
>see
>the advantage as a compromise I could leave the non-default layout even
>if I'd prefer that we work on the policy if there are any known
>drawbacks of the specification we once agreed upon.
>
>In this sense is it OK if I move seaborn from Github to git.debian.org
>leaving whatever Git repository layout is used and let Debian Science
>team keep on the maintenance?
>
>Kind regards
>
> Andreas.

Re repositories - I welcome nmus, patches and PRs on github. So far in an 
example  move of a package (pandas iirc) under another team didn't magically 
resolved outstanding issues.
Fwiw - Yes, you have my blessing to move seaborn. Thank you
-- 
Sent from a phone which beats iPhone.

Re: quick Q to Matthias Re: Sympy(+sagemath+nipy+~30 more) removal ahead

[Yaroslav Halchenko]

On Tue, 10 Jan 2017, Tobias Hansen wrote:

> On 01/10/2017 10:44 PM, Yaroslav Halchenko wrote:

> >> (For me the only failed tests were the two in the bug, and just the patch
> >> was enough to fix that.)

> > and I guess recent python-pil pruned olefile from the depends  (I believe it
> > was there in prev version)

> > although I don't see any corresponding changelog entry for that in
> > http://metadata.ftp-master.debian.org/changelogs/main/p/pillow/pillow_4.0.0-2_changelog

> > Matthias -- could you clarify if olefile depends was consciously removed or
> > should we complain with a bug report? ;-)  unfortunately there is no VCS
> > defined for python-pil to go through the laundry:


> olefile is new so pillow didn't depend on it before. You can also see it
> here:
> https://tracker.debian.org/media/packages/p/pillow/control-3.4.2-1

> Why do you think the test failures are due to missing olefile?

because of something like

==
ERROR: test_diagram_attributes (blockdiag.tests.test_builder.TestBuilder)
--
Traceback (most recent call last):
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/tests/test_builder.py",
 line 8, in test_diagram_attributes
diagram = self.build('diagram_attributes.diag')
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/tests/utils.py",
 line 101, in build
return self._build(parse_file(pathname))
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/tests/utils.py",
 line 104, in _build
return ScreenNodeBuilder.build(tree)
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/builder.py",
 line 613, in build
return cls(tree, config, layout).run()
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/builder.py",
 line 616, in __init__
self.diagram = DiagramTreeBuilder().build(tree, config)
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/builder.py",
 line 27, in build
self.instantiate(self.diagram, tree)
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/builder.py",
 line 115, in instantiate
group.set_attribute(stmt)
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/elements.py",
 line 76, in set_attribute
getattr(self, "set_%s" % name)(value)
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/elements.py",
 line 581, in set_default_shape
if noderenderer.get(value):
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/noderenderer/__init__.py",
 line 43, in get
init_renderers()
  File 
"/build/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_2.7/build/src/blockdiag/noderenderer/__init__.py",
 line 26, in init_renderers
module = plugin.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2290, 
in load
self.require(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2307, 
in require
items = working_set.resolve(reqs, env, installer)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 849, 
in resolve
raise DistributionNotFound(req, requirers)
DistributionNotFound: The 'olefile' distribution was not found and is required 
by Pillow


and then digging in, installing python-olefile and then tests functioning
correctly (up to those other failing ones)

here is the log if interested
http://neuro.debian.net/_files/_buildlogs/blockdiag/1.5.3+dfsg/blockdiag_1.5.3+dfsg-1_amd64.build

-- 
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: quick Q to Matthias Re: Sympy(+sagemath+nipy+~30 more) removal ahead

[Yaroslav Halchenko]

On Tue, 10 Jan 2017, Rebecca N. Palmer wrote:

> > olefile (0.43-1) unstable; urgency=medium

> >   * Initial release (closes: #850404).

> >  -- Matthias Klose   Fri, 06 Jan 2017 07:36:25 +0100

> Which makes it too new to get into stretch, so we're not allowed to
> build-depend on it if we want to stay there.
> (https://release.debian.org/stretch/rc_policy.txt)

good point! ;)   

then current pil I guess should be made usable without it, otherwise
blockdiag is doomed ;)

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

quick Q to Matthias Re: Sympy(+sagemath+nipy+~30 more) removal ahead

[Yaroslav Halchenko]

On Tue, 10 Jan 2017, Rebecca N. Palmer wrote:

> > missing python{,3}-olefile in Build-Depends.

> There is no such package in unstable - was this a typo?

may be confusion is due to my shell rotten fingers typing? ;)

$> apt-cache policy python{,3}-olefile
python-olefile:
  Installed: (none)
  Candidate: 0.44-1
  Version table:
 0.44-1 600
600 http://http.debian.net/debian sid/main amd64 Packages
600 http://http.debian.net/debian sid/main i386 Packages
python3-olefile:
  Installed: (none)
  Candidate: 0.44-1
  Version table:
 0.44-1 600
600 http://http.debian.net/debian sid/main amd64 Packages
600 http://http.debian.net/debian sid/main i386 Packages


my guess is that divergence was due to severe novelty of that package:

olefile (0.44-1) unstable; urgency=medium

  * New upstream release.

 -- Matthias Klose   Mon, 09 Jan 2017 12:52:45 +0100

olefile (0.43-1) unstable; urgency=medium

  * Initial release (closes: #850404).

 -- Matthias Klose   Fri, 06 Jan 2017 07:36:25 +0100


> (For me the only failed tests were the two in the bug, and just the patch
> was enough to fix that.)

and I guess recent python-pil pruned olefile from the depends  (I believe it
was there in prev version)

although I don't see any corresponding changelog entry for that in
http://metadata.ftp-master.debian.org/changelogs/main/p/pillow/pillow_4.0.0-2_changelog

Matthias -- could you clarify if olefile depends was consciously removed or
should we complain with a bug report? ;-)  unfortunately there is no VCS
defined for python-pil to go through the laundry:

# apt-cache policy python-pil
python-pil:
  Installed: 4.0.0-2
  Candidate: 4.0.0-2
  Version table:
 *** 4.0.0-2 500
500 http://127.0.0.1:3142/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
# apt-cache show python-pil | grep olefile


$> debcheckout python-pil
No repository found for package python-pil.


-- 
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: [Neurodebian-devel] Please consider moving common packages to Debian-Science

[Yaroslav Halchenko]

On November 19, 2016 12:03:06 PM EST, Ole Streicher <oleb...@debian.org> wrote:
>Hi Yaroslav, Yury and all.
>
>
>On 19.11.2016 17:50, Yaroslav Halchenko wrote:
>> On Sat, 19 Nov 2016, Yury V. Zaytsev wrote:
>>>> * pandas
>>>> * pymc
>>>> * statsmodels
>>>> * scikit-learn
>> 
>>> I'd also add at least those two:
>> 
>>> * mpi4py
>>> * seaborn
>> 
>>>> Would you consider moving these packages to debian-science instead?
>This
>>>> would enable team-maintenance for a larger team and may help to
>keep
>>>> them in a good shape. At least, I don't want to join neurodebian
>just to
>>>> fix the stuff in-place.
>> 
>>> The question, of course, is if moving the packages will really
>magically
>>> attract more maintainers... my understanding is that packages are
>maintained
>>> in NeuroDebian by default to make it easier for NeuroDebian
>maintainers &
>>> leverage the repository infra they have in place. But maybe
>something worth
>>> considering anyways.
>
>I can speak here just for myself: I found the upstream patch that
>solved
>the main issue in statsmodels, and it is more complicated for all to
>upload the patch to the bug, having it back downloaded and applied to
>the git. Having this complicated process in mind, at least I delayed
>working on this quite quite a bit. A repository where I can contribute
>directly is just more inviting. YMMV, however.
>
>> In general I don't mind at all moving (or better -- having moved ;) )
>> any of those packages under debian-science maintenance!Which one
>> would you like to start with?  e.g. statsmodels is indeed the
>> interesting one.  I have just uploaded fresh pandas (which brought
>new
>> FTBFS :-/) with hope that some might just go away in statsmodels, but
>> that didn't happen.   I am still slowly working with statsmodels and
>> have some non-pushed changes, but if you are keen to start with e.g.
>> pandas and fixing up any of those issues as it being a part of Debian
>> science -- it would be awesome.  Just let me know which package(s)
>you
>> want to start with so we don't overlap.
>
>As I wrote, I looked at statmodels; however the solution suggested by
>Sandro Tosi (tzdata) didn't work. So I am stuck there now; however
>there
>is just this one remaining issue.
>
>Best regards
>
>Ole
>
>___
>Neurodebian-devel mailing list
>neurodebian-de...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/neurodebian-devel

Fwiw my packaging repository is on github, I would appreciate a PR if you would 
like to help rapidly with a patch... I am ATM looking into uploading updated 
maintenance/0.8 iirc upstream branch. Is the fix you are talking about from 
there?
-- 
Sent from a phone which beats iPhone.

Re: [Neurodebian-devel] Please consider moving common packages to Debian-Science

[Yaroslav Halchenko]

On Sat, 19 Nov 2016, Yury V. Zaytsev wrote:
> > * pandas
> > * pymc
> > * statsmodels
> > * scikit-learn

> I'd also add at least those two:

> * mpi4py
> * seaborn

> > Would you consider moving these packages to debian-science instead? This
> > would enable team-maintenance for a larger team and may help to keep
> > them in a good shape. At least, I don't want to join neurodebian just to
> > fix the stuff in-place.

> The question, of course, is if moving the packages will really magically
> attract more maintainers... my understanding is that packages are maintained
> in NeuroDebian by default to make it easier for NeuroDebian maintainers &
> leverage the repository infra they have in place. But maybe something worth
> considering anyways.

Hi Ole and Yury,

In general I don't mind at all moving (or better -- having moved ;) )
any of those packages under debian-science maintenance!Which one
would you like to start with?  e.g. statsmodels is indeed the
interesting one.  I have just uploaded fresh pandas (which brought new
FTBFS :-/) with hope that some might just go away in statsmodels, but
that didn't happen.   I am still slowly working with statsmodels and
have some non-pushed changes, but if you are keen to start with e.g.
pandas and fixing up any of those issues as it being a part of Debian
science -- it would be awesome.  Just let me know which package(s) you
want to start with so we don't overlap.

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: Neurodebian tasks (and Debian Science)

[Yaroslav Halchenko]

quick clarification for now, hopefully would find time for more later)

On Wed, 06 Apr 2016, Ole Streicher wrote:
> > Are you aiming to provide that level of granularity within debian 
> > installer?  if so -- that would be cool.

> Sure, I am also unstatisfied with the current state. There is currently
> no way to select individual packages during the installation and also
> not with tasksel, and I would guess that this will stay so for Debian
> Stretch. However, once we have our "foot in the door" (that's probably a
> "False Friend" in english), we have a good reason and pressure to get
> something. We just need volunteers ;-)

> But let's be pragmatic here. The proposed solution is not ideal, but it
> is a step forward, and something realistic.

agree. thus +100 ;)


> > I am not sure what such a default blend should carry really... how 
> > could I decide for a lab to use e.g. AFNI vs FSL vs [...]

> Neurodebian already offers a bootable image, and a default virtual
> machine -- so you already *have* some idea of a default installation.

we had some live cd attempt in the past but didn't push it forward.
thus the only bootable image is the VM, which is just a stock debian
stable + neurodebian repo enabled + neurodebian-desktop package for
custom appearance (+ some NeuroDebian menu with pre-selected apps which
get installed if user clicks on them) + "welcome wizard" which at the
end pretty much provides few of those 'tasks' options.  But the point is
that nothing neurosciency in a default installation.

that automatic installation idea though -- it might be actually a cute
one to be adopted for -tasks packages, which could provide those ad-hoc
.desktop files within a dedicated Blend submenu and plugs for all
user-executable tools/packages linked there.

Example:
http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/xdg/desktop/neurodebian-psychopy.desktop
which uses this tool
http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/nd-autoinstall

but that is orthogonal to your current effort Ole, so sorry for
derailing.


-- 
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: [Caffe] uploaded to mentors but NOT RFS

[Yaroslav Halchenko]

On Wed, 02 Sep 2015, lumin wrote:
> As a packaging Newbie I indeed paied considerable time on it...
> at the same time I learned a lot packaging it.
> This is just my 3rd Debian package (and it includes my 1st python3
> package), so I'm not sure how far it is to be accepted into Archive.

> Just a ping, thank you all. :-) just a minor recommendation... for the
snapshot versions use following strategy to come up with upstream version --
should end with what 'git describe' ends with for the treeish: e.g.

$> git describe --tags e8e66
rc2-513-ge8e660d

as you see -- current one is not understood by git,

$> git show 0.~rc2+git20150902+e8e660d3  
fatal: ambiguous argument '0.~rc2+git20150902+e8e660d3': unknown revision 
or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

whenever such one (where you use "-g" instead of "+"):

$> git show 0.~rc2+git20150902-ge8e660d3
commit e8e660d3ca5b5d8d1e8f2853c0d606cb525d8a72
Merge: cbb2ed1 4f64b9e
Author: Jeff Donahue 
Date:   Tue Sep 1 19:37:41 2015 -0700

Merge pull request #2990 from mattdawkins/add-openblas-path

Add extra OpenBLAS include search path

does. that makes it possible for gbp to even generate tarball from that treeish 
if .orig is not found locally

just few cents hoping of help ;)

-- 
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: Huge data files in Debian

[Yaroslav Halchenko]

Let's continue on debian-devel indeed

On Fri, 17 Jul 2015, Andreas Tille wrote:

 Hi Ole,

 while it is probably correct to assume that several scientists have a
 similar problem I think the proper channel is debian-devel list since
 may be also gamers and others have this problem.  There was previous
 discussion years ago with no real outcome as far as I know.

 Kind regards

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150717155426.gn28...@onerussian.com

Re: Should non-science packages needed by science packages be maintained by Debian Science?

[Yaroslav Halchenko]

On Thu, 19 Mar 2015, Andreas Tille wrote:

 thanks for working on these math packages.

+1

  Would it be appropriate for Debian Science to maintain memtailor, or 
  should I just maintain itself?  Theoretically, it could be a dependency 
  for some future non-science package.

 Usually predependencies are created by those people who are interested
 in the final package.  If the final package is maintained by Debian
 Science I'd call it perfectly consequently that Debian Science also
 maintains its predepends.  We have several examples for this and so
 the short answer to your question is yes.

+1
moreover, at times it would even be desired and recommended.  This way
it would be easier to guarantee that  version/progression of those core
packages would be tailored to the target leaf science software, not some
e.g. Desktop app  like it would be in the case if the predepency is
maintained by the Desktop-all team ;)

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150319150500.gu29...@onerussian.com

Re: Dealing with FTBFS with gcc 5 (Matthias?)

[Yaroslav Halchenko]

On Thu, 12 Feb 2015, Julien Puydt wrote:

 Hi,

 quite a number of FTBFS with gcc 5 bugs are hitting packages under
 the debian-science umbrella ; as I'm part of the team, I'll try to

 help on those, but since I have no clue what the problem(s) exactly
 is(are) yet, I have a few questions :

 1. How can I set up a pbuilder with that compiler ?

gcc 5 is in experimental, so I guess it should be the experimental
chroot but with forced gcc 4:5

there are various ways I guess to achieve it, but here is a fully
scripted one ;)

mkdir -p /tmp/exp-hooks; echo -ne '#!/bin/sh\nget install -t experimental gcc 
g++\n' | /tmp/exp-hooks/E0expgcc; chmod +x /tmp/exp-hooks/E0expgcc
sudo pbuilder --create --mirror http://http.debian.net/debian --distribution 
experimental --hookdir /tmp/exp-hooks

NB might want to dump it to some other than base.tgz file

 2. Is there a wiki page somewhere listing the most frequent issue ?

FWIW -- some of them seems to be due to internal problems with gcc
package(s) as far as I see it, e.g. in scipy

gfortran:f77: scipy/fftpack/src/dfftpack/zffti.f
x86_64-linux-gnu-gcc-ar: adding 23 object files to 
build/temp.linux-x86_64-2.7/libdfftpack.a
sh: 1: x86_64-linux-gnu-gcc-ar: not found
error: Command x86_64-linux-gnu-gcc-ar rc 
build/temp.linux-x86_64-2.7/libdfftpack.a 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dffti.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dsinqi.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dffti1.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dsinqb.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/zffti1.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dcosqi.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dcosqb.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dcosti.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/zfftb.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dsint.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dcosqf.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dfftf.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dfftf1.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dsinqf.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dfftb1.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dsint1.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/zfftf1.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dfftb.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dcost.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/zfftf.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/zfftb1.o
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/dsinti.o 
build/temp.linux-x86_64-2.7/scipy/fftpack/src/dfftpack/zffti.o failed with 
exit status
127sh: 1: x86_64-linux-gnu-gcc-ar: not found

so it might be first worthwhile clarifying with  Matthias:

- aren't those really just have to do with internal gcc package issue
  and mass bug filing was a bit undue?

- is there a page summarizing gcc 5 issue so they could be efficiently
  tackled?

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150212143053.gt7...@onerussian.com

Re: How to open-source a program?

[Yaroslav Halchenko]

Hi Ole,


Since you cross-posted to multiple lists, I am not sure if you got 
a reply...  did you? ;)

 Has anyone already went through such an exercise and could assist me in 
 writing a nice E-mail? Or are there better ways to proceed?

There were quite a few of such emails circulating on debian-med
and quick google lead me to e.g.
https://wiki.debian.org/DebianMed/Meeting/Southport2012/ePetition_Phylip

 However, the program is *very* old, and parts of it already leaked out 
 (rewritten in other programming languages) in some Open Source packages, 
 (astrolib [IDL] and IRAF) -- legally or not.

 I asked the author whether the program could be made open source, but he 
 stated that the lawyers in Ottawa would forbid him to do so. One would need 
 to query the National Research Council in Ottawa, Canada to discuss this.

In my case, for NeuroDebian I also has contacted quite a few groups, and at
times with additional persistence nearly in all cases we have managed to pursue
original copyright holders to open-source their scientific projects, at times
quite large and with outstanding legacy.  So, even if initial reply would
say No, don't give up at once.  More arguments an examples might shift
original opinion.

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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150208165829.ga7...@onerussian.com

Re: Bye bye Debian Science

[Yaroslav Halchenko]

On Thu, 05 Feb 2015, Sylvestre Ledru wrote:
 Just a quick email to let you know that I am going to quit this team.

Good luck Sylvestre in new endeavors!!!  But if not Science any
longer, I still hope we will have pleasure to see you around Debian ;-)

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150206141919.gc7...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python liabrary for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

uploaded (and pushed now) and then realized that we should have also
stripped python-support from all *Depends... so committed that one too

Cheers

On Thu, 10 Apr 2014, Yaroslav Halchenko wrote:



 Yes. Nd_build4all creates  packages for most releases (I can't check all,
 due to an insufficient cowbuilder installation, I guess), but get lintian
 errors for the Ubuntu releases.

 great (see below on errors)


 Unfortunately, nd_addinst doesn't install me the cow files for
 nd+debian-squeeze  and ubuntu-saucy  with the errors

  WARNING: The following packages cannot be authenticated!
    debootstrap
  E: There are problems and -y was used without --force-yes

 or
  E: No such script: /usr/share/debootstrap/scripts/saucy

 just make 1 more symlink manually:

 /usr/share/debootstrap/scripts/saucy - gutsy

 for now (or update debootstrap to some backport build... I just usually
 do symlink manually)

 and for Ubuntu 10.04 there are unmet dependencies:

  The following packages have unmet dependencies:
    pbuilder-satisfydepends-dummy: Depends: debhelper (= 9.0.0) but it 
  is
 not going to be installed.

 that one is way too old now -- forget about it ;-)


 For the all working Ubuntu release I get a lintian error message
  oliver@pecog-computserver:~/git$ lintian *.changes
  E: python-expyriment changes: bad-distribution-in-changes-file precise
  E: python-expyriment changes: bad-distribution-in-changes-file quantal
  E: python-expyriment changes: bad-distribution-in-changes-file raring

 that is ok -- since lintian expects uploads to Debian releases and while
 backporting we add a changelog entry matching the release name we are 
 building for

 will build now (upload later -- about to hit the road)
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140412114621.ge8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python liabrary for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

On Wed, 09 Apr 2014, Oliver Lindemann wrote:

Thanks of the guidance. I guess I fixed all issues. I used dh_python2
thou, since dh_pysupport seems to be deprecated:
[1]https://wiki.debian.org/Python/Policy

;-) good ... I forgot from which ubuntu release it became available so
we might loose backports for some elderly ones (that is why I still keep
using pysupport even though it is deprecated in Debian
mainland)... but indeed let's just check

did you have luck setting up the same build farm as 
http://neuro.debian.net/blog/2012/2012-04-14_ndtools.html
-- if you could check on builds across releases -- that would be cool

I noticed that dh_python2 solves the image-file-in-usr-lib warning,
since it removes images from lib folder and creates symlinks. Convenient!

;-)

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140409142745.gu8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python liabrary for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

On Tue, 08 Apr 2014, Oliver Lindemann wrote:

  ha -- thanks to jwilk now I am aware of

  17:59 #debian-python:  jwilk: yoh: Lintian says: E: python-expyriment 
 source: python-depends-but-no-python-helper python-expyriment
  [1]http://lintian.debian.org/tags/python-depends-but-no-python-helper.html

  ,---
  | When using debhelper compatibility level below 9, dh will call
  | dh_pysupport by default if it's installed, but the build dependency on
  | python-support is still necessary.
  `---

  So -- with the boost to compat 9 dh_pysupport is not called
  automatically

  Also -- that is the point of calling dh_pysupport and having 
 ${python:Depends}
  to not specify those python and python-pysupport depends manually as it
  is now.

Sorry, I did get that sentence. Would you suggest to remove
${python:Depends} for the dependencies? That solves to lintian error, but
I though it is a general dependency for even python-library.

no -- the other one -- remove explicit python and python-support from Depends

But you would need to call dh_pysupport explicitly probably like

override_dh_install:
dh_install
dh_pysupport

The other warning from the newest lintian version are fixed. I hope it is
not too bad, to make a lintian override for the image-file-in-usr-lib
warning.

yeah -- that should be good

Cheers,
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140408134024.gg8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

On Mon, 07 Apr 2014, Oliver Lindemann wrote:

Possible a very stupid question, but I can't replicate the reported
linitan errors after I git-buildpackage. Any idea why?

oliver@pecog-computserver:~/git$ lintian --version
Lintian v2.5.10.4

I bet that is why:

$ apt-cache policy lintian
lintian:
  Installed: 2.5.21~bpo70+1
  Candidate: 2.5.22~bpo70+1
  Version table:
 2.5.22~bpo70+1 0
100 http://debproxy/debian/ wheezy-backports/main amd64 Packages
 *** 2.5.21~bpo70+1 0
100 /var/lib/dpkg/status
 2.5.10.4 0
500 http://debproxy/debian/ wheezy/main amd64 Packages

so even I didn't have fully up-to-date lintian.  For uploads to Debian proper
(which go through sid AKA unstable) in sid which is 2.5.22.1 atm should be
used... and actually build should happen in sid environment (e.g. via
pbuilder/cowbuilder).

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140407125226.gn8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

ha -- thanks to jwilk now I am aware of

17:59 #debian-python:  jwilk: yoh: Lintian says: E: python-expyriment source: 
python-depends-but-no-python-helper python-expyriment
http://lintian.debian.org/tags/python-depends-but-no-python-helper.html

,---
| When using debhelper compatibility level below 9, dh will call
| dh_pysupport by default if it's installed, but the build dependency on
| python-support is still necessary.
`---

So -- with the boost to compat 9 dh_pysupport is not called
automatically 

Also -- that is the point of calling dh_pysupport and having ${python:Depends}
to not specify those python and python-pysupport depends manually as it
is now.

Also -- worth looking into other lintian errors -- shame on me that I
haven't checked before uploading -2 :-/

$ lintian python-expyriment_0.7.0+git34-g55a4e7e-2_amd64.changes
E: python-expyriment source: python-depends-but-no-python-helper 
python-expyriment
W: python-expyriment: image-file-in-usr-lib 
usr/lib/python2.7/dist-packages/expyriment/expyriment_logo.png
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 /usr/share/doc/python-expyriment/html/_modules/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/control/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/design/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/io/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/io/extras/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/misc/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/stimuli/*
E: python-expyriment: doc-base-file-references-missing-file 
expyriment-documentation:33 
/usr/share/doc/python-expyriment/html/_modules/expyriment/stimuli/extras/*

Cheers,

On Thu, 03 Apr 2014, Oliver Lindemann wrote:

Priority and dehelper compat level have been modified.

Oliver

On 03/04/2014 03:00, Yaroslav Halchenko wrote:

  On Wed, 02 Apr 2014, Andreas Tille wrote:


  Hi,


  just one quick additional note:  Please use Priority: optional.  The
  rationale is discussed in several threads and documented in team policy.


  I would also (strongly) recommend debhelper compat level 9 - but the
  NeuroDebian people might have their reason to derive from this advise.

  indeed -- 9 should be fine for all the reasonable backports... sorry that I
  have missed that ;)

  $ whohas -D Debian,Ubuntu --strict debhelper
  Ubuntu  debhelper   7.4.15ubuntu1   
 [1]http://packages.ubuntu.com/lucid/debhelper
  Ubuntu  debhelper   9.20120115ubuntu3   
 [2]http://packages.ubuntu.com/precise/debhelper
  Ubuntu  debhelper   9.20120608ubuntu1   
 [3]http://packages.ubuntu.com/quantal/debhelper
  Ubuntu  debhelper   9.20120909ubuntu1   
 [4]http://packages.ubuntu.com/raring/debhelper
  Ubuntu  debhelper   9.20130630ubuntu1   
 [5]http://packages.ubuntu.com/saucy/debhelper
  Ubuntu  debhelper   9.20131227ubuntu1   
 [6]http://packages.ubuntu.com/trusty/debhelper
  Debian  debhelper   8.0.0   
 [7]http://packages.debian.org/squeeze/debhelper
  Debian  debhelper   9.20120909~bpo60+1  
 [8]http://packages.debian.org/squeeze-backports/debhelper
  Debian  debhelper   9.20120909  
 [9]http://packages.debian.org/wheezy/debhelper
  Debian  debhelper   9.20140228  
 [10]http://packages.debian.org/jessie/debhelper
  Debian  debhelper   9.20140228  
 [11]http://packages.debian.org/sid/debhelper
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140406155509.gi8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

On Fri, 04 Apr 2014, Andreas Tille wrote:
   The current changelog entry contains the changes to the first package
   (which makes sense if it was released somewhere) and most importantly
   the Closes: #742639 string.  If you want to close a bug in Debian you
   should close it in an upload to Debian (for the nitpickers: yes, I'm
   aware of alternatives, but I'm describing the usual case for a newbee).
   Since the package is not yet released the target distribution should be
   UNRELEASED.  In Debian Med we have a workflow that the sponsor will
   set this to unstable before he is doing the upload.

  And then, if it would be Debian Med team member to upload straight from GIT 
  --
  just let us (NeuroDebian) know and we will upload backport building straight
  from the uploaded source package.

 I'm afraid I don't get what you want to tell me with this sentence.

if before it was me sponsoring the uploads (original straight from the
source package on mentors, then directly from debian-science git), then
if in future some other debian-science team member uploads new version
of the package to Debian proper -- I will build backports for
NeuroDebian using the uploaded source  package (not from Git).

I hope this makes it clearer ;)

   Hope this clarification makes sense and that NeuroDebian people take
   over now with final sponsering since I'm afraid I might miss some more
   pieces of information.

  oki doki -- will do

 Thanks for your upload (confirmed in the other mail) and I hope I did
 not tipped to much on your shoes 

not on mine really -- I usually try to appreciate the fact that
IM/emails/etc can suck for delivering original mental/emotional
intent ;-) (may be that is why I use so many smiles, since I often cheer
while writing the replies ;) )

Cheers
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140404131738.gr8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

NB please stop CCing me and even NeuroDebian team -- both of us (me and
   Michael) are on the debian-science ML

   Oliver -- are you on the list?

On Thu, 03 Apr 2014, Andreas Tille wrote:
  Does that mean that you want me to set the debchange back to version-1
  and remove that tag. No problem. I am happy to do that, if that is required.

 While required is the wrong word, it is regarded as good practice and
 thus I'd recommend it.

  Maybe a stupid question:  I simply do not understand this policy. The
  package is already available via NeuroDebian.

There was some confusion here.

Oliver 

- you are right with your concern that revering back to -1 would be
  incorrect.  -1 was already uploaded and accepted to Debian, so the
  revision could only go forward from here (e.g. to -2 ;)) as it
  is now in GIT

- indeed, tag debian/0.7.0+git34-g55a4e7e-2 was a bit rushed
  I removed it in that Git repo -- please prune locally as well.
  I usually tag only after package is uploaded and some times even wait
  for package to get accepted before I tag/push the tag

I will now build/check/upload the package.

 That's a good point.  I think the NeuroDebian people should take over
 here.  I was not aware of this and was only speaking from a pure Debian
 point of view.  I would be happy if NeuroDebian people would come a bit
 closer to Debian (keyword Debian Pure Blend) and do not provoke making
 people like me who only know the Debian package pool giving questionable
 advise.

NeuroDebian would come a bit closer to Debian if Debian Pure Blends
come closer ;-) or in other words -- Being Debian Pure Blend is
nowhere closer than NeuroDebian is already since we feed few
blends already, including Debian Science, so this comment I would say is
not appropriate and not constructive (in my opinion).  Leaving
(reoccurring) discussion on Pure Blends vs NeuroDebian aside for a
possible beer-drinking occasion let's continue with technical issues
here.

  If I do not make a new
  changelog paragraph, this results in two different initial Debian
  release with exactly same revision number (version-1). One here and
  one at NeuroDebian.  Is that really intended?

 In fact in *this* case you might confuse users who have installed a
 (NeuroDebian) package with a certain version number if you deliver
 another package with the same version but different content.  So in
 this specific case we need to derive from the good practice advise.

 However, STRONGLY (sorry for shouting but I really mean it that way)
 recomment, that NeuroDebian follow the good practice of other
 derivatives and create version numbers like

 upstreamversion-0neurodebian1

 or so.  To explain what I mean I write here what I would consider
 a sensible changelog for your package:



 python-expyriment (0.7.0+git34-g55a4e7e-1) UNRELEASED; urgency=low

   * Initial release to Debian (Closes: #742639)
   * Add list of exclusions for git
   * Add doc-base support
   * Add watch file for uscan
   * Use the correct URLs for the Vcs-* fields (as per Debian Policy 5.6.26)
   * Override the Lintian warning about package section
   * add: upstream/metadata
   * update doc-base

  -- Oliver Lindemann oliver.lindem...@uni-potsdam.de  Wed, 02 Apr 2014 
 19:12:55 +0200

 python-expyriment (0.7.0+git34-g55a4e7e-0neurodebian1) neurodebian; 
 urgency=low

   * Initial release in NeuroDebian

  -- Oliver Lindemann oliver.lindem...@uni-potsdam.de  Wed, 26 Mar 2014 
 14:35:33 +0100

Backports uploaded to NeuroDebian  carry ~nd suffix for Debian revision
portion of the package versions, thus sorting lower than official
version.  See e.g.

$ acpolicy python-expyriment
python-expyriment:
  Installed: 0.7.0+git34-g55a4e7e-1
  Candidate: 0.7.0+git34-g55a4e7e-1
  Version table:
 *** 0.7.0+git34-g55a4e7e-1 0
600 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status
 0.7.0+git34-g55a4e7e-1~nd80+1 0
400 http://neuro.debian.net/debian/ jessie/main amd64 Packages
 0.7.0+git34-g55a4e7e-1~nd70+1 0
400 http://neuro.debian.net/debian/ wheezy/main amd64 Packages

Thus nothing for anyone preparing for proper Debian upload to take care about
really.  If next version of package would modify only content of debian/ --
prepare 0.7.0+git34-g55a4e7e-2.  If that would be a new upstream 'release' or
'snapshot' prepare e.g. 0.7.1-1 and we (NeuroDebian) will take care about
providing backports from NeuroDebian with suffix which would precede
official version, thus all upgrades etc would work just fine.

 The oldest paragraph has a lower version number than *-1 which enables
 a smooth upload to the Debian mirror.  It also expresses that the target
 release is NOT unstable (no idea how NeuroDebian is handling release
 names - unstable should be reserved for Debian unstable.  For instance
 Ubuntu is using quantal currently (if I'm not miss leaded).

 The current changelog entry contains the changes to the first package
 (which makes sense if 

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

On Thu, 03 Apr 2014, Yaroslav Halchenko wrote:
 I will now build/check/upload the package.

uploaded and pushed the tag

Cheers!

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140404045948.gp8...@onerussian.com

Re: Choosing proper Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)

[Yaroslav Halchenko]

On Wed, 02 Apr 2014, Andreas Tille wrote:

 Hi,

 just one quick additional note:  Please use Priority: optional.  The
 rationale is discussed in several threads and documented in team policy.

 I would also (strongly) recommend debhelper compat level 9 - but the
 NeuroDebian people might have their reason to derive from this advise.

indeed -- 9 should be fine for all the reasonable backports... sorry that I
have missed that ;)

$ whohas -D Debian,Ubuntu --strict debhelper   

 
Ubuntu  debhelper   7.4.15ubuntu1   
http://packages.ubuntu.com/lucid/debhelper
Ubuntu  debhelper   9.20120115ubuntu3   
http://packages.ubuntu.com/precise/debhelper
Ubuntu  debhelper   9.20120608ubuntu1   
http://packages.ubuntu.com/quantal/debhelper
Ubuntu  debhelper   9.20120909ubuntu1   
http://packages.ubuntu.com/raring/debhelper
Ubuntu  debhelper   9.20130630ubuntu1   
http://packages.ubuntu.com/saucy/debhelper
Ubuntu  debhelper   9.20131227ubuntu1   
http://packages.ubuntu.com/trusty/debhelper
Debian  debhelper   8.0.0   
http://packages.debian.org/squeeze/debhelper
Debian  debhelper   9.20120909~bpo60+1  
http://packages.debian.org/squeeze-backports/debhelper
Debian  debhelper   9.20120909  
http://packages.debian.org/wheezy/debhelper
Debian  debhelper   9.20140228  
http://packages.debian.org/jessie/debhelper
Debian  debhelper   9.20140228  
http://packages.debian.org/sid/debhelper

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140403010047.ga8...@onerussian.com

Re: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments

[Yaroslav Halchenko]

Hi Oliver,

Andreas, of the Debian Science team (I am part of too), suggested to
invite you to join.  Given that as the upstream developer of expyriment
you are primarily interested to have only that piece
packaged/distributed through Debian, not sure if it would be of direct
interest to you.  But here you come:  next step could be to bring
expyriment under Debian science umbrella/maintenance -- that might
provide numerous benefits in the long run (more help with
updating/fixing the package etc).  Even though we are finalizing
packaging to satisfy Debian policy standards, it might need tiny bit of
work to homogenize it with the rest of Debian Science packages...
So I will leave it for you to decide, and Andreas I bet could guide you
if you decide to follow this direction

P.S. we would always be able to provide backports through NeuroDebian as
well, as long as packaging keeps backporting in mind -- so there should
be no problem.

Cheers!

On Wed, 26 Mar 2014, Andreas Tille wrote:

 Hi Yaroslav,

 again forwarding to Debian Science - please recommend Oliver Lindemann
 to subscribe Debian Science.

 Kind regards
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140326163915.gt28...@onerussian.com

Re: Bug#742573: ITP: seaborn -- Python statistical visualization library

[Yaroslav Halchenko]

On Wed, 26 Mar 2014, Andreas Tille wrote:
 since I assume you will maintain this package in Debian Science team I'm

lazy me didn't think about placing it under Debian Science but I guess
it shouldn't hurt ;-)  would need to recall (GIT) layout/procedures.

if you have a look
http://github.com/yarikoptic/seaborn
(was aiming to place it on github.com/neurodebian as canonical VCS but
could be changed) if you spot more things TODO...
I have decided to use pybuild more, but apparently would need still to
take care about oddities while backporting to wheezy (may be just
backporting nose there):

make[1]: Entering directory `/tmp/buildd/seaborn-0.3.0'
xvfb-run --auto-servernum --server-num=20 dh_auto_test override_dh_auto_test
/usr/bin/python2.7: No module named nose.__main__; 'nose' is a package and 
cannot be directly executed
E: pybuild pybuild:256: test: plugin distutils failed with: exit code=1: cd 
'/tmp/buildd/seaborn-0.3.0/.pybuild/pythonX.Y_2.7/build'; python2.7 -m nose 
--with-doctest 
dh_auto_test: pybuild --test -i python{version} -p 2.7 2.6 --dir . returned 
exit code 13
make[1]: *** [override_dh_auto_test] Error 13
make[1]: Leaving directory `/tmp/buildd/seaborn-0.3.0'


Otherwise, for sid, packaging is complete I believe -- just waiting for
scipy to get finally rebuilt for python3.4 so we could build this beast.
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140326164849.gu28...@onerussian.com

Re: Conflict between debian/upstream (DEP-12) debian/upstream/ (uscan)

[Yaroslav Halchenko]

Have I missed the background? 

is debian/watch getting renamed to debian/upstream -- where is the
conflict?

On Wed, 12 Feb 2014, Andreas Tille wrote:

 Hi,

 On Wed, Feb 12, 2014 at 04:11:41PM +0900, Charles Plessy wrote:
  Le Wed, Feb 12, 2014 at 12:06:42AM -0500, James McCoy a écrit :

   That being said, I don't have access to most of the packages.  Even if I
   did, it feels dirty to go and commit to a couple hundred packages I
   have no involvement with instead of adapting two pieces of software to
   deal with both path names.

  Hi James,

  you already have commit access to the Debian Med packages, like all other
  Debian developers.  Please go ahead !

 I take this go ahead for yes, I accept the move.  While I would have
 no problems with this I wonder if it is appropriate to simply go on here
 without at least informing Debian Science and DebiChem who also maintain
 some d/upstream files.  If I might have sounded against the move in the
 past my main problem was that the affected parties were not included into
 the decision making process.

 So I have put the relevant mailing lists in CC to at least give people
 lurking there some heads up and a slight chance to insist.

 I would say:  If nobody will insist until after the weekend we might go
 ahead.  And for the actual action I agree with Charles that I see no
 problem if James would simply commit a change to Debian Med repositories
 (SVN and Git).  That's fine and would save us (me or Charles) some work
 and is perfectly possible permission-wise.

 Kind regards

   Andreas.

 PS: I think I did not got any answer to my question about further plans
 for the debian/upstream/ dir.  I would be really happy to understand
 the big picture to make sure we will not again invent something which
 needs to be changed later on.
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140222154310.gf5...@onerussian.com

Re: Conflict between debian/upstream (DEP-12) debian/upstream/ (uscan)

[Yaroslav Halchenko]

ah -- info is there (missed it among numerous) CCs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736760

citing:
Since 2.14.1, uscan now uses debian/upstream/signing-key.* for the
upstream signatures.

This seems to conflict with the debian/upstream file, as decribed in
https://wiki.debian.org/UpstreamMetadata
http://dep.debian.net/deps/dep12/

In general I would not mind collecting all the upstream information under
debian/upstream/

But it would have made much more sense if e.g. debian/watch should have been
renamed into e.g.  debian/upstream/origin  -- then I would have seen point of
uscan using now debian/upstream/signing-key.*.  Now such a rename in
uscan is IMHO only brings even more confusion among debian/ files
(debian/watch which uses debian/upstream/signing-key.*).


On Sat, 22 Feb 2014, Yaroslav Halchenko wrote:

 Have I missed the background? 

 is debian/watch getting renamed to debian/upstream -- where is the
 conflict?

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140222154807.gg5...@onerussian.com

Re: RFS: VLFeat computer vision library

[Yaroslav Halchenko]

FWIW -- I have tried to build backports using our neurodebian setup...  it seem
that all 32bit userland builds (while system is running on 64bit kernel)
fail with

...
bin/glnxa64/objs/aib.o bin/glnxa64/objs/array.o 
bin/glnxa64/objs/covdet.o bin/glnxa64/objs/fisher.o bin/glnxa64/objs/generic.o 
bin/glnxa64/objs/getopt_long.o bin/glnxa64/objs/gmm.o 
bin/glnxa64/objs/hikmeans.o bin/glnxa64/objs/hog.o bin/glnxa64/objs/homkermap.o 
bin/glnxa64/objs/host.o bin/glnxa64/objs/ikmeans.o bin/glnxa64/objs/imopv.o 
bin/glnxa64/objs/imopv_sse2.o bin/glnxa64/objs/kdtree.o 
bin/glnxa64/objs/kmeans.o bin/glnxa64/objs/lbp.o bin/glnxa64/objs/liop.o 
bin/glnxa64/objs/mathop.o bin/glnxa64/objs/mathop_avx.o 
bin/glnxa64/objs/mathop_sse2.o bin/glnxa64/objs/mser.o bin/glnxa64/objs/pgm.o 
bin/glnxa64/objs/quickshift.o bin/glnxa64/objs/random.o 
bin/glnxa64/objs/rodrigues.o bin/glnxa64/objs/scalespace.o 
bin/glnxa64/objs/slic.o bin/glnxa64/objs/stringop.o bin/glnxa64/objs/svm.o 
bin/glnxa64/objs/svmdataset.o bin/glnxa64/objs/vlad.o\
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--rpath,\$ORIGIN/ 
-Wl,--as-needed -lpthread -lm -lm -lpthread -m64\
-fopenmp \
-Wl,-soname,libvl.so.0 \
-o bin/glnxa64/libvl.so
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/4.8/libgomp.so 
when searching for -lgomp
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/4.8/libgomp.a 
when searching for -lgomp
/usr/bin/ld: cannot find -lgomp
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/4.8/libgcc.a 
when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/4.8/libgcc_s.so 
when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/4.8/libgcc.a 
when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/4.8/libgcc_s.so 
when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [bin/glnxa64/libvl.so] Error 1
make[2]: Leaving directory `/tmp/buildd/vlfeat-0.9.17+dfsg0'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/tmp/buildd/vlfeat-0.9.17+dfsg0'
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


so you might check on that... I think I ran into similar problem before but
can't recall/look into it atm.

On Fri, 22 Nov 2013, Anton Gladky wrote:

 Hi Andreas and Dima,

 sorry I forgot to mention it here, I have already uploaded this package a 
 couple
 of days ago. It is in NEW-queue already.

 But your suggestions are really reasonable. Dima, could, you, please,
 commit it to git?

 Thanks,

 Anton


 2013/11/22 Andreas Tille andr...@an3as.eu:
  Hi Dima,

  thanks for your patience - Alioth is up and running now again.

  On Fri, Nov 08, 2013 at 10:49:46AM -0800, Dima Kogan wrote:
  Andreas Tille andr...@an3as.eu writes:

   Hi Dima,

   On Thu, Nov 07, 2013 at 11:10:54PM -0800, Dima Kogan wrote:
2013/11/8 Dima Kogan d...@secretsauce.net:
Hi all.

I packaged VLFeat (http://vlfeat.org), and am looking for 
sponsorship.

Anton Gladky gladky.an...@gmail.com writes:

Hi Dima, I will be glad to review/upload this package.
But i can do it only on weekends.

   Thank you very much, Anton. There is no rush, so please take your time.

   Is your work in Debian Science VCS?

  Yes:

   http://anonscm.debian.org/gitweb/?p=debian-science/packages/vlfeat.git

  I checked this out and have noticed in debian/README.source:

The SIFT implementation was removed from the source ...

  That's OK, but if you change the upstream source you should either
  provide

 a) get-orig-source target in d/rules
 b) specify Files-Excluded in d/copyright and use the enhanced
uscan described here:

   https://wiki.debian.org/UscanEnhancements

  I personally recommend the latter since it is more simple to implement
  and from my personal point of view more transparent.

   In what Debian Science task would this library fit best?

  The image analysis task sounds most appropriate to me.

  I added

 Suggests: libvlfeat-dev

  since we usually link to user applications in non-dev metapackages.  It 
  might
  make sense to consider an imageanalysis-dev metapackage since the task now
  is assembling several lib*-dev packages that way.  What do you think?

  Is there any chance to also create a vlfeat-{tools,utils} package with a
  plain user application for demonstarting the library?

  Feel 

Re: RFS: VLFeat computer vision library

[Yaroslav Halchenko]

On Fri, 22 Nov 2013, Dima Kogan wrote:
 faith in it now. Yaroslav, can you pleaase try it again on your 32-bit
 install? I can set one up in emulation, but hopefully it just works now.
 The tree is here:

  http://anonscm.debian.org/gitweb/?p=debian-science/packages/vlfeat.git

for lazy me it would be easier if I just had a .dsc uploaded to
mentors...  otherwise -- yeah, I will try later ;)

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131122230521.gc6...@onerussian.com

Re: hello from potential new maintainer

[Yaroslav Halchenko]

On Tue, 08 Oct 2013, Ghislain Vaillant wrote:

 Hi everyone,

 Thought I would introduce myself first before submitting anything here.
 I am a Ph.D. student in medical imaging with a special interest in

I guess the work of http://www.debian.org/devel/debian-med/ and
http://neuro.debian.net/ would be of interest to you as well (there are
no restrictions in how many teams/sub-projects you could participate ;))

 computing and open source. I would like to package some of the tools and
 libraries I have been using to Debian, since most people in my lab use
 either straight Debian or, more often, Ubuntu.

We could also ship backports (for Debian and Ubuntu) of
interesting packages ready for consumption through NeuroDebian.

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131008180458.gu26...@onerussian.com

Re: Packaging special packages

[Yaroslav Halchenko]

Hi Ole,

From what I understand there are really two questions:

- should we upload small pipeline packages?

NB Julian's comment on They are not useful for the general public imho
should not of concern here -- probably major part of the Debian
archive is not useful for the general public and that is what makes
Debian Debian -- it is useful for everyone!

  if the concern here is them being useless without data and small, then
  probably not worthwhile uploading into main unless data gets available
  there as well.  If it could (theoretically) be used without data
  but too small on its own -- may be worth bundling pipelines into
  a single package?

  some of our (NeuroDebian) packages also require vast data but in
  general usable without it and large enough, so we do ship those tools
  in Debian proper while providing 'complimentary' data packages
  from a dedicated 'data' suite of neurodebian.

- Data packages:  if it is just 2M I probably would try to upload
  that tiny pipeline + data in a single package (might need 2 pkgs if
  pipeline is of arch 'any').  It should fulfill the requirement to no
  pollute archive with tiny packages since data would add the weight ;)

  If it is 100M -- indeed a new resolution would be needed since archive
  atm is not welcoming data packages per se.  It might then go to
  contrib as a 'downloader' package.  If pipeline could be used without
  data, I would Recommend data from contrib (forgot now if that is
  legit according to the policy, if not -- Suggest)

On Wed, 11 Sep 2013, Olе Streicher wrote:

 Hi Science packagers,

 Some time ago, there was a small discussion between me and Julian Taylor
 about the packaging of a special package [1], which was also forwarded
 to this list.

 However, I would like to re-start this discussion now and get some more
 opinions since the problem may exist for a couple of scientific software
 packages:

 The European Southern Observatory runs one telescope (VLT) in Chile
 which uses several instruments (camera, spectrograph etc.) to get the
 data. The data processing for these instruments is very specific and is
 done in so-called pipelines, from which about 20 exist [2]. Their
 structure is quite similar, so once the first pipeline is packaged, the
 rest doesn't require much effort. The dependencies of the pipelines are
 already packaged in Debian.

 However, there is one critics, that was brought up by Julian: every
 pipeline can be used only for one specific instrument on this unique
 telescope. If one doesn't have observational data from the VLT for that
 specific instrument, the pipeline is worthless. And usually all
 observations are done by a specific request of a scientist to fullfill
 his needs.

 On the other hand, these data become freely available for everyone [3],
 allowing (and ecouraging) the scientific re-use by the whole
 community. Especially for scientists without direct access to the
 telescope, this is an excellent opportunity for scientific work. I think
 that this perfectly fits into the best goals of the Debian ethics.

 Typically, binary packages of the pipeline code would have a footstamp
 of  ~ 1MB. However, the pipelines are usually accompanied with a
 calibration data set, whose size ranges from some 100 kB to ~100 MB. The
 calibration files are needed to actually run the pipeline with some
 scientific result. I think it would be in any case too much to put all
 these data onto Debian mirrors, just for the few astronomers out there.

 So, having a package that downloads and installs the calibration data
 would be the best here, right? But this would make the packages no
 longer self-contained. Would that be a legal problem for a Debian
 package in main?

 What do you think: is it worth to upload these pipeline packages to
 Debian? Or is it better to keep them in some personal repository?

 Best regards

 Ole

 [1] http://bugs.debian.org/709330
 [2] http://www.eso.org/sci/software/pipelines/
 [3] http://www.eso.org/UserPortal
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130911203339.gf11...@onerussian.com

debian/upstream::references:multiple_components

[Yaroslav Halchenko]

oki doki -- since it seems to be too quiet...  let me start from an
attacking angle:  by using debian/upstream as the container for
publication references we can't decouple separate components having
different publication references to use for different components,
neither shipped in separate binary packages or a single one (e.g. a
collection of datasets).

The only viable resolution as far as I see it to extend Reference
entry(ies) with e.g. Files: field which would contain a list of globs
to point to files as installed on the system by binary packages.  But
that cross the line from upstream and source packages into the land of
binary packages... not sure how you guys would accept it.

Otherwise, without such specification, all the references are somewhat
useless e.g. in cases when there are multiple for completely different
components provided by any given source package.

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130823013048.ga30...@onerussian.com

Re: Report from Debian Science BoF at DebConf 13

[Yaroslav Halchenko]

Lame me missed the whole debconf13 in physical presence and remote
participation in this BoF. 

FWIW it is great to see that discussion was going about the issue of
citations.

From the wiki:

Create a dh_science helper
All debian/upstream files could be installed inside the binary package at 
for instance
/usr/share/science/pkg 
This could just be done by some dh_science helper automatically and it also 
could add some trigger which creates an according BibTeX file all time a new 
package containing a citation is installed. 

I would vote for this feature! ;)  so far I have been adding debian/upstream to
docs of the my packages pretty much with the hope that some time later they
could be used exactly for that purpose of collecting bibliographies for
installed packages... echoing an older somewhat abandoned  attempt where
we suggested to keep bibliography in copyright files

http://anonscm.debian.org/gitweb/?p=pkg-exppsy/debian-bibliography.git;a=blob;hb=HEAD;f=tools/dbib_collect

I would not call the helper dh_science though since it is not
science-specific... if bibliographies to come solely from debian/upstream,
should be dh_upstream I guess ;)

Cheers!

On Mon, 12 Aug 2013, Andreas Tille wrote:

 Hi to all who were not able to enjoy DebConf,

 we just had some Science BoF with some results about handling citations.
 I did the summary inside the Wiki to enable further input:

https://wiki.debian.org/DebianScience/Citations

 There was some hint about the usage of DebTags via goplay / goscience.

 It was also discussed why we can not cover all needs we have in Blends
 by debtags and nobody even raised their hand to volunteer making sure we
 get some match between DebTags and Tasks which would enable some kind of
 matching in a sense that if a package fits per DebTag information it
 could be automatically taken over to the relevant task.  As long as this
 does not happen the most simple way to get your package included into a
 task is naming the package and the task(s) it fits into on the Debian
 Science mailing list.  We do the edit for you if you have no idea how to
 add the one liner per package into the tasks file.

 The gobby notes do not contain further results - perhaps somebody has
 some comments about important things.  Other attendees might comment on.

 Greetings from Le Camp

Andreas.
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130812163008.gb17...@onerussian.com

Re: Wiki for science package is damaged

[Yaroslav Halchenko]

That is because UDD is currently not exposed via DDE (ie not listed on
http://dde.debian.net/dde/?list).
Related discussion is
https://lists.debian.org/debian-qa/2012/03/msg00043.html
but I am myself not clear on what is the current status/plan?

On Thu, 11 Apr 2013, melchiaros wrote:

 Hi,

 this mornign was a change on:

 http://blends.alioth.debian.org/science/tasks/linguistics

 and

 http://blends.alioth.debian.org/science/tasks/dataacquisition

 and maybe other project sides,

 which has dropped the long descriptions of the software packages.

 Instead there are lines like those for example:

 ??? Missing long description for package apertium

 Is it possible to revert this changes and bring back to full descriptions?


 greetings

 melchiaros
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130411124510.gi5...@onerussian.com

missing banner on debian-science task pages

[Yaroslav Halchenko]

e.g.  http://blends.alioth.debian.org/science/tasks/meteorology page has empty
banner on top -- shouldn't (wasn't) there some logo -- img is missing src
there entirely.

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130328230222.gj2...@onerussian.com

[RFC] debian/upstream -- add Funding: field

[Yaroslav Halchenko]

Many projects are often (fully or partially) supported by different
governmental agencies and/or private funds.  Those in turn often request
(or at least ask) to acknowledge such sources of funding on projects
pages and corresponding products.  ATM there is quite a few of such
projects maintained in Debian but it is nearly impossible to
identify them, that is why I think it would be great to add a new field,
which would describe those, e.g.

Funding: NSF XX-123456, NIH 123456, ...

That would improve our ability to show to those agencies that we take
care about considerable amount of products produced from their funding
initiatives.

What do you think?
-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130313130731.gc2...@onerussian.com

http://wiki.debian.org/UpstreamMetadata -- broken links to .bib-related pages

[Yaroslav Halchenko]

in UDD loading through a YAML intermediate

http://upstream-metadata.debian.net/for_UDD/biblio.yaml  -- NOT FOUND
http://anonscm.debian.org/viewvc/collab-qa/udd/config-org.yaml -- An Exception 
Has Occurred
...

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130313133716.gg2...@onerussian.com

UpstreamMetadata -- any official reference

[Yaroslav Halchenko]

Is there any other than DEP 12 public reference to this effort (
proceedings/talk/abstract ) which could serve as an official
reference for this effort?

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130313133940.gh2...@onerussian.com

Re: [RFC] debian/upstream -- add Funding: field

[Yaroslav Halchenko]

On Wed, 13 Mar 2013, Andreas Tille wrote:
  Funding: NSF OCI-12345
 This is correct syntax.

check

  or a list
  Funding:
   - NSF OCI-12345
   - NIH XXX-12345
  Is that correct approach/syntax?
 I admit, I'm not sure whether this is correct YAML.  Any reason to not simply 
 use
Funding: NSF OCI-12345, NIH XXX-12345

http://en.wikipedia.org/wiki/YAML :

Lists

Conventional block format uses a hyphen+space to begin a new item in list.

 --- # Favorite movies
 - Casablanca
 - North by Northwest
 - The Man Who Wasn't There

Optional inline format is delimited by comma+space and enclosed in brackets 
(similar to JSON).[6]

 --- # Shopping list
 [milk, pumpkin pie, eggs, juice]

so one-liner then should be

Funding: [NSF OCI-12345, NIH XXX-12345]


 I admit that information is not perfectly structured any more but I
 would like to rather keep things simple than fiddling around with list
 syntax.

yeah... for a moment I even thought to suggest making it an associative array
with keys being funding agencies, but then I thought it would be an overkill,
thus inferior.  If we just adhere to some sources naming conventions (e.g. NSF
instead of National Science Foundation and alike) -- we should be fine.  As
long as we identify the agency and possibly able to extract the related award
identifier (just a number in case of NSF), we could provide cool
hyperlinks to the respective pages, e.g. for NSF it is

http://www.nsf.gov/awardsearch/showAward?AWD_ID=AWARD_NUMBER

   Just a suggestion - otherwise it is your task to check whether
 the syntax is correct. :-P

check ;)

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130313135444.gi2...@onerussian.com

Re: You can now check BibTeX file obtained from debian/upstream files

[Yaroslav Halchenko]

On Thu, 06 Sep 2012, Andreas Tille wrote:
  ultimate use case -- tool which given a list of packages returns list of
  bibliography entries ready for use in a publication.
 I could imagine several ways to answer this question (my prefered way
 would be to use UDD).  Doing this based on the information in the BibTeX
 file is IMHO a misuse of the BibTeX database:  BibTeX was invented to
 manage citations for LaTeX texts - it was not invented to obtain
 information about Debian packages.

hm... [cut my previous, ironic version of the reply] 
wasn't it invented to cite the software provided by Debian packaging?
if so, association with the packages is imho quite relevant there then

 So while it would be pretty simple to add the field you were asking for
 to the BibTeX file you need better arguments to convince me to do
 something that could be done with a pretty simple UDD query way more
 reliably.

users + UDD == confusion

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120906134008.gu26...@onerussian.com

Re: You can now check BibTeX file obtained from debian/upstream files

[Yaroslav Halchenko]

On Sun, 02 Sep 2012, Andreas Tille wrote:
  DebianPackage) could be automatically  filled up -- you already
  have package names in the .tex table you generate, but not in .bib
  (which is what I whined about)

 A, this was not clear to me because I somehow fail to see any use case
 for this.  Can you explain what purpose such a field should serve in the
 BibTeX file - perhaps I'm missing something.

so I could easily associate bibtex entries with packages... or actually
the reverse mapping would be of interest more -- given a package name to
find relevant bibliography entries.  In my existing use case I was
trying to find a package with multiple references so I could take it as
an example of such debian/upstream ;)

ultimate use case -- tool which given a list of packages returns list of
bibliography entries ready for use in a publication.

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120905154830.gd26...@onerussian.com

Re: You can now check BibTeX file obtained from debian/upstream files

[Yaroslav Halchenko]

On Fri, 31 Aug 2012, Andreas Tille wrote:

  DSCPackages = {source1, source2, ...} # there could be multiple
  or
  DEBPackages = {binary1, binary2, ...}

  so that .bib is sufficient to point to the corresponding package(s)
  ?

 There is the (not yet documented Field[1]) Debian-Package where you
 can restrict a citation to a certain binary package.

I saw it -- but this one is to be defined in debian/upstream.  It is not
present atm in the generated .bib file where Debian-Package (if we just
maintain the same name as a name of bibtex field, may be just remove '-'
since I am not sure if that is supported in bibtex, i.e.
DebianPackage) could be automatically  filled up -- you already
have package names in the .tex table you generate, but not in .bib
(which is what I whined about)

 There is no real solution for having one citation for more than one
 source and binary packages (and I have no idea how to implement this
 with the current system).

wouldn't it come natively if I have a copy of debian/upstream with
references in multiple source packages?

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120831131358.gc2...@onerussian.com

Re: You can now check BibTeX file obtained from debian/upstream files

[Yaroslav Halchenko]

On Sun, 06 May 2012, Andreas Tille wrote:

 At

http://blends.debian.net/packages-metadata/

 you can find the files debian.{bib,tex,pdf}.  All these files are

Thank you Andreas once again for pushing this.

quick better-later-than-never comment: wouldn't it be nice to have some
bibtex fields to signal which packages the reference relates to? e.g.

DSCPackages = {source1, source2, ...} # there could be multiple
or
DEBPackages = {binary1, binary2, ...}

so that .bib is sufficient to point to the corresponding package(s)
?

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120830140554.ga14...@onerussian.com

Re: RE : Kudos to High Energy Physics packagers (Re: r3479 - /projects/science/trunk/debian-science/tasks/highenergy-physics)

[Yaroslav Halchenko]

my 1 c

On Sat, 14 Jul 2012, PICCA Frédéric-Emmanuel wrote:
 Hello, yes we are preparing a PAN Blend (Photon and Neutron Blend) dedicated 
 to the synchrotron and neutron facilities.

Although I might sound hypocritical, I am not sure if separating out
into a new blend would be worthwhile unless there is something radically
new to be added to it which would not suite the whole Debian Science
blend.  If that happens, IMHO, it would still be great if corresponding
task page in Debian Science blend would stay maintained/updated as
well.

And a separate blend issue imho is almost orthogonal to a having
of dedicated (sub)teams, alioth project, mailing lists 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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120714145357.gg21...@onerussian.com