Is it possible to package caffe, a deep learning framework ?

Hi Debian-Science folks, (please CC me when reply) Caffe is a deep learning framework. It is developed by the Berkeley Vision and Learning Center (BVLC) and by community contributors. Caffe is released under the BSD 2-Clause license. http://caffe.berkeleyvision.org/ I'm

[caffe] current status of packaging the deeplearning framework

* libcaffe-cuda-dev Thanks. [1] http://anonscm.debian.org/cgit/debian-science/packages/caffe.git/ -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description

Re: [caffe] current status of packaging the deeplearning framework

before CMake, and at that time I'm only familiar with Make but not CMake. Besides, the patches to Makefile contain some dirty hacks. I agree to switch build system from Make to CMake, and will do it soon. -- .''`. Lumin

Re: [caffe] current status of packaging the deeplearning framework

] https://github.com/BVLC/caffe/issues/2638 -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc Description: This is a digitally signed message part

Re: [caffe] current status of packaging the deeplearning framework

/issues/337 [5] https://code.google.com/p/thrust/issues/detail?id=359#c5 [6] https://github.com/BVLC/caffe/issues/27 -- .''`. Lumin : :' : `. `' `-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A signature.asc

Re: [caffe] current status of packaging the deeplearning framework

On Sat, 2015-08-08 at 10:57 +0100, Ghislain Vaillant wrote: Another naming convention we use for these elf executables is to use libname-bin. [...] Thank you for advice, and I prefer the name caffe-{cpu,cuda}, because user will be able to find the caffe package with $ apt list caffe* -

Re: Fwd: Re: [Caffe] uploaded to mentors but NOT RFS

On Wed, 2015-09-09 at 09:03 +, lumin wrote: > > note that nvidia-cuda-toolkit is from non-free. And packages from main > can't build-depend on non-free components :-/ It means that it might > be necessary either to > > 1. move caffe into contrib (again, away from

Bug#826715: RFS: lua-torch-torch7/0~20160604-g69d7a01-1 [ITP]

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org, a...@debian.org Dear mentors, This package is the very core part of "Torch", a state-of-the-art machine learning framework. Note, this package requires luajit from experimental, and the

Bug#826704: RFS: lua-torch-cwrap/0~20160222-gdbd0a62-1 [ITP]

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org, a...@debian.org Dear mentors, This package is a part of "Torch", a state-of-the-art machine learning framework. I am looking for a sponsor for my package "lua-torch-cwrap" * Package name

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

On Thu, 2016-05-26 at 14:32 +0100, Ghislain Vaillant wrote: > I don't agree. Regarding the testsuite, I believe most features should > be tested at package build time, including the Python stuff. We want to > fail early if something goes wrong. To me, the autopkgtest testsuite > serves a

Bug#826076: RFS: lua-cwrap/0~20160222-gdbd0a62-1 -- CWrap package for Torch Framework [ITP]

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "lua-cwrap" * Package name: lua-cwrap Version : 0~20160222-gdbd0a62-1 Upstream Author : Torch Developers * URL

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

On Thu, 2016-05-19 at 06:32 +, 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

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

Control: block -1 by 795841 Control: block 788539 by 795841 On Wed, 2016-05-18 at 21:12 +, 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

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

Control: block -1 by 799262 one more functional blocker, python3-opencv opencv is (I guess) frequently used by caffe users, Debian should have python3-opencv if we provide python3-caffe. when is the EOL of python2.x? I forgot it. If it is not 2017, can we first upload python2-caffe-* ? I'll

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

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

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

debomatic result * build pass, * autopkgtest OK, according to log no error occurs * lintian remains 1 warning about that weird YAML issue * piuparts fails because of DoM problem updated package was uploaded to mentors https://mentors.debian.net/package/caffe

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

> 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

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

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

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

Hi mentors, I found the way to fix lintianI: no-fortify-functions, and I'll add multi-arch support as suggested by Aron, so please wait for my next upload.

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

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

Bug#823308: ITP: caffe-contrib -- a deep learning framework, compiled with CUDA

Package: wnpp Severity: wishlist Owner: lumin <cdlumin...@gmail.com> X-Debbugs-CC: costamagnagianfra...@yahoo.it, ghisv...@gmail.com, debian-science@lists.debian.org Hi, #788539 is cpu version of caffe, this is CUDA version. CPU version goes into main section while this CUDA versio

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

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: a...@debian.org, deb...@danielstender.com, deb...@onerussian.com, debian-de...@lists.debian.org, debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "caffe" * Package name: caffe

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

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

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

Hi guys, Some updates to the caffe package: (can be seen in git repo but no mentors upload) 1. added octave-caffe-cpu package, but there remains some lintian errors to be solved. 2. changed package caffe-cpu into metapackage, move tools to package caffe-tools-cpu. the metapackage

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

