[Caffe] uploaded to mentors but NOT RFS

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Caffe] uploaded to mentors but NOT RFS

M. Zhou
Hi all,
(CC'ing people interested in package Caffe)

It takes so long time for Caffe to be packaged for Debian,
now the package is nearly prepared to be uploaded, and
there are still some small issues to be addressed.

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

My local build result (2 amd64 machines: chroot testing, and testing):
 [debuild] [OK]
 [d/rules:: custom-cpu] [OK]
 [d/ruels:: custom-cuda] [OK]

As a packaging Newbie I indeed paied considerable time on it...
at the same time I learned a lot packaging it.
This is just my 3rd Debian package (and it includes my 1st python3
package), so I'm not sure how far it is to be accepted into Archive.

Just a ping, thank you all. :-)

--
 .''`.                                               Lumin
: :' :                        
`. `'  
  `-    638B C75E C1E5 C589 067E  35DE 6264 5EB3 5F68 6A8A

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Caffe] uploaded to mentors but NOT RFS

Yaroslav Halchenko

On Wed, 02 Sep 2015, lumin wrote:
> As a packaging Newbie I indeed paied considerable time on it...
> at the same time I learned a lot packaging it.
> This is just my 3rd Debian package (and it includes my 1st python3
> package), so I'm not sure how far it is to be accepted into Archive.

> Just a ping, thank you all. :-) just a minor recommendation... for the
snapshot versions use following strategy to come up with upstream version --
should end with what 'git describe' ends with for the treeish: e.g.

$> git describe --tags e8e66                
rc2-513-ge8e660d

as you see -- current one is not understood by git,

$> git show 0.9999~rc2+git20150902+e8e660d3  
fatal: ambiguous argument '0.9999~rc2+git20150902+e8e660d3': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

whenever such one (where you use "-g" instead of "+"):

$> git show 0.9999~rc2+git20150902-ge8e660d3
commit e8e660d3ca5b5d8d1e8f2853c0d606cb525d8a72
Merge: cbb2ed1 4f64b9e
Author: Jeff Donahue <[hidden email]>
Date:   Tue Sep 1 19:37:41 2015 -0700

    Merge pull request #2990 from mattdawkins/add-openblas-path
   
    Add extra OpenBLAS include search path

does. that makes it possible for gbp to even generate tarball from that treeish if .orig is not found locally

just few cents hoping of help ;)

--
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik       

Reply | Threaded
Open this post in threaded view
|

Re: [Caffe] uploaded to mentors but NOT RFS

Yaroslav Halchenko
In reply to this post by M. Zhou

On Wed, 02 Sep 2015, lumin wrote:

> Hi all,
> (CC'ing people interested in package Caffe)

> It takes so long time for Caffe to be packaged for Debian,
> now the package is nearly prepared to be uploaded, and
> there are still some small issues to be addressed.

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

> My local build result (2 amd64 machines: chroot testing, and testing):
>  [debuild] [OK]
>  [d/rules:: custom-cpu] [OK]
>  [d/ruels:: custom-cuda] [OK]

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 main :-( )

2. or  provide two source packages, of which main would build only
CPU implementation while in non-free would build both/only GPU
(depending how organized).  

Or is there a better solution which I am missing somehow?

--
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik       

Reply | Threaded
Open this post in threaded view
|

Re: [Caffe] uploaded to mentors but NOT RFS

Paul Tagliamonte-3
On Tue, Sep 08, 2015 at 10:36:00PM -0400, Yaroslav Halchenko wrote:
> 2. or  provide two source packages, of which main would build only
> CPU implementation while in non-free would build both/only GPU
> (depending how organized).  

Yeah, that's not super great. I might consider a -src
package and build-depend on that. That's a monumental hack, though, and
I don't like seeing that in the archive.

Another, totally untested (policy-wise) idea is to use build stages. No
idea if anything would support that (non-free buildd side, or
policywise).

Best bet is to move to contrib, I guess.


   Paul

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Caffe] uploaded to mentors but NOT RFS

Graham Inggs-3
On 9 September 2015 at 04:42, Paul Tagliamonte <[hidden email]> wrote:
> On Tue, Sep 08, 2015 at 10:36:00PM -0400, Yaroslav Halchenko wrote:
>> 2. or  provide two source packages, of which main would build only
>> CPU implementation while in non-free would build both/only GPU
>> (depending how organized).
>
> Yeah, that's not super great. I might consider a -src
> package and build-depend on that. That's a monumental hack, though, and
> I don't like seeing that in the archive.

What is wrong with doing it that way?
Working with nvidia-cuda-toolkit, I've come across the following packages:

https://packages.qa.debian.org/s/starpu.html
https://packages.qa.debian.org/s/starpu-contrib.html
https://packages.qa.debian.org/h/hwloc.html
https://packages.qa.debian.org/h/hwloc-contrib.html
https://packages.qa.debian.org/e/eztrace.html
https://packages.qa.debian.org/e/eztrace-contrib.html

Reply | Threaded
Open this post in threaded view
|

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

M. Zhou
In reply to this post by Yaroslav Halchenko
Hi,

On Wed, 2015-09-09 at 09:02 +0000, lumin wrote:

> snapshot versions use following strategy to come up with upstream version --
> should end with what 'git describe' ends with for the treeish: e.g.
>
> $> git describe --tags e8e66
> rc2-513-ge8e660d
>
> as you see -- current one is not understood by git,
>
> $> git show 0.9999~rc2+git20150902+e8e660d3
> fatal: ambiguous argument '0.9999~rc2+git20150902+e8e660d3': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
>
> whenever such one (where you use "-g" instead of "+"):
>
> $> git show 0.9999~rc2+git20150902-ge8e660d3
> commit e8e660d3ca5b5d8d1e8f2853c0d606cb525d8a72
> Merge: cbb2ed1 4f64b9e
> Author: Jeff Donahue <[hidden email]>
> Date:   Tue Sep 1 19:37:41 2015 -0700
>
>      Merge pull request #2990 from mattdawkins/add-openblas-path
>      
>      Add extra OpenBLAS include search path
>
> does. that makes it possible for gbp to even generate tarball from that treeish if .orig is not found locally
>
> just few cents hoping of help ;)
>

Well, Thank you so much for this hint.
I'm planning to import new upstream version of caffe several days later,
at that time "treeish" will be used in new version string.

Thanks.


Reply | Threaded
Open this post in threaded view
|

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

M. Zhou
In reply to this post by Yaroslav Halchenko
On Wed, 2015-09-09 at 09:03 +0000, 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 main :-( )
>
> 2. or  provide two source packages, of which main would build only
> CPU implementation while in non-free would build both/only GPU
> (depending how organized).
>
> Or is there a better solution which I am missing somehow?
>
When I'm initializing package "Caffe" I wrote so:

source: caffe: contrib (because build-deps on CUDA)
binary: caffe-cpu: main/science (because it has absolutely no
relationship with contrib/non-free blobs.)
binary: caffe-cuda: contrib/science (dep on CUDA)

However this is conflicting with POLICY, so I just bumped
them all into contrib/{science,...}

Now  the source package debian-science/caffe is designed to
be able to be built twice, one is caffe-cpu and another is caffe-cuda.
So I don't want to change it as it works very well on my machines.

Now the *only* blocker is just, *FTBFS* on several ARCHs (thanks to Debian DoM service).

P.S. Now upstream code is not quite stable, so I plan
to just upload caffe to experimental, even if CUDA-6.5 is
transitioning into sid.

Thanks :-)