Re: Any input for some talk about usage of Debian in HPC
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?
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
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
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?
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
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
+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
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
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
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
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
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
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
__
/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'
__ 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
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
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
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
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)
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?)
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
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
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?
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: looking for some feedback on singularity-container on Testing
On Wed, 26 Sep 2018, Christophe Trophime wrote: >Hi, >I'm experiencing with singularity-container on a SMP Debian/Testing. >I'm trying to run a singularity of a Debian/Stretch based app. >I cannot get to run the app : >mpirun -np n execute stretch-app.simg app >Did someone have some experiences with singularity? me -- 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?
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?
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 usc
Re: Bug#907806: How to disable tests for Python2 only?
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?
On Mon, 10 Sep 2018, Andreas Tille wrote: > On Mon, Sep 10, 2018 at 10:54:02AM -0400, Yaroslav Halchenko wrote: > > Outstanding few issues so far are reported/dealt with upstream: > > https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker > > updating packaging is in debian-0.20 branch at > > http://github.com/yarikoptic/scikit-learn > ... sorry to repeat myself but having team maintained packages on > github is not inviting to others. Is there any reason not to > use Salsa? yeap, let's make a repo on salsa. Would you be ok to retain my weird "based on upstream git" setup? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: How to disable tests for Python2 only?
On Mon, 10 Sep 2018, Andrey Rahmatullin wrote: > On Mon, Sep 10, 2018 at 04:33:21PM +0200, Andreas Tille wrote: > > Hi, > > looking at the bug log of scikit-learn[1] it seems to be a simple means to > > do > > --- a/debian/control > > +++ b/debian/control > > @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, > > python3-pytest, > > python3-matplotlib, > > python3-joblib (>= 0.9.2), > > + python3-distributed , > > libsvm-dev (>= 2.84.0), > > libatlas3-base, > > Build-Depends-Indep: > I don't think that's how build profiles work. > > However, it seems that due to the fact that this package uses > > --buildsystem=python_distutils > Which is already a problem, as it doesn't support py3. > There is a lot of strange hacks in this rules file. I'm especially > interested in "dh_autoreconf debian/rules -- clean_generated" but that's a > question for another discussion. many hacks might be left overs for historical (age of the package) + backports (hence cythonize rule, allows to provide backports for older debian/ubuntu via neurodebian) reason. Would be nice to review/remove those no longer needed, but attention should be taken care not to break backportability. So far built/tested fine even for jessie (8) and ubuntu xenial (16.04). > > Are there any other ways to exclude some tests for Python2 to make this > > package build again? > rules call nosetests directly so I guess find out how to do that with > nosetests. overall, as I've just noted in the bugreport, I think it is better to concentrate on making upcoming 0.20 (will use pytest not nose among other things) into debian. Outstanding few issues so far are reported/dealt with upstream: https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker updating packaging is in debian-0.20 branch at http://github.com/yarikoptic/scikit-learn -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: New version of statsmodels is out possibly fixing important bug - any volunteer
Fwiw I will look into updating soon unless someone beats me to it On August 11, 2018 1:50:42 AM EDT, Andreas Tille wrote: >Hi, > >it seems upstream dealt with issue #3892 in latest upstream version >0.9. >As far as I can see this will fix #880245. > >Any volunteer to upgrade the package? > >Kind regards > > Andreas. -- Sent from a phone which beats iPhone.
Re: PyTables version 3.4.3-2
building now Thanks! On Tue, 15 May 2018, Antonio Valentino wrote: > Dear Frederic, dear Yaroslav, > I prepared a new version of the debian package for PyTables (3.4.3-2). > The new version fixes a serious bug (#898577) [3], it is a compatibility > issue with numpy 1.14.3 that causes a FTBFS. > The new package is available on git [1] and on mentors [2]. > Please consider to upload. > [1] https://salsa.debian.org/science-team/pytables.git > [2] https://mentors.debian.net/package/pytables > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898577 > 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: Taking over scikit-learn into Debian Science team maintenance
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 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
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
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
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?
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)
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
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?
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] ...)
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] ...)
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
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)
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
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
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
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
Thanks for digging into this and sorry I have missed that. I typically add export http*_proxy to prevent any network interactions but I guess didn't get that far with statsmodels. FWIW, for dipy package I now ask upstream to provide me e.g. dipy_0.12.0.orig-doc-examples.tar.gz where there are examples, which require lengthy computation to produce doc pieces To resolve this issue quickly, I might have also simply patched/excluded those examples/docs which require external datasets (especially with incompatible terms), from building. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Sun, 24 Sep 2017, Andreas Tille wrote: > Hi Yaroslav, > On Sat, Sep 23, 2017 at 10:00:35AM -0400, Yaroslav Halchenko wrote: > > > I would prefer to move pandas to Debian Science or Debian Python. I > > > fail to see the specific use in NeuroDebian field. > > I ould repeat that I don't mind having it moved under -science or > > -python teams maintenance. But it shouldn't make it more difficult for > > me to maintain it. > Thanks for the permission to move the package. Could you please be more > verbose what exactly might make your maintenance more difficult? Its > about changing Vcs-Fields and Maintainer field - is this in some way > making things harder for you? nah, VCS field(s) is a non issue. making package non-backportable automatically, introducing new patch management mechanisms (dpq or whatnot) which I am not too familiar with -- such things could make things more difficult. If just a matter of moving a repository -- that is all ok as long as I know where to find a new one and could contribute ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Sun, 24 Sep 2017, Andreas Tille wrote: > On Sun, Sep 24, 2017 at 11:24:10AM -0700, Diane Trout wrote: > > Status with statsmodels almost done > > Trying to deal with jquery. > > leaving command > > -rm ./build/html/_static/jquery.js > > causes a build failure now. > Without checking the source: I'm usually doing something like > override_dh_install: > dh_install > find debian -name jquery.js -delete > This should avoid build failures. FTR not sure how that could have caused a build failure since leading '-' in makefile means "ignore the failure" -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Fri, 22 Sep 2017, Andreas Tille wrote: > > diff -Nru pandas-0.20.3/debian/changelog pandas-0.20.3/debian/changelog > > --- pandas-0.20.3/debian/changelog 2017-07-10 20:00:59.0 -0400 > > +++ pandas-0.20.3/debian/changelog 2017-09-21 16:11:29.0 -0400 > > @@ -1,3 +1,14 @@ > > +pandas (0.20.3-2) unstable; urgency=medium > > + > > + * debian/control > > +- boosted policy to 4.0.0 (I think we should be ok) > Current is 4.1.0 (despite lintian claims 4.0.0) yeap, noted > > I could also add you to pkg-exppsy team under which we still have the > > "active" > > vcs for pandas. > I would prefer to move pandas to Debian Science or Debian Python. I > fail to see the specific use in NeuroDebian field. I ould repeat that I don't mind having it moved under -science or -python teams maintenance. But it shouldn't make it more difficult for me to maintain it. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Fri, 22 Sep 2017, Piotr Ożarowski wrote: > [Diane Trout, 2017-09-21] > > I made larger changes to statsmodels, by using pybuild instead of the > > previous multiple targets in debian/rules. > you can simplify it even further by using pybuild's --ext-dest-dir: > (I didn't test as this branch FTBFS for me) how recent is that feature? one of the concerns of mine to be paid attention to is being able to easily backport this package for older debian/ubuntus (we could patch, by per-release patching is somewhat tedious) for the upload to NeuroDebian. Current state of things (I will now upload that fresh -2 build now for where it built) is at http://neuro.debian.net/pkgs/python-pandas.html -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
On Thu, 21 Sep 2017, Diane Trout wrote: > On Thu, 2017-09-21 at 17:56 -0400, Yaroslav Halchenko wrote: > > If you could allow to review would be great. > > Thanks for all the work. > > I was btw also trying to build with the patch you shared yesterday > Once I have all the changes for pandas would you like me to put them on > a branch on alioth? Or should I send them via format-patch somewhere? I could work with either. I will upload now -2 (sorry if we duplicated some efforts) with following changes (diff for changelog): diff -Nru pandas-0.20.3/debian/changelog pandas-0.20.3/debian/changelog --- pandas-0.20.3/debian/changelog 2017-07-10 20:00:59.0 -0400 +++ pandas-0.20.3/debian/changelog 2017-09-21 16:11:29.0 -0400 @@ -1,3 +1,14 @@ +pandas (0.20.3-2) unstable; urgency=medium + + * debian/control +- boosted policy to 4.0.0 (I think we should be ok) +- drop statsmodels from build-depends to altogether avoid the circular + build-depends (Closes: #875805) + * Diane Trout: +- Add dateutil-2.6.1-fixed-ambiguous-tz-dst-be.patch (Closes: #875807) + + -- Yaroslav Halchenko Thu, 21 Sep 2017 16:11:29 -0400 I could also add you to pkg-exppsy team under which we still have the "active" vcs for pandas. > Also it looked to me like you were changing debian/changelog with each > change? (Some people just use the git log and then apply all the > updates to d/changelog in one go with git buildpackage. I prefer indeed reflecting each change in a changelog with a commit and using debcommit to commit it ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Python 3 Statsmodels & Pandas
If you could allow to review would be great. Thanks for all the work. I was btw also trying to build with the patch you shared yesterday On September 21, 2017 5:48:58 PM EDT, Diane Trout wrote: > >> If my poor opinion counts: For the moment we should run those tests >> in >> the build process than can be easily be run. Everything else should >> probably be sorted out later (in autopkgtest or another later upload >> if >> somebody has a clue how we can solve the circular depenendecies). >> >> We somehow need to get some working spatstats to continue with other >> packages. >> > >Status: > >[X] Pandas builds with nocheck, nodoc >[X] Statsmodels builds with Python 3 using above pandas >[X] Pandas tests pass with statsmodels for Python 2 & 3 installed. >[ ] Pandas builds docs with statsmodels installed > >My most recent build error was about pandoc not being available. > >Unfortunately the tests take a long time enough that I can write this >email before I know if adding pandoc fixed the problem. > >dh_auto_tests run Python 2.7, 3.5, 3.6 tests, and then autopkgtests >runs them again. > >I posted the larger fixes to pandas I've done to the appropriate bugs > >#875807 python3-pandas FTBFS: 3 timezone unit tests fail >#875805 python3-pandas: Please break circular dependency > >There's a few more minor patches on my laptop that I haven't attached >to a bug for pandas. > >* Updating standards version >* using debhelper 10 >* switching sphinx doc build to use python3 >* and deleting a few more build files in dh_clean target. > >I made larger changes to statsmodels, by using pybuild instead of the >previous multiple targets in debian/rules. > >All of those changes are currently on alioth in detrout-python3. > >When all these tests pass, shall I add myself to uploaders and release? >or does someone else want to review first? > >Diane -- Sent from a phone which beats iPhone.
Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
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&ver=0.19.2-5&arch=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
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
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?
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 i
Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
On Tue, 28 Mar 2017, Ole Streicher wrote: > Yaroslav Halchenko 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&ver=0.19.2-5&arch=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?
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 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!
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
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
On Fri, 20 Jan 2017, Ole Streicher wrote: > Yaroslav Halchenko 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
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
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
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
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: Sympy(+sagemath+nipy+~30 more) removal ahead
On Tue, 10 Jan 2017, Rebecca N. Palmer wrote:
> blockdiag - FTBFS (test mistakes annoying-but-harmless wand warning for an
> error) with patch
> ^
> |(some indirectly)
For me it FTBFS in a clean chroot with a gzillion of failed tests
-- all of those due to missing python{,3}-olefile in Build-Depends.
So is anyone up for preparing a quick NMU with Rebecca's patch and
olefile added, or I would do 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: About to upload another version of skimage
On January 7, 2017 6:02:15 AM EST, Ole Streicher wrote: >Hi all, > >Since https://bugs.debian.org/849196 is solved with numpy_1.2.0~rc2-1, >I >am going to upload another version of skimage with the tests >re-enabled. > >If there are doubts, please let me know. Otherwise, I would like to >have >a test-enabled version in Stretch. > >Cheers > >Ole +100 for reenabling tests -- Sent from a phone which beats iPhone.
Re: [Neurodebian-devel] Please consider moving common packages to Debian-Science
On Sat, 19 Nov 2016, Ole Streicher wrote: > 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. ok -- uploaded statsmodels 0.8.0~rc1+git59-gef47cd9-1 which finally builds fine at least on sid amd64 ;) woohoo! now the bottleneck is back to pandas, a slightly fresher version of which fixed some issues but introduced new ones leading to failed tests/builds on e.g. i386 https://buildd.debian.org/status/fetch.php?pkg=pandas&arch=i386&ver=0.19.1-1&stamp=1479504883 help would be appreciated. -- 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
On November 19, 2016 12:03:06 PM EST, Ole Streicher 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
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)
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: Neurodebian tasks (and Debian Science)
On Tue, 05 Apr 2016, Ole Streicher wrote: > Dear Yaroslav, and all, > I am currently looking on how we get the Debian Blends into the > installer for the next release. This is connected to Bug #758116 [1] > One of the points there is the inclusion of NeuroDebian, which does not > follow the usual Pure Blends scheme. Since you gave a "+100" in the bug, > I however suspect that there is some interest in having NeuroDebian > visible in the installer. Thank you for thinking about us! ;) Sorry for a long "quick" reply. still +100 although... I am wondering now how valuable would be to have those large meta-packages installed as part of debian installer -- in many (if not majority or all) of the cases any of those are valuable primarily as pointers to what packages they point to, so users could go and select particular packages (e.g. in aptitude) from those among Recommended and Suggested. Would any user ever want that particular selection of Recommended packages? may be, but I see that most often users would want a particular selection from those pointed by Suggests and Recommends. Are you aiming to provide that level of granularity within debian installer? if so -- that would be cool. But unlikely, at least at current stage I guess. Don't take it as discouragement, just merely as my expression of an opinion/concern. > Looking into your repository content [2], the "by field" selection is > quite close to a number of Debian Science tasks: > * Packages for Electrophysiology > --> science-electrophysiology > * Packages for Modeling of neural systems > --> science-neuroscience-modelling > * Packages for Neuroscience Datasets > --> science-neuroscience-datasets > * Packages for Psychophysics > --> science-psychophysics > Some Fields in neurodebian seem not to have 1:1 tasks in debian-science: > * Packages for Distributed Computing > --> science-distributedcomputing (your selection is a bit smaller?) > * Packages for Magnetic Reasonance Imaging > * Packages for Neuroscience Education > The debian-science task "science-neuroscience-congnitive" has no > corresponding "field" in neurodebian, but seems to belong there. Let me leave it for Michael Hanke to reply since he is the master guru beyond neurodebian web site "engine". > The Debian-Science blend is quite filled with tasks: there are currently > 47 tasks in it. Wouldn't it make sense to move out the specific tasks > (science-electrophysiology. science-neuroscience-modelling, > science-neuroscience-datasets, science-psychophysics, and > science-neuroscience-congnitive) into the "neurodebian" package (and > remove it from debian-science)? Do you consider neuroscience not a science? ;) Or is debian-science blend is solely to collect all other sciences which haven't found/established their own blends? and as soon as they do, new naming/packages arrive etc... moreover many of those are not neuro- specific, and some times even though used in neuro-, they might be used in other sciences (e.g. consider electrophysiology -- it is not just neuroelectrophysiology) that somewhat points to our "concern" with current approach on blends -- pretty much attempt to impose separate hierarchies wherever structure is more of a tag cloud (single software/task could be a part of multiple blends). That is why we somewhat tried to avoid creating our own neuro- blend and just contributed where we thought neuroscience related tasks/software was most appropriate -- to debian-science and/or -med. That is why at some point I came up with (now unused) http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/blends-inject to ease 'injection' of entries of task files for multiple blends. Sorry if it is all non-constructive and more of a whining ;) > We then would just need a metapackage that includes (recommends) all > neurodebian tasks that should be installed on a default NeuroDebian > blend. 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 HCP vs some other processing toolkit, or psychtoolbox vs psychopy vs visionegg vs ... -- or why to install all of them (unless they are like me ;) ) > A "neurodebian-tasks" package would be useful as well so that > people could use tasksel to install additonal NeuroDebian tasks (or to > remove them if not needed). I guess we could indeed establish a neurodebian-tasks package which could may be provide some pre-canned tasks and also one of which would include neurodebian package itself. But I don't think that those tasks would be the tasks as the blends composes them. I see pretty much tasks which would be nearly a single package tasks pointing to most common neuro- toolkits so a new user could immediately recognize familiar/necessary tools to be installed. That would IMHO be indeed practically useful. I do see thought some possible larger tasks, e.g. "Neuroimaging in Python", which would install a bit wider colle
Re: [Caffe] uploaded to mentors but NOT RFS
On Wed, 02 Sep 2015, lumin wrote: > Hi all, > (CC'ing people interested in package Caffe) > It takes so long time for Caffe to be packaged for Debian, > now the package is nearly prepared to be uploaded, and > there are still some small issues to be addressed. > http://anonscm.debian.org/cgit/debian-science/packages/caffe.git > My local build result (2 amd64 machines: chroot testing, and testing): > [debuild] [OK] > [d/rules:: custom-cpu] [OK] > [d/ruels:: custom-cuda] [OK] note that nvidia-cuda-toolkit is from non-free. And packages from main can't build-depend on non-free components :-/ It means that it might be necessary either to 1. move caffe into contrib (again, away from main :-( ) 2. or provide two source packages, of which main would build only CPU implementation while in non-free would build both/only GPU (depending how organized). Or is there a better solution which I am missing somehow? -- 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
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: [caffe] one step closer to the final caffe package
On Mon, 31 Aug 2015, lumin wrote: > Hi folks, > (CC'ing people who are interested in package "caffe") I would keep CClist a bit shorter (I am part of debian-science as well, so no need for explicit CC) > It is a good news that the package caffe in > anonscm/debian-science/caffe.git builds again. > Package caffe-cpu and package caffe-cuda shold be built properly on > amd64 and i386 hosts. great! > However it's not quite in a good shape, currently I'm looking > into these things: > * how to avoid FTBFS on ARCHs which are not amd64|i386, >because control :: build-deps contains CUDA (nvidia-cuda-toolkit) make them architecture specific gpu* packages should have "Architecture: amd64 i386" and nvidia-cuda-toolkit (in build-depends) should have "[amd64 i386]" > * letting custom target in d/rules work again > * adding a python-caffe-cpu, and a python-caffe-cuda pcakage. > * adding manpages for ELFs. > * is it ok to build-deps on nvidia-cuda-toolkit/experimental (6.5.14) >because cuda 6.0 in unstable is t old to work with gcc4.9 >or even gcc4.8 when building caffe-cuda. >(it is said that gcc-4.6 was removed recently from unstable ...) it is ok to depend but then you would need to upload to debian experimental as well atm. -- 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
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?
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?)
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?
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
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)
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)
>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/20140410133151.gm8...@onerussian.com
Re: Choosing "proper" Section field (Was: Bug#742639: ITP: python-expyriment -- Python liabrary for cognitive and neuroscientific experiments)
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)
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)
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)
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)
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)
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)
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 -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 Blend"s 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 (-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 > -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 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 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 it was rele
Re: Choosing "proper" Section field (Was: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments)
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#742573: ITP: seaborn -- Python statistical visualization library
On Wed, 26 Mar 2014, Andreas Tille wrote: > Hi Yaroslav, > On Wed, Mar 26, 2014 at 12:48:49PM -0400, Yaroslav Halchenko 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... > Please use the Debian Science Git at alioth (not only for this but for > all your packages that might concern Debian Science and are not in the > NeuroDebian Git at alioth). well -- about 99% (I can think of fail2ban which not... not sure otherwise) of our packages concern Debian Science one way or another... also many of them concern Debian Med... but yeah -- for this one I guess it would be good to place it under Debian science umbrella... will do > > 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. > Would you just add it to the apropriate tasks? sure -- added to viewing -- 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/20140327013806.gb28...@onerussian.com
Re: Bug#742573: ITP: seaborn -- Python statistical visualization library
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: Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments
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: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
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: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
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: RFS: VLFeat computer vision library
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: RFS: VLFeat computer vision library
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 :
> > 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 writes:
> >> > Hi Dima,
> >> > On Thu, Nov 07, 2013 at 11:10:54PM -0800, Dima Kogan wrote:
> >> >> > 2013/11/8 Dima Kogan :
> >> >> >> Hi all.
> >> >> >> I packaged VLFeat (http://vlfeat.org), and am looking for
> >> >> >> sponsorship.
> >> >> > Anton Gladky 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
> > pla
Re: RFS: nfft -- Library for computing Non-uniform Fast Fourier Transforms
Q: are planing to ship also some additional packages which would make use of NFFT library in the (near) future? On Tue, 08 Oct 2013, Ghislain Vaillant wrote: > Hello everyone, > Following the ITP filed here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725705 > I have uploaded a first package for the NFFT library. It is an extension > of the FFTW library for non-equispaced nodes, which is an essential > component of Magnetic Resonance Imaging reconstruction. I believe it > would be a great addition to the existing Debian science collection, > alongside FFTW. Is anybody interested in sponsoring it ? > The NFFT uses FFTW and follows a similar data structure and design. It > also uses autotools, which made the packaging not too tricky to start > with. Keep in mind this is my first package, so please be patient :-) > Here is the link to the RFS: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725772 > Cheers, > Ghislain -- 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/20131008180700.gv26...@onerussian.com
Re: hello from potential new maintainer
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
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
Re: debian/upstream::references:multiple_components
On Fri, 23 Aug 2013, Andreas Tille wrote: > Hi Yaroslav, > we do just have the key "Debian-Package" which for instance is used in > ncbi-tools6 source d/upstream file. IMHO this exactly addresses what > you want to address with "Files". And yes, it leaves the strict > "upstream" land ... but we somehow need this. > Did I missunderstood you? nope -- you just got a partial understanding of my concern ;-) Debian-Package is insufficient for what I am pursuing, since package might contain e.g. 1000 small .csv datasets for which I would have separate publication references. Making separate binary packages for each would not make sense. And I would still like to have ability to associate a particular group of files (e.g. /usr/share/data/collection1/author-*.csv) with a publication. -- 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/20130823051447.gr32...@onerussian.com