idn't migrate > >https://packages.qa.debian.org/s/skimage.html > >I would prefer to avoid overriding of the testsuite, so we might end up in > >1) fixing the build failures > >2) restrict caffe on the success architectures > > > >cheers, > > > >G. > > > > > -- > > Best, > > Lumin > -- Best, Lumin

Re: Re: Is theano worth saving?

> I believe the easiness of `apt install` which Daniel brought in is no > longer so much of a *strong* argument, now that pip + wheels has become > quite mature. That's my personal opinion though. I think I should say something since I'm maintaining some Theano alternative packages [1] and I

[GSoC] pre-study (WIP) for the "Benchmarking" project

please don't hesitate to step forward. :-) Thank you. [1] https://gitlab.com/lumin/benchmark [2] Please feel free to open a issue if you have gitlab account. [3] https://wiki.debian.org/SummerOfCode2017/Projects/Benchmarking

Re: About the sense of removing -march=native (Was: Is theano worth saving?)

> So do you think we are doing a bad service to our users by striping > -march=native?  Could you please provide some numbers? No, we are not doing bad. Nobody is wrong. We cannot gain compatibility and performance at the same time. I don't remember the exact numbers of those experiments

Re: Re: science-optimisation (Was: About the sense of removing -march=native)

> I was also immediately convinced that DEB_BUILD_OPTIONS=custom is the > better interface. `apt-build` (an orphaned package) is also a good reference for doing -march=native rebuilds. https://tracker.debian.org/pkg/apt-build One of the DKMS upstream maintainers told me that we can do anything

Bug#835660: RFS: meta-torch-core-free/1~exp1 [ITP] -- Torch core stack basically ready

using this command: dget -x https://mentors.debian.net/debian/pool/main/m/meta-torch-core-free/meta-torch-core-free_1~exp1.dsc Changes since the last upload: meta-torch-core-free (1~exp1) experimental; urgency=low * Initial release. (Closes: #794634) -- Best, Lumin

Re: Please categorise your packages for the Debian Science metapackages

(Dropping the CC list) Hi Andreas, I'm holding 6 uncategorized d-science packages. * caffe and caffe-contrib are categorized into machine-learning task. See the patch attached. * the remaining 4 packages are core components of the torch7 framework, and the torch7 metapackage

Re: skimage status

Hi, Thank you Ole Streicher. The only migration blocker of my deep learning package Caffe is exactly skimage. Since skimage has a chance to enter Stretch, caffe will have the chance as well. https://tracker.debian.org/pkg/caffe

Re: Keras (abstraction layer for Theano and TensorFlow) seeks for an adopter

Hello everyone, I'd like to provide some information about this. Bengio (an important guy behind Theano) declared the end of Theano's development. So we should not pay too much time on it. Tensorflow, the computation graph can be considered as a successor of Theano the symbolic graph engine.

Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hi Debian Science Team, The main purpose for me to write this mail is to notify you guys that I'm going to assign MKL a higher priority than OpenBLAS via the update-alternative mechanism. MKL provides alternatives to e.g. libblas.so.3

