[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]



On Thu, 2016-05-19 at 06:32 +0000, Gianfranco Costamagna wrote:
> Hi Lumin,

> >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!

An update to this, according to
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
Even if I want to add some testsuite for python-caffe, I don't need
to add those runtime deps in control, I can add them in tests/control
instead, by adding "Depends" field that supprted by d/tests/control.

> >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

OpenCV 3.0 can yield python3-opencv package with just a small patch,
which is provided by a user in an opencv debian bug.
Protobuf might be similar.

> >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?

And I agree, on behalf of the release team I should make python3-*
packages in the initial upload. I decide to bump python from
2 to 3. python3-caffe can be built easily with packages outside
of Debian archive. One of the unapplied patches I removed
is for python3->python2 downgrade reversal.

opencv and protobuf is still on the way of 2 to 3, in Debian.

> can two python packages be produced by caffe or just one at each time?

One each time. Cmake requires a option PYTHON_VERSION=X where X can be
either "2" or "3".

> 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.

let's bump python version for this package.

> 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?)

CPU version is safe. and
no need to worry about GCC and CUDA, the source of trouble
is the compatibility between NVCC and GCC. 
That's exactly why I'm now a maintainer of CUDA ............
I helped the 6.5->7.0 and 7.0->7.5 bump of CUDA, and the NVCC
usability got into a better situation, where caffe-cuda
survived.

CUDA 8.0 is comming soon, if NVCC 8.x fails to work with GCC-6,
we just lock build-dep at GCC-5. Safe too.

Actually I guess CUDA 8.5 release date is prior to stretch freeze.

> >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.

Well one more bad news...

> 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)

I'm not familiar with that package, and I think if I'm going
to help caffe's recursive dependency package maintainers,
I intend to first have a look at opencv or protobuf.

Stretch freeze is Q1 2017, I'm afraid whether caffe can
be uploaded into stretch in time.

* python3-opencv upload
* python3-protobuf upload
* python3-skimage NON-DFSG bugs

> Gianfranco

Thank you.


Reply to: