Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #735730 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-01 13:50 +0200
    Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Ghislain Vaillant <ghisvail@gmail.com> - 2016-05-02 15:20 +0200
      Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Gianfranco Costamagna <costamagnagianfranco@yahoo.it> - 2016-05-02 15:30 +0200
      Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-03 04:20 +0200
        Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Ghislain Vaillant <ghisvail@gmail.com> - 2016-05-03 09:40 +0200
          Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Gianfranco Costamagna <locutusofborg@debian.org> - 2016-05-03 10:10 +0200
            Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-07 03:40 +0200
              Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Ghislain Vaillant <ghisvail@gmail.com> - 2016-05-07 11:10 +0200
                Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-12 11:30 +0200
                  Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Gianfranco Costamagna <locutusofborg@debian.org> - 2016-05-16 17:00 +0200
                    Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Ghislain Vaillant <ghisvail@gmail.com> - 2016-05-17 16:00 +0200
                      Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-17 16:50 +0200
                        Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Ghislain Vaillant <ghisvail@gmail.com> - 2016-05-17 18:00 +0200
                          Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-18 14:50 +0200
                            Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] James Clarke <jrtc27@jrtc27.com> - 2016-05-18 15:20 +0200
                              Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] James Clarke <jrtc27@jrtc27.com> - 2016-05-18 15:30 +0200
                                Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-18 16:20 +0200
                                  Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Gianfranco Costamagna <locutusofborg@debian.org> - 2016-05-18 23:20 +0200
                                    Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-19 07:30 +0200
                                      Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Gianfranco Costamagna <costamagnagianfranco@yahoo.it> - 2016-05-19 08:40 +0200
                                        Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-19 12:10 +0200
                                    Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-19 08:00 +0200
                            Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] Jakub Wilk <jwilk@debian.org> - 2016-05-18 16:20 +0200
                          Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-18 15:10 +0200
      Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP] lumin <cdluminate@gmail.com> - 2016-05-03 07:10 +0200

Page 1 of 2  [1] 2  Next page →

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

[Multipart message — attachments visible in raw view] — view raw

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: aron@debian.org, debian@danielstender.com, debian@onerussian.com, debian-devel@lists.debian.org, debian-science@lists.debian.org

Dear mentors,

  I am looking for a sponsor for my package "caffe"

 * Package name    : caffe
   Version         : 1.0.0~rc3-1
   Upstream Author : Berkeley Vision and Learning Center
 * URL             : caffe.berkeleyvision.org
 * License         : BSD-2-Clause
   Section         : science

  It builds those binary packages:

 caffe-cpu  - Fast, open framework for Deep Learning (CPU_ONLY)
 caffe-cuda - Fast, open framework for Deep Learning (CUDA)
 libcaffe-cpu-dev - development files for Caffe (CPU_ONLY)
 libcaffe-cpu1 - library of Caffe, a deep learning framework (CPU_ONLY)
 libcaffe-cuda-dev - development files for Caffe (CUDA)
 libcaffe-cuda1 - library of Caffe, a deep leanring framework (CUDA)
 python-caffe-cpu - Python2 interface of Caffe (CPU_ONLY)
 python-caffe-cuda - Python2 interface of Caffe (CUDA)

  To access further information about this package, please visit the following URL:

  https://mentors.debian.net/package/caffe

  Alternatively, one can download the package with dget using this command:

    dget -x https://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_1.0.0~rc3-1.dsc

  Debomatic-amd64 build log can be obtained at

  http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3-1/buildlog
  Note, the source uploaded to debomatic-amd64 is different to the one
  at mentors -- the time stamp in d/changelog differs, the only difference.

  Changes since the last upload:

caffe (1.0.0~rc3-1) experimental; urgency=low

  * Initial release. (Closes: #788539)
  * Fix spelling error in src/caffe/layers/memory_data_layer.cpp.

Thanks :-)

[toc] | [next] | [standalone]

#735928

On 01/05/16 12:44, lumin wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: aron@debian.org, debian@danielstender.com, debian@onerussian.com, debian-devel@lists.debian.org, debian-science@lists.debian.org
>
> Dear mentors,
>
>    I am looking for a sponsor for my package "caffe"
>
>   * Package name    : caffe
>     Version         : 1.0.0~rc3-1
>     Upstream Author : Berkeley Vision and Learning Center
>   * URL             : caffe.berkeleyvision.org
>   * License         : BSD-2-Clause
>     Section         : science
>
>    It builds those binary packages:
>
>   caffe-cpu  - Fast, open framework for Deep Learning (CPU_ONLY)
>   caffe-cuda - Fast, open framework for Deep Learning (CUDA)
>   libcaffe-cpu-dev - development files for Caffe (CPU_ONLY)
>   libcaffe-cpu1 - library of Caffe, a deep learning framework (CPU_ONLY)
>   libcaffe-cuda-dev - development files for Caffe (CUDA)
>   libcaffe-cuda1 - library of Caffe, a deep leanring framework (CUDA)
>   python-caffe-cpu - Python2 interface of Caffe (CPU_ONLY)
>   python-caffe-cuda - Python2 interface of Caffe (CUDA)
>
>    To access further information about this package, please visit the following URL:
>
>    https://mentors.debian.net/package/caffe
>
>    Alternatively, one can download the package with dget using this command:
>
>      dget -x https://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_1.0.0~rc3-1.dsc
>
>    Debomatic-amd64 build log can be obtained at
>
>    http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3-1/buildlog
>    Note, the source uploaded to debomatic-amd64 is different to the one
>    at mentors -- the time stamp in d/changelog differs, the only difference.
>
>    Changes since the last upload:
>
> caffe (1.0.0~rc3-1) experimental; urgency=low
>
>    * Initial release. (Closes: #788539)
>    * Fix spelling error in src/caffe/layers/memory_data_layer.cpp.
>
> Thanks :-)
>