Package nearly ready. (was: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hi, On Fri, 2018-04-27 at 11:53 -0500, Dirk Eddelbuettel wrote: > I agree with Lumin here and not Seb -- if and when one adds MKL, it > should > also be higher priority. That is the point of such a package (which > will > likely linger in contrib or non-free anyway). As suggest

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hi Sébastien, > Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2: Thanks. I didn't notice that when considering ways to avoid corner cases. > I also think that removing the Provides is not a good idea. The alternative is > provided by the package, and that should be made clear in the

RFS: intel-mkl/2018.2.199-1 -- ready for review

. Don't perform source-only upload since this is non-free blob. A source+amd64+i386 upload is needed. Thanks in advance. :-) Best, lumin signature.asc Description: PGP signature

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hello guys, I've just updated the MKL packaging, and added a BLAS performance tester there. I'll test the package soon, but let me first describe the changes. > He put forward a simpler solution: Just don't provide libblas.so.3, such > that MKL will never be used to satisfy the dependency of

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

On Wed, May 02, 2018 at 10:03:38AM -0500, Dirk Eddelbuettel wrote: > > On 2 May 2018 at 14:41, Lumin wrote: > | Seems that things are getting more complicated. Recall that here we'are > | going to prevent users from GPL violation in situations such as this > | one: > | >

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

On Fri, May 18, 2018 at 11:49:05PM +0800, Drew Parsons wrote: > > I wonder if the simplest solution is to just have > intel-mkl Depends: libblas. i.e. use policy to simply prevent a sole > mkl installation. > > That way, the mkl alternative will always have a free BLAS to press > it's

Re: Bug#899159: Acknowledgement ([numpy/grave] Incorrect Memory offset in numpy.uint8 arrays)

Sorry, I made a stupid mistake. uint8 ranges from 0 to 255. signature.asc Description: PGP signature

Bug#899159: [numpy/grave] Incorrect Memory offset in numpy.uint8 arrays

Package: python3-numpy Version: 1:1.14.3-2 Severity: grave X-Debbugs-CC: debian-science@lists.debian.org Dear Numpy maintainers, As a student/researcher, I cannot bear any library that *SILENTLY* produces totally wrong result. This time numpy just triggered me, and I wish you can understand that

Re: Change of license of Nvidia drivers

Hi Jerome, Thank you for putting forward this issue. I guess the maintainers have noticed this problem, as per changelog of this upload: nvidia-graphics-drivers (387.34-1) experimental; urgency=medium Anyway I'm pinging the driver maintainer. > Hi all, > > Maybe I am not asking to the

Thoughts about Debian's present and future Deep Learning Packages

Hello Debian-Science folks, I'd like to put forward several thoughts which were not discussed publically, and by the way update the status of Debian's deep learning software packages. Status about Deep Learning Packages --- In my fuzzy memory I may have posted

Bits about Intel MKL packaging -- In NEW

Hello, I'm closing this RFS[ITP] since the package was in NEW. https://ftp-master.debian.org/new/intel-mkl_2018.3.222-1.html Many thanks to Graham Inggs who sponsored it.

Re: need repositories for keras subprojects

Hi Stephen, > I am updating the keras package and the newest release of keras 2.2.0 > now depends on some modules that have been broken off upstream into > separate tarballs, namely "keras-applications" and > "keras-preprocessing". > > So I am making corresponding packages for these. Would

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

things discussed above, there is upstream confirmation to the ambiguous license declaration in several headers. See [1] The blockers are cleared. I think I'll update the package as proposed, and the copyright information as said in [1] before this weekend. [1] https://github.com/intel/mkl-dnn/issues/206#issuecomment-385772103 Regards, Lumin signature.asc Description: PGP signature

Re: Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hi Sébastien, > - if MKL was not already selected and the user says no, the setting > will be > left untouched (either in automatic or manual mode, depending on the > user > customization) > > - if MKL was already selected and the user says no (e.g. after a > reconfigure), > then MKL will be

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

Hi Sébastien, > However, MKL is non-free software, and in particular its source code is not > publicly available. By using MKL as the default BLAS/LAPACK implementation, > you might be violating the licensing terms of copyleft software that would > become dynamically linked against it. Please

Bug#897238: RFS: intel-mkl/2018.2.199-1 -- Intel Math Kernel Library (Intel MKL)

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "intel-mkl" * Package name: intel-mkl Version : 2018.2.199-1 Upstream Author : Intel * URL :

Re: Re: Bits about Intel MKL packaging -- Higher Priority than OpenBLAS

eam/intel-mkl/blob/master/debian/libmkl-rt.config [3] https://salsa.debian.org/science-team/intel-mkl/blob/master/debian/libmkl-rt.postinst.in [4] https://salsa.debian.org/science-team/intel-mkl [5] https://salsa.debian.org/lumin-guest/tempfiles/blob/master/mkl-debc-i386.txt [6] ht

Patch for pandas RC 884294, someone to sponsor?

Control: tags -1 +patch Pandas FTBFS on amd64 due to test failure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884294 I reproduced this FTBFS on my machine (sid/amd64). This test failure was due to a numpy problem. Upstream workaround (bypass) is available: *

Re: Patch for pandas RC 884294, someone to sponsor?

> I'd volunteer to upload once it is pushed. Please ping me after pushing > since there is not commit mailing list and I'm not sure whether the > tracker solution is implemented yet. Done. https://salsa.debian.org/science-team/pandas/commits/debian -- Best,

Re: Preconditions for python-moto finished - help needed to build package itself

Hi Andreas, I checked the packaging, and my debuild ended up with an error different from > AttributeError: 'module' object has no attribute 'backport_assert_raises' According to a quick investigation on this problem, I'm sure there are still some missing B-Ds in control file. With patch

Re: Preconditions for python-moto finished - help needed to build package itself

Hi, On 6 February 2018 at 15:56, Andreas Tille wrote: > Would you mind pushing your patch directly? I do not see any advantage > if I would proxy your patch. ;-) Done. > I admit up to know I have not checked this file but probably having > these will help. Then I

Re: Keras (abstraction layer for Theano and TensorFlow) seeks for an adopter

Hi, > Could you expend the bit on the CMake build system and required patching. Do > you have a link to follow that discussion? The CMake build files are located here [3]. It was originally created for windows. There are two packaging-related issues on upstream issues, [2] and [4]. The

RFS: hepmc -- [RC] on behalf of multiarch-support removal

