Whom should I send a patch to?

[lumin]

Assume that, I improved some .vim scripts in the package vim-runtime,
then I run apt-cache show vim-runtime, to find a email addr like this :
```
Maintainer: Debian Vim Maintainers
pkg-vim-maintain...@lists.alioth.debian.org
```
Then, I have some choices:
1. Join a team related to vim, then send a patch to ANYONE of the
maintainers.
2. Directly choose a maintainer and send the patch.
3. Send it the the mail list.
which way is recommended?

Thank you.
-- 
Regards,
  C.D.Luminate

odd Vcs-Git pointer in control file, package fortune-zh

[lumin]

Hi,

I'm a very newbie trying to adopt a package, according to the Debian new
maintainer's guide.
My target package is now fortune-zh, as it seems to be very simple to
work with (to fix chinese character typo that I noticed).

In the 1.10 version (jessie, unstable) of fortune-zh, I found this line
in control:
Vcs-Git: git://anonscm.debian.org/chinese/fortune-zh.git

So I cloned that Git repo, and then found the latest version in that git
repo is 1.9 ..

Then I looked up for bugs filed for fortune-zh, then found #518054 and
#629014. I didn't found any hint revealing where the newest repo lies.

I wonder if that 1.10 commit was out of nothing?
I have no idea where to clone that newest repo (containing 1.10) so I
can continue my ITA.

This is the 1.10's changelog part:
  1 fortune-zh (1.10) unstable; urgency=low
  2 
  3   * QA upload.
  4   * Really set Architecture field to 'all'. (Closes:
#518054)
  5   * Build package in binary-indep.
  6   * Add missing targets build-{arch,indep}.
  7   * Maintainer field set to QA Group.
  8   * Drop Uploaders field.
  9   * Bump Standards-Version to 3.9.5.
 10   * Set debhelper compatibility level to 9.
 11 
 12  -- Emanuele Rocca e...@debian.org  Mon, 20 Jan 2014
23:14:42 +0100

Thanks :)
-- 
 .''`.
: :' :
`. `' 
  `-  


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1423024679.2586.18.ca...@gmail.com

Re: odd Vcs-Git pointer in control file, package fortune-zh

[lumin]

Thank you for advise, Russ Allbery and Paul Wise.
I'll try it later :)
-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1423134462.2546.17.ca...@gmail.com

RFS: fortune-zh_1.11, section games

[lumin]

Dear mentors,

(Please CC me when reply, thanks!)

Package: fortune-zh (native)
License: GPL
Description: Chinese Data files for fortune
 This package contains the Chinese data files for fortune in
 UTF-8 encoding.
 .
 Those data files included:
  * tang300 (300_Tang_Poems)
  * song100 (100_Song_Poems)
  * shijing (Shi_Jing)
 .
 They are all classical Chinese poems.

I am a newbie and now maintaining package fortune-zh[0],
and now I think it's time to find sponsorship to upload new
release of fortune-zh and continue with my ITA[1].

The current version of fortune-zh in jessie and unstable are
both 1.10, and I'd like to put fortune-zh_1.11 into unstable.

Thanks :)

Here is the changelog for 1.11:
  1 fortune-zh (1.11) unstable; urgency=low
  2 
  3   * New maintainer.
  4   * tang300:
  5 - fixed a few characters.
  6   * Added new manpage man/fortune-zh(6).
  7   * debian/source/format:
  8 - Switched to dpkg-source 3.0 (native) format.
  9   * shijing:
 10 - converted from shijing.gb to UTF-8 encoding.
 11   * Makefile:
 12 - updated.
 13 - enabled data file shijing.
 14   * debian/control:
 15 - update description.
 16 - remove dependency on zh-autoconvert, use iconv instead.
 17   * fortune-zh:
 18 - remove dependency on zh-zutoconvert, use iconv instead.

[0] http://anonscm.debian.org/cgit/chinese/fortune-zh.git/
[1] Bug#629014: ITA: fortune-zh -- Chinese Data files for fortune


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1424692596.2772.17.ca...@gmail.com

Re: RFS: fortune-zh_1.11, section games

[lumin]

Oops, I should file a RFS bug against it, instead of posting here.

I'm sorry and please ignore the former message, I'm filing the RFS
bug now.

Thanks. ;)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1424761170.6295.2.ca...@gmail.com

Bug#779072: RFS: fortune-zh/1.13 [ITA #629014] -- Chinese Data files for fortune

[lumin]

Package: sponsorship-requests
Severity: wishlist

Dear memtors,

I am looking for a sponsor for my package fortune-zh:

 * Package name: fortune-zh
   Version : 1.13
   Upstream Author : Yu Guanghui y...@debian.org
 * URL :
http://anonscm.debian.org/cgit/chinese/fortune-zh.git
 * License : GPL
   Section : games

  It builds those arch-indep packages:

fortune-zh - Chinese Data files for fortune

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

  http://anonscm.debian.org/cgit/chinese/fortune-zh.git

  Changes since the last upload:

fortune-zh (1.13) unstable; urgency=low

  * Disable data file shijing
- fortune-zh: updated
- debian/control: updated
- man/fortune-zh.6: updated
- Makefile: updated

 -- Zhou Mo cdlumin...@gmail.com  Tue, 24 Feb 2015 06:47:51 +

fortune-zh (1.12) unstable; urgency=low

  * fortune-zh:
- handle environment LANG properly.
  * Specify dependency on libc (=2.1.1) explicitly:
- debian/control: updated.

 -- Zhou Mo cdlumin...@gmail.com  Tue, 24 Feb 2015 01:21:57 +

fortune-zh (1.11) unstable; urgency=low

  * New maintainer.
  * tang300:
- fixed a few characters.
  * Added new manpage fortune-zh(6).
  * debian/source/format:
- Switched to dpkg-source 3.0 (native) format.
  * shijing:
- converted from shijing.gb to UTF-8 encoding.
  * Makefile:
- updated.
- enabled data file shijing.
  * debian/control:
- update description.
- remove dependency on zh-autoconvert, use iconv instead.
  * fortune-zh:
- remove dependency on zh-zutoconvert, use iconv instead.

 -- Zhou Mo cdlumin...@gmail.com  Mon, 23 Feb 2015 11:41:47 +

Thanks.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1424762003.6295.14.ca...@gmail.com

Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-mentors@lists.debian.org, a...@debian.org

Dear mentors,

  I am looking for a sponsor for package cv:

 * Package name: cv
   Version : 0.6-1
   Upstream Author : Xfennec
 * URL : https://github.com/Xfennec/cv
 * License : GPL-3
   Section : utils

  It builds those binary packages:

cv - Coreutils (progress) Viewer

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

  https://github.com/Xfennec/cv

  The current packaging work is available at my github repo:

  https://github.com/CDLuminate/cv
  (branch: debian)

  Changes since the last upload:

cv (0.6-1) UNRELEASED; urgency=low

  * Initial release (Closes: #)
  * This is my first Debian package.
  * Adjusted Makefile according to maint-guide.
- i.e. modified DESTDIR variable and install path.

 -- Zhou Mo cdlumin...@gmail.com  Sat, 16 May 2015 01:33:02 +


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1431751641.3703.22.ca...@gmail.com

Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)

[lumin]

Hi guys,

On Mon, 2015-05-18 at 14:24 +0200, Christoph Egger wrote:
 I'll give it a look shortly

Thank you ;)

 probably not that one, right?

OMG, I missed that line ...

 Additionally I noticed there's already a package shipping /usr/bin/cv:
 
  radiance: /usr/bin/cv
 
 maybe you can use a different name?

Let me CC the author to discuss the name issue ...

Xfennec (the author of cv):
In fact there is a package named radiance in debian archive,
which includes a executable named cv. So this is a conflict again...

The description of cv I wrote in control file is
Coreutils (progress) Viewer.

Well, Xfennec, can we pick a new name for it ?
And please give your opinion.

Thank you both :-)

-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1431959872.2783.7.ca...@gmail.com

Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)

[lumin]

On Mon, 2015-05-18 at 17:18 +0200, Xfennec wrote:
 Well, the best tip I can give is the following GitHut issue:
 https://github.com/Xfennec/cv/issues/8
 
 The summary of this is that I'm pleased with the current name, and
 think the name conflict is quite unlikely, and is easy to deal with
 simple aliases. 

Well, IMHO how about cvp, which means Coreutils Viewer for Progress,
1. it's more clear in the terms of meaning, than cv
2. with a 'p' trailing after, it's no much harder to type than cv
3. cvp is available

$ apt-file search /usr/bin/cvp
kicad: /usr/bin/cvpcb
$ 

If you don't like cvp, then IMHO what about cvsp,
which means Coreutils Viewer for Seek Position.
(What a revealing name)
1. more clear on meaning, than cv
2. this one is revealing, but harder to type than both cv and cvp
3. cvsp is available 

$ apt-file search '/usr/bin/cvsp '
$

FWIW I think adding postfix for cv is much easier to accept
for Xfennec.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1431993774.6921.15.ca...@gmail.com

Bug#779072: RFS: fortune-zh/1.11 [ITA] -- Chinese Data files for fortune

[lumin]

retitle 779072 RFS: fortune-zh/1.11 [ITA] -- Chinese Data files for
fortune
thanks

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

  http://mentors.debian.net/package/fortune-zh


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

dget -x
http://mentors.debian.net/debian/pool/main/f/fortune-zh/fortune-zh_1.11.dsc

  Changes since the last upload:

fortune-zh (1.11) unstable; urgency=low

  * New maintainer. (Closes: #629014)
  * Fix a few characters in tang300.
  * Add manpage for fortune-zh(6).
  * Switched to dpkg-source 3.0 (native) format.
- debian/source/format
  * Convert shijing.gb into UTF-8 encoding.
  * Update description.
  * Remove dependency on zh-autoconvert, use iconv instead.
and specify dependency on libc (=2.1.1) explicitly.
- fortune-zh, debian/control
  * Handle environment LANG properly in fortune-zh.
  * Update Makefile.

I reverted the release of 1.12 and 1.13, and squashed changes
into 1.11, since the release of 1.12 and 1.13 is nearly bumping
version numbers.
I acknowledge that this is dirty in some ways.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432025176.4267.5.ca...@gmail.com

Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)

[lumin]

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

  http://mentors.debian.net/package/cv


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

dget -x http://mentors.debian.net/debian/pool/main/c/cv/cv_0.6-1.dsc

  More information about hello can be obtained from
http://www.example.com.

  Changes since the last upload:

cv (0.6-1) unstable; urgency=low

  * Initial release (Closes: #785425)
  * This is my first Debian package.
  * Adjusted Makefile according to maint-guide.
- for DESTDIR variable and install path.
- Harden binary files.
  * Adjusted manpage for lintian.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1431930901.2668.24.ca...@gmail.com

Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)

[lumin]

I have rebuild the package cv_0.6-1, with
a working watch file, and modified Makefile, 
and some other small changes.
lintian clean.

Then the last thing remains to be done upon this package
is the change of name ?



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

  http://mentors.debian.net/package/cv


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

dget -x http://mentors.debian.net/debian/pool/main/c/cv/cv_0.6-1.dsc