A few remarks:

- d/changelog: should only contain the entry closing the initial release
bug.

- d/control: Build-Depends on libboost-all-dev. Do you really need to
pull the complete Boost stack for the build? Quick look I have had:

"find_package(Boost 1.46 REQUIRED COMPONENTS system thread filesystem)"

So you should only require libboost-{filesystem,system,thread}-dev.

- d/control: Build-Depends on nvidia-cuda-toolkit which automatically
pulls nvidia-cuda-dev, so no need to specify nvidia-cuda-dev.

- d/*.install.in: no multi-arch install paths? why?

- d/libcaffe-dev.install.in: what is the purpose of the additional
libproto.a binary?

- d/rules + d/*.in: IMO, sounds like a very convoluted way of running 2
separate builds (one for CPU one for CUDA) and moving the files in the
right places. Another possibility could have been to have caffe-cpu and
caffe-cuda as separate source packages, one in main and one in contrib.
For each of them, the packaging would have been much more simple to
maintain I suppose.

- lintian (from d-o-m):

I: caffe source: quilt-patch-missing-description fix-spelling-error

Might want to fix this if not done already. Also please mention whether
the patch has been forwarded upstream.

I: libcaffe-cpu-dev: unstripped-static-library 
usr/lib/caffe/libproto.a(caffe.pb.cc.o)

Again not sure what this libproto.a is doing here.

I: libcaffe-cpu1: hardening-no-fortify-functions 
usr/lib/libcaffe.so.1.0.0-rc3

Are you using hardening in d/rules? If so, then the injected flags
might be shadowed by the build system. Consider fixing this.

Good luck,
Ghis

[toc] | [prev] | [next] | [standalone]

#735930

control: owner -1 !
control: tags -1 moreinfo

Hi Ghislain, thanks for the good review!

I remember I looked at this package a while ago, so, if you (lumin) can fix what Ghislain
pointed out, I'll be happy to do a new reivew and hopefully sponsor :)

cheers,

G.




Il Lunedì 2 Maggio 2016 15:13, Ghislain Vaillant <ghisvail@gmail.com> ha scritto:
On 01/05/16 12:44, lumin wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: aron@debian.org, debian@danielstender.com, debian@onerussian.com, debian-devel@lists.debian.org, debian-science@lists.debian.org
>
> Dear mentors,
>
>    I am looking for a sponsor for my package "caffe"
>
>   * Package name    : caffe
>     Version         : 1.0.0~rc3-1
>     Upstream Author : Berkeley Vision and Learning Center
>   * URL             : caffe.berkeleyvision.org
>   * License         : BSD-2-Clause
>     Section         : science
>
>    It builds those binary packages:
>
>   caffe-cpu  - Fast, open framework for Deep Learning (CPU_ONLY)
>   caffe-cuda - Fast, open framework for Deep Learning (CUDA)
>   libcaffe-cpu-dev - development files for Caffe (CPU_ONLY)
>   libcaffe-cpu1 - library of Caffe, a deep learning framework (CPU_ONLY)
>   libcaffe-cuda-dev - development files for Caffe (CUDA)
>   libcaffe-cuda1 - library of Caffe, a deep leanring framework (CUDA)
>   python-caffe-cpu - Python2 interface of Caffe (CPU_ONLY)
>   python-caffe-cuda - Python2 interface of Caffe (CUDA)
>
>    To access further information about this package, please visit the following URL:
>
>    https://mentors.debian.net/package/caffe
>
>    Alternatively, one can download the package with dget using this command:
>
>      dget -x https://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_1.0.0~rc3-1.dsc
>
>    Debomatic-amd64 build log can be obtained at
>
>    http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3-1/buildlog
>    Note, the source uploaded to debomatic-amd64 is different to the one
>    at mentors -- the time stamp in d/changelog differs, the only difference.
>
>    Changes since the last upload:
>
> caffe (1.0.0~rc3-1) experimental; urgency=low
>
>    * Initial release. (Closes: #788539)
>    * Fix spelling error in src/caffe/layers/memory_data_layer.cpp.
>
> Thanks :-)
>

A few remarks:

- d/changelog: should only contain the entry closing the initial release

bug.

- d/control: Build-Depends on libboost-all-dev. Do you really need to
pull the complete Boost stack for the build? Quick look I have had:

"find_package(Boost 1.46 REQUIRED COMPONENTS system thread filesystem)"

So you should only require libboost-{filesystem,system,thread}-dev.

- d/control: Build-Depends on nvidia-cuda-toolkit which automatically
pulls nvidia-cuda-dev, so no need to specify nvidia-cuda-dev.

- d/*.install.in: no multi-arch install paths? why?

- d/libcaffe-dev.install.in: what is the purpose of the additional
libproto.a binary?

- d/rules + d/*.in: IMO, sounds like a very convoluted way of running 2
separate builds (one for CPU one for CUDA) and moving the files in the
right places. Another possibility could have been to have caffe-cpu and
caffe-cuda as separate source packages, one in main and one in contrib.
For each of them, the packaging would have been much more simple to
maintain I suppose.

- lintian (from d-o-m):

I: caffe source: quilt-patch-missing-description fix-spelling-error

Might want to fix this if not done already. Also please mention whether
the patch has been forwarded upstream.

I: libcaffe-cpu-dev: unstripped-static-library 
usr/lib/caffe/libproto.a(caffe.pb.cc.o)

Again not sure what this libproto.a is doing here.

I: libcaffe-cpu1: hardening-no-fortify-functions 
usr/lib/libcaffe.so.1.0.0-rc3

Are you using hardening in d/rules? If so, then the injected flags
might be shadowed by the build system. Consider fixing this.

Good luck,
Ghis

[toc] | [prev] | [next] | [standalone]

#736076

Hi mentors,

I've fixed the issues you pointed out. New packages
are rebuilt locally, and uploaded to mentors.
https://mentors.debian.net/package/caffe

Debomatic-amd64 is still building this updated package:
http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3-1/buildlog

Following is my comments to the remarks

On Mon, 2016-05-02 at 14:13 +0100, Ghislain Vaillant wrote:
> - d/changelog: should only contain the entry closing the initial release
> bug.

Removed the line not necessary.

> - d/control: Build-Depends on libboost-all-dev. Do you really need to
> pull the complete Boost stack for the build? Quick look I have had:
> 
> "find_package(Boost 1.46 REQUIRED COMPONENTS system thread filesystem)"
> 
> So you should only require libboost-{filesystem,system,thread}-dev.

Depends on libboost-{filesystem,system,thread,python}-dev, instead
of libboost-all-dev.

> - d/control: Build-Depends on nvidia-cuda-toolkit which automatically
> pulls nvidia-cuda-dev, so no need to specify nvidia-cuda-dev.

Removed nvidia-cuda-dev as build-deps.

> - d/*.install.in: no multi-arch install paths? why?

I have no plan to make multiarch support for this package,
because that makes no sense. In production environment
Caffe is a computational intensive and memory-consuming
application, and I believe no user will need multi-arch
support for this package.

Made no change related to multi-arch.

> - d/libcaffe-dev.install.in: what is the purpose of the additional
> libproto.a binary?

There is a protobuf definition file under Caffe's source,
  src/caffe/proto/caffe.proto
which is a very essential file as it defined
caffe's "protocol". And libproto.a is the compiled
binary version of that protocol.

Besides, the Official "install" target installs
that static lib, so it is recommended by upstream
to have such a lib. Hence it goes into the -dev packages.

> - d/rules + d/*.in: IMO, sounds like a very convoluted way of running 2
> separate builds (one for CPU one for CUDA) and moving the files in the
> right places. Another possibility could have been to have caffe-cpu and
> caffe-cuda as separate source packages, one in main and one in contrib.
> For each of them, the packaging would have been much more simple to
> maintain I suppose.

I've ever considered split them up into 2 source packages,
but building 2 set of binary from 1 source is my initial intent.
I may split them in the future.

> - lintian (from d-o-m):
> 
> I: caffe source: quilt-patch-missing-description fix-spelling-error
> 
> Might want to fix this if not done already. Also please mention whether
> the patch has been forwarded upstream.

Added header to this patch. 

> I: libcaffe-cpu-dev: unstripped-static-library 
> usr/lib/caffe/libproto.a(caffe.pb.cc.o)
> 
> Again not sure what this libproto.a is doing here.

As explained above, this file may be not useless.

> I: libcaffe-cpu1: hardening-no-fortify-functions 
> usr/lib/libcaffe.so.1.0.0-rc3
> 
> Are you using hardening in d/rules? If so, then the injected flags
> might be shadowed by the build system. Consider fixing this.

I've tried to inject these flags according to wiki:Hardening
```
# Hardening Caffe according to https://wiki.debian.org/Hardening
DPKG_EXPORT_BUILDFLAGS=1
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
include /usr/share/dpkg/buildflags.mk
CFLAGS+=$(CPPFLAGS)
CXXFLAGS+=$(CPPFLAGS)
```

But hardening-fortify-source-function is still unfixed.
```
$ hardening-check /usr/bin/caffe
/usr/bin/caffe:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes
```

I have no idea about it...

Thank you for reviewing!

> Good luck,
> Ghis

[toc] | [prev] | [next] | [standalone]

#736108

On 03/05/16 03:08, lumin wrote:
>> - d/*.install.in: no multi-arch install paths? why?
>
> I have no plan to make multiarch support for this package,
> because that makes no sense. In production environment
> Caffe is a computational intensive and memory-consuming
> application, and I believe no user will need multi-arch
> support for this package.
>
> Made no change related to multi-arch.

What about cross-building?

>> - d/libcaffe-dev.install.in: what is the purpose of the additional
>> libproto.a binary?
>
> There is a protobuf definition file under Caffe's source,
>    src/caffe/proto/caffe.proto
> which is a very essential file as it defined
> caffe's "protocol". And libproto.a is the compiled
> binary version of that protocol.
>
> Besides, the Official "install" target installs
> that static lib, so it is recommended by upstream
> to have such a lib. Hence it goes into the -dev packages.

What upstream does is not always aligned with what Debian recommends
though. I was just wondering how the caffe and proto binaries were
related. Plus, it makes lintian ouput comments about unstripped static
libs.

>> - d/rules + d/*.in: IMO, sounds like a very convoluted way of running 2
>> separate builds (one for CPU one for CUDA) and moving the files in the
>> right places. Another possibility could have been to have caffe-cpu and
>> caffe-cuda as separate source packages, one in main and one in contrib.
>> For each of them, the packaging would have been much more simple to
>> maintain I suppose.
>
> I've ever considered split them up into 2 source packages,
> but building 2 set of binary from 1 source is my initial intent.
> I may split them in the future.

Here is why I would consider splitting them **now**. A significant 
portion of your d/rules consist in detecting whether CUDA is available
and optionally enable compilation of the CUDA version. This could be
avoided by having a caffe or caffe-cpu source package, which potentially
builds on all arch, and a caffe-cuda source package with the CUDA 
Build-Depends, for which you would not need to manually specify the target
architectures.

Benefits from this include:
1) The caffe[-cpu] source package and related binaries can live in main,
instead of contrib at the moment.
2) The caffe-cuda source package does not need the manual architecture
restriction stuff.
3) Last but not least, the resulting source packages become much
simpler to maintain in the long term, which is good from a
**team-maintenance perspective**.

As an FYI, the version of CUDA you are asking is available for ppc64el
and no longer for i386. With your solution, you (now) have to modify
this manually in d/{control,rules}. With separate source packages, you 
would not have to.

> I've tried to inject these flags according to wiki:Hardening
> ```
> # Hardening Caffe according to https://wiki.debian.org/Hardening
> DPKG_EXPORT_BUILDFLAGS=1
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
> export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
> include /usr/share/dpkg/buildflags.mk
> CFLAGS+=$(CPPFLAGS)
> CXXFLAGS+=$(CPPFLAGS)
> ```

You should only require
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_CPPFLAGS_MAINT_APPEND = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

I have added DEB_CPPFLAGS_MAINT_APPEND, since CMake does not always
automatically transfer the CFLAGS to CPPFLAGS. Unless, the caffe
build system is set-up for doing so.

> But hardening-fortify-source-function is still unfixed.
> ```
> $ hardening-check /usr/bin/caffe
> /usr/bin/caffe:
>   Position Independent Executable: yes
>   Stack protected: yes
>   Fortify Source functions: no, only unprotected functions found!
>   Read-only relocations: yes
>   Immediate binding: yes
> ```
>
> I have no idea about it...

You would have to look for override lines of the form:

set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)

An upstream classic unfortunately.

Ghis

[toc] | [prev] | [next] | [standalone]

#736112

Hi,

>set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)
>
>An upstream classic unfortunately.


as upstream I did this once, and the side effect was something weird.

when you run multiple times cmake .. the cflags gets appended multiple times, so you might
end up in a really weird CMakeCache.txt and with really long build lines.

I'm not sure which way is the best one, but cmake should provide something different from CFLAGS.

e.g.
CMAKE_C_FLAGS
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS

and so on.
that way they will be appended to current CFLAGS without having to override them manually.

(thanks again for your nice reviews!)

g.

[toc] | [prev] | [next] | [standalone]

#736954

Hi,

I've split the caffe-cpu package and the caffe-cuda package,
and I'd like to first handle the cpu version, leaving the CUDA
version pending at debian/science/caffe-contrib.
The updated cpu version has been uploaded to mentors:

https://mentors.debian.net/package/caffe

This update involves fix on multiarch, removal of caffe-cuda,
and removal of libproto.a .

However I found that hardening-no-fortify-functions is still
unsolved, and the upstream CMakeFiles.txt seems not to be
the trouble maker, as it contains this line
```
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -Wall")
```
and I really see the -D_FORTIFY_SOURCE=2 option added in the
verbose gcc command line.

On Tue, 2016-05-03 at 08:03 +0000, Gianfranco Costamagna wrote:
> Hi,
> 
> >set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)
> >
> >An upstream classic unfortunately.
> 
> 
> as upstream I did this once, and the side effect was something weird.
> 
> when you run multiple times cmake .. the cflags gets appended multiple times, so you might
> end up in a really weird CMakeCache.txt and with really long build lines.
> 
> I'm not sure which way is the best one, but cmake should provide something different from CFLAGS.
> 
> e.g.
> CMAKE_C_FLAGS
> CMAKE_C_FLAGS_RELEASE
> CMAKE_C_FLAGS_DEBUG
> CMAKE_EXE_LINKER_FLAGS
> CMAKE_MODULE_LINKER_FLAGS
> 
> and so on.
> that way they will be appended to current CFLAGS without having to override them manually.
> 
> (thanks again for your nice reviews!)
> 
> g.

[toc] | [prev] | [next] | [standalone]

#736984

On 07/05/16 02:35, lumin wrote:
> Hi,
>
> I've split the caffe-cpu package and the caffe-cuda package,
> and I'd like to first handle the cpu version, leaving the CUDA
> version pending at debian/science/caffe-contrib.
> The updated cpu version has been uploaded to mentors:
>
> https://mentors.debian.net/package/caffe
>
> This update involves fix on multiarch, removal of caffe-cuda,
> and removal of libproto.a .
>
> However I found that hardening-no-fortify-functions is still
> unsolved, and the upstream CMakeFiles.txt seems not to be
> the trouble maker, as it contains this line
> ```
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -Wall")
> ```
> and I really see the -D_FORTIFY_SOURCE=2 option added in the
> verbose gcc command line.
>
> On Tue, 2016-05-03 at 08:03 +0000, Gianfranco Costamagna wrote:
>> Hi,
>>
>>> set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)
>>>
>>> An upstream classic unfortunately.
>>
>>
>> as upstream I did this once, and the side effect was something weird.
>>
>> when you run multiple times cmake .. the cflags gets appended multiple times, so you might
>> end up in a really weird CMakeCache.txt and with really long build lines.
>>
>> I'm not sure which way is the best one, but cmake should provide something different from CFLAGS.
>>
>> e.g.
>> CMAKE_C_FLAGS
>> CMAKE_C_FLAGS_RELEASE
>> CMAKE_C_FLAGS_DEBUG
>> CMAKE_EXE_LINKER_FLAGS
>> CMAKE_MODULE_LINKER_FLAGS
>>
>> and so on.
>> that way they will be appended to current CFLAGS without having to override them manually.
>>
>> (thanks again for your nice reviews!)
>>
>> g.

s/DEB_CPPFLAGS_MAINT_APPEND/DEB_CXXFLAGS_MAINT_APPEND in your d/rules.

Ghis

[toc] | [prev] | [next] | [standalone]

#738111

On Sat, 2016-05-07 at 10:05 +0100, Ghislain Vaillant wrote:
> 
> s/DEB_CPPFLAGS_MAINT_APPEND/DEB_CXXFLAGS_MAINT_APPEND in your d/rules.
> 

Done. Updated package has been uploaded to mentors:
https://mentors.debian.net/package/caffe

[toc] | [prev] | [next] | [standalone]

#739037

Hi Lumin


>Done. Updated package has been uploaded to mentors:
>https://mentors.debian.net/package/caffe
1) did you try to enable the Debug build too?
without CMAKE_BUILD_TYPE=RelWithDebInfo you won't be able to get automatic debug packages I think


2) why the python3 support is disabled? note: this will require a trip in new queue, so if possible
I would prefer a python3-only build



3) all the "debian/tmp" strings in install files should/can be removed I guess

(I didn't review all the packaging, just something that might/should be fixed.

I'll wait for Ghislain to finish his review ;)

G.

[toc] | [prev] | [next] | [standalone]

#739293

Dear all,

On 16/05/16 15:50, Gianfranco Costamagna wrote:
> Hi Lumin
>
>
>> Done. Updated package has been uploaded to mentors:
>> https://mentors.debian.net/package/caffe
> 1) did you try to enable the Debug build too?
> without CMAKE_BUILD_TYPE=RelWithDebInfo you won't be able to get automatic debug packages I think

I don't think it is true (anymore?), since Debian injects its own "None"
build configuration + DEB_*_MAINT_FLAGS.

> 2) why the python3 support is disabled? note: this will require a trip in new queue, so if possible
> I would prefer a python3-only build

Same here. Since the build system leaves you the choice, please consider
packaging the Python 3 version. Python 2 has an expiration date anyway.

> 3) all the "debian/tmp" strings in install files should/can be removed I guess

Indeed, they should probably be removed.

> (I didn't review all the packaging, just something that might/should be fixed.
>
> I'll wait for Ghislain to finish his review ;)

* I am really not a fan of the templated configuration of the dh_install
files. Worst case, do it programmatically in d/rules rather than
declaratively with templates + a call to yet another custom script.
AFAIC, this creates a lot of overhead for no obvious benefits from a
team-maintenance point-of-view.

* Thinking long-term solution, one should just bite the bullet and make 
the build system multi-arch aware. It's just one module in CMake
(GnuInstallDirs) and substituting hardcoded DESTINATION paths with the
appropriate CMake variables. I am sure upstream would accept such patch,
and all distributions could benefit from it. I have done it multiple
times and never encountered resistance upstream. Plus the significant 
simplification of the debian files...

* On a different note, caffe seems to support building the documentation
from source with doxygen. Please consider packaging it in a separate
binary package (caffe-doc). The content of examples/* and models/*
might also fit in this -doc package.

* You should consider adding a packaging testsuite. You could start with
a script running part or all the examples shipped in the -doc package,
which would verify that the packaged software run as intended.

* You should consider adding some upstream metadata as described in [1].
I am sure the Caffe guys would appreciate that we appropriately forward
the citation information displayed on their README.

* What is the purpose of keeping unapplied patches in d/patches?

* Missing uversionmangling in d/watch for appropriate tracking of
release candidate releases.

* Consider using libblas-dev | libblas.so as Build-Depends instead of
libopenblas-dev. Not everyone is using openblas as its prefered blas
implementation and upstream does not force to use this specific vendor
(do they?), so no reason to force it here either.

* For the future, seems like additional caffe-tools and octave-caffe
binary packages could be created from the content generated by the
matlab/ and tools/ leaves of the source tree. I guess that's what is
acknowledged in debian/TODO.

[1] https://wiki.debian.org/UpstreamMetadata

Ghis

[toc] | [prev] | [next] | [standalone]

#739307

Thank you for this careful and thorough review!

On Tue, 2016-05-17 at 14:50 +0100, Ghislain Vaillant wrote:
> Dear all,
> 
> On 16/05/16 15:50, Gianfranco Costamagna wrote:
> > Hi Lumin
> >
> >
> >> Done. Updated package has been uploaded to mentors:
> >> https://mentors.debian.net/package/caffe
> > 1) did you try to enable the Debug build too?
> > without CMAKE_BUILD_TYPE=RelWithDebInfo you won't be able to get automatic debug packages I think
> 
> I don't think it is true (anymore?), since Debian injects its own "None"
> build configuration + DEB_*_MAINT_FLAGS.

Actually the current packaging files can successfully yield
*-dbgsym*.deb packages.

> > 2) why the python3 support is disabled? note: this will require a trip in new queue, so if possible
> > I would prefer a python3-only build
> 
> Same here. Since the build system leaves you the choice, please consider
> packaging the Python 3 version. Python 2 has an expiration date anyway.

As said in Debian's python policy I'm aware of it. Let me
clarify this point here. one of the build dependencies of
python-caffe-* is python*-protobuf, and python3-protobuf
is not possible for current protobuf version in Debian.
In a word, build dependencies not satisfied for python3-caffe-*.

> > 3) all the "debian/tmp" strings in install files should/can be removed I guess
> 
> Indeed, they should probably be removed.

Will do this.

> > (I didn't review all the packaging, just something that might/should be fixed.
> >
> > I'll wait for Ghislain to finish his review ;)
> 
> * I am really not a fan of the templated configuration of the dh_install
> files. Worst case, do it programmatically in d/rules rather than
> declaratively with templates + a call to yet another custom script.
> AFAIC, this creates a lot of overhead for no obvious benefits from a
> team-maintenance point-of-view.

I'll fix this. Removing those template generation matter indeed
avoids a python3 script.

> * Thinking long-term solution, one should just bite the bullet and make 
> the build system multi-arch aware. It's just one module in CMake
> (GnuInstallDirs) and substituting hardcoded DESTINATION paths with the
> appropriate CMake variables. I am sure upstream would accept such patch,
> and all distributions could benefit from it. I have done it multiple
> times and never encountered resistance upstream. Plus the significant 
> simplification of the debian files...

Will patch it.

> * On a different note, caffe seems to support building the documentation
> from source with doxygen. Please consider packaging it in a separate
> binary package (caffe-doc). The content of examples/* and models/*
> might also fit in this -doc package.

Yeah but I'm thinking about the latex(pdf) document generation,
I don't know should I add Build-Indep on texlive or is there
a "core" package to complete doxygen latex compiling.

I'll build caffe-doc package from "caffe" source, and also recommend
"caffe-doc" package in packages from "caffe-contrib".

> * You should consider adding a packaging testsuite. You could start with
> a script running part or all the examples shipped in the -doc package,
> which would verify that the packaged software run as intended.

Caffe has complete gtest testing routings. According to my 
experience of using Caffe, it should be working
if it passed the dh_auto_test. 

Adding more test is easy, and I think some more testsuite
from me will benifit other maintainers since they can learn
from it how to test this software by hand.

I'll do this.

> * You should consider adding some upstream metadata as described in [1].
> I am sure the Caffe guys would appreciate that we appropriately forward
> the citation information displayed on their README.

I didn't know Debian has such a cool thing. Will do this.

> * What is the purpose of keeping unapplied patches in d/patches?

Uh I forgot to remove them ... Will fix it.

> * Missing uversionmangling in d/watch for appropriate tracking of
> release candidate releases.

Since uscan(1) describes uversionmangle I think I can manage it.

> * Consider using libblas-dev | libblas.so as Build-Depends instead of
> libopenblas-dev. Not everyone is using openblas as its prefered blas
> implementation and upstream does not force to use this specific vendor
> (do they?), so no reason to force it here either.

No, I don't agree using libblas-dev as build-dep. Caffe only supports
3 BLAS backends: atlas, openblas and Intel MKL. Besides, openblas surpasses
basic BLAS by a large margin on performance, we should not switch
build-dep from openblas/atlas back to basic blas for a computational
intensive application, which would be awkward.

There is a discussion thread about which BLAS to use for the debian package.
Some caffe user believes that, it doesn't matter what BLAS the
maintainer choose, any high-performance one will do.
So I chose openblas after an investigation.

see
https://github.com/BVLC/caffe/issues/2601

> * For the future, seems like additional caffe-tools and octave-caffe
> binary packages could be created from the content generated by the
> matlab/ and tools/ leaves of the source tree. I guess that's what is
> acknowledged in debian/TODO.

ELFs under tools/ are shipped in package "caffe-{cpu,cuda}". I prefer this
scheme rather than "caffe-cpu(metapackage) + caffe-tools(elfs)".
BTW I'd like to create a metapackage "caffe-cpu-all".

For octave-caffe, I haven't find the way to pass the build with octave
yet. I'd like to postpone this binary package to future uploads.

OpenCL support from caffe upstream is still *experimental*, but
it will come one day, hence it was added to TODO. caffe-doc
and octave-caffe are as said above.

> [1] https://wiki.debian.org/UpstreamMetadata
> 
> Ghis

Thank you Ghislain Vaillant, the Caffe package quality
will be significantly improved at next time mentors
upload! Thank you Gianfranco Costamagna for long-time
attention!

[toc] | [prev] | [next] | [standalone]

#739320

On 17/05/16 15:42, lumin wrote:
> Thank you for this careful and thorough review!
 >
>>> 2) why the python3 support is disabled? note: this will require a trip in new queue, so if possible
>>> I would prefer a python3-only build
>>
>> Same here. Since the build system leaves you the choice, please consider
>> packaging the Python 3 version. Python 2 has an expiration date anyway.
>
> As said in Debian's python policy I'm aware of it. Let me
> clarify this point here. one of the build dependencies of
> python-caffe-* is python*-protobuf, and python3-protobuf
> is not possible for current protobuf version in Debian.
> In a word, build dependencies not satisfied for python3-caffe-*.

You're right, I think I saw a post on d-devel of someone attempting to
package protobuf for Py3. My bad.

>> * On a different note, caffe seems to support building the documentation
>> from source with doxygen. Please consider packaging it in a separate
>> binary package (caffe-doc). The content of examples/* and models/*
>> might also fit in this -doc package.
>
> Yeah but I'm thinking about the latex(pdf) document generation,
> I don't know should I add Build-Indep on texlive or is there
> a "core" package to complete doxygen latex compiling.

doxygen-latex [1]?

[1] https://packages.debian.org/sid/doxygen-latex

> I'll build caffe-doc package from "caffe" source, and also recommend
> "caffe-doc" package in packages from "caffe-contrib".

We usually put -doc in Suggests for the -dev or -bin package, depending
on what the docs cover (API, user guide...).

>> * You should consider adding a packaging testsuite. You could start with
>> a script running part or all the examples shipped in the -doc package,
>> which would verify that the packaged software run as intended.
>
> Caffe has complete gtest testing routings. According to my
> experience of using Caffe, it should be working
> if it passed the dh_auto_test.

Just to clarify, I meant this sort of packaging testsuite [2].

[2] https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html

What happens during dh_auto_test is completely different. The packaging
testsuite is for CI purposes.

> Adding more test is easy, and I think some more testsuite
> from me will benifit other maintainers since they can learn
> from it how to test this software by hand.
>
> I'll do this.

As said earlier, the minimum is to test what you **install**. Making
sure the packaged examples can be built and run from the packaged
library is an example of such test case.

>> * You should consider adding some upstream metadata as described in [1].
>> I am sure the Caffe guys would appreciate that we appropriately forward
>> the citation information displayed on their README.
>
> I didn't know Debian has such a cool thing. Will do this.

Later, you'll be able to watch the results on the d-science sentinel
for the machine-learning task [3]. The citation will appear at the
bottom of the description, like in other packages.

[3] http://blends.debian.org/science/tasks/machine-learning

>> * What is the purpose of keeping unapplied patches in d/patches?
>
> Uh I forgot to remove them ... Will fix it.
>
>> * Missing uversionmangling in d/watch for appropriate tracking of
>> release candidate releases.
>
> Since uscan(1) describes uversionmangle I think I can manage it.
>
>> * Consider using libblas-dev | libblas.so as Build-Depends instead of
>> libopenblas-dev. Not everyone is using openblas as its prefered blas
>> implementation and upstream does not force to use this specific vendor
>> (do they?), so no reason to force it here either.
>
> No, I don't agree using libblas-dev as build-dep. Caffe only supports
> 3 BLAS backends: atlas, openblas and Intel MKL. Besides, openblas surpasses
> basic BLAS by a large margin on performance, we should not switch
> build-dep from openblas/atlas back to basic blas for a computational
> intensive application, which would be awkward.
>
> There is a discussion thread about which BLAS to use for the debian package.
> Some caffe user believes that, it doesn't matter what BLAS the
> maintainer choose, any high-performance one will do.
> So I chose openblas after an investigation.
>
> see
> https://github.com/BVLC/caffe/issues/2601

You have heard of alternatives [4], haven't you?

[4] https://wiki.debian.org/DebianAlternatives

So, if you b-dep on libopenblas-dev, you will force a linkage on one
specific vendor for blas, and bypass the alternatives concept. This is
what you noticed with `readelf -d` in the issue.

Instead, you should be using libblas-dev | libblas.so, which will
provide a virtual dependency (libblas.so.3) which can be satisfied by
either vendors of blas. See the result with ArrayFire [5].

[5] https://packages.debian.org/sid/libarrayfire-cpu3

>> * For the future, seems like additional caffe-tools and octave-caffe
>> binary packages could be created from the content generated by the
>> matlab/ and tools/ leaves of the source tree. I guess that's what is
>> acknowledged in debian/TODO.
>
> ELFs under tools/ are shipped in package "caffe-{cpu,cuda}". I prefer this
> scheme rather than "caffe-cpu(metapackage) + caffe-tools(elfs)".
> BTW I'd like to create a metapackage "caffe-cpu-all".
>
> For octave-caffe, I haven't find the way to pass the build with octave
> yet. I'd like to postpone this binary package to future uploads.
>
> OpenCL support from caffe upstream is still *experimental*, but
> it will come one day, hence it was added to TODO. caffe-doc
> and octave-caffe are as said above.

Indeed, not so important at this point. These can be added later if
need arises.

Thanks for working on this.

Ghis

[toc] | [prev] | [next] | [standalone]

#739501

On Tue, 2016-05-17 at 16:55 +0100, Ghislain Vaillant wrote:
> On 17/05/16 15:42, lumin wrote:
> > Thank you for this careful and thorough review!

http://anonscm.debian.org/cgit/debian-science/packages/caffe.git/

Let me summarize the changes this time

* remove python script for autogen, generate install control
  file in rules instead. The trick used is borrowed from
  CUDA packaging.

* update content in install control file, including removing
  debian/tmp.

* add caffe-doc package

* change target release from experimental to unstable

* add 3 new patch:
  - cmake-using-basic-blas
  - cmake-using-gnuinstalldirs
  - cmake-fix-python-module-installdir

* removed unapplied patches.

* update README.Debian

* remove custom target in rules, since standard build is
  not heavy anymore.

* fix many lintian Warnings for caffe-doc in rules

* add debian/tests/control, and a simple test debian/tests/simple

* use uversionmangle in watch, version parse ok

* add debian/upstream/metadata , but lintian says

> W: caffe source: upstream-metadata-yaml-invalid

Is there anything wrong with this file? I have no idea

```
Homepage: http://caffe.berkeleyvision.org/
Name: Caffe
Reference:
  Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and Darrell, Trevor
  Title: Caffe: Convolutional Architecture for Fast Feature Embedding
  Journal: arXiv preprint arXiv:1408.5093
  Year: 2014
  URL: http://arxiv.org/abs/1408.5093
  eprint: http://arxiv.org/pdf/1408.5093.pdf
Repository-Browse: https://github.com/BVLC/caffe
```

well, the above issue seems to be the last one before it
can be uploaded.

when I'm writing this email debomatic is still compiling:
http://debomatic-amd64.debian.net/distribution#unstable/caffe/1.0.0~rc3-1/buildlog

[toc] | [prev] | [next] | [standalone]

#739507

[Multipart message — attachments visible in raw view] — view raw

> On 18 May 2016, at 13:44, lumin <cdluminate@gmail.com> wrote:
> * add debian/upstream/metadata , but lintian says
> 
>> W: caffe source: upstream-metadata-yaml-invalid
> 
> Is there anything wrong with this file? I have no idea
> 
> ```
> Homepage: http://caffe.berkeleyvision.org/
> Name: Caffe
> Reference:
>  Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and Darrell, Trevor
>  Title: Caffe: Convolutional Architecture for Fast Feature Embedding

You need to quote the colon in "Caffe:".
https://wiki.debian.org/UpstreamMetadata recommends
http://yaml-online-parser.appspot.com/ for validation.

Regards,
James

[toc] | [prev] | [next] | [standalone]

#739513

[Multipart message — attachments visible in raw view] — view raw

> On 18 May 2016, at 14:15, James Clarke <jrtc27@jrtc27.com> wrote:
> 
>> On 18 May 2016, at 13:44, lumin <cdluminate@gmail.com> wrote:
>> * add debian/upstream/metadata , but lintian says
>> 
>>> W: caffe source: upstream-metadata-yaml-invalid
>> 
>> Is there anything wrong with this file? I have no idea
>> 
>> ```
>> Homepage: http://caffe.berkeleyvision.org/
>> Name: Caffe
>> Reference:
>> Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and Darrell, Trevor
>> Title: Caffe: Convolutional Architecture for Fast Feature Embedding
> 
> You need to quote the colon in "Caffe:”.

The entire field, that is (you can’t quote a subset of it afaik), i.e.

Title: 'Caffe: Convolutional Architecture for Fast Feature Embedding'

> https://wiki.debian.org/UpstreamMetadata recommends
> http://yaml-online-parser.appspot.com/ for validation.

Regards,
James

[toc] | [prev] | [next] | [standalone]

#739525

> Title: 'Caffe: Convolutional Architecture for Fast Feature Embedding'

Thank you James, I've solved this problem.

Mentors, please check the latest caffe package on mentors:

https://mentors.debian.net/package/caffe

debomatic result should be the same as that obtained 1 hour ago.
I think source package "caffe" is now clean in all aspects.

[toc] | [prev] | [next] | [standalone]

#739626

Hi Lumin,

>Thank you James, I've solved this problem.
I don't want to do the final checks until Ghislain gives me his personal ack, but
I see that the python3 dependencies might be fixed with not-much effort.

issues I would like to see fixed or answered:
python/requirements.txt <-- please check for missing runtime dependencies.


why some of them are outside that shlibs:Depends and not picked up automatically?
talking about
python-skimage and python-protobuf

e.g. you can't run cython if you don't put it on build-dependencies.
also all the requiremends, need to be in build-dependencies in order to be picked up
by python:Depends correctly.

for the python3 porting:
protobuf is python3 ready 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
what about helping the maintainer in uploading it?


for skimage:
the package has two RC bugs, both fixed upstream 
#788965, #794859.
you need to fix all the dependencies if you really want your package in Stretch!
(btw for skimage, the new release fixes all the RC bugs
I also asked why it hasn't been packaged yet
https://github.com/scikit-image/scikit-image/issues/2091
)

Gianfranco

[toc] | [prev] | [next] | [standalone]

#739688

Control: block -1 by 795841
Control: block 788539 by 795841

On Wed, 2016-05-18 at 21:12 +0000, Gianfranco Costamagna wrote:
> Hi Lumin,
> 
> >Thank you James, I've solved this problem.
> I don't want to do the final checks until Ghislain gives me his personal ack, but
> I see that the python3 dependencies might be fixed with not-much effort.
> 
> issues I would like to see fixed or answered:
> python/requirements.txt <-- please check for missing runtime dependencies.

debhelper will pick them up as python package dependencies:
  dh_python2 --requires=python/requirements.txt

> why some of them are outside that shlibs:Depends and not picked up automatically?
> talking about
> python-skimage and python-protobuf

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

> e.g. you can't run cython if you don't put it on build-dependencies.
> also all the requiremends, need to be in build-dependencies in order to be picked up
> by python:Depends correctly.

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:

>   Depends: libcaffe-cpu1 (= 1.0.0~rc3-1), python-skimage, python-protobuf, cython, ipython, python (<< 2.8), python (>= 2.7~), python    -dateutil, python-gflags, python-h5py, python-leveldb, python-matplotlib, python-networkx, python-nose, python-numpy (>= 1:1.8.0),     python-numpy-abi9, python-pandas, python-pil, python-scipy, python-six, python-yaml, python:any (>= 2.7.5-5~), libboost-python1.55.    0, libboost-system1.55.0, libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libgoogle-glog0, libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>    = 4.2.1)

Why should runtime deps be added into build-dep, which are useless
unless I provide python-caffe-* testsuite.

> for the python3 porting:
> protobuf is python3 ready 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
> what about helping the maintainer in uploading it?

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

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.

> for skimage:
> the package has two RC bugs, both fixed upstream 
> #788965, #794859.
> you need to fix all the dependencies if you really want your package in Stretch!
> (btw for skimage, the new release fixes all the RC bugs
> I also asked why it hasn't been packaged yet
> https://github.com/scikit-image/scikit-image/issues/2091
> )

It seems that skimage is not a blocker of Caffe.

$ apt list python3-skimage* -a
Listing... Done
python3-skimage/stable,unstable,now 0.10.1-2 all [installed]

[toc] | [prev] | [next] | [standalone]

#739697

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web