Hi, Can anybody sponsor my team upload for "hepmc"? Thanks. https://salsa.debian.org/science-team/hepmc - commit: cb8aa811bb7e8b5be46107ca9992a5ad58df73cb - upload: unstable changes: hepmc (2.06.09-2) unstable; urgency=medium * Team Upload. * Replace B-D-I:texlive-math-extra with

Re: Dealing with the mess around package hepmc and its reverse-dependencies in Debian

On Tue, Aug 14, 2018 at 06:25:10PM -0400, Boyuan Yang wrote: > ..in which libhepmc4 and libhepmcfio4 are all provided by src:hepmc. Package in good shape again. https://salsa.debian.org/science-team/hepmc

Bug#905582: RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "nsync", which is a tensorflow dependency. * Package name: nsync Version : 1.20.1-1 Upstream Author : google * URL

Re: O: double-conversion -- routines to convert IEEE floats to and from strings

On Sat, Aug 18, 2018 at 07:23:48PM +0200, Sébastien Villemot wrote: > Hi Lumin, > > Le samedi 18 août 2018 à 15:16 +0000, Lumin a écrit : > > double-conversion is a tensorflow dependency and surprisingly it was > > orphaned. I will continue maintaining it within d-sci

Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Control: tags -1 +moreinfo Control: blocks -1 by 906646 894411 Control: blocks 804612 by -1 Hi Mentors and d-Science Team, **Many thanks** to Aron Xu for his sponsorship with a 512GB-RAM builder.

Re: O: double-conversion -- routines to convert IEEE floats to and from strings

control: owner -1 control: retitle -1 ITA: double-conversion -- routines to convert IEEE floats to and from strings double-conversion is a tensorflow dependency and surprisingly it was orphaned. I will continue maintaining it within d-science team. However, in order to avoid embedding a copy of

Bug#907018: RFS: hepmc/2.06.09-3 [RC]

Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "hepmc" * Package name: hepmc Version : 2.06.09-3 Upstream Author : [fill in name and email of upstream] * URL

Anyone interested in Tensorflow packaging? Makefile available now.

Hello d-Science and d-Python team, Long time ago, TensorFlow packaging was blocked by bazel, a google's java-based building system which is hard to harness. At that time, cmake build was available but it's written for windows. However, by chance I discovered that tensorflow now ships a set of

Bug#895729: RFS: mkl-dnn/0.13~20180406-ga5f6077-1 [ITP] -- math kernel lib for deep neural network

Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "highwayhash" * Package name: mkl-dnn Version : 0.13~20180406-ga5f6077-1 Upstream Author : Intel * URL :

MKL is redistributable; Should we package it?

Hello d-science folks, I noticed that intel's math kernel library is redistributable[1]. Since it is widely used in various fields, an mkl package in Debian archive my be beneficial to at least science software users. However despite of the explicit declaration that MKL is redistributable, MKL

Re: MKL is redistributable; Should we package it?

-for-python-and-intel-performance-libraries-with-pip-and On 30 March 2018 at 07:43, Ghislain Vaillant <ghisv...@gmail.com> wrote: > > Le ven. 30 mars 2018 à 08:18, Lumin <cdlumin...@gmail.com> a écrit : >> >> Hello d-science folks, >> >> I noticed that intel'

Bug#894671: RFS: nltk/3.2.5-2 [ITA] : natural language processing lib, popcon: ~300

Package: sponsorship-requests Severity: normal X-Debbugs-CC: debian-science@lists.debian.org Dear mentors, I am looking for a sponsor for my package "nltk" * Package name: nltk Version : 3.2.5-2 Upstream Author : [fill in name and email of upstream] * URL :

Re: Looking for feedback on a recent upload

Hi Thomas, Glad to see you came back to maintain this package. This package gives an overview of your package status in Debian: https://tracker.debian.org/pkg/toulbar2 > Would it be possible to have any feedback on this: > > - is it packaging fine on salsa (am I finished) ? I indeed

Re: Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code

Some updates about this pre-RFS: Summary: 1. The README.Debian file is totally invalidated. Please don't review the repo. 2. I switched to use python plus ninja for building Debian's TF, which may have a chance to evolve into the final solution. On Fri, Aug 24, 2018 at 22:58 Lumin wrote

Re: Debian OpenBLAS Package Rebuild Procedure

On Sun, Jul 26, 2020 at 06:51:37PM +0100, John Duffy wrote: > I would be grateful for confirmation that I have followed the correct > procedure > to make a change to the package source code. There is not likely a standard procedure for doing so. BTW, I did not find any problem in your procedure.

Re: Notes from the 2020-07-17 Bazel-Debian-Google meeting

Hi, This is really a great news! I've removed all the leftover from the science-team/tensorflow repo. Please go ahead with bazel there if you don't want to create new repos. Feel free to remove bits that I forgot to remove. On Fri, Jul 17, 2020 at 05:57:26PM +0200, Michael R. Crusoe wrote: >