cv (0.6-1) unstable; urgency=low

  * Initial release (Closes: #785425)
  * This is my first Debian package.
  * Adjusted Makefile according to maint-guide.
- for DESTDIR variable and install path.
- Harden binary files.
  * Adjusted manpage for lintian.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432097580.3044.3.ca...@gmail.com

Avoiding linking with /home/packaging/X/libxx.so

[lumin]

Hi mentors,

I've been struggling with this shared library linking issue for
a while.
I scanned maint-guide, dev-ref (detail not enough),
debmake-doc (osamu's new version of maint-guide),
and a library packaging guide [1] that debmake-doc recommended.
Then I still have no idea how to handle the problem I encountered.

I also downloaded many sources, which generates
  libx libx-dev libx-bin
such as glibc, but find it difficult to allocate maintainer's solution.

The background is ,I intended to package caffe, its build 
system is just make. 

In short if I got a source tree like this:

.
./src
./src/Makefile
./src/hello.c
./Makefile
./lib
./lib/Makefile
./lib/sharedlib.c
./lib/sharedlib.h

And I'd like to package it as following:

package: hello
  depends: libsharedlib1
package: libsharedlib1
  NOTE: libsharedlib1 has no SONAME
package: libsharedlib-dev

Let's assume ./src/Makefile is:

$ cat Makefile.bak 
main: hello

hello.o: hello.c
$(CC) -g -c -Wall hello.c
hello: hello.o
$(CC) -g -o hello hello.o ../lib/libsharedlib.so --NOTICE
clean:
-rm hello *.o

I got stuck here:

$ ldd hello
[...]
../lib/libsharedlib.so (0x7f400a08e000) --NOTICE
[...]

However I'm going to install hello to /usr/bin, libsharedlib.so to
/usr/lib/libsharedlib.so.X
So the generated hello is not installable.

The question is, how to get hello linked to /usr/lib/libsharedlib.so,
since in fact that lib is located at $(CUDIR)/../lib/libsharedlib.so?

Thank you!

[1]http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1434096674.24847.25.ca...@gmail.com

Re: Avoiding linking with /home/packaging/X/libxx.so

[lumin]

Hi mentors,

 
 That's not the unusual way to link to a shared library. You should use
 something like:
 
   $(CC) -g -o hello hello.o -L../lib/ -lsharedlib
 
 (Although it would probably only work if the library had a SONAME.)

I did an experiment. Had the rpath issue fixed, the build result seems
to be far much better! and no any ELF contains RPATH after modifying 
upstream Makefile (full quilt patch attached as [01-*.patch]).

I installed the experimentally built packages, and they works well.

$ readelf -d libcaffe.so.0 
0x000e (SONAME)  Library soname: [libcaffe.so.0]
$ readelf -d caffe.bin 
0x0001 (NEEDED)  Shared library: [libcaffe.so.0]
$ ldd caffe.bin   | grep caffe
libcaffe.so.0 = /usr/lib/libcaffe.so.0 (0x7f8e1d222000)

1. I added SONAME for shlib, changing upstream makefile.
it is implemented by a hack:

 44 +   #$(Q)$(CXX) -shared -o $@ $(OBJS) $(LINKFLAGS) $(LDFLAGS)
$(DYNAMIC_FLAGS)
 45 +   echo $(CXX) -shared -o $@ $(OBJS) $(LINKFLAGS) $(LDFLAGS)
$(DYNAMIC_FLAGS) \
 46 +   -Wl,-soname,$(SONAME)  build_so.sh
 47 +   sed -i -e 's/-pie//g' build_so.sh
 48 +   sh build_so.sh
 49 +   sh -c cd $(LIB_BUILD_DIR); ln -s $(SONAME) libcaffe.so

it looks weird, but I didn't find the source of '-pie' option,
in order to remove -pie option, so used a dirty hack.
if I don't remove -pie, g++ would complain: cannot find
reference to
main , such thing. then failed to build.
this dirty hack works very well.

2. In upstream Makefile, I replaced -rpath with -L$(..). globally,
   e.g.

 80  $(TOOL_BINS): %.bin : %.o | $(DYNAMIC_NAME)
 81 @ echo CXX/LD -o $@
 82 $(Q)$(CXX) $ -o $@ $(LINKFLAGS) -l$(PROJECT) $(LDFLAGS) \
 83 -   -Wl,-rpath,$(ORIGIN)/../lib
 84 +   -L$(ORIGIN)/$(LIB_BUILD_DIR)/

 * Andrey Rahmatullin w...@debian.org, 2015-06-12, 14:31:
 SONAMEs, not paths, are added to DT_NEEDED.
 
 Technically, you can put (both relative and absolute) paths in
 DT_NEEDED, not only SONAMEs. The dynamic linker is happy to use such
 DT_NEEDED entries. It's a terrible idea, though. :-)

Well, now I added SONAME, and the test build looks very good.
Now I can continue with my ITP.
FYI: I also attached (experimental)rules and (experimental)control,
if someone is interested.

Thank you all for answering my questions :-)

-- 
Regards,
  C.D.Luminate
Fix rpath issue in upstream Makefile
--- a/Makefile
+++ b/Makefile
@@ -1,3 +1,7 @@
+# start debian
+SONAME := libcaffe.so.0
+Q :=
+# end debian
 PROJECT := caffe
 
 CONFIG_FILE := Makefile.config
@@ -31,7 +35,7 @@
 # The target shared library name
 LIB_BUILD_DIR := $(BUILD_DIR)/lib
 STATIC_NAME := $(LIB_BUILD_DIR)/lib$(PROJECT).a
-DYNAMIC_NAME := $(LIB_BUILD_DIR)/lib$(PROJECT).so
+DYNAMIC_NAME := $(LIB_BUILD_DIR)/$(SONAME)
 
 ##
 # Get all source files
@@ -255,7 +259,7 @@
 	# boost::thread is called boost_thread-mt to mark multithreading on OS X
 	LIBRARIES += boost_thread-mt
 	# we need to explicitly ask for the rpath to be obeyed
-	DYNAMIC_FLAGS := -install_name @rpath/libcaffe.so
+	DYNAMIC_FLAGS := -Wl,-soname,$(SONAME)
 	ORIGIN := @loader_path
 else
 	ORIGIN := \$$ORIGIN
@@ -443,7 +447,7 @@
 	@ echo CXX/LD -o $@ $
 	$(Q)$(CXX) -shared -o $@ $(PY$(PROJECT)_SRC) \
 		-o $@ $(LINKFLAGS) -l$(PROJECT) $(PYTHON_LDFLAGS) \
-		-Wl,-rpath,$(ORIGIN)/../../build/lib
+		-L$(ORIGIN)/$(LIB_BUILD_DIR)/
 
 mat$(PROJECT): mat
 
@@ -506,7 +510,12 @@
 
 $(DYNAMIC_NAME): $(OBJS) | $(LIB_BUILD_DIR)
 	@ echo LD -o $@
-	$(Q)$(CXX) -shared -o $@ $(OBJS) $(LINKFLAGS) $(LDFLAGS) $(DYNAMIC_FLAGS)
+	#$(Q)$(CXX) -shared -o $@ $(OBJS) $(LINKFLAGS) $(LDFLAGS) $(DYNAMIC_FLAGS)
+	echo $(CXX) -shared -o $@ $(OBJS) $(LINKFLAGS) $(LDFLAGS) $(DYNAMIC_FLAGS) \
+		-Wl,-soname,$(SONAME)  build_so.sh
+	sed -i -e 's/-pie//g' build_so.sh
+	sh build_so.sh
+	sh -c cd $(LIB_BUILD_DIR); ln -s $(SONAME) libcaffe.so
 
 $(STATIC_NAME): $(OBJS) | $(LIB_BUILD_DIR)
 	@ echo AR -o $@
@@ -537,19 +546,22 @@
 		| $(DYNAMIC_NAME) $(TEST_BIN_DIR)
 	@ echo CXX/LD -o $@ $
 	$(Q)$(CXX) $(TEST_MAIN_SRC) $(TEST_OBJS) $(GTEST_OBJ) \
-		-o $@ $(LINKFLAGS) $(LDFLAGS) -l$(PROJECT) -Wl,-rpath,$(ORIGIN)/../lib
+		-o $@ $(LINKFLAGS) $(LDFLAGS) -l$(PROJECT) \
+		-L$(ORIGIN)/$(LIB_BUILD_DIR)/
 
 $(TEST_CU_BINS): $(TEST_BIN_DIR)/%.testbin: $(TEST_CU_BUILD_DIR)/%.o \
 	$(GTEST_OBJ) | $(DYNAMIC_NAME) $(TEST_BIN_DIR)
 	@ echo LD $
 	$(Q)$(CXX) $(TEST_MAIN_SRC) $ $(GTEST_OBJ) \
-		-o $@ $(LINKFLAGS) $(LDFLAGS) -l$(PROJECT) -Wl,-rpath,$(ORIGIN)/../lib
+		-o $@ $(LINKFLAGS) $(LDFLAGS) -l$(PROJECT) \
+		-L$(ORIGIN)/$(LIB_BUILD_DIR)/
 
 $(TEST_CXX_BINS): $(TEST_BIN_DIR)/%.testbin: $(TEST_CXX_BUILD_DIR)/%.o \
 	$(GTEST_OBJ) | $(DYNAMIC_NAME) $(TEST_BIN_DIR)
 	@ echo LD $
 	$(Q)$(CXX) $(TEST_MAIN_SRC) $ $(GTEST_OBJ) \
-		-o $@ $(LINKFLAGS) $(LDFLAGS) -l$(PROJECT) -Wl,-rpath,$(ORIGIN)/../lib
+		-o $@ $(LINKFLAGS) $(LDFLAGS) -l$(PROJECT) \
+		-L$(ORIGIN)/$(LIB_BUILD_DIR)/
 
 # Target 

Re: Avoiding linking with /home/packaging/X/libxx.so

[lumin]

Hi Andrey Rahmatullin,

NOTE: libsharedlib1 has no SONAME
 If it has no SONAME then this won't work. Shared libraries should have
 SONAMEs (also, where that 1 does come from then?).

Well, upstream doesn't set SONAME, and ..
if I just put .so libs together with executables into into a 
binary package, can I omit the absence of SONAME ?

  [...]
  ../lib/libsharedlib.so (0x7f400a08e000) --NOTICE
 Is this a problem? ldd resolves paths at the run time.

I didn't know this before.
After build I noticed that:

$ ldd caffe | grep libcaffe
libcaffe.so
= /home/lumin/hdd/caffe/.build_release/tools/./../lib/libcaffe.so 
(0x7fb4c816)

To my surprise after I installed this executable to /usr/bin:

$ ldd caffe.bin  | grep libcaffe
libcaffe.so = /usr/bin/./../lib/libcaffe.so
(0x7fa36300f000)

Now I realized that, this is not a problem ...

 If it has rpath set then you should fix that. Otherwise it's not clear if
 the problem really exists as your example is artificial and doesn't show
 real things.

My problem in the original post was resolved.
And, I'm confused with the meaning of rpath set ... fix that,
the Makefile of caffe indeed uses many -rpath options, e.g.

553 $(TOOL_BINS): %.bin : %.o | $(DYNAMIC_NAME)
554 @ echo CXX/LD -o $@
555 $(Q)$(CXX) $ -o $@ $(LINKFLAGS) -l$(PROJECT) $(LDFLAGS)
\
556 -Wl,-rpath,$(ORIGIN)/../lib

Is there any problem with -rpath that needs a fix ?

FYI: software caffe is available at:
https://github.com/BVLC/caffe

  The question is, how to get hello linked to /usr/lib/libsharedlib.so,
  since in fact that lib is located at $(CUDIR)/../lib/libsharedlib.so?
 There is no such thing. SONAMEs, not paths, are added to DT_NEEDED. If you
 mean rpath that's another question and it depends on your build system,
 among other things.

Got it. Now I know the lib path is not just a static string embedded
into ELFs ... I'm not familiar with ld.so's mechanism.

Thank you :-)

-- 
lumin cdlumin...@gmail.com


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1434122160.2131.42.ca...@gmail.com

Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)

[lumin]

On Wed, 2015-05-27 at 09:27 +0200, Xfennec wrote:
 Is such a name is
 available within Debian ?

The good news is, the name progress as an executable is 
available in Debian.

$ apt-file search progress |  grep /bin

debconf: /usr/bin/debconf-apt-progress
fastdnaml: /usr/lib/fastdnaml/bin/dnaml_progress
goto-fai-progress: /usr/bin/fai-progress
kdesdk-scripts: /usr/bin/build-progress.sh
pcl-tools: /usr/bin/pcl_progressive_morphological_filter
videotrans: /usr/bin/movie-progress

and there's no sbin named progress, as expected.
So may I use *progress* as cv's *package name* and *excutable name* ?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432721780.3365.4.ca...@gmail.com

Bug#790957: RFS: fortune-zh/2.0 -- Chinese Data files for fortune

