Re: Keras (abstraction layer for Theano and TensorFlow) seeks for an adopter
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?
Steve
Reply to: