Re: pandas git Was: statsmodels: FTBFS: TypeError: 'float' object cannot be interpreted as an index
Hi Yaroslav, On Wed, Jan 04, 2017 at 09:37:34PM -0500, Yaroslav Halchenko wrote: > > I've also migrated pandas to Debian Science Git[1]. When trying to > > build I can not reproduce the actual error #845734 but the build fails > > with > > I did spend some time on pandas today and uploaded 0.19.2 ... since it > was easier for me to work in my previous git repo (with custom gbp.conf > and all the pre-cythonized files) and there were no actual fixes in team > version of the repo I just did that for now and pushed to old repo. Fair enough. To not keep an outdated repository around I removed the now outdated fork of the repository in Debian Science. > Hopefully this version will not trigger too many tripwires on other > architectures -- then we could "finalize" the migration and agree on > some aspects (e.g. keeping pre-cythonized files ;) ) I would strongly recommend to settle your repositories on git.debian.org in some team space that enables other contributors easy access. Kind regards Andreas. -- http://fam-tille.de
Re: Please categorise your packages for the Debian Science metapackages
Dear Andreas, All my packages should really go to astronomy. Two sets of packages I would hide in any case, the last one would need to fit in the right task in the astronomy blend. (python|python3|yorick)-pyorick hide yorick-mira should go to astronomy (python|python3|yorick)-svipc hide Kind regards, Thibaut. Le 04/01/2017 à 15:50, Andreas Tille a écrit : > Hi, > > as in every release cycle I'm trying to verify that every package > maintained in Debian Science team is properly categorised in our Blends > tasks. If a package is just a predependency for some other scientific > software I can add it to a blacklist of packages that should not show > up in the Debian Science metapackages explicitly. I have uploaded the > list of not yet categorised (not yet blacklisted) source packages to > >http://blends.debian.net/tmp/debian-science.txt > > The list also contains the latest uploader - so simply seek for your > name - everybody in CC is mentioned at least once in the list and should > definitely have a look. If other readers here feel competent to > classify a package for one or more (!) tasks in our task list > >https://blends.debian.org/science/tasks/ > > evary suggestion is welcome. > > To add a binary (!) package to a task you can simply > > debcheckout -u your_alioth_login debian-science > cd debian-science/tasks > > and edit the task in question. Members of the Debian Pure Blends team > as well as any DD (ACLs are set but I have heard this does not work > reliably) have commit permissions. I'm also fine if you debcheckout > anonymously and send me `git format-patch` formated changes or just > answer here to this mail. > > If you are not sure whether a package belongs to a task or not feel > free to discuss this here. > > Kind regards and thanks for your cooperation > > Andreas. >
Re: Please categorise your packages for the Debian Science metapackages: fenics/dolfin
Hi Andreas, there are a couple more fenics components in the mathematics-dev task: Python-dolfin (and dolfin-dev) python-ffc python-ufl I'm thinking it's redundant to list these separately under mathematics-dev if there's already an entry in the mathematics task. Likewise in your not-yet categorised list: dijitso python-dijitso is another of the FENiCs components that I think doesn't need to be listed separately. How is "blacklisting" done? Is it just a matter of removing the entries in the files in debian-science/tasks ? Drew On Thu, 2017-01-05 at 13:04 +0800, Drew Parsons wrote: > dolfin-bin and fenics are currently listed under the mathematics > task. > > In a sense python-dolfin is more appropriate for listing than dolfin- > bin. But dolfin-bin depends on it and also provides a couple of > small > utility programs. So I'm inclined to leave dolfin-bin as listed > > dolfin is the front-end of the FENiCS system, and I think the fenics > package is now deprecated. Johannes, did you intend to update the > fenics Debian metapackage, or should we remove it from the Debian > archive? We could handle it in the dolfin source package to save > maintenance efforts if you want to keep it. > > Whether we want the fenics package removed or not, I guess there's no > need to have the two entries in the task list for fenics/dolfin. Once > we're decided I can log in to the tasks server to make the edits to > keep one entry. > > Drew > > On Wed, 2017-01-04 at 15:50 +0100, Andreas Tille wrote: > > Hi, > > > > as in every release cycle I'm trying to verify that every package > > maintained in Debian Science team is properly categorised in our > > Blends > > tasks. If a package is just a predependency for some other > > scientific > > software I can add it to a blacklist of packages that should not > > show > > up in the Debian Science metapackages explicitly. I have uploaded > > the > > list of not yet categorised (not yet blacklisted) source packages > > to > > > > http://blends.debian.net/tmp/debian-science.txt > > > > The list also contains the latest uploader - so simply seek for > > your > > name - everybody in CC is mentioned at least once in the list and > > should > > definitely have a look. If other readers here feel competent to > > classify a package for one or more (!) tasks in our task list > > > > https://blends.debian.org/science/tasks/ > > > > evary suggestion is welcome. > > > > To add a binary (!) package to a task you can simply > > > > debcheckout -u your_alioth_login debian-science > > cd debian-science/tasks > > > > and edit the task in question. Members of the Debian Pure Blends > > team > > as well as any DD (ACLs are set but I have heard this does not work > > reliably) have commit permissions. I'm also fine if you > > debcheckout > > anonymously and send me `git format-patch` formated changes or just > > answer here to this mail. > > > > If you are not sure whether a package belongs to a task or not feel > > free to discuss this here. > > > > Kind regards and thanks for your cooperation > > > > Andreas. > > > >
Re: Please categorise your packages for the Debian Science metapackages: fenics/dolfin
dolfin-bin and fenics are currently listed under the mathematics task. In a sense python-dolfin is more appropriate for listing than dolfin- bin. But dolfin-bin depends on it and also provides a couple of small utility programs. So I'm inclined to leave dolfin-bin as listed dolfin is the front-end of the FENiCS system, and I think the fenics package is now deprecated. Johannes, did you intend to update the fenics Debian metapackage, or should we remove it from the Debian archive? We could handle it in the dolfin source package to save maintenance efforts if you want to keep it. Whether we want the fenics package removed or not, I guess there's no need to have the two entries in the task list for fenics/dolfin. Once we're decided I can log in to the tasks server to make the edits to keep one entry. Drew On Wed, 2017-01-04 at 15:50 +0100, Andreas Tille wrote: > Hi, > > as in every release cycle I'm trying to verify that every package > maintained in Debian Science team is properly categorised in our > Blends > tasks. If a package is just a predependency for some other > scientific > software I can add it to a blacklist of packages that should not show > up in the Debian Science metapackages explicitly. I have uploaded > the > list of not yet categorised (not yet blacklisted) source packages to > > http://blends.debian.net/tmp/debian-science.txt > > The list also contains the latest uploader - so simply seek for your > name - everybody in CC is mentioned at least once in the list and > should > definitely have a look. If other readers here feel competent to > classify a package for one or more (!) tasks in our task list > > https://blends.debian.org/science/tasks/ > > evary suggestion is welcome. > > To add a binary (!) package to a task you can simply > > debcheckout -u your_alioth_login debian-science > cd debian-science/tasks > > and edit the task in question. Members of the Debian Pure Blends > team > as well as any DD (ACLs are set but I have heard this does not work > reliably) have commit permissions. I'm also fine if you debcheckout > anonymously and send me `git format-patch` formated changes or just > answer here to this mail. > > If you are not sure whether a package belongs to a task or not feel > free to discuss this here. > > Kind regards and thanks for your cooperation > > Andreas. >
Re: Please categorise your packages for the Debian Science metapackages
(Dropping the CC list) Hi Andreas, I'm holding 6 uncategorized d-science packages. * caffe and caffe-contrib are categorized into machine-learning task. See the patch attached. * the remaining 4 packages are core components of the torch7 framework, and the torch7 metapackage (meta-torch-core-free) is still in experimental. Torch7 is also a machine-learning framework. lua-torch-cwrap lua-torch-dok lua-torch-paths lua-torch-sundown The 4 source packages should be hidden. Thanks. On Wed, 2017-01-04 at 15:50 +0100, Andreas Tille wrote: > I'm also fine if you debcheckout > anonymously and send me `git format-patch` formated changes or just > answer here to this mail. From e0811df11c582cd53eccea3feb02b50a8c0b6a9c Mon Sep 17 00:00:00 2001 From: Zhou Mo Date: Thu, 5 Jan 2017 02:39:44 + Subject: [PATCH] categorize caffe and caffe-contrib to machine-learning --- tasks/machine-learning | 8 1 file changed, 8 insertions(+) diff --git a/tasks/machine-learning b/tasks/machine-learning index c69534b..a27eecc 100644 --- a/tasks/machine-learning +++ b/tasks/machine-learning @@ -145,3 +145,11 @@ Suggests: ask Suggests: libdlib-dev Depends: r-cran-mlbench + +Depends: caffe-cpu | caffe-cuda +License: BSD-2-Clause +Homepage: http://caffe.berkeleyvision.org/ +Pkg-Description: Fast, open framework for Deep Learning + Caffe is a deep learning framework made with expression, speed, + and modularity in mind. It is developed by the Berkeley Vision + and Learning Center (BVLC) and community contributors. -- 2.11.0
Re: packaging Siconos
Hi, On Wed, Jan 04, 2017 at 04:07:42PM -0300, Stephen Sinclair wrote: > > Hmmm, I'd naively say please try later again. If this does not help > > you might need to contact alioth admins. > > Ok, I tried again and discovered it was automatically adding "-guest" > to my username. Now I managed to verify the account, which has the > word "-guest" appended, which is ok, I guess. This is the totally normal behaviour (and I guess also somewhere printed on the screen - but who is reading such stuff? ;-)) > > Not that I'm aware of. I only know that lapack is packaged. > > Ok so perhaps it would be a useful endeavour then. I'll look into > making a few packages with our dependencies. I do notice that we have > modified a few headers in those dependencies to make them include a > common BLAS header for example, but I suppose such changes will make > sense for Debian too. I'd recommend to use quilt patches to implement this. > > Hope this helps > > Indeed, thanks for the links! :-) Andreas. -- http://fam-tille.de
Re: packaging Siconos
Andreas, Thanks very much for your reply. On Wed, Jan 4, 2017 at 12:40 PM, Andreas Tille wrote: >> If so, I can report a problem registering an account, I have tried >> twice and both times after email verification I am greeted with this >> error message: >> >> "Exiting with error >> >> Could Not Get User" > > Hmmm, I'd naively say please try later again. If this does not help > you might need to contact alioth admins. Ok, I tried again and discovered it was automatically adding "-guest" to my username. Now I managed to verify the account, which has the word "-guest" appended, which is ok, I guess. > You might like to have a look at "Sponsering of Blends"[2]. I see, my first time encountering the Blends concept so I will read up. >> - public domain code from http://www.netlib.org, in particular >> "odepack"; is there any history of this code being packaged previously >> for Debian? I do not want to duplicate efforts, but would be willing >> to make packages for what we use. > > Not that I'm aware of. I only know that lapack is packaged. Ok so perhaps it would be a useful endeavour then. I'll look into making a few packages with our dependencies. I do notice that we have modified a few headers in those dependencies to make them include a common BLAS header for example, but I suppose such changes will make sense for Debian too. >> - numerics_bindings: this apparently has already been proposed for >> Debian in 2009 but was closed, perhaps out of lack of interest, would >> it be possible for it to be re-opened? https://bugs.debian.org/536270 > > Either reopen or create a new ITP. Both is fine. Ok, excellent, thank you. >> - two of our optional dependencies do have weird license situations: >> PATH has a strange license found at >> http://pages.cs.wisc.edu/%7Eferris/path/LICENSE and SOL/lumod seems to >> have no license at all: >> http://web.stanford.edu/group/SOL/software/lumod/ ; so the question >> is, should I remove these from our source release tarball using a >> patch? > > Since no license is per definition non-free you need to remove it in any > case. You might like to contact the authors of both projects to choose > a free license. I've done this with varying success in the Debian Med > team[3]. I think when writing to the authors a good start of your > e-mail would be: > >I'm writing you on behalf of the Debian Science team which is >a group of maintainers inside Debian with the objective to >package free software with relevance to scientific research for >official Debian. I will do so. >> 3) I would like to know what Debian Science thinks of the static >> linking or private library approach, vs. making dedicated packages for >> these collections of Fortran routines. > > To say it very shortly: Static libraries are sucking. Feel free > to ask for a longer explanation. No need, I understand. > Hope this helps Indeed, thanks for the links! regards, Steve
Re: Please categorise your packages for the Debian Science metapackages
Hi Andreas, Quoting Andreas Tille (2017-01-04 15:50:17) > as in every release cycle I'm trying to verify that every package > maintained in Debian Science team is properly categorised in our Blends > tasks. > I'm also fine if you debcheckout > anonymously and send me `git format-patch` formated changes or just > answer here to this mail. python-pynlpl and uctodata should go to 'linguistics' Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl http://proycon.anaproy.nl http://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Re: packaging Siconos
Hi Stephen, On Wed, Jan 04, 2017 at 11:10:34AM -0300, Stephen Sinclair wrote: > I am working on an open source (Apache2 license) numerical simulation > engine for non-smooth dynamical systems which is called Siconos: > > http://siconos.gforge.inria.fr > > Lately we have been motivated to package it for Debian Sid, and I > think the Debian Science team is the right place to propose this. Yes it is. Thanks for your intend to package Siconos for Debian. > I > have been working on the package itself, but now I would like to know > more about the process for contributing to Sid. I have several > questions before I make a Debian bug and propose the package for > sponsorship. > > First and foremost, our development is hosted on github, and I have > been working on a fork of our repository on a branch called > "debian/sid", following recommendations here: > https://wiki.debian.org/PackagingWithGit > > Currently the package code lives at: > https://github.com/siconos/siconos-deb/tree/debian/sid > > 1) Now, I am wondering if it is useful/required for me to move this > repository to Alioth? Yes, please do so since it has lots of advantages. One of these would be for instance that we could add Siconos to the task "Numerical computation" even before a final upload when residing only in Debian Science Git [1]. > If so, I can report a problem registering an account, I have tried > twice and both times after email verification I am greeted with this > error message: > > "Exiting with error > > Could Not Get User" Hmmm, I'd naively say please try later again. If this does not help you might need to contact alioth admins. > In any case, on to more questions: > > Siconos has several layers, each with their own shared library: one > wrapping "external" libraries such as numerical routines found on > various university websites, I'll come back to this; then there is a > "numerics" library which provides an interface to a series of > numerical solvers; on top of this there is the "kernel" which > provides a C++ framework for modeling non-smooth dynamical systems; > there are then some application-specific layers on top of these such > as "control" and "mechanics"; finally, there is a set of Python > modules wrapping all these libraries generated by SWIG. We also have > examples and documentation. > > To represent all of this I have divided the software into several .deb > packages, libsiconos-numerics, libsiconos-kernel, > libsiconos-mechanics, etc. as well as a Python package python-siconos > to install the SWIG bindings, and siconos-mechanics-tools to install > the 3D viewer we use for visualizing results in 3D contact mechanics, > as well as some tools for manipulating the files (in HDF5 format). I > have also made some metapackages e.g. libsiconos-all-dev and just > "siconos" that install everything needed for Siconos development, and > everything at all Siconos-related, respectively. Sounds very sensible. > I also made siconos-doc and siconos-examples, however to build > siconos-doc we need sphinxcontrib-bibtex which appears to be "in the > pipeline", so I will wait on that one. https://bugs.debian.org/800358 Not sure about this specific package but in several cases just waiting is not enough. Either there would be a chance to go without this package or helping with the package sounds more promising. > 2) I would like to know what Debian Science's take on this packaging > approach is, what should I do differently if anything? I would like > to prepare the package for sponsorship. You might like to have a look at "Sponsering of Blends"[2]. > The "libsiconos-externals.so" library is actually a collection of > "other" code that Siconos depends on but is not readily available > through apt-get. As such it doesn't really make sense to package it > as part of Siconos, so in my package I actually compile > libsiconos-externals.a as a static library and link it with > libsiconos-numerics (which is really the only part of Siconos that > uses it). For Debian, I think it would be more acceptable to package > these dependencies separately and make Siconos depend on them. I > would be willing to do this work. It is all code published under > permissive licenses, here is a list of them: Yes, please create separate packages. > - public domain code from http://www.netlib.org, in particular > "odepack"; is there any history of this code being packaged previously > for Debian? I do not want to duplicate efforts, but would be willing > to make packages for what we use. Not that I'm aware of. I only know that lapack is packaged. > - numerics_bindings: this apparently has already been proposed for > Debian in 2009 but was closed, perhaps out of lack of interest, would > it be possible for it to be re-opened? https://bugs.debian.org/536270 Either reopen or create a new ITP. Both is fine. > - two of our optional dependencies do have weird license situations: > PATH has a strange license fo
packaging Siconos
Dear Debian Science team, I am working on an open source (Apache2 license) numerical simulation engine for non-smooth dynamical systems which is called Siconos: http://siconos.gforge.inria.fr Lately we have been motivated to package it for Debian Sid, and I think the Debian Science team is the right place to propose this. I have been working on the package itself, but now I would like to know more about the process for contributing to Sid. I have several questions before I make a Debian bug and propose the package for sponsorship. First and foremost, our development is hosted on github, and I have been working on a fork of our repository on a branch called "debian/sid", following recommendations here: https://wiki.debian.org/PackagingWithGit Currently the package code lives at: https://github.com/siconos/siconos-deb/tree/debian/sid 1) Now, I am wondering if it is useful/required for me to move this repository to Alioth? If so, I can report a problem registering an account, I have tried twice and both times after email verification I am greeted with this error message: "Exiting with error Could Not Get User" In any case, on to more questions: Siconos has several layers, each with their own shared library: one wrapping "external" libraries such as numerical routines found on various university websites, I'll come back to this; then there is a "numerics" library which provides an interface to a series of numerical solvers; on top of this there is the "kernel" which provides a C++ framework for modeling non-smooth dynamical systems; there are then some application-specific layers on top of these such as "control" and "mechanics"; finally, there is a set of Python modules wrapping all these libraries generated by SWIG. We also have examples and documentation. To represent all of this I have divided the software into several .deb packages, libsiconos-numerics, libsiconos-kernel, libsiconos-mechanics, etc. as well as a Python package python-siconos to install the SWIG bindings, and siconos-mechanics-tools to install the 3D viewer we use for visualizing results in 3D contact mechanics, as well as some tools for manipulating the files (in HDF5 format). I have also made some metapackages e.g. libsiconos-all-dev and just "siconos" that install everything needed for Siconos development, and everything at all Siconos-related, respectively. I also made siconos-doc and siconos-examples, however to build siconos-doc we need sphinxcontrib-bibtex which appears to be "in the pipeline", so I will wait on that one. https://bugs.debian.org/800358 2) I would like to know what Debian Science's take on this packaging approach is, what should I do differently if anything? I would like to prepare the package for sponsorship. The "libsiconos-externals.so" library is actually a collection of "other" code that Siconos depends on but is not readily available through apt-get. As such it doesn't really make sense to package it as part of Siconos, so in my package I actually compile libsiconos-externals.a as a static library and link it with libsiconos-numerics (which is really the only part of Siconos that uses it). For Debian, I think it would be more acceptable to package these dependencies separately and make Siconos depend on them. I would be willing to do this work. It is all code published under permissive licenses, here is a list of them: - public domain code from http://www.netlib.org, in particular "odepack"; is there any history of this code being packaged previously for Debian? I do not want to duplicate efforts, but would be willing to make packages for what we use. - numerics_bindings: this apparently has already been proposed for Debian in 2009 but was closed, perhaps out of lack of interest, would it be possible for it to be re-opened? https://bugs.debian.org/536270 - two of our optional dependencies do have weird license situations: PATH has a strange license found at http://pages.cs.wisc.edu/%7Eferris/path/LICENSE and SOL/lumod seems to have no license at all: http://web.stanford.edu/group/SOL/software/lumod/ ; so the question is, should I remove these from our source release tarball using a patch? I will perhaps approach the authors ask about their license. - Some Fortran routines from Ernst Hairer here: http://www.unige.ch/%7Ehairer/software.html These explicitly have a permissive license http://www.unige.ch/~hairer/prog/licence.txt, so I would be willing to make a package for them. Of course it's *easier* to just statically link all of these directly into our package, or include them as a private shared library. So, 3) I would like to know what Debian Science thinks of the static linking or private library approach, vs. making dedicated packages for these collections of Fortran routines. (Many of them could be useful for other numerical simulation software, e.g. Evan Drumwright appears to have packaged odepack for use with his Moby software http://www-robotics.usc.edu/%7Edrumwr
