On Tue, Oct 31, 2017 at 1:42 PM, Ghislain Vaillant <ghisvail@gmail.com> wrote:
On 31/10/17 16:11, Stephen Sinclair wrote:
On Tue, Oct 31, 2017 at 12:50 PM, Ghislain Vaillant <ghisvail@gmail.com>
wrote:
On 31/10/17 13:15, Stephen Sinclair wrote:
Hello,
On Mon, Oct 30, 2017 at 8:28 PM, Ghislain Vaillant <ghisvail@gmail.com>
wrote:
Would that time be better spent on the Tensorflow / Keras combo, which
is
arguably significantly more popular in research? I am afraid we are
already
spreading our packaging efforts thin on the machine learning ecosystem.
I am trying to learn a thing or two about packaging and hoping I can
add my weight to the team on this front. Despite years of Linux
*user* experience, I admit I've never really figured out the full
Debian packaging ecosystem, and I'd like to take this RFA opportunity
as well as my current work on a new package for the Siconos dynamical
systems simulation library to improve.
I am guessing this library is using Theano / Lasagne in the backend,
right?
It has a dependency on python3-theano, yes. I agree with your other
email that it might be wise to move towards integrating the tensorflow
backend. Has there been discussion on packaging Tensorflow? I don't
see it with apt-get search.
Last time I checked, TF was blocked by the packaging of the basel build
system (sigh).
I am not surprised! It was very painful to get it working locally for
me, at a previous time. I think I even may have given up and waited
for a new wheel release, I don't remember. These days I use Docker
images to run Tensorflow, it is just easier.
In the meantime I'll play with updating this keras package based on
the existing Theano package, to improve my knowledge. Hopefully this
will help me get started with some other packages I am interested in.
Keras is perhaps not the most suitable package to begin with packaging. You
might be willing to aim for something smaller first. Perhaps fixing an easy
packaging bug within the team would be a better start.
It *seems* to be a pretty normal Python package that shouldn't be too
hard, provided that Theano is stable. I have now been able to "adopt"
it locally, fix some issues, update to Keras 2.0.8, and test it
successfully in CPU mode on the MNIST MLP example without any issues.
The actual packaging isn't too hard, it is mainly everything "around"
packaging that I find confusing -- how to adopt, how to upload,
correct usage of alioth, etc. I will be careful. Now that I have
played around with this package I think I can do the ITA and see if I
get approval when I submit.
My understand of what I should do to adopt this package:
1. Change the bug from RFA to ITA
Yep, and set yourself as its owner (see documentation about the Debian BTS)
2. Update "Maintainer:" to my name (or should I change it to debian
science?)
Nope, leave it as Debian Science. You'll add yourself to the Uploaders field
instead.
Okay, it was in Daniel's name, so I'll change it to that. I will look
at other Debian Science packages for an example.
3. "Upload" this change to close the ITA bug. (This means using dput,
right?)
This means seeking for a sponsor in the team to do it for you at first.
4. Update the package to latest keras and fix policy issues -- lintian
currently for me does not identify any policy issues so I am not sure
what it is about. It does say that the Section: should change from
"science" to "python" due to the package name, I am not sure if this
should be ignored in the context of debian-science.
Lintian is correct. The python{,3}-keras binary packages should be Section:
python. The source package could be Section: science or python depending on
your view point. I'd probably put it in Section: python too.
Okay.
5. Update the new version. (Close a bug with this second upload? Not
sure.)
I realize that perhaps 3 and 5 here mean that I should actually submit
a form email to debian-science to have someone upload it for me.
Correct.
If there are problems with 4, then I must coordinate with
debian-science if e.g. theano is out of date or whatever. (Not saying
it is, just clarifying my understanding of what I would do in that
case..)
Indeed. I am the maintainer of src:libgpuarray and regularly coordinate with
Rebecca who handles src:theano and has been a pleasure to work with.
Okay excellent, we can coordinate through debian-science if necessary.
Also, I do not know where the current package sources are kept.
Currently I have used "gbp import-dsc" to create a git repository
locally, I could put this on alioth. It seems there is only one
changelog entry, so no history to recover.
Daniel should be able to answer that.
In this case the upstream is a git repository, it seems gbp support
either importing each release as a tarball, basing on the upstream git
as patches in the debian directory, or keeping the upstream in a
separate root in the same repository. I am not sure what is
preferable. Is there a recommended debian-science package I can look
at for an example of how to work with git/github upstreams?