[lumin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: a...@debian.org

lintian: clean

Dear mentors,

  I am looking for a sponsor for my package fortune-zh

 * Package name: fortune-zh
   Version : 2.0
   Upstream Author : Debian Chinese Team
 * URL : http://anonscm.debian.org/gitweb/?p=chinese/fortune-zh.git
 * License : GPL
   Section : games

  It builds those binary packages:

fortune-zh - Chinese Data files for fortune

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

http://mentors.debian.net/package/fortune-zh

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

dget -x 
http://mentors.debian.net/debian/pool/main/f/fortune-zh/fortune-zh_2.0.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

fortune-zh (2.0) unstable; urgency=low

  * New 2.X release.
  * Add many new Chinese Culture data files:
- chinese.d/
  * Update debian/copyright
- Add myself
- Add the source of new contents
  * Record the significant change of fortune-zh 2.0 in README.debian
  * Update fortune-zh (new cookie file) with new options.
  * Update package description.
- debian/control
  * Update manpage describing some new features of 2.X
  * Fix invalid encodings in tang300 (LP: #499664)
  * Simplify Makefile, removing redundant lines.
  * Remove .u8 symlinks, and Create a fortune-zh.links to substitude them.



  Regards,
   Zhou Mo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1435918328.15634.8.ca...@gmail.com

Re: why dpkg-buildpackage doesn't care my build targets in debian/rule

[lumin]

I got it.

Thank you,
 Santiago, Jakub, Johannes, Mattia and Wookey !

:)
-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432439429.7146.3.ca...@gmail.com

why dpkg-buildpackage doesn't care my build targets in debian/rule

[lumin]

Hi mentors,

I'm trying to package caffe as said [1] at debian-science@ .
However I encountered a problem when writing debian/rules.

I'd like to take over the whole build process, so I wrote:

 32 override_dh_auto_build: build_cpuonly
 33 
 34 build_cpuonly: config_cpuonly
 35 $(shell debian/my/00-fix-caffe-include-path-debian.sh)
 36 $(MAKE) -j4 all
 37 $(MAKE) -j4 test
 38 $(MAKE) runtest
 39 
 40 config_cpuonly:
 41 cp debian/my/Makefile.config.cpuonly Makefile.config
 42 
 43 .PHONY: config_cpuonly build_cpuonly

in file debian/rules.
Then I tested it with

$ dh build

It works fine, but when I test the rules file with

$ dpkg-buildpackage -us -uc

the dpkg-buildpackage ignored my build process,
because target all depends on the file Makefile.config which is
generated by target config_cpuonly, and dpkg-buildpackage 
doesn't run config_cpuonly target.

I'm very confused about it.
Well, maint-guide says so:

Then you issue the following command in the source directory:
$ dpkg-buildpackage -us -uc
This will do everything to make full binary and source packages
for you. It will:
[...]
build the program (debian/rules build) 
ATTENTION!
[...]

The highlighted line means

debian/rules build  -- dh build

That is to say, $ dh build works, while 
dpkg-buildpackage --
debian/rules build --
dh build
doesn't work.

HOW SHOULD THE WEIRD THING HAPPEN?

[1] https://lists.debian.org/debian-science/2015/05/msg00024.html


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432218658.976.18.ca...@gmail.com

Re: why dpkg-buildpackage doesn't care my build targets in debian/rule

[lumin]

Hi,

I modified the debian/rules[1] according to 
Santiago and Jakub (thank you both!),
and tested again. The result was the same.

dh build works while dpkg-buildpackage doesn't.

[1] --- the whole debian/rules
  1 #!/usr/bin/make -f
  2 # See debhelper(7) (uncomment to enable)
  3 # output every command that modifies files on the build system.
  4 DH_VERBOSE = 1
  5 
  6 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/*
  7 DPKG_EXPORT_BUILDFLAGS = 1
  8 include /usr/share/dpkg/default.mk
  9 
 10 # main packaging script based on dh7 syntax
 11 %:
 12 dh $@ 
 13 
 14 # debmake generated override targets
 15 override_dh_auto_build:
 16 cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
 17 debian/my/00-fix-caffe-include-path-debian.sh
 18 $(MAKE) all
 19 $(MAKE) test
 20 $(MAKE) runtest
-end debian/rules--


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432252944.5003.6.ca...@gmail.com

Re: why dpkg-buildpackage doesn't care my build targets in debian/rule

[lumin]

Hi mentors,

I solved this problem, after line-by-line reviewing the
screen output of those commands.

It turns out that, the clean target of Makefile
needs the Makefile.config too.

this rules file makes dpkg-buildpackage continue building.
(I deleted some comments )
---
#!/usr/bin/make -f
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk

%:
dh $@ 

override_dh_auto_clean:
cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
dh_auto_clean
# without following line the the source tree 
# would be not clean. Hence dpkg-buildpackage
# refuse to build.
rm Makefile.config  

override_dh_auto_build:
# well. let's copy config back again.
cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
debian/my/00-fix-caffe-include-path-debian.sh
$(MAKE) all
$(MAKE) test
$(MAKE) runtest
-

 It's hard to tell what went wrong without seeing complete d/rules, or at
 least complete build log. I guess the bug lies in the part of
 debian/rules you snipped.

Thank you Jakub for the hint.
However my snipped part of rules was fine, the problem is,
I didn't notice the need of Make clean for a Makefile.config.
Therefore dpkg-buildpackage aborted at 

dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build caffe-20150521~rc2
 fakeroot debian/rules clean
dh clean ---  currently no Makefile.config, abort.

rather than dh build.
-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432269094.2378.17.ca...@gmail.com

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi Gianfranco Costamagna,

On Mon, 2015-08-17 at 08:27 +, Gianfranco Costamagna wrote:
 yes, exactly the point I had, so somewhere the user should be aware that 
 reporting
 the bug on Debian Bug Tracking System is *wrong*.

 and here we are:
 how do you say that to the user?
 You say overriding the env is bad, but you didn't provide (AFAICS) a good way 
 for letting
 the user know about the profile

I didn't mean overriding the env is bad. I mean:
 - can we directly add ENVs for users?
  - how about doing this in wrapper script:
 sed -i -e $a\$(cat /usr/share/.../example/profile) .bashrc
   - very bad.
Then can ENVs be handled automatically?

Then there are 2 things to convey to linuxbrew-wrapper users:

 * linuxbrew packaging bug is not debian bug but upstream bug,
   report linuxbrew bug at upstream github.

 * there's a example profile located at
 /usr/share/doc/linuxbrew-wrapper/examples/profile
   and one can simply source it in bashrc/zshrc for the basic
   linuxbrew utilization. If user installed some libs with
   linuxbrew, he/she needs to handle BREW_LIB BREW_INCLUDE
   LD_LIBRARY_PATH ...etc ENVs.

And I'm going to state them

 * before invoking upstream install script
 * in the manpage which is to be added.

Is there better way to tell the 2 points to users ?

 * postinst ? *.News ?

 this is fine, as long as you set RPATH on the linuxbrew packages, or you
 LD preload in some way the binary at each run

LD_LIBRARY_PATH / RPATH:
IMHO LD_LIBRARY_PATH is better, since rpath is a problem
on Debian packaging and RPATH info is embedded into ELFs.

 Note: I didn't run the code, because I think some discussion is needed, at 
 least on debian-devel to see
 other folks's opinions.

I think so. however
currently this package is not ready to get public attention.
At lease I need to compose a manpage to state the main idea
of this package.

 I know very well the subject, and actually I did something brew similar in my 
 work company, to keep our
 installing them in a private location, to avoid messing up with users systems 
 and messing up with different versions 
 
 of our libraries (a customer might do not want to rebuild against a new 
 library version, if the old one
 fits the needs for him).
 
 The problem here is that using non-standard locations is source of troubles, 
 but I see you/brew fixed them
 in the proper way (at least the same way I fixed them in my workplace).

I'm glad to hear that.

 If other DDs gives an ack I'll be happy to finish my review :)

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


signature.asc
Description: This is a digitally signed message part

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi Gianfranco Costamagna,

On Thu, 2015-08-13 at 11:53 +, Gianfranco Costamagna wrote:
 General Note: I don't think I'll sponsor this package without a discussion on 
 debian-devel mail list, 
 
 because I do not honestly think we need another package management, specially 
 because
 mixing stuff might lead to libraries incompatibilities, and something more.

Well... not going to bring trouble to apt/dpkg.

Since linuxbrew is by default a home-based pacakge management tool,
it is useful e.g when a group of people are working on the same
amd64 workstation and some of them have no root/sudo access.
In that circumstance, one can conveniently run brew install
to install package they want without bothering root/admin much,
as long as brew has that corresponding formula.

So I think utilizing linuxbrew is just a matter what user do
at his ${HOME}, and will not affect the system wide package management,
After all the changes linuxbrew made is just in the `${HOME}/.linuxbrew` .

 Do you install something in non-standard directories so there is no need of 
 looking at this?
 (note: I used too few times homebrew to know it)
 (I guess you install on HOMEBREW_PREFIX and ~/.linuxbrew if I read correctly 
 the code)

No, no installation into non-standard directory.
FYI this is the current dpkg -L linuxbrew-wrapper:

/.
/usr
/usr/lib
/usr/lib/linuxbrew
/usr/lib/linuxbrew/install
/usr/bin
/usr/bin/linuxbrew
/usr/share
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/linuxbrew-wrapper
/usr/share/doc
/usr/share/doc/linuxbrew-wrapper
/usr/share/doc/linuxbrew-wrapper/copyright
/usr/share/doc/linuxbrew-wrapper/README.Debian
/usr/share/doc/linuxbrew-wrapper/changelog.Debian.gz
/usr/bin/brew - /usr/bin/linuxbrew

Where the /usr/bin/linuxbrew is exactly the wrapper script,
it
 1. run the real linuxbrew if linuxbrew is already at user's home.
 2. run the upstream install script if user invoked 'brew' and
then the wrapper script found no existing linuxbrew.

By default the HOMEBREW_PREFIX is pointed to ${HOME}/.linuxbrew
however I think I should provide a way to override it.

 BTW, you should also try to patch cmake to look at the new directories, at 
 least when it
 isn't run in a buildd system.

Sorry that I'm not following you here:
there is no cmake files both in the original linuxbrew git repo 
and the wrappe package.

Do you mean adding cmake files in the package ?

 anyway, let's review:
 1) d/changelog:
 UNRELEASED is not an acceptable pocket distribution.

I will do dch -r when confirmed that this package is really ready
to be uploaded.

[...]
 3) please add a manpage (help2man might help as a starting point)

Yes, indeed I should provide a manpage for /usr/bin/linuxbrew
and merly override the lintian-missing-manpage of symlink /usr/bin/brew.

 4) add a real watch file or remove it completely

I'm going to remove it.

 5) copyright: I do not like GPL-3.0+, maybe 2.0+ might be better, and usually 
 it is considered
 a good copyright the one that is the same as upstream, because otherwise you 
 might not be able
 to forward Debian patches upstream (like in this case, GPL-3+ means you can't 
 redistribute
 as BSD-2-clause without an explicit written permission, even if I didn't 
 check right now
 the above, and IANAL)
[...]

Thank you Gianfranco Costamagna for reviewing this package!
:-)

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


signature.asc
Description: This is a digitally signed message part

Bug#794187: closed by Gianfranco Costamagna costamagnagianfra...@yahoo.it (uploaded on new queue)

[lumin]

Oops That package is good except for one thing:

 the issue comes from patch:   add-license-info.patch

The patch is patching author's source files with author's original
copyright declaration in the global LICENSE file and the one
in head of progress.c . The patch was sent to author days ago
and we (Asias and me) are waiting for author to reply.

Asias told me that to be extremely careful about license,
hence this patch is not serious, when shipped with debian package...

well...

On Tue, 2015-08-18 at 08:24 +, Debian Bug Tracking System wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the sponsorship-requests package:
 
 #794187: RFS: progress/0.8-1 [ITP] (it is formerly known as 'cv'))
 
 It has been closed by Gianfranco Costamagna costamagnagianfra...@yahoo.it.
 
 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Gianfranco Costamagna 
 costamagnagianfra...@yahoo.it by
 replying to this email.
 
 



signature.asc
Description: This is a digitally signed message part

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi Gianfranco Costamagna,

I have just uploaded a updated package to mentors several seconds ago,
and I will CC you later in the d-devel discussion.

On Tue, 2015-08-18 at 08:09 +, Gianfranco Costamagna wrote:
 d/changelog should mention only initial release (closes: #) and nothing 
 more.

If I don't write them in dch, even I will forget what I've done to
the package months later. 

Policy chapter 4.4 said so:

 Changes in the Debian version of the package should be briefly explained in 
the Debian changelog file debian
 /changelog. This includes modifications made in the Debian package compared to 
the upstream one as well as other
 changes and updates to the package. 

So I realized that I really wrote some unnecessary things into dch.

 debian/linuxbrew-wrapper.lintian-overrides
 useless now?

It's still useful.
I symlink'ed wrapper script /usr/bin/linuxbrew to /usr/bin/brew,
and I provided a manpage for linuxbrew-wrapper(7) and symlinked it to
linuxbrew(7).

Then lintian still requires a manpage for /usr/bin/brew,
and this is to be overrided. After pulling a full linuxbrew repo
to home, there will be a manpage brew(1) in it. 

 debian/copyright, please rethink the GPL-3+ Debian license (not mandatory, 
 but it might be good to clarify

I have changed Debian license to GPL-2. 

FYI: the packaging repo is located at
http://anonscm.debian.org/cgit/users/cdluminate-guest/linuxbrew-wrapper.git/
-- 
 .''`.   Lumin
: :' : 
`. `'   
  `-638B C75E C1E5 C589 067E  35DE 6264 5EB3 5F68 6A8A


signature.asc
Description: This is a digitally signed message part

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi Gianfranco Costamagna,

On Sun, 2015-08-16 at 07:26 +, Gianfranco Costamagna wrote:
 yes, this is not a problem, and this is already done locally (manually) by 
 many
 folks.
 
 But who will take care of packaging bug x for package y installed with 
 linuxbrew?

Such packaging bug is upstream bug, and is handled by Homebrew 
and Linuxbrew upstream. And files made that trouble was not provided
by Debian package ..

After the Linuxbrew maintainer updated linuxbrew or fixed bugs
of linuxbrew, users run brew update to trigger git to pull
updated contents.

 as a maintainer I would like to avoid people opening bugs against my packages
 if the bugs are in the linuxbrew packaging recipes.

I think the same with you, as the problem is from files that lives
outside of Debian package.

 I meant, where brew install x will put the x installed files?

Well, here is an example which installs openssl with linuxbrew:

$ brew list openssl
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/bin/c_rehash
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/bin/openssl
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/include/openssl/ (75 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/lib/engines/ (12 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/lib/pkgconfig/ (3 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/lib/ (6 files)
/home/lumin/.linuxbrew/Cellar/openssl/1.0.2d_1/share/man/ (1542 files)

Contents of every package installed by linuxbrew are stored at
.linuxbrew/Cellar/ and are separated by package name:

$ pwd
/home/lumin/.linuxbrew/Cellar
$ ls -F
jpeg/  makedepend/  openssl/  pkg-config/  unzip/  zlib/

Besides, linuxbrew will symlink executables, libs, dev-files into
.linuxbrew/{bin,lib,include} directories, e.g.

.linuxbrew/lib $ ls -Fl

total 4
lrwxrwxrwx 1 lumin lumin   38 Aug 17 05:27 engines - 
../Cellar/openssl/1.0.2d_1/lib/engines/
lrwxrwxrwx 1 lumin lumin   12 Aug 17 06:20 libcanyoufindme.so - libcrypto.so
lrwxrwxrwx 1 lumin lumin   12 Aug 17 06:19 libccrr.so - libcrypto.so
lrwxrwxrwx 1 lumin lumin   42 Aug 17 05:27 libcrypto.a - 
../Cellar/openssl/1.0.2d_1/lib/libcrypto.a
lrwxrwxrwx 1 lumin lumin   43 Aug 17 05:27 libcrypto.so - 
../Cellar/openssl/1.0.2d_1/lib/libcrypto.so
lrwxrwxrwx 1 lumin lumin   49 Aug 17 05:27 libcrypto.so.1.0.0 - 
../Cellar/openssl/1.0.2d_1/lib/libcrypto.so.1.0.0

 You install a library x, and you want to link with your code z,
 how do you make your build system aware of x location?
 
 assuming x is installed somewhere in home/.linuxbrew/.apps/x/usr/lib/libx.so

We can confirm that GCC and LD with default configuration 
will never grab user's home for headers and libs except specified.
Hence in order to make build system aware of x location,
we must pass -I -L -l arguments to compilers.

Please take a look at this example profile added several minutes ago:
http://anonscm.debian.org/cgit/users/cdluminate-guest/linuxbrew-wrapper.git/tree/debian/example/profile
This is my idea for handling that issue.

For example if I want to compile a small program [1], which
should be linked with brew-installed openssl:

$ source that example profile
$ gcc md5bin.c -I$BREW_INCLUDE -L$BREW_LIB -lcanyoufindme
( here I symlinked libcanyoufindme.so - libcrypto.so to )
( make sure it is not linked with my system openssl. )

And it just works.
the wrapped BREW_LIB and BREW_INCLUDE are more convenient
than hardcoded -L -l and -I arguments.

 Do the user need to override build flags to make x found by the compiler?

As following example, users should append extra flags to compiler,
and the way showed above is currently the simplest way I know.

 Nope, I mean the answer above. Installing a user package is fine, just 
 install it
 and find the binary file to run it
 
 Installing a library is not so trivial, because you need to make your compiler
 aware of the location and use it.

With this wrapper the only thing user need to do is to add ENV into there
.bashrc .zshrc or profile. (sed'ing user's rc files is extremely bad)
the BREW_INCLUDE and BREW_LIB is my solution on this library problem.

 Thanks to you for packaging it!

Just for fun :-)
Please note that, the updated package was uploaded to mentors:
http://mentors.debian.net/package/linuxbrew-wrapper
http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc

 I really would like to have something brew similar to linux,
 but I would like to create a mess for other packages, and screw
 up the user system :)

Maybe even worse when making Linux From Scratch ...

Thank you Gianfranco Costamagna :-)


[1] small program which need libcrypto.so from openssl

#include unistd.h
#include stdlib.h
#include string.h
#include openssl/md5.h

int
main (int argc, char **argv)
{
char md[16];
unsigned char * string = Debian;
MD5 (string, strlen(string), (unsigned char *)md);
write (1, md, 16);
return 0

Bug#794187: RFS: progress/0.7.1~git20150730+9c31d02b65-1 [ITP] (it is formerly known as 'cv')

[lumin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package progress

 * Package name: progress
   Version : 0.7.1~git20150730+9c31d02b65-1
   Upstream Author : Xfennec xfen...@cqfd-corp.org
 * URL : https://github.com/Xfennec/progress
 * License : GPL-3.0+
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.7.1~git20150730+9c31d02b65-1.dsc


  Changes since the last upload:

progress (0.7.1~git20150730+9c31d02b65-1) unstable; urgency=low

  * Initial release. Closes: #785425
  * Fix manpage syntax error.

Regards,
  Zhou Mo


signature.asc
Description: This is a digitally signed message part

Bug#794187: RFS: progress/0.8-1 [ITP] (it is formerly known as 'cv'))

[lumin]

Control: retitle 794187 RFS: progress/0.8-1 [ITP] (it is formerly known as 
'cv'))

Dear mentors,

I'v fixed lintian warning after the last time upload to mentors.
Now package progress_0.8-1 is lintian clean.

  I am looking for a sponsor for my package progress

 * Package name: progress
   Version : 0.8-1
   Upstream Author : Xfennec xfen...@cqfd-corp.org
 * URL : https://github.com/Xfennec/progress
 * License : GPL-3.0+
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.8-1.dsc

  Last upload is version 0.7.1~git...+..., and its source ships an compiled ELF
  which is a mistake of upstream. Importing version 0.8 removes that ELF file,
  hence source tree clean.

  Changes since the last upload:

progress (0.8-1) UNRELEASED; urgency=low

  * Initial release. Closes: #785425
  * Fix manpage syntax error.
  * Imported upstream version 0.8
  * Fix upstream Makefile
+ Append LDFLAG to LFLAG, for hardening.


  Regards,
   Zhou Mo



signature.asc
Description: This is a digitally signed message part

Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi mentors,

Weeks ago I intended to package linuxbrew,
the missing package manager, which is a fork of Homebrew (Mac OS X).

Linuxbrew it's Formula update is managed by git,
hence initially I found it tricky to manage original linuxbrew
with gbp tools, for these reason:

 * if original linuxbrew (including its Formulas) is provided,
   the dquilt will fall into a tough situation. that is to say,
   if I patched the upstream linuxbrew, then when user's about
   to run
 $ brew update
   then the git will complain the dquilt patched linuxbrew is dirty,
   that is bad.
 * security issues are handled by upstream, and it's update
   period is much faster than debian package upload period.

Maybe it's not wise to provide the whole, original linuxbrew,
and providing just a wrapper package is better, since that
will be easy to maintain. After a discussion [1] with linuxbrew
maintainer I think providing just a wrapper package is
the best solution.

The wrapper package I refered was already uploaded to mentors[2],
but I don't know if this is proper, so I didn't file RFS.

You can get the source here:
http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc

The wrapper package includes:
 
 1. the (ruby) install script from upstream
 2. a shell wrapper for linuxbrew wrote by myself

Any advice ?
Thank you :-)

The ITP of linuxbrew is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792642


[1] https://github.com/Homebrew/linuxbrew/issues/495
[2] http://mentors.debian.net/package/linuxbrew-wrapper
-- 
 .''`.   Lumin
: :' : 
`. `'   
  `-638B C75E C1E5 C589 067E  35DE 6264 5EB3 5F68 6A8A


signature.asc
Description: This is a digitally signed message part

delete unsafe symlink with dquilt

[lumin]

Hi mentors,

I'm preparing the linuxbrew package for Debian [1],
and found it hard to remove 2 troublesome symlinks from upstream
source. 

Lintian complains that

 E: linuxbrew source: source-contains-unsafe-symlink 
  Library/ENV/pkgconfig/fuse/fuse.pc

 They are:
 ~/hdd/debian/linuxbrew/Library/ENV/pkgconfig/fuse$ file *
 fuse.pc:broken symbolic link to /usr/local/lib/pkgconfig/fuse.pc
 osxfuse.pc: broken symbolic link to /usr/local/lib/pkgconfig/osxfuse.pc

So I followed [2] adding a dquilt patch to remove them.
However dquilt just gave adding the deadlink.

 $ dquilt add Library/ENV/pkgconfig/fuse/fuse.pc 
 Cannot add symbolic link Library/ENV/pkgconfig/fuse/fuse.pc

Man quilt says

  quilt add

has just one option available:

  -P patchPatch to add files to.

Goswin von Brederlow  It is probably better to simply remove the
Goswin von Brederlow  files in the clean target.

However I tried it and it doesn't prevent this lintian source ERROR.
Any idea to handle this situation properly?

Thanks :-)

[1] http://anonscm.debian.org/cgit/users/cdluminate-guest/linuxbrew.git/
[2] https://lists.debian.org/debian-mentors/2011/06/msg0.html



signature.asc
Description: This is a digitally signed message part

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

On Tue, 2015-08-25 at 09:54 +, Gianfranco Costamagna wrote:
 1) I did a buildinstall of the package, and I can't make it work
 
 
 
 brew install cmake
 brew
 brew --help
 linuxbrew --help
 
 returns nothing

Oops...Sorry for that...
By mistake I introduced this bug into the wrapper script.
Patch [1] fixes this bug. And it was fixed in the freshly uploaded
mentor package.

The first time running brew should be similar as following:

$ brew
Maybe you are the first time running brew/linuxbrew,
here are some hints:
* Modify your PATH,MANPATH,INFOPATH environment to utilize software
  installed by linuxbrew.
  + See example file /usr/share/doc/linuxbrew/examples/profile

== This script will install:
/home/lumin/.linuxbrew/bin/brew
/home/lumin/.linuxbrew/Library/...
/home/lumin/.linuxbrew/share/man/man1/brew.1

Press RETURN to continue or any other key to abort

 2) man brew doesn't work, man linuxbrew works

Please note that, the linuxbrew installer will pull a manpage of brew
(as above /home/lumin/.linuxbrew/share/man/man1/brew.1)
into ~/.linuxbrew/share/man/man1/brew.1

And after you changed MANPATH ENV, man brew should work.
(export MANPATH=${HOME}/.linuxbrew/share/man:${MANPATH})

And hence I provided no manpage for `brew` but only `linuxbrew`,
and overrode the lintian missing-manpage /usr/bin/brew
(/usr/bin/brew is symlink - /usr/bin/linuxbrew),
avoiding conflict with pulled brew manpage.

 3) looking at the source, in first_time_hint the example file have a wrong 
 location
 + See example file /usr/share/doc/linuxbrew/examples/profile

And this is another packaging bug, which is remained 
when I changed package name from linuxbrew to 
linuxbrew-wrapper.

I have wrote wrong path in linuxbrew-wrapper.install:

 debian/bin/linuxbrew   usr/bin/
-installusr/lib/linuxbrew/
+installusr/lib/linuxbrew-wrapper/
 
 maybe you mean
 
 /usr/share/doc/linuxbrew-wrapper/examples/profile
 
 (and that function is never called on my system)

Not being called is a BUG, and I've fixed it and tested it
as said above.

 4) I see an install file, but it has no +x, so it can't be run
 sudo chmod +x /usr/lib/linuxbrew/install
 
 shouldn't the end user know that he needs to manually run the installation?

That install script should be automatically invoked by wrapper script
/usr/bin/linuxbrew. And letting users to manually run that script
is not what I want, since that way is always available.

Now the wrapper script BUG is fixed, and users the first time
run brew will see the install process is automated.

My local built latest package ships an `/usr/lib/linuxbrew-wrapper/install`
with (0755/-rwxr-xr-x). I don't know what happend
rendering your /usr/lib/linuxbrew-wrapper/install lost the read mode.

I installed that file in linuxbrew-wrapper.install:
install  usr/lib/linuxbrew-wrapper/

Maybe I should add somthing into d/rules to make sure 
that install script is installed with r mode?

Additionally, the wrapper script /usr/bin/linuxbrew is designed to
be able to accept a install script without r mode, and it runs
 ruby $INSTALL
to do that install process.

 after running install almost everything works as expected, so maybe its just
 a matter of tweaking the script for some bits, and setting the +x to the file
 (after mentioning $somewhere that it needs to be run).
 
 What about doing that in a postinst script?

Invoke it in postinst is not proper, I believe.

 (sorry for this late mail, but I usually install stuff only when packaging
 looks good to me :) )

 BTW I'm installing cmake right now :) (with all the ton of build-dependencies)
 
 I really appreciate this software, I think Debian folks will enjoy it!

Thank you for attention to this package, and thank you
for finding so many my mistakes. I've learnt a lot
within this ITP process as it is my 3rd debian package.

The latest uploaded package, should bring you better felling :-)

[1]
diff --git a/debian/bin/linuxbrew b/debian/bin/linuxbrew
index 72f0233..308b3ee 100755
--- a/debian/bin/linuxbrew
+++ b/debian/bin/linuxbrew
@@ -62,11 +62,11 @@ elif [ -d ${LINUXBREW_PREFIX} ]; then
   printf Please check that directory.\n
   false
 elif [ -x ${BREW_INSTALL} ]; then
-  first_time_hint ()
+  first_time_hint
   exec ${BREW_INSTALL}
 elif [ -r ${BREW_INSTALL} ]; then
   if [ -x $(which ruby) ]; then
-first_time_hint ()
+first_time_hint
 ruby ${BREW_INSTALL}
   else
 printf E: found no ruby interpreter to run linuxbrew installer.\n



signature.asc
Description: This is a digitally signed message part

Bug#804343: RFS: libsvm/3.20-1 [NMU] -- library implementing support vector machines

[lumin]

Hi,

That's OK.
Please ping me if there's anything I can help.

Thanks.

On Mon, 2015-11-09 at 18:59 -0600, Chen-Tse Tsai wrote:
> Hi,
> 
> 
> Sorry for the late reply as I missed your message earlier. I'll update
> the package as soon as possible. Thanks for the help!
> 
> 
> Regards,
> Chen-Tse

Bug#804343: RFS: libsvm/3.20-1 [NMU] -- library implementing support vector machines

[lumin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for package "libsvm" for an NMU.
  (libsvm is in archive section main)

  This package has not been updated for very long time, and
  I'd like to update it. The curretly recorded maintainer
  didn't reply my email which was sent a month ago.

  Please note that, this package just passed the Debomatic build.
  http://debomatic-amd64.debian.net/distribution#unstable/libsvm/3.20-1/buildlog

 * Package name: libsvm
   Version : 3.20-1
   Upstream Author : Chih-Chung Chang and Chih-Jen Lin <cj...@csie.ntu.edu.tw>
 * URL : http://www.csie.ntu.edu.tw/~cjlin/libsvm/
 * License : http://www.csie.ntu.edu.tw/~cjlin/libsvm/COPYRIGHT
   Section : devel

  It builds those binary packages:

 libsvm-dev - LIBSVM header files
 libsvm-java - Java API to support vector machine library (libsvm.jar)
 libsvm-tools - LIBSVM binary tools
 libsvm3- library implementing support vector machines
 libsvm3-java - Java API to support vector machine library (libsvm3.jar)
 python-libsvm - Python interface for support vector machine library

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

  http://mentors.debian.net/package/libsvm

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

dget -x 
http://mentors.debian.net/debian/pool/main/libs/libsvm/libsvm_3.20-1.dsc

  Changes since the last upload:

libsvm (3.20-1) unstable; urgency=medium

  * Non-maintainer upload.
  * Import new upstream version.
  * d/control:
+ Bump standards version to 3.9.6.
+ Remove obsolete DM-Upload-Allowed field.
+ Add Vcs-Browser field.
+ Remove duplicated Homepage description. (Closes: #693889)
  * Add watch file.
  * d/rules: Bump version as new version is imported.
  * Update "d/*.install".



Regards,
   lumin

Bug#804343: RFS: libsvm/3.20-1 [NMU] -- library implementing support vector machines

[lumin]

Hi,

On Sat, 2015-11-07 at 17:21 +, Gianfranco Costamagna wrote:
> version for an NMU should be 3.20-0.1

I've fixed this locally.

> this is really out of an NMU scope, do you have any evidence about the 
> maintainer
> being MIA/not interested anymore, or acking you to upload a new release?

1. Found no activity for maintainer in the BTS.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;correspondent=ctse.t...@gmail.com

2. Found no VCS in the packaging files, so Found nowhere to
   look for clue for maintainer activity.

3. A NMU-PING was sent to the maintainer 40 days ago,
   and I have got no ack yet.
   Let me forward this mail privately to you.

4. In the d/changelog, the recorded maintainer is not active on this
   package for many years.
   
   FYI: his last upload time is Mon, 11 Jun 2012 

In summary, I deduce that the recorded maintainer is curretly not active.

> >  * d/control:
> >+ Bump standards version to 3.9.6.
> >+ Remove obsolete DM-Upload-Allowed field.
> >+ Add Vcs-Browser field.
> >+ Remove duplicated Homepage description. (Closes: #693889)
> >  * Add watch file.
> >  * d/rules: Bump version as new version is imported.
> >  * Update "d/*.install".

> this is nice for sure (and I like it), but really out of an NMU scope
> https://wiki.debian.org/NonMaintainerUpload
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

I changed the revision number from -1 to -0.1,
and want to know if there remains anything to be done,
to get the package into the NMU scope.

The updated package was uploaded to mentors,
http://mentors.debian.net/package/libsvm

Thanks ;-)

> cheers,
> 
> G.

Trouble with Alioth user repo: can't be cloned

[lumin]

Hi mentors,

I encountered this trouble when making user's personal repo
on alioth.d.o  according to the link below.
[https://wiki.debian.org/Alioth/Git]

I've set up 2 repos:
http://anonscm.debian.org/cgit/users/cdluminate-guest/caffe.git
http://anonscm.debian.org/cgit/users/cdluminate-guest/test.git
Now I can browse them with cgit, but when I was about to clone them
it just failed.

$ git clone
https://anonscm.debian.org/git/users/cdluminate-guest/caffe.git
Cloning into 'caffe'...
fatal: repository
'https://anonscm.debian.org/git/users/cdluminate-guest/caffe.git/' not
found

I checked the repo location, then 
 * do chmod -R a+xr REPO
 * check git-daemon-export-ok
 * check hook/post-update
but it still fails to  clone with the same error report.

I'm confused. 

Thanks.
-- 
Regards,
  C.D.Luminate


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1436423485.13931.7.ca...@gmail.com

Re: Trouble with Alioth user repo: can't be cloned

[lumin]

Hi Alexander Wirt,

Thank you very much, and now it works!

On Thu, 2015-07-09 at 08:58 +0200, Alexander Wirt wrote:
  I'm confused. 
 And you are right to be confused. It was a bug on our (alioth) side. 
 
 I fixed it and cloning is now possible.
 
 Alex
 
  


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1436426970.13931.9.ca...@gmail.com

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi,

On Tue, 2015-08-25 at 16:29 +, Gianfranco Costamagna wrote:
 yes I got confused by this line
 usr/share/man/man7/linuxbrew-wrapper.7.gz usr/share/man/man7/linuxbrew.7.gz

with that symlink, both

  man $PACKAGE_NAME i.e. man linuxbrew-wrapper
  man $WRAPPER_NAME i.e. man linuxbrew

work.

 I was talking about -x, not about -r.
 Since the linuxbrew wasn't calling it automatically I tried to call it 
 manually.
 But now that the bug is fixed there is no need anymore to use -x, so it is 
 fine now.

Oops, that's a typo, in fact I mean the 'x' mode, not 'r'.
After all how can the ruby interpreter interprets a ruby script
ridiculously without 'r' mode ?

 not needed anymore, it was a bug, you fixed it, it is fine :D

However I see a new lintian warning saying script-without-x-mode
at the new queue. It doesn't matter but I think I'd better get
it fixed next time upload.

 the feeling was good, BuiltSignedUploaded to new queue!
 
 thanks for your awesome contribution to Debian!

Thank you for sponsoring  checking !   :-)

 Now I have some final issues I would like to leave for a future upload:
 1) I installed it and did a 
 
 brew install cmake
 
 it installed brew correctly, but I had to run it again to properly start
 the cmake build.
 
 Maybe in the first run it shouldn't forget about the action requested?
 (not sure if a bug or a design feature)

Yes, the current wrapper script indeed drops the arguments
passed to itself, when installing linuxbrew.
(in fact pulling a git repo)

They can be merged into 1 step with this patch:
(merging them into 1 step may be better for those real first-time
 linuxbrew users)

diff --git a/debian/bin/linuxbrew b/debian/bin/linuxbrew
index 458307c..de0bbb3 100755
--- a/debian/bin/linuxbrew
+++ b/debian/bin/linuxbrew
@@ -63,11 +63,13 @@ elif [ -d ${LINUXBREW_PREFIX} ]; then
   false
 elif [ -x ${BREW_INSTALL} ]; then
   first_time_hint
-  exec ${BREW_INSTALL}
+  ${BREW_INSTALL}
+  exec ${BREW_EXEC} $@
 elif [ -r ${BREW_INSTALL} ]; then
   if [ -x $(which ruby) ]; then
 first_time_hint
 ruby ${BREW_INSTALL}
+exec ${BREW_EXEC} $@
   else
 printf E: found no ruby interpreter to run linuxbrew installer.\n
 false

 2) you might want to add a README.source or a get-orig-source target
 to explain where to grab the source code for it.
 
 e.g. I can understand the script comes from
 curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install
 
 but maybe making it under git revision, and adding a Debian pointer to it
 will allow other folks to see if updates are available or not.

The upstream install script is in linuxbrew.git branch: go
https://github.com/Homebrew/linuxbrew/blob/go/install

It has no version number, and upstream suggest that we keep
the data-based version number.

I have considered Debian pointers like the `watch` file,
however linuxbrew never releases,
(It's in the style of rolling update in terms of all linuxbrew Formulas)
So I just deleted watch file.

In order to decide that if there is a newer version of install script
available, there are 2 ways :

 * track on commits of linuxbrew.git branch 'go'
   https://github.com/Homebrew/linuxbrew/commits/go
   But I found no related function in manpage of uscan.

 * download that script and then diff,
 if differs: new version is available
 else: already updated.

Since that install script in relatively stable 
(not yet changed since Apr 24)
I don't mind to manually update check and update it.

However I think automate the process will be better
for adopters. I'm about to add related things in d/rules
next time upload.

 thanks again for packaging it and for following my boring nitpicks :)

Also thanks again for pointing them out :-)
-- 
 .''`.   Lumin
: :' : 
`. `'   
  `-638B C75E C1E5 C589 067E  35DE 6264 5EB3 5F68 6A8A

Re: Introduce wrapper package of linuxbrew into Debian

[lumin]

Hi Gianfranco Costamagna,

On Wed, 2015-08-19 at 13:07 +, Gianfranco Costamagna wrote:
 BTW the git urls are wrong:
 
 examples of good git urls:
 
 Vcs-Git: git://anonscm.debian.org/collab-maint/package-xx.git
 Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/package-xx.git

Fixed this in control :-)

 again, forwarding patches from GPL-* to BSD-* is not allowed.
 So another folk won't be able to forward a patch you made in Debian to
 upstream.
 
 Think about that possibility, maybe it isn't important/real for you, but
 I want to make you aware of that

So keep the same license as upstream indeed avoids many trouble...
I've changed debian license to BSD-2-Clause, which is the same as upstream.


The revised package was uploaded to mentors:
http://mentors.debian.net/package/linuxbrew-wrapper
http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-1.dsc

Changes since last upload:
 * dch -r unstable
 * bump debian copyright to bsd-2-clause
 * update manpage

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



signature.asc
Description: This is a digitally signed message part

[caffe] one step closer to the final caffe package

[lumin]

Hi folks,
(CC'ing people who are interested in package "caffe")

It is a good news that the package caffe in 
anonscm/debian-science/caffe.git builds again.
Package caffe-cpu and package caffe-cuda shold be built properly on
amd64 and i386 hosts.

However it's not quite in a good shape, currently I'm looking
into these things:

 * how to avoid FTBFS on ARCHs which are not amd64|i386,
   because control :: build-deps contains CUDA (nvidia-cuda-toolkit)

 * letting custom target in d/rules work again

 * adding a python-caffe-cpu, and a python-caffe-cuda pcakage.

 * adding manpages for ELFs.

 * is it ok to build-deps on nvidia-cuda-toolkit/experimental (6.5.14)
   because cuda 6.0 in unstable is t old to work with gcc4.9
   or even gcc4.8 when building caffe-cuda.
   (it is said that gcc-4.6 was removed recently from unstable ...)

 * add explicit depend on gcc-4.9, as cuda 6.5 won't work with gcc-5,
   especially after gcc-5 transition.

They are my todos on this package and you can see somewhat a progress...
and I haven't check lintian yet.

I think I can finish the packaging without help, but would
appreciate if any :-)
(build it on my laptop is very slow ...)

Thank you.


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

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Hi Gianfranco Costamagna,

On Thu, 2015-09-03 at 13:41 +, Gianfranco Costamagna wrote:

> Can you please start by fixing the lintian warnings on mentors page?

Now caffe is lintian clean.
and I've stripped some lines in dch.

Please have a look at it. :-)

Thanks.

http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.~rc2+git20150902+e8e660d3-1.dsc


signature.asc
Description: This is a digitally signed message part

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

On Thu, 2015-09-03 at 15:13 +, Gianfranco Costamagna wrote:
> 
> Hi,
> 
> control:
> 
> libboost-all-dev (>= 1.55) | libboost1.55-all-dev (>= 1.55),
> what is the rationale for that? I guess libboost-all-dev is already enough...

I've removed libboost1.55-all-dev (>= 1.55) locally.

> Multi-Arch: no
> isn't that the default?

Really? let me look up for some doc...
if so I'll strip them.

> "Pre-Depends: ${misc:Pre-Depends}"
> 
> this should be useless

Since it's generated by default with debmake (next-gen dh-make),
I didn't notice that.

I've stripped them locally.

> 
> rules:
> --builddirectory=
> can be passed also in dh call, making useless everywhere

(I'm not sure I'm following you at this point)
Initially I wrote rules as so:

%:
  dh $@ --builddirectory=XX1
if flag
  dh $@ --builddirectory=XX2
endif

Then I found that I can't control the rules
within my understanding (because of the another conditional build
-- cuda version)

And current rules is easy for me to understand and maintain.

> "fakeroot dh binary"
> 
> well, I usually don't like such hacks in rules file :)

This is just part of custom target, which is not included in
the standard build process, and it's for user's custom localbuild.

Inspired by Debian's OpenBLAS, I provided 2 custom targets:
custom-cpu and custom-cuda
and that's the way I found that works and can generate the packages.

For detail please see debian/README.Debian :-)

> CUSTOM_JOBS   := "-j4"
> 
> well mips porters might hate you for this!

I think I should clarify the variable.

As said above and said in `debian/README.Debian`, this is
just a job number control of custom-* targets, and has no
effect on standard dpkg-buildpackage process jobs, which is
controlled by ENVs and --parallel.

> isn't something like
> override_dh_auto_build:
> dh_auto_configure flags-build1
> dh_auto_build -O--parallel --builddirectory=build1
> dh_auto_configure flags-build2
> dh_auto_build -O--parallel --builddirectory=build2
> 
> not good for your purpose?

override_dh_auto_build:
dh_auto_build --builddirectory=${CAFFE_CPU_BUILDDIR} \ 
-- all caffe pycaffe  
ifeq (y, $(flag_build_caffe_cuda)) 
dh_auto_build --builddirectory=${CAFFE_CUDA_BUILDDIR} \ 
-- all caffe pycaffe  
endif 

Cafffe_cuda is a conditional build, which means the build
against caffe_cuda should only be triggered on i386|amd64.

IMHO squashing dh_auto_configure and dh_auto_build into
override_dh_auto_build can make understanding dh behaviour
harder...

I'll have a search on codesearch.d.n soon and see how others
handle issues alike.



In all, I'm satisfied with current rules, as it's easy to understand,
and tweak.

Thank you so much for reviewing it.
I'll do another mentors upload soon, after an investigation on
codesearch.d.n



signature.asc
Description: This is a digitally signed message part

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

On Fri, 2015-09-04 at 17:14 +, Gianfranco Costamagna wrote:
> Hi again,
> 
> The package doesn't build in a clean environment.
> 
> http://debomatic-amd64.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog

Well, I am surprised source Caffe suffers FTBFS on x86 and x86_64.
While the source never fails to build on my machines...

  Debomatic build result

amd64   [FTBFS] caffe-cuda: ld error: undefined reference to xxx [1]
arm64   [ - ]
armel   [ - ]
armhf   [ debomatic issue ? ] nearly success but failed several tests, then: 
qemu: uncaught target signal 6 (Aborted) - core dumped [3]
i386[FTBFS] dh_auto_configure: cmake error: variables NOTFOUND [2]
mipsel  [ debomatic issue ] apt-get update failed
mips[ - ]
powerpc [ debomatic issue ] E: Failed to execute “/usr/bin/aptitude”: Exec 
format error [4]
ppc64el [ - ]
s390x   [ debomatic issue ] E: Failed to execute “/usr/bin/aptitude”: Exec 
format error [5]

I have been looking into this issue for a while.

[1] 
http://debomatic-amd64.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[2] 
http://debomatic-i386.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[3] 
http://debomatic-armhf.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[4] 
http://debomatic-powerpc.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog
[5] 
http://debomatic-s390x.debian.net/distribution#experimental/caffe/0.~rc2+git20150902+e8e660d3-1/buildlog



signature.asc
Description: This is a digitally signed message part

Re: Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Hi Gianfranco Costamagna,

On Fri, 2015-09-04 at 17:04 +, Gianfranco Costamagna wrote:
> if they aren't called by standard dh calls it is fine to keep them there.
> 
> maybe just move to the bottom, (I think they are already there)

I will keep those custom target in the bottom of d/rules.
Yes, all of custom-target-related lines had been already 
clustered at the bottom of d/rules, and I have drew a big
split line at the beginning of them, in the updated version.

> well, they aren't called by buildd systems, so I don't care.
> 
> Users who apt-get source your package should also know how to build
> the custom stuff.

The custom stuff is explained in the README.Debian, and it
in fact includes a custom compile guide and some more other
things.

> I guess you already did it correctly.
> 
> I like this version more than the previous one (note, I didn't test a build)
> 
> anyway:
> please add gcc/g++ 4.9 or whatever to the b-d in control file. It is not 
> guarantee
> specially after the gcc-5 switch that they will be there.

I have added g{cc,++}-4.9 in the updated d/control, so this package
won't FTBFS due to dependency bump of build-essential to gcc5.

However if CUDA/experimental is an updated version (7.0), 
gcc5 should be able to work.
(I successfully built Caffe on ArchLinux + CUDA 7 + gcc 5)

> to see if nvidia is available (amd or i386 I would do something like:
> 
> In rules file, to see
> ifeq ($(shell dpkg-query --status nvidia-cuda-toolkit |grep -o Package), 
> Package)
> 
> flag_build_caffe_cuda := y
> 
> endif

I think this is better than above:

 19 ifeq (installed, $(shell dpkg -s nvidia-cuda-toolkit | grep -o installed))
 20 flag_build_caffe_cuda := y
 21 endif

then we can make sure nvidia-cuda-toolkit is "installed" on
system rather than "residual-config" or something else.

Thank you for this trick and it looks cool.
:-)

> this way you avoid a double "if" and if tomorrow cuda gets another arch 
> support, you just need
> to add it in the control file.

Thanks.



signature.asc
Description: This is a digitally signed message part

how to prevent dpkg-shlibdeps from Depending on CONFLICTING packages?

[lumin]

Hi mentors,

I'm packaging caffe, which is nearly done.

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

http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.~rc2+git20150902+e8e660d3-1.dsc

Source caffe are built twice against different configurations,
and are compiled into 2 groups of binary packages, 4 in each group:

caffe-cpu  conflict with   caffe-cuda
libcaffe-cpu0  conflict with   libcaffe-cuda0
libcaffe-cpu-dev   conflict with   libcaffe-cuda-dev
python-caffe-cpu   conflict with   python-caffe-cuda

They are well built on my amd64 build machine, but when I'm testing
installing them I found this:
(I stripped some lines)

 Package: caffe-cpu
 Source: caffe
 Depends: libcaffe-cpu0 (= 0.~rc2+git20150902+e8e660d3-1), 
libboost-python1.55.0, libc6 (>= 2.14), libcaffe-cuda0 (>= 
0.~rc2+git20150902+e8e660d3), libgcc1 (>= 1:4.1.1), libgflags2, 
libgoogle-glog0, libleveldb1, liblmdb0 (>= 0.9.7), libopencv-core2.4, 
libopencv-highgui2.4, libopencv-imgproc2.4, libprotobuf9, libpython2.7 (>= 
2.7), libstdc++6 (>= 4.9)
 Conflicts: caffe-cuda

 Package: caffe-cuda
 Source: caffe
 Depends: libcaffe-cuda0 (= 0.~rc2+git20150902+e8e660d3-1), 
libboost-python1.55.0, libc6 (>= 2.14), libcudart6.5 (>= 2.0), libgcc1 (>= 
1:4.1.1), libgflags2, libgoogle-glog0, libleveldb1, liblmdb0 (>= 0.9.7), 
libopencv-core2.4, libopencv-highgui2.4, libopencv-imgproc2.4, libprotobuf9, 
libpython2.7 (>= 2.7), libstdc++6 (>= 4.9)
 Conflicts: caffe-cpu

 Package: libcaffe-cpu-dev
 Source: caffe
 Depends: libcaffe-cpu0 (= 0.~rc2+git20150902+e8e660d3-1)
 Conflicts: libcaffe-cuda-dev

 Package: libcaffe-cpu0
 Source: caffe
 Provides: libcaffe.so.0 <-NOTICE-
 Depends: libboost-python1.55.0, libboost-system1.55.0, libboost-thread1.55.0, 
libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libgflags2, libgoogle-glog0, libhdf5-8, 
libleveldb1, liblmdb0 (>= 0.9.7), libopenblas-base, libopencv-core2.4, 
libopencv-highgui2.4, libopencv-imgproc2.4, libprotobuf9, libpython2.7 (>= 
2.7), libstdc++6 (>= 4.9)
 Conflicts: libcaffe-cuda0

 Package: libcaffe-cuda-dev
 Source: caffe
 Depends: libcaffe-cuda0 (= 0.~rc2+git20150902+e8e660d3-1)
 Conflicts: libcaffe-cpu-dev

 Package: libcaffe-cuda0
 Source: caffe
 Provides: libcaffe.so.0  <--NOTICE
 Depends: libboost-python1.55.0, libboost-system1.55.0, libboost-thread1.55.0, 
libc6 (>= 2.14), libcublas6.5 (>= 4.0), libcudart6.5 (>= 5.0), libcurand6.5 (>= 
3.2), libgcc1 (>= 1:4.1.1), libgflags2, libgoogle-glog0, libhdf5-8, 
libleveldb1, liblmdb0 (>= 0.9.7), libopenblas-base, libopencv-core2.4, 
libopencv-highgui2.4, libopencv-imgproc2.4, libprotobuf9, libpython2.7 (>= 
2.7), libstdc++6 (>= 4.9)
 Conflicts: libcaffe-cpu0

 Package: python-caffe-cpu
 Source: caffe
 Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), libboost-python1.55.0, 
libc6 (>= 2.4), libcaffe-cuda0 (>= 0.~rc2+git20150902+e8e660d3), libgcc1 
(>= 1:4.1.1), libgoogle-glog0, libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 
(>= 4.2.1), libcaffe-cpu0
 Conflicts: python-caffe-cuda

 Package: python-caffe-cuda
 Source: caffe
 Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), libboost-python1.55.0, 
libc6 (>= 2.4), libcaffe-cpu0 (>= 0.~rc2+git20150902+e8e660d3), libgcc1 (>= 
1:4.1.1), libgoogle-glog0, libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 
4.2.1), libcaffe-cuda0
 Conflicts: python-caffe-cpu

We can see that:

 * there is no problem at dependency of libcaffe-cpu0 and libcaffe-cuda0
 * libdev packages have correct and healthy dependency.
 * caffe-cpu depends on libcaffe-cpu0 (correct), and  libcaffe-cuda0 (wrong), 
so does caffe-cuda
 * python packages depends on both libcaffe-cpu0 and libcaffe-cuda0

However caffe-cpu and caffe-cuda suites are conflicting with each other,
which means the dependency entry generated by `dpkg-shlibdeps` is wrong.

I looked up dpkg-shlibdeps(1), but found no option like 'exclude' 'prevent' 
etc...

How should I prevent that wrong and needless dependencies ?
Sed'ing caffe-cpu.substvars, throwing "libcaffe-cuda0*" out ?

Thanks in advance. :-)

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


signature.asc
Description: This is a digitally signed message part

[Caffe] uploaded to mentors but NOT RFS

[lumin]

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
Description: This is a digitally signed message part

Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-mentors@lists.debian.org, 
788...@bugs.debian.org

Dear mentors,

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

 * Package name: caffe
   Version : 0.~rc2+git20150902+e8e660d3-1
   Upstream Author : BVLC (BERKELEY VISION AND LEARNING CENTER)
 * URL : http://caffe.berkeleyvision.org/
 * License : BSD-2-Clause
   Section : science

  It builds those binary packages:

 caffe-cpu  - Fast open framework for Deep Learning (Tools, CPU_ONLY)
 caffe-cuda - Fast open framework for Deep Learning (Tools, CUDA)
 libcaffe-cpu-dev - Fast open framework for Deep Learning (LibDev, CPU_ONLY)
 libcaffe-cpu0 - Fast open framework for Deep Learning (Lib, CPU_ONLY)
 libcaffe-cuda-dev - Fast open framework for Deep Learning (LibDev, CUDA)
 libcaffe-cuda0 - Fast open framework for Deep Learning (Lib, CUDA)
 python-caffe-cpu - Fast open framework for Deep Learning (Python2, CPU_ONLY)
 python-caffe-cuda - Fast open framework for Deep Learning (Python2, CUDA)

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

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

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

dget -x 
http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.~rc2+git20150902+e8e660d3-1.dsc


  Changes since the last upload:

caffe (0.~rc2+git20150902+e8e660d3-1) experimental; urgency=low

  * Initial release. (Closes: #788539)
  * Modify upstream Makefile:
- Add SONAME: libcaffe.so.0 for libcaffe.so
- Fix rpath issue
  * Modify upstream CMake files:
- Add SONAME: libcaffe.so.0 for libcaffe.so
  * Flush content of ".gitignore" from upstream tarball


  Regards,
   Zhou Mo


signature.asc
Description: This is a digitally signed message part

Re: how to prevent dpkg-shlibdeps from Depending on CONFLICTING packages?

[lumin]

Oh, I've resolved this issue by myself, with assistance of
codesearch.d.n, which is really quite a useful site.

:-)

I solved it by this way:

107 override_dh_shlibdeps:
108 dh_shlibdeps \
109 --package=caffe-cpu \
110 --package=libcaffe-cpu0 \
111 --package=libcaffe-cpu-dev \
112 --package=python-caffe-cpu \
113 -- \
114 -xlibcaffe-cuda0
115 ifeq (y, $(flag_build_caffe_cuda))
116 dh_shlibdeps \
117 --package=caffe-cuda \
118 --package=libcaffe-cuda0 \
119 --package=libcaffe-cuda-dev \
120 --package=python-caffe-cuda \
121 -- \
122 -xlibcaffe-cpu0
123 endif

Thank you all.

On Thu, 2015-09-03 at 07:10 +, lumin wrote:
> Hi mentors,
> 
> I'm packaging caffe, which is nearly done.
> 
> http://mentors.debian.net/package/caffe
> 
> http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.~rc2+git20150902+e8e660d3-1.dsc
> 
> Source caffe are built twice against different configurations,
> and are compiled into 2 groups of binary packages, 4 in each group:
> 
> caffe-cpu  conflict with   caffe-cuda
> libcaffe-cpu0  conflict with   libcaffe-cuda0
> libcaffe-cpu-dev   conflict with   libcaffe-cuda-dev
> python-caffe-cpu   conflict with   python-caffe-cuda
> 
> They are well built on my amd64 build machine, but when I'm testing
> installing them I found this:
> (I stripped some lines)
> 
>  Package: caffe-cpu
>  Source: caffe
>  Depends: libcaffe-cpu0 (= 0.~rc2+git20150902+e8e660d3-1), 
> libboost-python1.55.0, libc6 (>= 2.14), libcaffe-cuda0 (>= 
> 0.~rc2+git20150902+e8e660d3), libgcc1 (>= 1:4.1.1), libgflags2, 
> libgoogle-glog0, libleveldb1, liblmdb0 (>= 0.9.7), libopencv-core2.4, 
> libopencv-highgui2.4, libopencv-imgproc2.4, libprotobuf9, libpython2.7 (>= 
> 2.7), libstdc++6 (>= 4.9)
>  Conflicts: caffe-cuda
> 
>  Package: caffe-cuda
>  Source: caffe
>  Depends: libcaffe-cuda0 (= 0.~rc2+git20150902+e8e660d3-1), 
> libboost-python1.55.0, libc6 (>= 2.14), libcudart6.5 (>= 2.0), libgcc1 (>= 
> 1:4.1.1), libgflags2, libgoogle-glog0, libleveldb1, liblmdb0 (>= 0.9.7), 
> libopencv-core2.4, libopencv-highgui2.4, libopencv-imgproc2.4, libprotobuf9, 
> libpython2.7 (>= 2.7), libstdc++6 (>= 4.9)
>  Conflicts: caffe-cpu
> 
>  Package: libcaffe-cpu-dev
>  Source: caffe
>  Depends: libcaffe-cpu0 (= 0.~rc2+git20150902+e8e660d3-1)
>  Conflicts: libcaffe-cuda-dev
> 
>  Package: libcaffe-cpu0
>  Source: caffe
>  Provides: libcaffe.so.0 <-NOTICE-
>  Depends: libboost-python1.55.0, libboost-system1.55.0, 
> libboost-thread1.55.0, libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libgflags2, 
> libgoogle-glog0, libhdf5-8, libleveldb1, liblmdb0 (>= 0.9.7), 
> libopenblas-base, libopencv-core2.4, libopencv-highgui2.4, 
> libopencv-imgproc2.4, libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 4.9)
>  Conflicts: libcaffe-cuda0
> 
>  Package: libcaffe-cuda-dev
>  Source: caffe
>  Depends: libcaffe-cuda0 (= 0.~rc2+git20150902+e8e660d3-1)
>  Conflicts: libcaffe-cpu-dev
> 
>  Package: libcaffe-cuda0
>  Source: caffe
>  Provides: libcaffe.so.0  <--NOTICE
>  Depends: libboost-python1.55.0, libboost-system1.55.0, 
> libboost-thread1.55.0, libc6 (>= 2.14), libcublas6.5 (>= 4.0), libcudart6.5 
> (>= 5.0), libcurand6.5 (>= 3.2), libgcc1 (>= 1:4.1.1), libgflags2, 
> libgoogle-glog0, libhdf5-8, libleveldb1, liblmdb0 (>= 0.9.7), 
> libopenblas-base, libopencv-core2.4, libopencv-highgui2.4, 
> libopencv-imgproc2.4, libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 4.9)
>  Conflicts: libcaffe-cpu0
> 
>  Package: python-caffe-cpu
>  Source: caffe
>  Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), 
> libboost-python1.55.0, libc6 (>= 2.4), libcaffe-cuda0 (>= 
> 0.~rc2+git20150902+e8e660d3), libgcc1 (>= 1:4.1.1), libgoogle-glog0, 
> libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 4.2.1), libcaffe-cpu0
>  Conflicts: python-caffe-cuda
> 
>  Package: python-caffe-cuda
>  Source: caffe
>  Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), 
> libboost-python1.55.0, libc6 (>= 2.4), libcaffe-cpu0 (>= 
> 0.~rc2+git20150902+e8e660d3), libgcc1 (>= 1:4.1.1), libgoogle-glog0, 
> libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 4.2.1), libcaffe-cuda0
>  Conflicts: python-caffe-cpu
> 
> We can see that:
> 
>  * there is no problem at dependency of libcaffe-cpu0 and libcaffe-cuda0
>  * libdev packages have correct and healthy dependency.
>  * caffe-cpu depends on libcaffe-cpu0 (correct), and  libcaffe-cuda0 (wrong), 
> so does 

Re: Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[lumin]

Hi,

I've uploaded updated Caffe to mentors.
http://mentors.debian.net/package/caffe

On Thu, 2015-09-03 at 15:13 +, Gianfranco Costamagna wrote:
> libboost-all-dev (>= 1.55) | libboost1.55-all-dev (>= 1.55),
> what is the rationale for that? I guess libboost-all-dev is already enough...

Reduced one.

> Multi-Arch: no
> isn't that the default?

Stripped all Multi-Arch: no in d/control.

> "Pre-Depends: ${misc:Pre-Depends}"
> this should be useless

Removed.

> rules:
> --builddirectory=
> can be passed also in dh call, making useless everywhere
> 
> 
> "fakeroot dh binary"
> 
> well, I usually don't like such hacks in rules file :)

Then, how about splitting those custom target into another file?

e.g. debian/custom 
 $ debian/custom cpu
 $ debian/custom cuda

Such change can 1. reduce length of d/rules,
2. avoid confusion on custom matter.

> CUSTOM_JOBS   := "-j4"
> 
> well mips porters might hate you for this!

Well, I changed the default custom build jobs to -j2.

> isn't something like
> override_dh_auto_build:
> dh_auto_configure flags-build1
> dh_auto_build -O--parallel --builddirectory=build1
> dh_auto_configure flags-build2
> dh_auto_build -O--parallel --builddirectory=build2
> 
> not good for your purpose?

I still don't understand how to write working rules
like that ...

Full changes since last time mentors upload is attached.

Thank you :-)
diff --git a/debian/control b/debian/control
index 4fc3b87..a3a8379 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian Science Maintainers 
 Build-Depends: cmake, debhelper (>=9),
libopencv-dev (>= 2.4),
-   libboost-all-dev (>= 1.55) | libboost1.55-all-dev (>= 1.55),
+   libboost-all-dev (>= 1.55),
libopenblas-dev,
libprotobuf-dev,
libleveldb-dev,
@@ -26,15 +26,14 @@ Build-Depends: cmake, debhelper (>=9),
nvidia-cuda-toolkit (>= 6.5.14) [amd64 i386]
 Standards-Version: 3.9.6
 Homepage: http://caffe.berkeleyvision.org
-Vcs-Git: https://github.com/BVLC/caffe.git
-X-Python-Version: >= 2.6
+Vcs-Browser: http://anonscm.debian.org/cgit/debian-science/packages/caffe.git
+Vcs-Git: https://anonscm.debian.org/git/debian-science/packages/caffe.git
+X-Python-Version: >= 2.7
 
 Package: caffe-cpu
 Architecture: any
-Multi-Arch: no
 Depends: libcaffe-cpu0 (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends}
+ ${misc:Depends}, ${shlibs:Depends}
 Conflicts: caffe-cuda
 Description: Fast open framework for Deep Learning (Tools, CPU_ONLY)
  Caffe is a deep learning framework made with expression, speed, 
@@ -46,8 +45,6 @@ Description: Fast open framework for Deep Learning (Tools, CPU_ONLY)
 Package: libcaffe-cpu0
 Section: contrib/libs
 Architecture: any
-Multi-Arch: no
-Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Conflicts: libcaffe-cuda0
 Provides: libcaffe.so.0
@@ -61,10 +58,9 @@ Description: Fast open framework for Deep Learning (Lib, CPU_ONLY)
 Package: libcaffe-cpu-dev
 Section: contrib/libdevel
 Architecture: any
-Multi-Arch: no
 Conflicts: libcaffe-cuda-dev
 Depends: libcaffe-cpu0 (= ${binary:Version}), ${misc:Depends}
-Description: Fast open framework for Deep Learning (LibDev, CPU_ONLY)
+Description: Fast open framework for Deep Learning (Dev, CPU_ONLY)
  Caffe is a deep learning framework made with expression, speed, 
  and modularity in mind. It is developed by the Berkeley Vision
  and Learning Center (BVLC) and community contributors.
@@ -74,10 +70,8 @@ Description: Fast open framework for Deep Learning (LibDev, CPU_ONLY)
 Package: caffe-cuda
 # CUDA is available only on i386 and amd64
 Architecture: i386 amd64
-Multi-Arch: no
 Depends: libcaffe-cuda0 (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends}
+ ${misc:Depends}, ${shlibs:Depends}
 Conflicts: caffe-cpu
 Description: Fast open framework for Deep Learning (Tools, CUDA)
  Caffe is a deep learning framework made with expression, speed, 
@@ -90,8 +84,6 @@ Package: libcaffe-cuda0
 Section: contrib/libs
 # CUDA is available only on i386 and amd64
 Architecture: i386 amd64
-Multi-Arch: no
-Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Conflicts: libcaffe-cpu0
 Provides: libcaffe.so.0
@@ -106,10 +98,9 @@ Package: libcaffe-cuda-dev
 Section: contrib/libdevel
 # CUDA is available only on i386 and amd64
 Architecture: i386 amd64
-Multi-Arch: no
 Depends: libcaffe-cuda0 (= ${binary:Version}), ${misc:Depends}
 Conflicts: libcaffe-cpu-dev
-Description: Fast open framework for Deep Learning (LibDev, CUDA)
+Description: Fast open framework for Deep Learning (Dev, CUDA)
  Caffe is a deep learning framework made with expression, speed, 
  and modularity in mind. It is developed by the Berkeley Vision
  and Learning Center (BVLC) and community contributors.
@@ -119,7 

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

[lumin]

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

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

[lumin]

Hi,

On Wed, 2015-09-09 at 09:02 +, 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.~rc2+git20150902+e8e660d3
> fatal: ambiguous argument '0.~rc2+git20150902+e8e660d3': unknown revision 
> or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
> 
> whenever such one (where you use "-g" instead of "+"):
> 
> $> git show 0.~rc2+git20150902-ge8e660d3
> commit e8e660d3ca5b5d8d1e8f2853c0d606cb525d8a72
> Merge: cbb2ed1 4f64b9e
> Author: Jeff Donahue <jeff.dona...@gmail.com>
> 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.

[Caffe / ITP / FTBFS] undefined reference to `XXX` issue

[lumin]

 if I should temporarily comment caffe-cuda out,
letting caffe-cpu work first, and wait for a day when caffe-cuda can pass the 
build.

Any comment is appreciated.
Thank you all. :-)

[1] http://caffe.berkeleyvision.org/
[2] http://anonscm.debian.org/cgit/debian-science/packages/caffe.git/
[3] 
https://github.com/CDLuminate/asdf/blob/master/caffe_0.~rc2%2B20150925-g674b349-1_amd64.build

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


signature.asc
Description: This is a digitally signed message part

Bug#799557: RFS: progress/0.9-1 -- Coreutils Progress Viewer

[lumin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: costamagnagianfra...@yahoo.it

Dear mentors,

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

 * Package name: progress
   Version : 0.9-1
   Upstream Author : Xfennec
 * URL : https://github.com/Xfennec/progress/
 * License : GPL-3.0+
   Section : utils


  This is just a small update. Upstream merged all Debian patches in
0.8-1, them released 0.9. Uploading this package for removing all Debian 
patches. 

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.9-1.dsc



  Changes since the last upload:

progress (0.9-1) unstable; urgency=medium

  * Imported upstream version 0.9
  * Removed all Debian patches, because all of them are merged by upstream.
- debian/patches/add-license-info.patch
- debian/patches/fix-makefile-ldflags.patch
- debian/patches/fix-manpage-has-errors.patch

  Regards,
   Zhou Mo


signature.asc
Description: This is a digitally signed message part

Bug#799565: RFS: linuxbrew/20150804-2 -- missing package manager for linux

[lumin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "linuxbrew-wrapper"

 * Package name: linuxbrew-wrapper
   Version : 20150804-2 
   Upstream Author : Linuxbrew contributors
 * URL : https://github.com/Homebrew/linuxbrew
 * License : BSD-2-Clause
   Section : utils

  It builds those binary packages:

linuxbrew-wrapper - Missing Package Manager For Linux

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

  http://mentors.debian.net/package/linuxbrew-wrapper


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

dget -x 
http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-2.dsc


  Changes since the last upload:


linuxbrew-wrapper (20150804-2) unstable; urgency=low

  * debian/bin/linuxbrew: 
+ Fix: not ignoring linuxbrew arguments when first time running.
+ Rewrite last part, which makes the wrapper script usable outside
  of this Debian package.
  * d/rules: add get-orig-source target.
  * Fixed lintian warning 
"script-not-executable usr/lib/linuxbrew-wrapper/install".

  Regards,
   Zhou Mo


signature.asc
Description: This is a digitally signed message part

Bug#799565: Acknowledgement (RFS: linuxbrew/20150804-2 -- missing package manager for linux)

[lumin]

Control: retitle 799565 RFS: linuxbrew-wrapper/20150804-2 -- missing package 
manager for linux


signature.asc
Description: This is a digitally signed message part

Re: Bug#799390: linuxbrew-wrapper: over-restrictive architecture setting?

[lumin]

Hi Aaron M. Ucko,

On Fri, 2015-09-18 at 13:11 -0400, Aaron M. Ucko wrote:

> linuxbrew-wrapper's control file declares amd64 to be the only
> supported architure.  Is that restriction really necessary?  From what
> I gather, Linuxbrew is perfectly capable of building software from
> source, so it should be no big deal if prebuilt binaries aren't
> available for other architectures.

Agree with you.
Linuxbrew upstream declares that it only supports amd64,
and there is only amd64 machines for me to test, so I wrote
amd64 in Architecture.

> Please consider changing the Architecture value to linux-any, or even
> any.

This is quoted from upstream README:

  Linuxbrew does not currently support 32-bit x86 platforms nor
  platforms other than x86. It would be possible for Linuxbrew to
  work on 32-bit x86 platforms with some effort. 

which means users under ARCHs other than amd64 may need to take care
of themselves.

I don't think it's appropriate to bump Architecture from "amd64"
to a wildcard without sort of notice to user.

Thank you for reporting this issue!


signature.asc
Description: This is a digitally signed message part

Bug#799557: RFS: progress/0.9-1 -- Coreutils Progress Viewer

[lumin]

On Mon, 2015-09-21 at 07:33 +, Gianfranco Costamagna wrote:
> can you please add them both?

Fixed, please take a look at dch.   :-)
And updated version was uploaded to mentors.


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

  http://mentors.debian.net/package/progress


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

dget -x
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.9-1.dsc

  More information about hello can be obtained from
http://www.example.com.

  Changes since the last upload:

progress (0.9-1) unstable; urgency=medium

  * Imported upstream version 0.9
  * Removed all Debian patches, because all of them are merged by
upstream.
- debian/patches/add-license-info.patch
- debian/patches/fix-makefile-ldflags.patch
- debian/patches/fix-manpage-has-errors.patch
  * d/control:
- fixed Vcs-Git field.
- added Vcs-Browser field.

Thank you for sponsoring!
-- 
 .''`.
: :' :
`. `' 
  `-  


signature.asc
Description: This is a digitally signed message part

Bug#804343: RFS: libsvm/3.20-1 [NMU] -- library implementing support vector machines

[lumin]

Hi,

Actually I don't know how it is going.

However IMHO you we can close this RFS, and wait for the maintainer
to update this package someday...

Thanks.

On Wed, 2015-11-25 at 15:44 +, Gianfranco Costamagna wrote:
> Hi Lumin and Chen-Tse,
> 
> thanks for the answer, let me know if you need a sponsor, otherwise I'll 
> close this rfs :)
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> 
> 
> Il Martedì 10 Novembre 2015 6:21, lumin <cdlumin...@gmail.com> ha scritto:
> Hi,
> 
> That's OK.
> Please ping me if there's anything I can help.
> 
> Thanks.
> 
> 
> On Mon, 2015-11-09 at 18:59 -0600, Chen-Tse Tsai wrote:
> > Hi,
> > 
> > 
> > Sorry for the late reply as I missed your message earlier. I'll update
> > the package as soon as possible. Thanks for the help!
> > 
> > 
> > Regards,
> > Chen-Tse

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

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@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 basic functionality seems to be working, 
  but there are still some problems.

  * the test_sharedmem.lua fails and it seems to be an upstream bug
  * the package complexity far surpassed the assumption of dh-lua,
so the rules file of this package is somewhat convolved,
mixing cmake build and the dh-lua build together, but it should
not be hard to understand. :-)

  It's project homepage is http://torch.ch

  I am looking for a sponsor for my package "lua-torch-torch7"

 * Package name: lua-torch-torch7
   Version : 0~20160604-g69d7a01-1
   Upstream Author : Torch Devs
 * URL : github.com/torch/torch7
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

libtorch-luat - libluaT.so of Torch Package for Torch Framework
 libtorch-luat-dev - libluaT.so of Torch Package for Torch Framework (dev)
 libtorch-th - libTH.so of Torch Package for Torch Framework
 libtorch-th-dev - libTH.so of Torch Package for Torch Framework (dev)
 lua-torch-torch7 - Torch Package for Torch Framework
 lua-torch-torch7-dev - Torch Package for Torch Framework (dev)

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

  https://mentors.debian.net/package/lua-torch-torch7


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-torch7/lua-torch-torch7_0~20160604-g69d7a01-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-torch-torch7 (0~20160604-g69d7a01-1) experimental; urgency=low

  * Initial release. Closes: #826532

Bug#826705: RFS: lua-torch-paths/0~20160203-g68d579a-1 [ITP]

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org, a...@debian.org

  Dear mentors,

  This package is a part of "Torch", a state-of-the-art machine
  learning framework. Home: http://torch.ch

  I am looking for a sponsor for my package "lua-torch-paths"

 * Package name: lua-torch-paths
   Version : 0~20160203-g68d579a-1
   Upstream Author : Torch Devs
 * URL : github.com/torch/paths
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

lua-torch-paths - Filename Manipulation Package for Torch Framework
 lua-torch-paths-dev - Filename Manipulation Package for Torch Framework (dev)

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

  https://mentors.debian.net/package/lua-torch-paths


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-paths/lua-torch-paths_0~20160203-g68d579a-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-torch-paths (0~20160203-g68d579a-1) unstable; urgency=low

  * Initial release. Closes: #826529

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

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@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: lua-torch-cwrap
   Version : 0~20160222-gdbd0a62-1
   Upstream Author : Torch Developers
 * URL : github.com/torch/cwrap
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

lua-torch-cwrap - CWrap package for Torch Framework

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

  https://mentors.debian.net/package/lua-torch-cwrap


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-cwrap/lua-torch-cwrap_0~20160222-gdbd0a62-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-torch-cwrap (0~20160222-gdbd0a62-1) unstable; urgency=low

  * Initial release. Closes: #826528

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

[lumin]

Mentors package is updated.

Bug#826081: RFS: linuxbrew-wrapper/20160506-1

[lumin]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

  I am looking for a sponsor for my package "linuxbrew-wrapper"

 * Package name: linuxbrew-wrapper
   Version : 20160506-1
   Upstream Author : Shaun Jackman.
 * URL : https://github.com/Linuxbrew/install
 * License : BSD-2-Clause
   Section : utils

  It builds those binary packages:

linuxbrew-wrapper - Homebrew package manager for Linux

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

  https://mentors.debian.net/package/linuxbrew-wrapper


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20160506-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

linuxbrew-wrapper (20160506-1) unstable; urgency=medium

  * Upstream Install script update.
  * Switch Homepage to http://linuxbrew.sh/ .
  * Update dependencies according to upstream's recommendation.
  * Bump Standards version to 3.9.8 .
  * Install the 'uninstall' script.
  * Update package descriptions.
  * Update get-orig-source and override_dh_fixperms targets in rules.
  * Update copyright.
  * Patch 'uninstall' for fixing interpreter in the script header.
  * Update Vcs-Git link.

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

[lumin]

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 different purpose, i.e. to test that an update in the install
> requirements does not break the currently uploaded package.

Isn't that done by piuparts? confused.
And yes I should also write a python tester script.

> So yes, the Python runtime dependencies should be part of Build-Depends
> and the Python testsuite should be called during the build.

I'll add them later.

>  From my experience using caffe at the lab, the Python interface is what
> people are mainly using. So IMO, it would be quite a let down if the
> caffe were uploaded without Python support.
> 
> IMO, it should be either Python 3 alone or Python 2 + 3. I made this
> mistake when packaging OpenGM and regret it now. I'll repeat it here,
> Python 2 has an expiration date and we should encourage people to use
> Python 3.

Let's make python3-caffe-* and let it be python3-only.

> I did not follow all the recent action on the packaging, but why are we
> still using templated install.in files instead of patching the build
> system for the great of the rest of the Linux community?

I indeed made all suggested changes including using `GNUInstallDirs`
to avoid template generation. Currently the *.in files are mostly
fake template (nothing to be replaced) but only
libcaffe-cpu-dev.install.in is the real one. I need to match
a library install directory in this file, which is the only
remaining template.

Oh yes I should rename those non-template files.
:-)

BTW, I tested the python3 build and I found that, the python3
version can be built without python3-protobuf, and the compilation
will not crash. Python3 module will be generated but when trying
to import caffe in python3 it will end up with something like:

error import google.protobuf

That is to say python3-protobuf is not a build-dep but a runtime-dep
for the python3 interface.

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

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@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 : https://github.com/torch/cwrap
 * License : BSD-3-Clause-like
   Section : interpreters

  It builds those binary packages:

lua-cwrap  - CWrap package for Torch Framework

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

  https://mentors.debian.net/package/lua-cwrap


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-cwrap/lua-cwrap_0~20160222-gdbd0a62-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-cwrap (0~20160222-gdbd0a62-1) unstable; urgency=low

  * Initial release. Closes: #826073

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

[lumin]

On Tue, 2016-05-31 at 16:17 +, Gianfranco Costamagna wrote:
> Hi,
> 
> python-skimage should be RC free now (if no other RC bugs are opened of 
> course :) )
> 
> let me know when you have updates,
> 
> G.

Thank you for working on it !
:-)

Bug#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

  I am looking for a sponsor for my package "lua-torch-nn"

 * Package name: lua-torch-nn
   Version : 0~20160604-gd23a8f5+dfsg-1
   Upstream Author : Torch devs
 * URL : github.com/torch/nn
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

libtorch-thnn - libTHNN.so of Neural Network Package for Torch Framework
 libtorch-thnn-dev - libTHNN.so of Neural Network Package for Torch
Framework (dev)
 lua-torch-nn - Neural Network Package for Torch Framework

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

  https://mentors.debian.net/package/lua-torch-nn


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-nn/lua-torch-nn_0~20160604-gd23a8f5+dfsg-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:
lua-torch-nn (0~20160604-gd23a8f5+dfsg-1) unstable; urgency=low

  * Initial release. Closes: #826794


-- 
Best,
Lumin

Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-torch-trepl"

 * Package name: lua-torch-trepl
   Version : 0~20160613-g06128f9-1
   Upstream Author : Torch Developers
 * URL : github.com/torch/trepl
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

lua-torch-trepl - REPL Package for Troch Framework
torch-trepl - REPL Package for Troch Framework

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

  https://mentors.debian.net/package/lua-torch-trepl


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-trepl/lua-torch-trepl_0~20160613-g06128f9-1.dsc

  More information about hello can be obtained from https://www.example.com

Bug#827582: RFS: lua-torch-xlua/0~20160617-g0dd5f4c-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-torch-xlua"

 * Package name: lua-torch-xlua
   Version : 0~20160617-g0dd5f4c-1
   Upstream Author : Torch Devs
 * URL : github.com/torch/xlua
 * License : BSD-3-Clause
   Section : interpreters

  It builds those binary packages:

lua-torch-xlua - Lua Extension Package for Torch Framework

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

  https://mentors.debian.net/package/lua-torch-xlua


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-xlua/lua-torch-xlua_0~20160617-g0dd5f4c-1.dsc


  Changes since the last upload:
lua-torch-trepl (0~20160613-g06128f9-1) experimental; urgency=low

  * Initial release. Closes: #826791



-- 
Best,
Lumin

Bug#827521: RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-torch-sys"

 * Package name: lua-torch-sys
   Version : 0~20160415-g8d2b8fa-1
   Upstream Author : Torch Devs
 * URL : github.com/torch/sys
 * License : BSD-3-clause
   Section : interpreters

  It builds those binary packages:

lua-torch-sys - System Package for Torch Framework

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

  https://mentors.debian.net/package/lua-torch-sys


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-sys/lua-torch-sys_0~20160415-g8d2b8fa-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-torch-sys (0~20160415-g8d2b8fa-1) experimental; urgency=low

  * Initial release. Closes: #826792

-- 
Best,
Lumin

Bug#814388: RFS: progress/0.13-1

[lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: progress
   Version : 0.13-1
   Upstream Author : xfennec
 * URL : https://github.com/Xfennec/progress
 * License : gpl-3
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.13-1.dsc

  debomatic-amd64 build OK:


http://debomatic-amd64.debian.net/distribution#unstable/progress/0.13-1/buildlog

  Changes since the last upload:

progress (0.13-1) unstable; urgency=medium

  * Import upstream version 0.13.
  * Fix typo in section progress (0.12.1+git20160202-g2ec12d42-1),
"pkg-control" -> "pkg-config"


  Regards,
   lumin

Bug#813495: RFS: progress/0.12.1+git20160202-g2ec12d42-1

[lumin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: progress
   Version : 0.12.1+git20160202-g2ec12d42-1
   Upstream Author : xfennec
 * URL : https://github.com/Xfennec/progress
 * License : gpl-3
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.12.1+git20160202-g2ec12d42-1.dsc

  debomatic amd64 build [OK]:
  

http://debomatic-amd64.debian.net/distribution#unstable/progress/0.12.1+git20160202-g2ec12d42-1/buildlog

  Changes since the last upload:

progress (0.12.1+git20160202-g2ec12d42-1) unstable; urgency=medium

  * Import upstream snapshot version 0.12.1+git20160202-g2ec12d42
  * d/control:
+ update long description.
+ add pkg-control to B-D.
  * d/rules: strip unnecessary lines.

Bug#816356: RFS: progress/0.13-2

[lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: progress
   Version : 0.13-2
   Upstream Author : xfennec
 * URL : https://github.com/Xfennec/progress
 * License : gpl-3
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.13-2.dsc

  Debomatic-amd64 build OK:
  
http://debomatic-amd64.debian.net/distribution#unstable/progress/0.13-2/buildlog

  Changes since the last upload:

progress (0.13-2) unstable; urgency=medium

  * Bump standards from 3.9.6 to 3.9.7 (requires no change)
  * Update Vcs-Browser to an https link.

-- 
 .''`.
: :' :
`. `' 
  `-  


signature.asc
Description: This is a digitally signed message part

Bug#819536: RFS: linuxbrew-wrapper/20150804-3

[lumin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "linuxbrew-wrapper"

 * Package name: linuxbrew-wrapper
   Version : 20150804-3
   Upstream Author : homebrew
 * URL : http://brew.sh/linuxbrew/
 * License : BSD-2-Clause
   Section : utils

  It builds those binary packages:

linuxbrew-wrapper - Missing Package Manager For Linux

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

  http://mentors.debian.net/package/linuxbrew-wrapper

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

dget -x 
http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-3.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

linuxbrew-wrapper (20150804-3) unstable; urgency=medium

  * control:
+ Bump standards version from 3.9.6 to 3.9.7 (requires no change)
+ Update Homepage.
+ Correct URL in Vcs-Browser field.
+ Remove homepage link in package description.
  * rules:
+ Disable DH_VERBOSE by default.
+ get-orig-source: Don't print command line, to avoiding confusion.
  * bin/linuxbrew: refresh wrapper script.
  * example/profile: refresh example.
  * linuxbrew-wrapper.7: reduce content in manpage.
  * README.Debian: refresh content.

[Mentors] upload via http fails with HTTP 403

[lumin]

Hi everyone,
(Please keep me in the CC/To list)

Not only once I have encountered this issue,
which seems to be really a service bug.

Following is a partial error message when I run
  dput -f -d mentors caffe_1.0.0~rc3-1_amd64.changes

my [mentors] section of /etc/dput.cf is copied from the mentors site.

```
D: File to upload: 
/home/lumin/hdd/schroot/sid/tmp/python-caffe-cuda_1.0.0~rc3-1_amd64.deb
D: Checksum for 
/home/lumin/hdd/schroot/sid/tmp/python-caffe-cuda_1.0.0~rc3-1_amd64.deb is fine
D: Checking: distribution experimental matches .*
D: File to upload: 
/home/lumin/hdd/schroot/sid/tmp/caffe_1.0.0~rc3-1_amd64.changes
Package is now being checked with lintian.
N: 10 tags overridden (10 warnings)
D: Default Method: http
D: Host Method: http
D: Login anonymous from section mentors used
Uploading to mentors (via http to mentors.debian.net):
D: FQDN: mentors.debian.net
D: Login: anonymous
D: Incoming: /upload
  Uploading caffe_1.0.0~rc3-1.dsc: D: HTTP-PUT to URL: 
http://mentors.debian.net/upload/caffe_1.0.0~rc3-1.dsc
Upload failed: 403 Forbidden
```

Besides, the ftp upload seems to be working, however
I got messages like this
(dput.cf: [mentors-ftp] is copied from mentors site)

```
Leaving existing caffe-cpu_1.0.0~rc3-1_amd64.deb on the server and continuing
NOTE: This existing file may have been previously uploaded partially.
   For official Debian upload queues, the dcut(1) utility can be
   used to remove this file, and after an acknowledgement mail is
   received in response to dcut, the upload can be re-initiated.
```

Does mentors support dcut?
Where should I send the gpg encrypted dcut command so the above
"NOTE" can be removed?

What happend? Thanks.

Re: [Mentors] upload via http fails with HTTP 403

[lumin]

On Fri, 2016-04-29 at 16:15 +0200, Christian Seiler wrote:
> 
> Did you upload the package with the same version number before and
> then deleted the package in the web interface? 

No deletion.

> My experience with
> mentors is that the HTTP interface really doesn't like that, IIRC I
> got HTTP 500 errors there a while back. 

I sometimes encounter similar problem.

> Nowadays I only use the FTP
> interface for uploading to mentors and haven't had any trouble with
> that whatsoever. Hence I would recommend switching to FTP and not
> using HTTP upload anymore at all.

I've not tried FTP before, would like to try but have no idea on this
kind of output:

Leaving existing libcaffe-cuda1-dbgsym_1.0.0~rc3-1_amd64.deb on the server and 
continuing
NOTE: This existing file may have been previously uploaded partially.
   For official Debian upload queues, the dcut(1) utility can be
   used to remove this file, and after an acknowledgement mail is
   received in response to dcut, the upload can be re-initiated.
  Uploading libcaffe-cuda1_1.0.0~rc3-1_amd64.deb: 553 Could not create file.

When it emerges the FTP upload is invalid, I won't receive mail.

> Hope that helps.

The bad news is after I deleted the previous upload of the Caffe
packages, there is no difference about the above FTP problem...

:-(

> Regards,
> Christian
> 

Re: [Mentors] upload via http fails with HTTP 403

[lumin]

On Fri, 2016-04-29 at 14:43 +, Gianfranco Costamagna wrote:
> This is what I had on my dput.cf
> (note: I used mentors a few months ago, last time)
> 
> [mentors]
> method  = ftp
> fqdn= mentors.debian.net
> incoming= .
> login   = anonymous

Same problem with this configuration.

  Uploading caffe_1.0.0~rc3-1_amd64.changes: 553 Could not create file.
Leaving existing caffe_1.0.0~rc3-1_amd64.changes on the server and continuing

Is that sever suffering from a disk-full trouble ???

Re: [Mentors] upload via http fails with HTTP 403

[lumin]

On Fri, 2016-04-29 at 13:53 +, Gianfranco Costamagna wrote:
> Hi,
> 1) upload *source only* stuff
> 2) no dcut is supported
> 
> to fix, just upload -f also the changes file, at this point it will be 
> processed, the files removed from the queue
> and you will be able to repush the package.
> 
> g.

Maybe I didn't clearly point out the problem.
With the same dput.cf, in the past I performed a number of times
of mentors upload (http), but recently mentors becomds unstable and
upload via http may fail with HTTP 403.

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

[lumin]

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

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

[lumin]

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

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

[lumin]

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 bump it in the future upload.

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

[lumin]

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 discussi

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

[lumin]

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

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

[lumin]

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

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

[lumin]

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

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

[lumin]

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

Bug#824104: RFS: gneural-network/0.9.1-1 [ITP]

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: Jean Michel Sellier , 
a...@debian.org

Dear mentors,

I am looking for a sponsor for my package "gneural-network"

 * Package name: gneural-network
   Version : 0.9.1-1
   Upstream Author : Jean Michel Sellier 
 * URL : https://www.gnu.org/software/gneuralnetwork/
 * License : GPL-3.0+
   Section : science

  It builds those binary packages:

gneural-network - GNU Gneural Network

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

  https://mentors.debian.net/package/gneural-network

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gneural-network/gneural-network_0.9.1-1.dsc


  Changes since the last upload:

gneural-network (0.9.1-1) unstable; urgency=low

  * Initial release. Closes: #824099

Thanks,

Bug#824104: RFS: gneural-network/0.9.1-1 [ITP]

[lumin]

On Thu, 2016-05-12 at 11:17 +0100, Ghislain Vaillant wrote:
> On 12/05/16 10:41, lumin wrote:
> > Package: sponsorship-requests
> > [...]
> > Thanks,
> 
> mentors: "Watch file is not present"
> 
> Why?

http://cvs.savannah.gnu.org/viewvc/gneuralnetwork/

GNU's savannah service:: gneuralnetwork, the official source
repo doesn't hold a real CVS code repo, but some tarballs,
which is not proper entry to be written in control as svn://xxx

So I removed that file. Well, let me CC the author.

To Jean Michel Sellier: could you please update that repo to
be a real cvs code repo? Then we can track the software update 
with Debian's automatic service, and we can guide users
to a working code repo. Thank you.

> Also, where is the packaging repository hosted? d-science? collab-maint?

Currently hosted on my personal user git repo on anonscm.
Gneural network is currently a small program.

> Since you are also the maintainer of caffe, it would make sense to have
> gneural-network maintained in d-science as part of the family of
> machine learning packages. What do you think?

With the consideration about the future, maintaining it under
the umbrella of debian-science is indeed a good idea. Let me
migrate it to debian-science after Jean Michel Sellier's update.

> Cheers,
> Ghis

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

[lumin]

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.

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

[lumin]

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

Bug#823289: RFS: progress/0.13-3

[lumin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: progress
   Version : 0.13-3
   Upstream Author : xfennec
 * URL : github.com/xfennec/progress
 * License : gpl
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/progress/progress_0.13-3.dsc

  debomatic-amd64 buildlog:
  
http://debomatic-amd64.debian.net/distribution#unstable/progress/0.13-3/buildlog

  Changes since the last upload:

progress (0.13-3) unstable; urgency=medium

  * Hardening build: Append $(CPPFLAGS) to CC argument list
in upstream Makefile.
  * Update Vcs-Git to https link.
  * Bump Standards version to 3.9.8 . (no change required)



  Regards,
   Zhou Mo

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

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: a...@debian.org, deb...@danielstender.com, deb...@onerussian.com, 
debian-de...@lists.debian.org, debian-scie...@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 :-)


signature.asc
Description: This is a digitally signed message part

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

[lumin]

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

Bug#832703: RFS: caffe-contrib/1.0.0~rc3-2

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: caffe-contrib
   Version : 1.0.0~rc3-2
   Upstream Author : BVLC
 * URL : caffe.berkeleyvision.org
 * License : BSD-2-Clause
   Section : science

  It builds those binary packages:

caffe-cuda - Fast, open framework for Deep Learning (Meta)
 caffe-tools-cuda - Tools for fast, open framework for Deep Learning (CUDA)
 libcaffe-cuda-dev - development files for Caffe (CUDA)
 libcaffe-cuda1 - library of Caffe, a deep leanring framework (CUDA)
 python3-caffe-cuda - Python3 interface of Caffe (CUDA)

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

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


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

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

debomatic-amd64:
http://debomatic-amd64.debian.net/distribution#experimental/caffe-contrib/1.0.0~rc3-2/buildlog

  Changes since the last upload:

caffe-contrib (1.0.0~rc3-2) experimental; urgency=medium

  * Add NVCC flag "-D_FORCE_INLINES".
  * Cherry-pick upstream fixes for map size issue.
- dont-set-map-size-1TB-in-db-lmdb
- print-to-stderr-for-example-LMDB-code
- update-MNIST-example-to-use-new-DB-classes
  * Synchronize packaging with src:caffe (1.0.0~rc3-4).
+ Import README.Debian from src:caffe.
  * Update symbols control file.


-- 
Best,
Lumin

weird dependency-installbility problem of buildd

[Lumin]

Hi mentors,

Package caffe-contrib_1.0.0~rc3-2 [1][2] build-deps on CUDA 7.5.18,
which is currently available for sid. This package passed
the debomatic-amd64 build [3], however when buildd is working on
this package it says there is "dependency installbility problem" [4].

But how can the existing "nvidia-cuda-toolkit_7.5.18-2" (sid/non-free)[5]
be missing?

Does anyone know what happened there? Is this a bug? Thanks.

[1] https://tracker.debian.org/pkg/caffe-contrib
​[2]
http://anonscm.debian.org/cgit/debian-science/packages/caffe-contrib.git/​
​[3]
http://debomatic-amd64.debian.net/distribution#experimental/caffe-contrib/1.0.0~rc3-2/buildlog
​
​[4]
https://buildd.debian.org/status/package.php?p=caffe-contrib=experimental
​
​[5]
https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit=sid
​


-- 
Best,
Lumin

Bug#832647: RFS: caffe/1.0.0~rc3-4

[Lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: caffe
   Version : 1.0.0~rc3-4
   Upstream Author : BVLC
 * URL : caffe.berkeleyvision.org
 * License : BSD-2-Clause
   Section : science

  It builds those binary packages:

caffe-cpu  - Fast, open framework for Deep Learning (Meta)
 caffe-doc  - Doxygen Document of Caffe
 caffe-tools-cpu - Tools for fast, open framework for Deep Learning
(CPU_ONLY)
 libcaffe-cpu-dev - development files for Caffe (CPU_ONLY)
 libcaffe-cpu1 - library of Caffe, deep learning framework (CPU_ONLY)
 python3-caffe-cpu - Python3 interface of Caffe (CPU_ONLY)

  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/main/c/caffe/caffe_1.0.0~rc3-4.dsc


  Changes since the last upload:


  * Cherry-pick upstream fixes for map size issue.
- dont-set-map-size-1TB-in-db-lmdb
- print-to-stderr-for-example-LMDB-code
- update-MNIST-example-to-use-new-DB-classes
  * Update symbols control file, diverge symbols control file for ppc64el.
  * Synchronize packaging with src:caffe-contrib (= 1.0.0~rc3-2).



-- 
Best,
Lumin

Bug#834332: RFS: lua-torch-optim/0~20160808-g6c59c35-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "lua-torch-optim"

 * Package name: lua-torch-optim
   Version : 0~20160808-g6c59c35-1
   Upstream Author : torch developers
 * URL : github.com/torch/optim
 * License : bsd-3-clause
   Section : interpreters

  It builds those binary packages:

lua-torch-optim - Numeric Optimization Package for Torch Framework

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

  https://mentors.debian.net/package/lua-torch-optim

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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-optim/lua-torch-optim_0~20160808-g6c59c35-1.dsc


  Changes since the last upload:

lua-torch-optim (0~20160808-g6c59c35-1) experimental; urgency=low

  * Initial release. Closes: #827435


-- 
Best,
Lumin

Bug#827582: RFS: lua-torch-xlua/0~20160617-g0dd5f4c-1 [ITP]

[Lumin]

Hi,

On 4 August 2016 at 18:15, Gianfranco Costamagna
<locutusofb...@debian.org> wrote:

> please ping back when rundime-deps are in the archive

Dependency satisfied for this package in experimental.
Updated the package on mentors:

https://mentors.debian.net/debian/pool/main/l/lua-torch-xlua/lua-torch-xlua_0~20160617-g0dd5f4c-1.dsc

* arch is changed to all
* updated extended description

> also you have some lintian issues
> X: lua-torch-xlua: package-contains-no-arch-dependent-filesI: lua-torch-xlua: 
> extended-description-is-probably-too-short
>
> G.

Debomatic is still failing ...

-- 
Best,
Lumin

Bug#834325: RFS: lua-torch-graph/0~20160415-g34d7128-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "lua-torch-graph"

 * Package name: lua-torch-graph
   Version : 0~20160415-g34d7128-1
   Upstream Author : torch developers
 * URL : github.com/torch/graph
 * License : bsd-3-clause
   Section : interpreters

  It builds those binary packages:

lua-torch-graph - Graph Computation Package for Torch Framework

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

  https://mentors.debian.net/package/lua-torch-graph

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

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-torch-graph/lua-torch-graph_0~20160415-g34d7128-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-torch-graph (0~20160415-g34d7128-1) experimental; urgency=low

  * Initial release. Closes: #827432


-- 
Best,
Lumin

Bug#827582: missing ITP

[Lumin]

Control: block 826793 by 827582

Hi, the missing ITP is found.

On 12 August 2016 at 11:30, Bart Martens <ba...@debian.org> wrote:
> Hi Lumin,
>
> Where is the ITP? There should be one, see the instructions at "new packages":
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage
>
> Regards,
>
> Bart Martens



-- 
Best,
Lumin

Bug#827895: missing ITP

[Lumin]

Control: block 826794 by 827895

Hi, now the missing ITP is found.

On 12 August 2016 at 11:23, Bart Martens <ba...@debian.org> wrote:
> Hi Lumin,
>
> Where is the ITP? There should be one, see the instructions at "new packages":
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage
>
> Regards,
>
> Bart Martens



-- 
Best,
Lumin