Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Hi Lumin,
>debhelper will pick them up as python package dependencies:
> dh_python2 --requires=python/requirements.txt
ok
>I don't remember why I put python-skimage there but I remember
>that python-protobuf was put there as explicit remind for me,
>indicating that protobuf is the blocker of python3-caffe-*.
ok
>Python modules listed in requirements are not required at runtime,
>except for numpy and boost-python. I noticed that dh_python2
>complains about "unused python:Depends" but the resulting python
>package dependency is correct:
ok
>Why should runtime deps be added into build-dep, which are useless
>unless I provide python-caffe-* testsuite.
not sure then, it should be fine that way!
>Really ready?
>I looked into the packaging repo, both master and package-3.x branch
>and I see no python3-protobuf package listed there.
>
>http://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/control?h=master
>http://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/control?h=packaging-3.x
I mean: "protobuf code is declared to be python3 ready"
so I guess it is a matter of adding a package in control file, adding python3 in rules and some little overrides.
my request was: can you please share that trivial patch at least on the bug report?
maybe somebody will pick it up and NMU the package
>The caffe package was ever blocked by
>* the GCC-4 -> GCC-5 transition and dependency library ABI bump
>* CUDA 6.5 -> 7.0 bump
>* CUDA 7.0 -> 7.5 bump
>and now it is blocked by
>* python3-protobuf
>if python3 is really required.
no, this isn't a blocker, but keep in mind that our goal is stretch, and python2 code doesn't fit too much in it.
I guess in case the dependencies will become python3 ready, you will add a new python3-caffe-cpu package, right?
can two python packages be produced by caffe or just one at each time?
in the latter case you will need to drop python-caffe-cpu, add python3-caffe-cpu and breaks+replaces to ensure an
upgrade path from the python2 to the python3 version.
For sure if having the python3 dependencies in place is a matter of some days, we should consider that, but
no, this isn't a blocker right now.
(I'm more worried about the whole breakage that comes at gcc and cuda updates, will you be able to keep the package
"installable and buildable" in unstable at each transition?)
>It seems that skimage is not a blocker of Caffe.
it is, the package is not in testing, so I guess caffe won't be able to migrate.
Don't forget that the goal is Stretch, not unstable, so you need to fix/help in fixing the dependencies if you want
your package to be buildable/installable on Stretch too.
the maintainer already did some work there
https://github.com/scikit-image/scikit-image/issues/2091#issuecomment-220156849
so you think you can help him?
(I could, if you ask me)
Gianfranco
Reply to: