Whom should I send a patch to?
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 ``` 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
Bug#814388: RFS: progress/0.13-1
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#816356: RFS: progress/0.13-2
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
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
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
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.
Re: [Mentors] upload via http fails with HTTP 403
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
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 ???
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: a...@debian.org, deb...@danielstender.com, deb...@onerussian.com, debian-de...@lists.debian.org, debian-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]
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#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Hi mentors, I found the way to fix lintianI: no-fortify-functions, and I'll add multi-arch support as suggested by Aron, so please wait for my next upload.
Bug#823289: RFS: progress/0.13-3
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]
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#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
On Sat, 2016-05-07 at 10:05 +0100, Ghislain Vaillant wrote: > > s/DEB_CPPFLAGS_MAINT_APPEND/DEB_CXXFLAGS_MAINT_APPEND in your d/rules. > Done. Updated package has been uploaded to mentors: https://mentors.debian.net/package/caffe
Bug#824104: RFS: gneural-network/0.9.1-1 [ITP]
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]
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]
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 computation
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
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]
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]
> 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]
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]
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]
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]
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]
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]
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#826081: RFS: linuxbrew-wrapper/20160506-1
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#826076: Acknowledgement (RFS: lua-cwrap/0~20160222-gdbd0a62-1 -- CWrap package for Torch Framework [ITP])
Mentors package is updated.
Bug#826705: RFS: lua-torch-paths/0~20160203-g68d579a-1 [ITP]
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]
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#826715: RFS: lua-torch-torch7/0~20160604-g69d7a01-1 [ITP]
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#827521: RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP]
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#827582: RFS: lua-torch-xlua/0~20160617-g0dd5f4c-1 [ITP]
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#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
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#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]
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#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Hi guys, Some updates to the caffe package: (can be seen in git repo but no mentors upload) 1. added octave-caffe-cpu package, but there remains some lintian errors to be solved. 2. changed package caffe-cpu into metapackage, move tools to package caffe-tools-cpu. the metapackage pulls libcaffe-cpu, caffe-tools-cpu and python-caffe-cpu, and it suggests the octave interface, libdevel pkg and the doxygen doc package. Concerning protobuf3 and opencv3: opencv3 is not a must, but python3-protobuf is needed. Some weeks ago I had a quick study on them and I found that they are not as easy to be dealt with as I hoped. * even failed to build the unchanged opencv3 package from experimental ... * protobuf3 compilation needs gmock but it's missing. need to inspect the packaging on how the missing gmock source was resolved by protobuf maintainers. Without python3-protobuf the python3-caffe-cpu still builds, although it doesn't runs correctly... Can we first get it into experimental to see on which Architecture does it FTBFS? [1] Besides in this way we can let it pass the first-time-new-queue when waiting for the required runtime-dep. Is experimental available for this purpose? Thanks. :-) [1] amd64 and ppc64el won't FTBFS, both tested by myself, and that's all I know.
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Well ... I'm somewhat confused by how old the uploaded package is ... it still builds python2 ... I'll comment octave package out and do a quick build, the package lying in NEW should be overwriten by the coming updated package. binary:caffe-cpu is NEW. binary:caffe-doc is NEW. binary:libcaffe-cpu-dev is NEW. binary:libcaffe-cpu1 is NEW. binary:python-caffe-cpu is NEW. source:caffe is NEW. On 1 July 2016 at 12:38, Gianfranco Costamagna < costamagnagianfra...@yahoo.it> wrote: > Hi, > > > >Is experimental available for this purpose? > > > > it is, I'm uploading shortly, I did a dget > > changed unstable to experimental in changelog, and if everything is good > I'll upload > > BTW skimage didn't migrate > https://packages.qa.debian.org/s/skimage.html > I would prefer to avoid overriding of the testsuite, so we might end up in > 1) fixing the build failures > 2) restrict caffe on the success architectures > > cheers, > > G. > -- Best, Lumin
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Control: reopen -1 Give me five minutes and about 5 minutes to mentors, Can we overwrite the -1 version ... There are too many changes between -1 and -2 ... On 1 July 2016 at 15:06, Gianfranco Costamagna wrote: > ETOOLATE > > >Well ... I'm somewhat confused by how old the uploaded package is ... it > still builds python2 ... > >I'll comment octave package out and do a quick build, the package lying > in NEW should be overwriten by the coming updated package. > > > > please give me a fixed -2, and I'll upload it on experimental. > > After that, we can just remove the bad binaries. > (do not break+replace on them, I don't think there is need if we are quick > enough) > > G. > > On 1 July 2016 at 12:38, Gianfranco Costamagna < > costamagnagianfra...@yahoo.it> wrote: > > Hi, > > > > > >>Is experimental available for this purpose? > > > > > > > >it is, I'm uploading shortly, I did a dget > > > >changed unstable to experimental in changelog, and if everything is good > I'll upload > > > >BTW skimage didn't migrate > >https://packages.qa.debian.org/s/skimage.html > >I would prefer to avoid overriding of the testsuite, so we might end up in > >1) fixing the build failures > >2) restrict caffe on the success architectures > > > >cheers, > > > >G. > > > > > -- > > Best, > > Lumin > -- Best, Lumin
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Control: close -1 OK, I'm checking the difference between -1 and HEAD now. Will open another RFS for -2. It's my fault that I didn't perform any mentors upload after I started the python3 transition ... So the mentors package keeps old ... On 1 July 2016 at 15:19, Gianfranco Costamagna wrote: > we can't as said before. > > > > > Il Venerdì 1 Luglio 2016 17:12, Lumin ha scritto: > > > > Control: reopen -1 > > Give me five minutes and about 5 minutes to mentors, > Can we overwrite the -1 version ... > > There are too many changes between -1 and -2 ... > > > > On 1 July 2016 at 15:06, Gianfranco Costamagna > wrote: > > ETOOLATE > > > >>Well ... I'm somewhat confused by how old the uploaded package is ... it > still builds python2 ... > >>I'll comment octave package out and do a quick build, the package lying > in NEW should be overwriten by the coming updated package. > > > > > > > >please give me a fixed -2, and I'll upload it on experimental. > > > >After that, we can just remove the bad binaries. > >(do not break+replace on them, I don't think there is need if we are > quick enough) > > > >G. > > > > > >On 1 July 2016 at 12:38, Gianfranco Costamagna < > costamagnagianfra...@yahoo.it> wrote: > > > >Hi, > >> > >> > >>>Is experimental available for this purpose? > >> > >> > >> > >>it is, I'm uploading shortly, I did a dget > >> > >>changed unstable to experimental in changelog, and if everything is good > I'll upload > >> > >>BTW skimage didn't migrate > >>https://packages.qa.debian.org/s/skimage.html > >>I would prefer to avoid overriding of the testsuite, so we might end up > in > >>1) fixing the build failures > >>2) restrict caffe on the success architectures > >> > >>cheers, > >> > >>G. > >> > > > > > >-- > > > >Best, > > > >Lumin > > > > > -- > > Best, > > Lumin > -- Best, Lumin
Bug#829256: RFS: caffe/1.0.0~rc3-2 [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: locutusofb...@debian.org Dear mentors, I am looking for a sponsor for my package "caffe" * Package name: caffe Version : 1.0.0~rc3-2 Upstream Author : Berkeley Vision and Learning Center * URL : caffe.berkeleyvision.org * License : BSD Section : science It builds those binary packages: caffe-cpu - Fask, 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-2.dsc Changes since the last upload: caffe (1.0.0~rc3-2) experimental; urgency=low * d/control - Rename binary package caffe-cpu to caffe-tools-cpu. - Create metapackage "caffe-cpu". - Update package descriptions. - Add B-D: liboctave-dev, octave-pkg-dev. - Bump python-caffe-cpu to python3-caffe-cpu. - Suggest caffe-doc for libcaffe-cpu-dev. * d/rules - Compile octave binary, however octave package is temporarily commented out bacause it's WIP. - Include defs.make from package 'octave-pkg-dev' for Octave related variables. - Bump from python2 build to python3 build. - change the compiling target order of override_dh_auto_build-arch. * d/man - Refresh manpage debian/man/caffe.1 , generated by txt2man with template file debian/man/caffe.txt - Remove unnecessary man pages. * d/patch - Update patches due to python2->python3 transition. - Update forward status in patch headers. - Add new patch cmake-octave-fix-library, which fixes python3 library name for mkoctfile. * d/tests - Add python3 interface B-D runtime-dependencies for testsuite. - Add test suite: python3caffetestsuite . - Update testsuite: simple . * Add install control files for octave-caffe-cpu. * Update debian/clean. * Update bash completion script for caffe. * Remove d/TODO. * Upload to experimental. The -1 version is an accident. -- Best, Lumin
Bug#829653: RFS: caffe-contrib/1.0.0~rc3-1 -- cuda version of caffe [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: costamagnagianfra...@yahoo.it , ghisv...@gmail.com Dear mentors, This cuda version is basically synced with the CPU version in packaging. I am looking for a sponsor for my package "caffe-contrib" * Package name: caffe-contrib Version : 1.0.0~rc3-1 Upstream Author : Berkeley vision and learning center * URL : github.com/bvlc/caffe * 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-1.dsc Changes since the last upload: caffe-contrib (1.0.0~rc3-1) experimental; urgency=low * Initial release. (Closes: #823308) -- Best, Lumin
Bug#829653: Acknowledgement (RFS: caffe-contrib/1.0.0~rc3-1 -- cuda version of caffe [ITP])
Well it seems that the first time mentors upload is going to FTBFS[1]. Hold on and I'll make an fixed upload. the fix is to add flag -D_FORCE_INLINES to nvcc. [1] dom-amd64: CUDA memcpy problem -- Best, Lumin
Bug#829658: RFS: caffe/1.0.0~rc3-3
Package: sponsorship-requests Severity: normal X-Debbugs-CC: costamagnagianfra...@yahoo.it Dear mentors, Debomatic-amd64 build success[1]. As for 32-bit architecture FTBFS issue of caffe, I'd cherry-pick upstream fix at next time upload, synchronizing caffe and caffe-contrib packaging. [1] http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3-3/buildlog I am looking for a sponsor for my package "caffe" * Package name: caffe Version : 1.0.0~rc3-3 Upstream Author : BVLC * URL : github.com/bvlc/caffe * 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-3.dsc Changes since the last upload: caffe (1.0.0~rc3-3) experimental; urgency=medium * Remove octave related packages and corresponding builds, because upstream support for octave is limited. * Fix typo in package descriptions, update descriptions. * Update rules. * Add symbols control file for libcaffe.so . * Update README.Debian . -- Best, Lumin
Bug#829653: Info received (Bug#829653: Acknowledgement (RFS: caffe-contrib/1.0.0~rc3-1 -- cuda version of caffe [ITP]))
http://debomatic-amd64.debian.net/distribution#experimental/caffe-contrib/1.0.0~rc3-1/buildlog The lastest mentors package is fixed. Please sponsor, thanks :-) On 5 July 2016 at 03:30, Debian Bug Tracking System wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Mentors > > If you wish to submit further information on this problem, please > send it to 829...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 829653: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829653 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > -- Best, Lumin
Bug#832647: RFS: caffe/1.0.0~rc3-4
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#832703: RFS: caffe-contrib/1.0.0~rc3-2
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
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&suite=experimental [5] https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit&suite=sid -- Best, Lumin
Bug#826705: RFS: lua-torch-paths/0~20160203-g68d579a-1 [ITP]
Thanks, I checked the recursive difference and updated the git repo: https://anonscm.debian.org/cgit/debian-science/packages/lua-torch-paths.git/commit/?id=53530801ef7d040951c052dfc8631b6491839eb6 On 4 August 2016 at 18:04, Gianfranco Costamagna wrote: > Hi, > >> I am looking for a sponsor for my package "lua-torch-paths" > > > sponsoring (in deferred/5) after removing the "lua5.1 | luajit" from -dev > package > > (debian directory attached) > > G. -- Best, Lumin
Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
On 4 August 2016 at 18:42, Gianfranco Costamagna wrote: > why do not build-depend on the dev package? > I'm talking about "lua-torch-torch7" This is due to, actually "trepl" doesn't B-D on the "lua-torch-torch7-dev" package. It is a runtime dependency. I'll leave a comment there. Keeping this runtime B-D there because it declares explicit dependency relationship. > also, there is some sadness in the libreadline.so link, are you sure there is > no better way to fix that? > what about a package split? I've thought about spliting it up -- inspece verbose dh build and extract the library compilation commands into d/rules -- however this makes d/rules complicated with hardcoded compiles. Seems that dh_lua didn't foresee such a demand, so the above method is the way first came up in my mind. Now that the symlink just works fine ... 1. split then up with hardcoded compile 2. create a new package that ships just a simlink How do you like it? > cheers, > > G. -- Best, Lumin
Bug#826715: RFS: lua-torch-torch7/0~20160604-g69d7a01-1 [ITP]
On 4 August 2016 at 17:48, Gianfranco Costamagna
wrote:
> so please enforce the version and go for experimental, how do you expect to
> be able to build it in unstable with experimental toolchain?
On my jessie the `luajit 2.0` works with `lua-torch-torch7` in some cases,
however this will be troublesome when running unit tests.
I'll change the target release, and make the B-D luajit version
constraint strict.
> also, not needed to specify this
> Depends: ${misc:Depends}, ${shlibs:Depends}, luajit | lua5.1,
>
>
>
> for the -dev package, because already specified in the library itself.
OK, I will fix this.
> +SET_TARGET_PROPERTIES(luaT PROPERTIES
> + VERSION 0
> + SOVERSION 0)
>
>
> do you really want to maintain that downstream? please forward it.
OK.
> why luaT and TH are not packaged separately? at a first look (not careful at
> all)
> they look external dependencies
Actually there are separated:
libtorch-th{,-dev} -> libTH.so
libtorch-luat{,-dev} -> libluaT.so
I avoided the libth{,-dev} libluat{,-dev} name scheme because I don't want to
pollute the lib* namespace, since they are for specific usage. Hence I created
package for them in the libtorch* scheme.
> also, from check-all-the-things:
> $ codespell --quiet-level=3
WOW so cool the tool is!
> it's all for now
> (I'll continue when I get a building package)
>
>
> G.
Will ping back when ready.
Thanks for reviewing!
--
Best,
Lumin
Bug#833766: RFS: caffe/1.0.0~rc3+20160715-g42cd785-1
Package: sponsorship-requests Severity: normal Debomatic-amd64: PASS http://debomatic-amd64.debian.net/distribution#experimental/caffe/1.0.0~rc3+20160715-g42cd785-1/buildlog Dear mentors, I am looking for a sponsor for my package "caffe" * Package name: caffe Version : 1.0.0~rc3+20160715-g42cd785-1 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+20160715-g42cd785-1.dsc Changes since the last upload: caffe (1.0.0~rc3+20160715-g42cd785-1) experimental; urgency=medium * Import upstream snapshot (42cd785e4b5ed824a9b2a02a19aa534042b64325). * Suggest OpenBLAS/Atlas library for metapackage caffe-cpu. * Update manpage d/man/caffe.1 . * Comment out "-pedantic" from rules to reduce the size of build log. * Drop cherry-picked patches, already included in this new snapshot: - dont-set-map-size-1TB-in-db-lmdb - print-to-stderr-for-example-LMDB-code - update-MNIST-example-to-use-new-DB-classes * Remove patch fix-spelling-error, which was merged by upstream. * Refresh patch cmake-fix-python-module-installdir. * Refresh symbols comtrol file. * Override dh_fixperms to remove executable bit from several python scripts. * Add git and libboost-dev to B-D. * Add patch: cmake-avoid-argument-missing . -- Best, Lumin
Bug#826715: RFS: lua-torch-torch7/0~20160604-g69d7a01-1 [ITP]
Hello,
Updated lua-torch-torch7, with a version bump:
https://mentors.debian.net/debian/pool/main/l/lua-torch-torch7/lua-torch-torch7_0~20160803-g17ff317-1.dsc
On 7 August 2016 at 16:32, Lumin wrote:
>
>
> I'll change the target release, and make the B-D luajit version
> constraint strict.
changed the target release to experimental,
require 'luajit >= 2.1' as B-D.
> > also, not neeed to specify this
> > Depends: ${misc:Depends}, ${shlibs:Depends}, luajit | lua5.1,
Fixed.
>
> > do you really want to maintain that downstream? please forward it.
>
Forwarded.
>
>
> > why luaT and TH are not packaged separately? at a first look (not
careful at all)
> > they look external dependencies
--
Best,
Lumin
Bug#827590: missing ITP
Control: retitle 826791 ITP: lua-torch-trepl/0~20160613-g06128f9-1 -- A REPL for Troch Framework Control: block 826791 by 827590 Hi, the ITP is found now. On 12 August 2016 at 11:19, Bart Martens 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
Control: block 826794 by 827895 Hi, now the missing ITP is found. On 12 August 2016 at 11:23, Bart Martens 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#827582: missing ITP
Control: block 826793 by 827582 Hi, the missing ITP is found. On 12 August 2016 at 11:30, Bart Martens 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#834146: RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP]
Package: sponsorship-requests Severity: wishlist Debomatic-amd64: PASS http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-sys/0~20160415-g8d2b8fa-1/buildlog * Changed target release to experimental * misc updates 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 developers * 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#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
Hi, updated the lua-torch-trepl package, including the change of release to experimental. https://mentors.debian.net/package/lua-torch-trepl it passed debomatic-amd64 build: http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-trepl/0~20160613-g06128f9-1/buildlog Concerning the readline.so problem, if this library is split into another package, then what name the package should take becomes a problem. Since it installs a symlink File: '/usr/lib/x86_64-linux-gnu/lua/5.1/readline.so' -> 'treplutils.so' which means it can't use the `lib*` namespace. Moreover, it is confusing if shipped in a `libtorch-readline` package (libtorch-th ships /usr/lib/x86_64-linux-gnu/libTH.so.0). Oh what about lua-torch-trepl-readline ? but this package used `lua-*` namespace and ships no lua file. with command [1] and [2] and [3] a readline.so can be separately generated but I think there is no much need, although not elegant. 1. I don't know how to name the package shipping only that symlink. 2. lua loads symbols dynamically, such symlink won't harm functionality. Well, that's the reason why I didn't change the readline.so symlink. Please comment, thanks. [1] libtool --silent --tag=CC --mode=compile cc -c -g -O2 -fdebug-prefix-map=/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr//include/lua5.1 -I/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl -Wall -Wextra -o /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/readline.lo readline.c [2] libtool --silent --tag=CC --mode=link cc \ -rpath /usr//lib/x86_64-linux-gnu -version-info 0:0:0 -Wl,--no-add-needed \ -o /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/liblua5.1-torch-trepl.la \ /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/utils.lo /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/readline.lo \ -fPIE -pie -Wl,-z,relro -Wl,-z,now -L/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl -lreadline [3] ln -sf ./.libs/liblua5.1-torch-trepl.so.0.0.0 \ /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/treplutils.so On 7 August 2016 at 16:16, Lumin wrote: > On 4 August 2016 at 18:42, Gianfranco Costamagna > wrote: > >> why do not build-depend on the dev package? >> I'm talking about "lua-torch-torch7" > > This is due to, actually "trepl" doesn't B-D on the "lua-torch-torch7-dev" > package. It is a runtime dependency. I'll leave a comment there. > > Keeping this runtime B-D there because it declares explicit dependency > relationship. > >> also, there is some sadness in the libreadline.so link, are you sure there >> is no better way to fix that? >> what about a package split? > > I've thought about spliting it up -- inspece verbose dh build and > extract the library compilation commands into d/rules -- however this > makes d/rules complicated with hardcoded compiles. > > Seems that dh_lua didn't foresee such a demand, so the above method is > the way first came up in my mind. > > Now that the symlink just works fine ... > > 1. split then up with hardcoded compile > 2. create a new package that ships just a simlink > > How do you like it? > >> cheers, >> >> G. > > > > -- > Best, > Lumin -- Best, Lumin
Bug#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]
Hi, Updated lua-torch-nn package on the mentors site: https://mentors.debian.net/debian/pool/main/l/lua-torch-nn/lua-torch-nn_0~20160812-g461701f+dfsg-1.dsc Debomatic-amd64: PASS http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-nn/0~20160812-g461701f+dfsg-1/buildlog Please sponsor, thanks. On 4 August 2016 at 18:12, Gianfranco Costamagna wrote: > control: owner -1 ! > control: tags -1 moreinfo > control: block -1 by 826715 > > > please ping back when dependencies are in the archive > > G. -- Best, Lumin
Bug#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]
Hi, On 13 August 2016 at 12:36, Gianfranco Costamagna wrote: > > > X: lua-torch-nn: package-contains-no-arch-dependent-files I changed arch from any -> all for bin:lua-torch-nn, because this binary package really contains no arch-dependent files. Apart from that I'm curious about how you find this issue, since I run $ lintian -i -I --pedantic xxx.changes but it didn't report such a problem. > and also, why are you installing files ending with ".c" in usr/include? Sorry for that, this is a mistake, which has been fixed in newly uploaded version. https://mentors.debian.net/debian/pool/main/l/lua-torch-nn/lua-torch-nn_0~20160812-g461701f+dfsg-1.dsc a new spelling fix patch is newly added to this package, which has been merged by upstream within 2 minutes after I submitted it. Debomatic-amd64 itself gets into trouble now, oops ... http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-nn/0~20160812-g461701f+dfsg-1/buildlog -- Best, Lumin
Bug#827582: RFS: lua-torch-xlua/0~20160617-g0dd5f4c-1 [ITP]
Hi, On 4 August 2016 at 18:15, Gianfranco Costamagna 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]
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#834332: RFS: lua-torch-optim/0~20160808-g6c59c35-1 [ITP]
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#834924: RFS: lua-torch-nngraph/0~20160804-g40e4207-1 [ITP]
Package: sponsorship-requests Severity: wishlist Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-nngraph/0~20160804-g40e4207-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-nngraph" * Package name: lua-torch-nngraph Version : 0~20160804-g40e4207-1 Upstream Author : torch developers * URL : github.com/torch/nngraph * License : bsd-3-clause Section : interpreters It builds those binary packages: lua-torch-nngraph - Neural Network Graph Package for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-nngraph Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-nngraph/lua-torch-nngraph_0~20160804-g40e4207-1.dsc Changes since the last upload: lua-torch-nngraph (0~20160804-g40e4207-1) experimental; urgency=low * Initial release. Closes: #827433 -- Best, Lumin
Bug#834925: RFS: lua-torch-xlua/0~20160617-g0dd5f4c-1 [ITP]
Package: sponsorship-requests Severity: wishlist Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-xlua/0~20160617-g0dd5f4c-1/buildlog 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 developers * URL : github.com/torch/xlua * License : bsd-3-clause and mit license (expat) 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-xlua (0~20160617-g0dd5f4c-1) experimental; urgency=low * Initial release. Closes: #826793 -- Best, Lumin
Bug#834926: RFS: lua-torch-sundown/0~20160713-g8353f5a-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "lua-torch-sundown" * Package name: lua-torch-sundown Version : 0~20160713-g8353f5a-1 Upstream Author : torch developers * URL : github.com/torch/sundown-ffi * License : bsd-3-clause and ISC Section : interpreters It builds those binary packages: lua-torch-sundown - Sundown Library (a Markdown implementation) for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-sundown Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-sundown/lua-torch-sundown_0~20160713-g8353f5a-1.dsc Changes since the last upload: lua-torch-sundown (0~20160713-g8353f5a-1) unstable; urgency=low * Initial release. Closes: #827430 -- Best, Lumin
Bug#835025: RFS: lua-torch-torch7/0~20160803-g17ff317-2
Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-torch7/0~20160803-g17ff317-2/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-torch7" * Package name: lua-torch-torch7 Version : 0~20160803-g17ff317-2 Upstream Author : torch developers * 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~20160803-g17ff317-2.dsc Changes since the last upload: lua-torch-torch7 (0~20160803-g17ff317-2) experimental; urgency=medium * Symlink the document directory to the lua directory, in order to fix the lua-torch-dok support. * Diverge the symbols control file of libTH.so for amd64 and i386, since SSE and AVX instruction sets are missing on other architectures. * Override dh_auto_test to run upstream unit test `torch.test()` . * Don't compress markdown document files (*.md), lua-torch-dok doesn't recognize compressed documentations. -- Best, Lumin
Bug#835332: RFS: lua-torch-dok/0~20160131-g1b36900-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "lua-torch-dok" * Package name: lua-torch-dok Version : 0~20160131-g1b36900-1 Upstream Author : torch developers * URL : github.com/torch/dok * License : bsd-3-clause Section : interpreters It builds those binary packages: lua-torch-dok - Support for the old torch7 dok system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-dok Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-dok/lua-torch-dok_0~20160131-g1b36900-1.dsc Changes since the last upload: lua-torch-dok (0~20160131-g1b36900-1) unstable; urgency=low * Initial release. Closes: #827431 -- Best, Lumin
Bug#835346: RFS: lua-torch-torch7/0~20160803-g17ff317-3
Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-torch7/0~20160803-g17ff317-3/buildlog Debomatic-i386: passing, FTBFS fixed. http://debomatic-i386.debian.net/distribution#experimental/lua-torch-torch7/0~20160803-g17ff317-3/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-torch7" * Package name: lua-torch-torch7 Version : 0~20160803-g17ff317-3 Upstream Author : torch developers * URL : github.com/torch/torch7 * License : bsd-3-cluase 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~20160803-g17ff317-3.dsc Changes since the last upload: lua-torch-torch7 (0~20160803-g17ff317-3) experimental; urgency=medium * Add patch fix-32bit-system-abs-failure, changing the test number which exceeds the lower bound of long int. * Don't walk into .pc directory when grabbing files for the unit test, to avoid the surprise that patched scripts being overwrote by original ones under .pc directory. -- Best, Lumin
Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
Hi, The dependencies are present in experimental, trepl is unblocked now. lua-torch-trepl is updated. Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-trepl/0~20160613-g06128f9-1/buildlog https://mentors.debian.net/package/lua-torch-trepl https://mentors.debian.net/debian/pool/main/l/lua-torch-trepl/lua-torch-trepl_0~20160613-g06128f9-1.dsc Please sponsor, thanks :-) On 12 August 2016 at 14:24, Gianfranco Costamagna wrote: > Hi, > >>This is due to, actually "trepl" doesn't B-D on the "lua-torch-torch7-dev" >>package. It is a runtime dependency. I'll leave a comment there. >>Keeping this runtime B-D there because it declares explicit dependency >>relationship. > > > oh, ok > >>I've thought about spliting it up -- inspece verbose dh build and >>extract the library compilation commands into d/rules -- however this >>makes d/rules complicated with hardcoded compiles. >> >>Seems that dh_lua didn't foresee such a demand, so the above method is >>the way first came up in my mind. > >> >>Now that the symlink just works fine ... >> >>1. split then up with hardcoded compile >>2. create a new package that ships just a simlink >> >>How do you like it? > > > no, seems worse. lets keep it > >>Suggests: lua-torch-dok, lua-torch-xlua > > > they need to be packaged first. > > G. > > > > -- > Best, > Lumin -- Best, Lumin
Bug#835659: RFS: lua-torch-image/0~20160730-g797fcb1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-image/0~20160730-g797fcb1-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-image" * Package name: lua-torch-image Version : 0~20160730-g797fcb1-1 Upstream Author : torch developers * URL : github.com/torch/image * License : bsd-3-clause Section : interpreters It builds those binary packages: lua-torch-image - Image Load/Save Library for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-image Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-image/lua-torch-image_0~20160730-g797fcb1-1.dsc Changes since the last upload: lua-torch-image (0~20160730-g797fcb1-1) experimental; urgency=low * Initial release. Closes: #827434 -- Best, Lumin
Bug#835660: RFS: meta-torch-core-free/1~exp1 [ITP] -- Torch core&free stack basically ready
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-scie...@lists.debian.org Note: Please make this upload deferred, since some dependencies are still in the queue. Clarification on the source name: This package is not named "meta-torch-core" because some of torch core components which require CUDA are not yet ready, and cannot be contained in a metapackage in main section. I will make "src:meta-torch-core-contrib" to include those rest contrib components. Debomatic: It will FTBFS untill new:lua-torch-trepl and the lua-torch-image RFS are cleared. Dear mentors, I am looking for a sponsor for my package "meta-torch-core-free" * Package name: meta-torch-core-free Version : 1~exp1 Upstream Author : myself * URL : none * License : bsd-3-clause Section : science It builds those binary packages: torch-core-free - Scientific Computing Framework For Luajit (Core Components) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/meta-torch-core-free Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/meta-torch-core-free/meta-torch-core-free_1~exp1.dsc Changes since the last upload: meta-torch-core-free (1~exp1) experimental; urgency=low * Initial release. (Closes: #794634) -- Best, Lumin
Bug#837209: RFS: lua-torch-nn/0~20160908-g9d7b9ea+dfsg-1
Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-nn/0~20160908-g9d7b9ea+dfsg-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-nn" * Package name: lua-torch-nn Version : 0~20160908-g9d7b9ea+dfsg-1 Upstream Author : torch developers * 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~20160908-g9d7b9ea+dfsg-1.dsc Changes since the last upload: lua-torch-nn (0~20160908-g9d7b9ea+dfsg-1) experimental; urgency=medium * Import upstream snapshot 9d7b9ea4c9ba38e92dc0186af33ff7c0f323d2a4. * Remove patch 'fix-spelling-errors' which was merged to upstream. * Refresh symbols control file. * Override lintianW: symbols-file-contains-debian-revision due to #539066. -- Best, Lumin
Bug#837210: RFS: lua-torch-torch7/0~20160908-ge5ebac6-1
Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-torch7/0~20160908-ge5ebac6-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-torch7" * Package name: lua-torch-torch7 Version : 0~20160908-ge5ebac6-1 Upstream Author : torch developers * 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~20160908-ge5ebac6-1.dsc Changes since the last upload: lua-torch-torch7 (0~20160908-ge5ebac6-1) experimental; urgency=medium * Import upstream snapshot e5ebac6a3d6b14382e4641a8701f23b57e7d6e30. * Remove all patches that were merged to upstream. - fix-spelling-error - fix-32bit-system-abs-failure - TH-cmake-add-version - luaT-cmake-add-version * Use elegant dh_auto_configure instead of hardcoded commands. * Add patch fix-cmake-checkfunctionexists to fix cmake failure. * Refresh symbols control file. * Override lintian misreport. See #539066 * Maintainer is Debian Science Team. * Put myself to Uploaders. -- Best, Lumin
Bug#837886: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
Package: sponsorship-requests Severity: wishlist Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-trepl/0~20160613-g06128f9-1/buildlog 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 + expat Section : interpreters It builds those binary packages: lua-torch-trepl - REPL Package for Troch Framework torch-trepl - Frontend of 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 Changes since the last upload: lua-torch-trepl (0~20160613-g06128f9-1) experimental; urgency=low * Initial release. Closes: #826791 -- Best, Lumin
Bug#838138: RFS: spl-linux/0.6.5.8-0.1 [NMU]
Package: sponsorship-requests Severity: normal X-Debbugs-CC: a...@debian.org Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#unstable/spl-linux/0.6.5.8-0.1/buildlog Sponsor-notice: please wait for confirmation from zfs maintainer a...@debian.org Dear mentors, I am looking for a sponsor for my package "spl-linux" * Package name: spl-linux Version : 0.6.5.8-0.1 Upstream Author : zfsonlinux developers * URL : zfsonlinux.org * License : CDDL Section : kernel It builds those binary packages: spl - Solaris Porting Layer user-space utilities for Linux spl-dkms - Solaris Porting Layer kernel modules for Linux To access further information about this package, please visit the following URL: https://mentors.debian.net/package/spl-linux Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/spl-linux/spl-linux_0.6.5.8-0.1.dsc Changes since the last upload: spl-linux (0.6.5.8-0.1) unstable; urgency=medium * Non-maintainer upload. * New upstream release. (Closes: #835992) * Fix invalid command in dkms, thanks Petter Reinholdtsen. (Closes: #836578) * Bump Standards Version to 3.9.8 .
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU]
Package: sponsorship-requests Severity: normal X-Debbugs-CC: a...@debian.org Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#unstable/zfs-linux/0.6.5.8-0.1/buildlog Sponsor-note: please wait for confirmation from zfs maintainer a...@debian.org Dear mentors, I am looking for a sponsor for my package "zfs-linux" * Package name: zfs-linux Version : 0.6.5.8-0.1 Upstream Author : zfsonlinux developers * URL : zfsonlinux.org * License : CDDL Section : kernel It builds those binary packages: libnvpair1linux - Solaris name-value library for Linux libuutil1linux - Solaris userland utility library for Linux libzfs2linux - OpenZFS filesystem library for Linux libzfslinux-dev - OpenZFS filesystem development files for Linux libzpool2linux - OpenZFS pool library for Linux zfs-dbg- Debugging symbols for OpenZFS userland libraries and tools zfs-dkms - OpenZFS filesystem kernel modules for Linux zfs-dracut - OpenZFS root filesystem capabilities for Linux - dracut zfs-initramfs - OpenZFS root filesystem capabilities for Linux - initramfs zfs-zed- OpenZFS Event Daemon zfsutils-linux - command-line tools to manage OpenZFS filesystems To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zfs-linux Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/z/zfs-linux/zfs-linux_0.6.5.8-0.1.dsc Changes since the last upload: zfs-linux (0.6.5.8-0.1) unstable; urgency=medium * Non-maintainer upload. * New upstream release. * Remove merged patches: - 1003-Add-tunable-to-ignore-hole_birth.patch - 1004-ignore-hole_birth-by-default.patch * Override dh_fixperms to remove executable bit for dsl_pool.c, eliminating lintian warning. * Install zfs-zed.service as zfs.service .
Bug#838138: RFS: spl-linux/0.6.5.8-0.1 [NMU] -- git format-patch
As required by aron.From 02c6e7ab3ff2a1e346956bcfa1a14b1288d9cca7 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:46:19 +
Subject: [PATCH 1/3] dch: import upstream release 0.6.5.8
---
debian/changelog | 7 +++
1 file changed, 7 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 5802ae0..23aff5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+spl-linux (0.6.5.8-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release. (Closes: #835992)
+
+ -- Zhou Mo Sat, 17 Sep 2016 15:53:14 +
+
spl-linux (0.6.5.7-1) unstable; urgency=medium
* Imported Upstream version 0.6.5.7
--
2.9.3
From cb632494fb831f6292b74f6828a0728a9673d80e Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:47:38 +
Subject: [PATCH 2/3] dkms: fix invalid command, thanks Petter Reinholdtsen
---
debian/changelog | 1 +
debian/dkms | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 23aff5d..7a32ef9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ spl-linux (0.6.5.8-0.1) unstable; urgency=medium
* Non-maintainer upload.
* New upstream release. (Closes: #835992)
+ * Fix invalid command in dkms, thanks Petter Reinholdtsen. (Closes: #836578)
-- Zhou Mo Sat, 17 Sep 2016 15:53:14 +
diff --git a/debian/dkms b/debian/dkms
index b349ded..cd477ca 100644
--- a/debian/dkms
+++ b/debian/dkms
@@ -20,7 +20,7 @@ PRE_BUILD="configure
esac)
--with-linux-obj=${kernel_source_dir}
"
-POST_INSTALL="cp
+POST_BUILD="cp
${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/spl_config.h
${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/module/Module.symvers
${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/${kernelver}/${arch}/
--
2.9.3
From 31566f5eca57370721cc032a7e53be1f60b49e06 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:48:33 +
Subject: [PATCH 3/3] control: bump standards version to 3.9.8
---
debian/changelog | 1 +
debian/control| 2 +-
debian/control.in | 2 +-
debian/control.modules.in | 2 +-
4 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 7a32ef9..2c803df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,7 @@ spl-linux (0.6.5.8-0.1) unstable; urgency=medium
* Non-maintainer upload.
* New upstream release. (Closes: #835992)
* Fix invalid command in dkms, thanks Petter Reinholdtsen. (Closes: #836578)
+ * Bump Standards Version to 3.9.8 .
-- Zhou Mo Sat, 17 Sep 2016 15:53:14 +
diff --git a/debian/control b/debian/control
index 51c1318..c412f9c 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: autoconf,
debhelper (>= 9),
dkms (>> 2.2.0.2-1~),
libtool
-Standards-Version: 3.9.6
+Standards-Version: 3.9.8
Homepage: http://www.zfsonlinux.org/
Vcs-Git: git://anonscm.debian.org/pkg-zfsonlinux/spl.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git
diff --git a/debian/control.in b/debian/control.in
index 51c1318..c412f9c 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -11,7 +11,7 @@ Build-Depends: autoconf,
debhelper (>= 9),
dkms (>> 2.2.0.2-1~),
libtool
-Standards-Version: 3.9.6
+Standards-Version: 3.9.8
Homepage: http://www.zfsonlinux.org/
Vcs-Git: git://anonscm.debian.org/pkg-zfsonlinux/spl.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git
diff --git a/debian/control.modules.in b/debian/control.modules.in
index a63f45e..74bf093 100644
--- a/debian/control.modules.in
+++ b/debian/control.modules.in
@@ -11,7 +11,7 @@ Build-Depends: autotools-dev,
libtool,
linux-headers-_KVERS_-common,
linux-headers-_KVERS_
-Standards-Version: 3.9.6
+Standards-Version: 3.9.8
Homepage: http://www.zfsonlinux.org/
Vcs-Git: git://anonscm.debian.org/pkg-zfsonlinux/spl.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git
--
2.9.3
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU] -- git format-patch
As required by aron.
From c552e462652bebf413812e761c71af8e09aeaf67 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:54:20 +
Subject: [PATCH 1/4] dch: import upstream release 0.6.5.8
---
changelog | 7 +++
1 file changed, 7 insertions(+)
diff --git a/changelog b/changelog
index 57a60c1..ed38d2d 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+zfs-linux (0.6.5.8-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release.
+
+ -- Zhou Mo Sat, 17 Sep 2016 16:11:07 +
+
zfs-linux (0.6.5.7-2) unstable; urgency=medium
[ Aron Xu ]
--
2.9.3
From 5697aaa98dd0cda3b878d637c12427cdbf3f89ad Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:56:07 +
Subject: [PATCH 2/4] patches: removed merged patches
---
changelog | 4 ++
.../1003-Add-tunable-to-ignore-hole_birth.patch| 63 --
patches/1004-ignore-hole_birth-by-default.patch| 20 ---
patches/series | 2 -
4 files changed, 4 insertions(+), 85 deletions(-)
delete mode 100644 patches/1003-Add-tunable-to-ignore-hole_birth.patch
delete mode 100644 patches/1004-ignore-hole_birth-by-default.patch
diff --git a/changelog b/changelog
index ed38d2d..cd82551 100644
--- a/changelog
+++ b/changelog
@@ -2,6 +2,10 @@ zfs-linux (0.6.5.8-0.1) unstable; urgency=medium
* Non-maintainer upload.
* New upstream release.
+ * Remove merged patches:
+- 1003-Add-tunable-to-ignore-hole_birth.patch
+- 1004-ignore-hole_birth-by-default.patch
+
-- Zhou Mo Sat, 17 Sep 2016 16:11:07 +
diff --git a/patches/1003-Add-tunable-to-ignore-hole_birth.patch b/patches/1003-Add-tunable-to-ignore-hole_birth.patch
deleted file mode 100644
index 3fed916..000
--- a/patches/1003-Add-tunable-to-ignore-hole_birth.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-Description: Add tunable to ignore hole_birth.
- Adds a module option which disables the hole_birth optimization
- which has been responsible for several recent bugs, including
- issue https://github.com/zfsonlinux/zfs/issues/4050.
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Rich Ercolani
-Reviewed-By: Brian Behlendorf
-Applied-Upstream: 6d836e6f8b358270d55a57ad8e8868c957f15bf3 (master commit)
-Last-Update: 2016-08-16
- man/man5/zfs-module-parameters.5 | 13 +
- module/zfs/dmu_traverse.c| 6 +-
- 2 files changed, 18 insertions(+), 1 deletion(-)
-
a/man/man5/zfs-module-parameters.5
-+++ b/man/man5/zfs-module-parameters.5
-@@ -27,6 +27,19 @@
- .sp
- .ne 2
- .na
-+\fBignore_hole_birth\fR (int)
-+.ad
-+.RS 12n
-+When set, the hole_birth optimization will not be used, and all holes will
-+always be sent on zfs send. Useful if you suspect your datasets are affected
-+by a bug in hole_birth.
-+.sp
-+Use \fB1\fR for on and \fB0\fR (default) for off.
-+.RE
-+
-+.sp
-+.ne 2
-+.na
- \fBl2arc_feed_again\fR (int)
- .ad
- .RS 12n
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,6 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
-+int32_t ignore_hole_birth = 0;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
-@@ -250,7 +251,7 @@
- *
- * Note that the meta-dnode cannot be reallocated.
- */
-- if ((!td->td_realloc_possible ||
-+ if (!ignore_hole_birth && (!td->td_realloc_possible ||
- zb->zb_object == DMU_META_DNODE_OBJECT) &&
- td->td_hole_birth_enabled_txg <= td->td_min_txg)
- return (0);
-@@ -692,4 +693,7 @@
-
- module_param(zfs_pd_bytes_max, int, 0644);
- MODULE_PARM_DESC(zfs_pd_bytes_max, "Max number of bytes to prefetch");
-+
-+module_param(ignore_hole_birth, int, 0644);
-+MODULE_PARM_DESC(ignore_hole_birth, "Ignore hole_birth txg for send");
- #endif
diff --git a/patches/1004-ignore-hole_birth-by-default.patch b/patches/1004-ignore-hole_birth-by-default.patch
deleted file mode 100644
index 5eed797..000
--- a/patches/1004-ignore-hole_birth-by-default.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Description: Enable by default the tunable to ignore hole_birth.
- Once hole_birth becomes more reliable, this patch should be
- removed, making the tunable default back to false.
-Bug: https://github.com/zfsonlinux/zfs/issues/4050
-Bug-Debian: https://bugs.debian.org/830824
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Carlos Alberto Lopez Perez
-Last-Update: 2016-08-16
-
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,7 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
--int32_t ignore_hole_birth = 0;
-+int32_t ignore_hole_birth = 1;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
diff --git a/patches/series b/patches/series
index d9fac31..26e7ae3 100644
--- a/patches/series
+++ b/patches/series
@@ -4,5 +4,3 @@
1000-ppc64el-endian-support.patch
1002-fix-mips-build.patch
enable-zed.patch
-1003-Add-tunable-to-ignore-hole_birth.
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU] -- git format-patch -- version 2
As required by aron.
patch version 2
changes from patch version 1:
* don't attempt to rename zfs-zed.service to zed.service,
we just follow this upstream change.
affected patch 0004From c552e462652bebf413812e761c71af8e09aeaf67 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:54:20 +
Subject: [PATCH 1/4] dch: import upstream release 0.6.5.8
---
changelog | 7 +++
1 file changed, 7 insertions(+)
diff --git a/changelog b/changelog
index 57a60c1..ed38d2d 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+zfs-linux (0.6.5.8-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release.
+
+ -- Zhou Mo Sat, 17 Sep 2016 16:11:07 +
+
zfs-linux (0.6.5.7-2) unstable; urgency=medium
[ Aron Xu ]
--
2.9.3
From 5697aaa98dd0cda3b878d637c12427cdbf3f89ad Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sat, 17 Sep 2016 16:56:07 +
Subject: [PATCH 2/4] patches: removed merged patches
---
changelog | 4 ++
.../1003-Add-tunable-to-ignore-hole_birth.patch| 63 --
patches/1004-ignore-hole_birth-by-default.patch| 20 ---
patches/series | 2 -
4 files changed, 4 insertions(+), 85 deletions(-)
delete mode 100644 patches/1003-Add-tunable-to-ignore-hole_birth.patch
delete mode 100644 patches/1004-ignore-hole_birth-by-default.patch
diff --git a/changelog b/changelog
index ed38d2d..cd82551 100644
--- a/changelog
+++ b/changelog
@@ -2,6 +2,10 @@ zfs-linux (0.6.5.8-0.1) unstable; urgency=medium
* Non-maintainer upload.
* New upstream release.
+ * Remove merged patches:
+- 1003-Add-tunable-to-ignore-hole_birth.patch
+- 1004-ignore-hole_birth-by-default.patch
+
-- Zhou Mo Sat, 17 Sep 2016 16:11:07 +
diff --git a/patches/1003-Add-tunable-to-ignore-hole_birth.patch b/patches/1003-Add-tunable-to-ignore-hole_birth.patch
deleted file mode 100644
index 3fed916..000
--- a/patches/1003-Add-tunable-to-ignore-hole_birth.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-Description: Add tunable to ignore hole_birth.
- Adds a module option which disables the hole_birth optimization
- which has been responsible for several recent bugs, including
- issue https://github.com/zfsonlinux/zfs/issues/4050.
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Rich Ercolani
-Reviewed-By: Brian Behlendorf
-Applied-Upstream: 6d836e6f8b358270d55a57ad8e8868c957f15bf3 (master commit)
-Last-Update: 2016-08-16
- man/man5/zfs-module-parameters.5 | 13 +
- module/zfs/dmu_traverse.c| 6 +-
- 2 files changed, 18 insertions(+), 1 deletion(-)
-
a/man/man5/zfs-module-parameters.5
-+++ b/man/man5/zfs-module-parameters.5
-@@ -27,6 +27,19 @@
- .sp
- .ne 2
- .na
-+\fBignore_hole_birth\fR (int)
-+.ad
-+.RS 12n
-+When set, the hole_birth optimization will not be used, and all holes will
-+always be sent on zfs send. Useful if you suspect your datasets are affected
-+by a bug in hole_birth.
-+.sp
-+Use \fB1\fR for on and \fB0\fR (default) for off.
-+.RE
-+
-+.sp
-+.ne 2
-+.na
- \fBl2arc_feed_again\fR (int)
- .ad
- .RS 12n
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,6 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
-+int32_t ignore_hole_birth = 0;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
-@@ -250,7 +251,7 @@
- *
- * Note that the meta-dnode cannot be reallocated.
- */
-- if ((!td->td_realloc_possible ||
-+ if (!ignore_hole_birth && (!td->td_realloc_possible ||
- zb->zb_object == DMU_META_DNODE_OBJECT) &&
- td->td_hole_birth_enabled_txg <= td->td_min_txg)
- return (0);
-@@ -692,4 +693,7 @@
-
- module_param(zfs_pd_bytes_max, int, 0644);
- MODULE_PARM_DESC(zfs_pd_bytes_max, "Max number of bytes to prefetch");
-+
-+module_param(ignore_hole_birth, int, 0644);
-+MODULE_PARM_DESC(ignore_hole_birth, "Ignore hole_birth txg for send");
- #endif
diff --git a/patches/1004-ignore-hole_birth-by-default.patch b/patches/1004-ignore-hole_birth-by-default.patch
deleted file mode 100644
index 5eed797..000
--- a/patches/1004-ignore-hole_birth-by-default.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Description: Enable by default the tunable to ignore hole_birth.
- Once hole_birth becomes more reliable, this patch should be
- removed, making the tunable default back to false.
-Bug: https://github.com/zfsonlinux/zfs/issues/4050
-Bug-Debian: https://bugs.debian.org/830824
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Carlos Alberto Lopez Perez
-Last-Update: 2016-08-16
-
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,7 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
--int32_t ignore_hole_birth = 0;
-+int32_t ignore_hole_birth = 1;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
diff --git a/patches/series b/patches/series
index d9fac31..26e7ae3 100644
--- a/patc
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU] -- git format-patch -- version 3
patch version 3 is just incremental to version 2. new changes are: * previously "zfs*.service" files are installed to package zfsutils-linux, however zed.service is renamed to zfs-zed.service by upstream, so changed zfsutils-linux.install to avoid installing the service twice.From 5b05d4a5fff78162e9ec4d67dca56b603cb56f77 Mon Sep 17 00:00:00 2001 From: Zhou Mo Date: Sat, 17 Sep 2016 17:32:40 + Subject: [PATCH] Avoid installing zfs-zed.service twice. --- zfsutils-linux.install | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/zfsutils-linux.install b/zfsutils-linux.install index 99cc48c..2b52b35 100644 --- a/zfsutils-linux.install +++ b/zfsutils-linux.install @@ -1,5 +1,8 @@ ../tree/zfsutils/* / -usr/lib/systemd/system/zfs* lib/systemd/system/ +usr/lib/systemd/system/zfs-mount.service lib/systemd/system/ +usr/lib/systemd/system/zfs-share.service lib/systemd/system/ +usr/lib/systemd/system/zfs-import-scan.service lib/systemd/system/ +usr/lib/systemd/system/zfs-import-cache.service lib/systemd/system/ usr/lib/systemd/system-preset/ lib/systemd/ usr/lib/modules-load.d/ lib/ lib/udev/ -- 2.9.3
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU] -- git format-patch -- version 4
Hi,
I refreshed the whole patch stack, with some new changes added.
* add a patch to enable zfs-import-scan.service by default.
in 0.6.5.7 all zfs services are enabled, and in 0.6.5.8 all
services are enabled by upstream except for zfs-import-scan.
* add the missing zfs.target .From 2878754d162ec1e8ad11447b5eadc9d19036e3b3 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sun, 18 Sep 2016 14:23:43 +
Subject: [PATCH 1/5] Patch: remove merged patches.
- 1003-Add-tunable-to-ignore-hole_birth.patch
- 1004-ignore-hole_birth-by-default.patch
---
.../1003-Add-tunable-to-ignore-hole_birth.patch| 63 --
.../1004-ignore-hole_birth-by-default.patch| 20 ---
debian/patches/series | 2 -
3 files changed, 85 deletions(-)
delete mode 100644 debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch
delete mode 100644 debian/patches/1004-ignore-hole_birth-by-default.patch
diff --git a/debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch b/debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch
deleted file mode 100644
index 3fed916..000
--- a/debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-Description: Add tunable to ignore hole_birth.
- Adds a module option which disables the hole_birth optimization
- which has been responsible for several recent bugs, including
- issue https://github.com/zfsonlinux/zfs/issues/4050.
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Rich Ercolani
-Reviewed-By: Brian Behlendorf
-Applied-Upstream: 6d836e6f8b358270d55a57ad8e8868c957f15bf3 (master commit)
-Last-Update: 2016-08-16
- man/man5/zfs-module-parameters.5 | 13 +
- module/zfs/dmu_traverse.c| 6 +-
- 2 files changed, 18 insertions(+), 1 deletion(-)
-
a/man/man5/zfs-module-parameters.5
-+++ b/man/man5/zfs-module-parameters.5
-@@ -27,6 +27,19 @@
- .sp
- .ne 2
- .na
-+\fBignore_hole_birth\fR (int)
-+.ad
-+.RS 12n
-+When set, the hole_birth optimization will not be used, and all holes will
-+always be sent on zfs send. Useful if you suspect your datasets are affected
-+by a bug in hole_birth.
-+.sp
-+Use \fB1\fR for on and \fB0\fR (default) for off.
-+.RE
-+
-+.sp
-+.ne 2
-+.na
- \fBl2arc_feed_again\fR (int)
- .ad
- .RS 12n
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,6 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
-+int32_t ignore_hole_birth = 0;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
-@@ -250,7 +251,7 @@
- *
- * Note that the meta-dnode cannot be reallocated.
- */
-- if ((!td->td_realloc_possible ||
-+ if (!ignore_hole_birth && (!td->td_realloc_possible ||
- zb->zb_object == DMU_META_DNODE_OBJECT) &&
- td->td_hole_birth_enabled_txg <= td->td_min_txg)
- return (0);
-@@ -692,4 +693,7 @@
-
- module_param(zfs_pd_bytes_max, int, 0644);
- MODULE_PARM_DESC(zfs_pd_bytes_max, "Max number of bytes to prefetch");
-+
-+module_param(ignore_hole_birth, int, 0644);
-+MODULE_PARM_DESC(ignore_hole_birth, "Ignore hole_birth txg for send");
- #endif
diff --git a/debian/patches/1004-ignore-hole_birth-by-default.patch b/debian/patches/1004-ignore-hole_birth-by-default.patch
deleted file mode 100644
index 5eed797..000
--- a/debian/patches/1004-ignore-hole_birth-by-default.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Description: Enable by default the tunable to ignore hole_birth.
- Once hole_birth becomes more reliable, this patch should be
- removed, making the tunable default back to false.
-Bug: https://github.com/zfsonlinux/zfs/issues/4050
-Bug-Debian: https://bugs.debian.org/830824
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Carlos Alberto Lopez Perez
-Last-Update: 2016-08-16
-
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,7 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
--int32_t ignore_hole_birth = 0;
-+int32_t ignore_hole_birth = 1;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
diff --git a/debian/patches/series b/debian/patches/series
index d9fac31..26e7ae3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,5 +4,3 @@
1000-ppc64el-endian-support.patch
1002-fix-mips-build.patch
enable-zed.patch
-1003-Add-tunable-to-ignore-hole_birth.patch
-1004-ignore-hole_birth-by-default.patch
--
2.9.3
From 8256e109fd4123f4fd84f905dc9dc8b717714061 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sun, 18 Sep 2016 14:25:04 +
Subject: [PATCH 2/5] Override dh_fixperms, which fixes a lintian warning.
---
debian/rules | 4
1 file changed, 4 insertions(+)
diff --git a/debian/rules b/debian/rules
index 5036f42..08cf981 100755
--- a/debian/rules
+++ b/debian/rules
@@ -139,6 +139,10 @@ override_dh_install:
find . -name lib*.la -delete
dh_install --list-missing
+override_dh_fixperms:
+ dh_fixperms
+ find debian -type f -name dsl_pool.c -exec chmod -x {} + # f
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU] -- git format-patch -- version 4
On Tue, 2016-09-20 at 04:29 +0800, Aron Xu wrote: > > Hi, > > I still have question on your patchset: > > 1. There is no need to override dh_fixperm explicitly for this > warning, this should be fixed upstream to remove the executable bit. Ok, got it. > > 2. From what I read the disabled status of zfs-import-scan.service is > intended, I wonder if this is preventing mounts when ZFS is used as > rootfs (so you make it enabled explicitly): > https://github.com/zfsonlinux/zfs/commit/92547bc45ca9a2114662d9343ae5 > 3e5098acb627 Well, this 'enable zfs-import-scan' change is due to my misunderstanding in previous discussion, however it's my fault not to check upstream document about the reason why that default was made. My root is still ext4 so I cannot verify zfs-initramfs behaviour. > > Thanks, > Aron
Bug#838740: RFS: lua-torch-trepl/0~20160613-g06128f9-2
Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-trepl/0~20160613-g06128f9-2/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-trepl" * Package name: lua-torch-trepl Version : 0~20160613-g06128f9-2 Upstream Author : torch developers * URL : github.com/torch/trepl * License : basically bsd-3-clause Section : interpreters It builds those binary packages: lua-torch-trepl - REPL Package for Troch Framework torch-trepl - Frontend of 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-2.dsc Changes since the last upload: lua-torch-trepl (0~20160613-g06128f9-2) experimental; urgency=medium * Fix hardcoded multiarch triplet in lua-torch-trepl.links . P.S. Actually this fixes a lintian Error.
Bug#838740: RFS: lua-torch-trepl/0~20160613-g06128f9-2
On Tue, 2016-09-27 at 11:59 +, Gianfranco Costamagna wrote: > Hi, > > > P.S. Actually this fixes a lintian Error. > > ough! I missed it thanks! No you didn't missed it, nor did I. This lintian warning emerges only on non-amd64 architecture. :-)
Bug#838740: RFS: lua-torch-trepl/0~20160613-g06128f9-2
On Tue, 2016-09-27 at 11:59 +, Gianfranco Costamagna wrote: > Hi, > > > P.S. Actually this fixes a lintian Error. > > ough! I missed it thanks! No you didn't missed it, nor did I. This lintian warning emerges only on non-amd64 architecture. :-)
[buildd] unexpected FTBFS on amd64 buildd «binet»
Hi there, I encountered an unexpected FTBFS on amd64 that I can't repro.[1] And I'd like to ask the list before fixing it by e.g. an binary only upload. My package lua-torch-torch7/experimental fails[2] to build from source because of an "illegal instruction" error at the debhelper auto test stage. However from that buildlog I can't tell which program to blame -- luajit or lua-torch-torch7. The upstream code indeed contains instruction specific stuff but I have never encountered such failure on amd64 architecture. Besides, I tested this package with debomatic-amd64[3] and the result is quite healthy. So I have trouble allocating where the source of problem is. Cosmic ray? My questions: * should we suspect the health state of that amd64 buildd machine «binet»? * what should I do next? do a binary-only amd64 upload or request (and how) for a rebuild against that package? [1] https://buildd.debian.org/status/package.php?p=lua-torch-torch7&suite=experimental [2] https://buildd.debian.org/status/fetch.php?pkg=lua-torch-torch7&arch=amd64&ver=0%7E20161013-g4f7843e-1&stamp=1476616893 [3] http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-torch7/0~20161013-g4f7843e-1/buildlog
Bug#844608: RFS: protobuf/3.0.0-7.1 [NMU]
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: t...@beamnet.de
Clarification:
* This NMU adds binary package python3-protobuf (#836821),
I've sent a patch there a month ago but got no response
from maintainer.
see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836821
* While building this package I encountered a randomly
happening BUG. Then I find that the protobuf maintainer
encountered exactly the same problem several months ago.
However I don't know which python version the maintainer
was using when he encountered this problem. If it's
python2, then I think this bug is not specific to python3,
hence not blocking python3-protobuf.
see: https://github.com/google/protobuf/issues/1995
* I need python3-protobuf as both B-D and Runtime-Dep for
my package.
* I performed only local build test. Debomatic-amd64 seems
failing at this time.
see:
http://debomatic-amd64.debian.net/distribution#unstable/protobuf/3.0.0-7.1/buildlog
* The latest git-format-patch is attached.
Dear mentors,
I am looking for a sponsor for my package "protobuf"
* Package name: protobuf
Version : 3.0.0-7.1
Upstream Author : [fill in name and email of upstream]
* URL : [fill in URL of upstreams web site]
* License : [fill in]
Section : devel
It builds those binary packages:
libprotobuf-dev - protocol buffers C++ library (development files)
libprotobuf-java - Java bindings for protocol buffers
libprotobuf-lite10 - protocol buffers C++ library (lite version)
libprotobuf10 - protocol buffers C++ library
libprotoc-dev - protocol buffers compiler library (development files)
libprotoc10 - protocol buffers compiler library
protobuf-compiler - compiler for protocol buffer definition files
python-protobuf - Python bindings for protocol buffers
python3-protobuf - Python 3 bindings for protocol buffers
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/protobuf
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/p/protobuf/protobuf_3.0.0-7.1.dsc
Changes since the last upload:
protobuf (3.0.0-7.1) unstable; urgency=medium
* Non-maintainer upload.
* Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821)
* Add missing B-D "libgtest-dev". (Closes: #836826)From f13503ae9081d0ce9d7149f537db5177705b29d0 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Thu, 17 Nov 2016 15:17:48 +
Subject: [PATCH] Add binary package python3-protobuf
---
debian/changelog | 8
debian/clean | 2 ++
debian/control| 25 +
debian/python-protobuf3.README.Debian | 11 +++
debian/rules | 24
5 files changed, 66 insertions(+), 4 deletions(-)
create mode 100644 debian/python-protobuf3.README.Debian
diff --git a/debian/changelog b/debian/changelog
index 26f245d..0960be1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+protobuf (3.0.0-7.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821)
+ * Add missing B-D "libgtest-dev". (Closes: #836826)
+
+ -- Zhou Mo Thu, 17 Nov 2016 13:30:28 +
+
protobuf (3.0.0-7) unstable; urgency=medium
* Team upload.
diff --git a/debian/clean b/debian/clean
index f723754..a16e6fe 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1 +1,3 @@
protoc.1
+debian/autoreconf.after
+debian/autoreconf.before
diff --git a/debian/control b/debian/control
index 7e73b8c..d0047c6 100644
--- a/debian/control
+++ b/debian/control
@@ -16,11 +16,15 @@ Build-Depends:
, g++ (>= 4:4.7)
, zlib1g-dev
, google-mock
+ , libgtest-dev
# Python
, dh-python
, python-all (>= 2.7)
, libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
, python-setuptools
+ , python3-setuptools
, python-google-apputils
# Manpage generator
, xmlto
@@ -181,6 +185,27 @@ Description: Python bindings for protocol buffers
definition to Python classes, and then the modules in this package will allow
you to use those classes in your programs.
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are
Bug#844608: Acknowledgement (RFS: protobuf/3.0.0-7.1 [NMU])
Hi,
I just updated the package on mentors,
https://mentors.debian.net/debian/pool/main/p/protobuf/protobuf_3.0.0-7.1.dsc
https://mentors.debian.net/package/protobuf
And it passed the build on debomatic-amd64
http://debomatic-amd64.debian.net/distribution#unstable/protobuf/3.0.0-7.1/buildlog
The updated patch is attached.diff -Nru protobuf-3.0.0/debian/changelog protobuf-3.0.0/debian/changelog
--- protobuf-3.0.0/debian/changelog 2016-09-02 06:57:13.0 +
+++ protobuf-3.0.0/debian/changelog 2016-11-17 13:30:28.0 +
@@ -1,3 +1,12 @@
+protobuf (3.0.0-7.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821)
+ * Add the missing B-D "libgtest-dev". (Closes: #836826)
+ * Add "python3-six" to B-D, which is required by python3 test.
+
+ -- Zhou Mo Thu, 17 Nov 2016 13:30:28 +
+
protobuf (3.0.0-7) unstable; urgency=medium
* Team upload.
diff -Nru protobuf-3.0.0/debian/clean protobuf-3.0.0/debian/clean
--- protobuf-3.0.0/debian/clean 2016-08-21 08:54:48.0 +
+++ protobuf-3.0.0/debian/clean 2016-11-17 13:30:28.0 +
@@ -1 +1,3 @@
protoc.1
+debian/autoreconf.after
+debian/autoreconf.before
diff -Nru protobuf-3.0.0/debian/control protobuf-3.0.0/debian/control
--- protobuf-3.0.0/debian/control 2016-08-25 22:28:51.0 +
+++ protobuf-3.0.0/debian/control 2016-11-17 13:30:28.0 +
@@ -16,12 +16,17 @@
, g++ (>= 4:4.7)
, zlib1g-dev
, google-mock
+ , libgtest-dev
# Python
, dh-python
, python-all (>= 2.7)
, libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
, python-setuptools
+ , python3-setuptools
, python-google-apputils
+ , python3-six
# Manpage generator
, xmlto
# Tests
@@ -180,6 +185,27 @@
need the protoc tool (in the protobuf-compiler package) to compile your
definition to Python classes, and then the modules in this package will allow
you to use those classes in your programs.
+
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
Package: libprotobuf-java
Architecture: all
diff -Nru protobuf-3.0.0/debian/python-protobuf3.README.Debian protobuf-3.0.0/debian/python-protobuf3.README.Debian
--- protobuf-3.0.0/debian/python-protobuf3.README.Debian 1970-01-01 00:00:00.0 +
+++ protobuf-3.0.0/debian/python-protobuf3.README.Debian 2016-11-17 13:30:28.0 +
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds Thu, 28 Aug 2014 21:10:30 -0700
diff -Nru protobuf-3.0.0/debian/rules protobuf-3.0.0/debian/rules
--- protobuf-3.0.0/debian/rules 2016-08-25 00:28:25.0 +
+++ protobuf-3.0.0/debian/rules 2016-11-17 13:30:28.0 +
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh $@ --with autoreconf,python2 --parallel
+ dh $@ --with autoreconf,python2,python3 --parallel
override_dh_auto_build-arch:
## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -14,8 +14,10 @@
# Generate the manpage.
xmlto man debian/protoc.xml
- # Python build.
+ # Python and Python3 build.
+ cp -rv python python3
cd python && python setup.py build --cpp_implementation
+ cd python3 && python3 setup.py build --cpp_implementation
override_dh_auto_build-indep:
dh_auto_build --indep
@@ -42,8 +44,14 @@
# Python test.
set -e; \
export LD_LIBRARY_PATH=$(CURDIR)/src/.libs; \
- cd python && for python in $(shell pyversions -r); do \
- $$python setup.py test --cpp_implementation; \
+ cd python && for PYTHON in $(shell pyversions -r); do \
+ $$PYTHON setup.py test --cpp_implementation; \
+ done
+# Python3 test.
+ set -e; \
+ export LD_LIBRARY_PATH=$(
Bug#844608: Looking for sponsor for protobuf NMU
Hi,
I prepared an NMU for protobuf for adding
python3-protobuf binary package, and now
I'm asking for maintainer comments and
looking for sponsor.
The package is available at
https://mentors.debian.net/package/protobuf
https://mentors.debian.net/debian/pool/main/p/protobuf/protobuf_3.0.0-7.1.dsc
And it passed debomatic-amd64 test:
http://debomatic-amd64.debian.net/distribution#unstable/protobuf/3.0.0-7.1/buildlog
Thanks!
P.S. The latest patch is attached.diff -Nru protobuf-3.0.0/debian/changelog protobuf-3.0.0/debian/changelog
--- protobuf-3.0.0/debian/changelog 2016-09-02 06:57:13.0 +
+++ protobuf-3.0.0/debian/changelog 2016-11-17 13:30:28.0 +
@@ -1,3 +1,12 @@
+protobuf (3.0.0-7.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821)
+ * Add the missing B-D "libgtest-dev". (Closes: #836826)
+ * Add "python3-six" to B-D, which is required by python3 test.
+
+ -- Zhou Mo Thu, 17 Nov 2016 13:30:28 +
+
protobuf (3.0.0-7) unstable; urgency=medium
* Team upload.
diff -Nru protobuf-3.0.0/debian/clean protobuf-3.0.0/debian/clean
--- protobuf-3.0.0/debian/clean 2016-08-21 08:54:48.0 +
+++ protobuf-3.0.0/debian/clean 2016-11-17 13:30:28.0 +
@@ -1 +1,3 @@
protoc.1
+debian/autoreconf.after
+debian/autoreconf.before
diff -Nru protobuf-3.0.0/debian/control protobuf-3.0.0/debian/control
--- protobuf-3.0.0/debian/control 2016-08-25 22:28:51.0 +
+++ protobuf-3.0.0/debian/control 2016-11-17 13:30:28.0 +
@@ -16,12 +16,17 @@
, g++ (>= 4:4.7)
, zlib1g-dev
, google-mock
+ , libgtest-dev
# Python
, dh-python
, python-all (>= 2.7)
, libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
, python-setuptools
+ , python3-setuptools
, python-google-apputils
+ , python3-six
# Manpage generator
, xmlto
# Tests
@@ -180,6 +185,27 @@
need the protoc tool (in the protobuf-compiler package) to compile your
definition to Python classes, and then the modules in this package will allow
you to use those classes in your programs.
+
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
Package: libprotobuf-java
Architecture: all
diff -Nru protobuf-3.0.0/debian/python-protobuf3.README.Debian protobuf-3.0.0/debian/python-protobuf3.README.Debian
--- protobuf-3.0.0/debian/python-protobuf3.README.Debian 1970-01-01 00:00:00.0 +
+++ protobuf-3.0.0/debian/python-protobuf3.README.Debian 2016-11-17 13:30:28.0 +
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds Thu, 28 Aug 2014 21:10:30 -0700
diff -Nru protobuf-3.0.0/debian/rules protobuf-3.0.0/debian/rules
--- protobuf-3.0.0/debian/rules 2016-08-25 00:28:25.0 +
+++ protobuf-3.0.0/debian/rules 2016-11-17 13:30:28.0 +
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh $@ --with autoreconf,python2 --parallel
+ dh $@ --with autoreconf,python2,python3 --parallel
override_dh_auto_build-arch:
## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -14,8 +14,10 @@
# Generate the manpage.
xmlto man debian/protoc.xml
- # Python build.
+ # Python and Python3 build.
+ cp -rv python python3
cd python && python setup.py build --cpp_implementation
+ cd python3 && python3 setup.py build --cpp_implementation
override_dh_auto_build-indep:
dh_auto_build --indep
@@ -42,8 +44,14 @@
# Python test.
set -e; \
export LD_LIBRARY_PATH=$(CURDIR)/src/.libs; \
- cd python && for python in $(shell pyversions -r); do \
- $$python setup.py test --cpp_implementation; \
+ cd python && for PYTHON in $(shel
Bug#844608: [Pkg-protobuf-devel] Looking for sponsor for protobuf NMU
Hi, On Tue, 2016-11-22 at 08:44 +, Gianfranco Costamagna wrote: > > and sponsored in deferred/5. Where can I find the deferred package? I found nothing at https://ftp-master.debian.org/deferred/ I'd like to confirm the package you sponsored shipped the correct patch, since the original one is somewhat buggy. The correct patch contains changelog like so: +protobuf (3.0.0-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821) + * Add the missing B-D "libgtest-dev". (Closes: #836826) + * Add "python3-six" to B-D, which is required by python3 test. P.S. python module "six" is required according to setup.py, I found that debomatic-amd64 tried to download and install the "six" package with pip at the python3 test stage, which should never happen according to policy (no download during build). Hence the addition of python3-six.
Bug#844608: [Pkg-protobuf-devel] Looking for sponsor for protobuf NMU
On Thu, 2016-11-24 at 14:37 +, Gianfranco Costamagna wrote: > > I don't think it was a bad upload, because I used DoM to build and > test it. Thank you for confirmation. I checked the package at DoM and it is correct. So let's wait for maintainers' comments.
Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU
On Thu, 2016-11-24 at 20:39 +0100, László Böszörményi (GCS) wrote: > > Your changes seem to be correct. I plan to upload the attached diff > in some hours if you don't mind. I see it in the NEW queue, thank you!
Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU
On Thu, 2016-11-24 at 20:39 +0100, László Böszörményi (GCS) wrote:
> Your changes seem to be correct. I plan to upload the attached diff
> in some hours if you don't mind.
It is now present in unstable. However the buildd status seems bad.
ppc64el due to segfault during python2 test.
kfreebsd-* had never compiled protobuf since 3.x.x release.
armel,armhf,hppa,i386,mips,mipsel,powerpc,x32 failed during python3 test due to
the same reason:
Traceback (most recent call last):
File "/«PKGBUILDDIR»/python3/google/protobuf/internal/reflection_test.py",
line 639, in testIntegerTypes
TestGetAndDeserialize('optional_uint32', 1 << 31, long)
NameError: name 'long' is not defined
There is no "long" type in python3, so this is an upstream
py2 -> py3 porting bug. See:
https://github.com/google/protobuf/issues/1504
I looked into protobuf's code at master branch and it seems to be solved:
https://github.com/google/protobuf/blob/master/python/google/protobuf/internal/reflection_test.py#L658-L659
https://github.com/google/protobuf/blob/master/python/google/protobuf/internal/reflection_test.py#L642-L645
Should we consider to cherry-pick the corresponding upstream commit to
Debian's protobuf 3.0.0 package or, to import protobuf 3.1.0
(maybe impossible due to transition freeze) ?
[1] https://buildd.debian.org/status/logs.php?pkg=protobuf&ver=3.0.0-8
[2] https://github.com/google/protobuf/releases
Maintaining C++ library symbols control file with unstable mangled symbols
Hi mentors,
I need advise on the way maintaining symbols control file when
the mangled C++ symbols are unstable.
I'm maintaining a package named "Caffe". I migrated the same
source from experimental to unstable, and it FTBFS'ed as you
see at [0], due to the mangled C++ symbols change. Actually
this package FTBFS'ed many times in the history due to
symbols change. (I have no e.g. ppc64el machine, hence
unable to test before upload)
The trouble I encountered:
I can test my source on DOM-{amd64,i386} to avoid FTBFS
on amd64 and i386 however I cannot take care of other
architectures such as ppc64el because I have no such hardware.
Besides, DOM-ppc64el, emulated by QEMU, seems not quite
reliable as native machine does. Then what I could do
is upload and wait for FTBFS, and then pick the patch,
and upload again...
What I found in order to solve this problem:
* dev-ref refered nothing about this issue, and neither does [1],
which is referenced in dev-ref.
* I don't want to set DPKG_GENSYMBOLS_CHECK_LEVEL, avoiding
the situation where the symbols changed but I'm not aware of it.
See dpkg-gensymbols(1) .
* As mentioned in dpkg-gensymbols(1) I can use `c++filt` to
de-mangle the symbols into a sane form. I quickly went
through some pages of the search results [2] but didn't
found someone maintaining symbols with c++filt (maybe
I should look into it deeper?).
So my question:
* How can I reduce the probability that my package FTBFSs
due to an C++ symbols change? It would change even if I
migrated the same source from experimental to unstable.
* What else can I do to maintain symbols for those rare
architectures e.g. ppc64el? This pipeline seems very bad:
(upload ->
wait for FTBFS ->
pick the patch from buildlog ->
refresh symbols and upload again)
Thanks in advance!
[0] https://buildd.debian.org/status/package.php?p=caffe
[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
[2] https://codesearch.debian.net/search?q=c\%2B\%2Bfilt
Bug#847426: RFS: fortune-zh/2.0
Package: sponsorship-requests Severity: normal X-Debbugs-CC: a...@debian.org, as...@debian.org, 073p...@gmail.com Dear mentors, I am looking for a sponsor for my package "fortune-zh" * Package name: fortune-zh Version : 2.0 Upstream Author : myself * URL : http://anonscm.debian.org/cgit/chinese/fortune-zh.git * License : GPL-3+ 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: https://mentors.debian.net/package/fortune-zh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fortune-zh/fortune-zh_2.0.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#unstable/fortune-zh/2.0/buildlog Changes since the last upload: fortune-zh (2.0) unstable; urgency=medium * New 2.X release. * Bump standards version to 3.9.8 . (requires no change) * Use https link in both Vcs-Git and Vcs-Browser section. * Fix invalid encodings in tang300 (LP: #499664) * Add new Chinese cookie under chinese.d/ . * Rewrite d/copyright in dep8 machine-readable style. * Update package description. * Update manpage man/fortune-zh.6 . * Simplify Makefile, removing redundant lines. * Remove .u8 symlinks. Use fortune-zh.links to create symlinks instead. * Override false positive lintian: capitalization-error-in-description . * Add autopkgtest support -- test fortune-zh script and cookie files. * Update fortune-zh script. [ Boyuan Yang ] * Add a Simplified Chinese manpage.
Bug#847426: RFS: fortune-zh/2.0
On Fri, 2016-12-09 at 12:52 +, Gianfranco Costamagna wrote: > > hopefully somebody from your team will pick it up, but > I already trust you enough to sponsor this package Thank you. > compat level is 10 now (debhelper >=10) I found the debhelper compatibility transition note on manpage debhelper(7). Will fix this. > but something I really would like is to fix VCS-Browser field > -Vcs-Browser: http://anonscm.debian.org/gitweb/?p=chinese/fortune-zh.git > +Vcs-Browser: https://anonscm.debian.org/cgit/chinese/fortune-zh.git OK. > other stuff LGTM, if you can change that Vcs bit I'll sponsor it. > (if nobody objects) Several days had passed. It seems no one of d-chinese team object to this upload. I'll do a new upload later.
Bug#847426: RFS: fortune-zh/2.0
Hi, Uploaded updated fortune-zh package to mentors: https://mentors.debian.net/debian/pool/main/f/fortune-zh/fortune-zh_2.0.dsc The changes I've made can be viewed here: https://anonscm.debian.org/git/chinese/fortune-zh.git/log/ (the latest 3 commits) Buildlog is good although DoM-amd64 seems problematic: http://debomatic-amd64.debian.net/distribution#unstable/fortune-zh/2.0/buildlog Is this acceptable?
Bug#849273: RFS: gemmlowp/0~20161216-gb56df4a-1 [ITP]
Package: sponsorship-requests Severity: wishlist Notes: * It is a Tensorflow dependency. * It is a header-only package with unit tests. * I plan to keep it in experimental for some time. * Its default build system is Bazel, I translated its original buildsystem into CMake for building the unit tests. CMakeLists was forwarded upstream: https://github.com/google/gemmlowp/pull/63 * DoM-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/gemmlowp/0~20161216-gb56df4a-1/buildlog Dear mentors, I am looking for a sponsor for my package "gemmlowp" * Package name: gemmlowp Version : 0~20161216-gb56df4a-1 Upstream Author : Google, Intel, ARM * URL : https://github.com/google/gemmlowp * License : Apache-2.0 Section : science It builds those binary packages: gemmlowp-dev - small self-contained low-precision GEMM library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gemmlowp Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gemmlowp/gemmlowp_0~20161216-gb56df4a-1.dsc Changes since the last upload: gemmlowp (0~20161216-gb56df4a-1) experimental; urgency=medium * Initial release. (Closes: #848882)
Bug#849387: RFS: farmhash/0~20161014-g92e897b-1 [ITP]
Package: sponsorship-requests Severity: wishlist Note, * This is a Tensorflow dependency. * DoM-amd64 build is passing. http://debomatic-amd64.debian.net/distribution#experimental/farmhash/0~20161014-g92e897b-1/buildlog Dear mentors, I am looking for a sponsor for my package "farmhash" * Package name: farmhash Version : 0~20161014-g92e897b-1 Upstream Author : Google Inc. * URL : https://github.com/google/farmhash * License : Expat Section : science It builds those binary packages: libfarmhash-dev - FarmHash, a family of hash functions (development files, docs) libfarmhash0 - FarmHash, a family of hash functions (shared library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/farmhash Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/farmhash/farmhash_0~20161014-g92e897b-1.dsc Changes since the last upload: farmhash (0~20161014-g92e897b-1) experimental; urgency=medium * Initial release. (Closes: #848883)
Bug#849387: RFS: farmhash/0~20161014-g92e897b-1 [ITP]
On Tue, 2016-12-27 at 05:10 +0100, Adam Borowski wrote: > > I'm afraid that the -dev package installs a lot of cruft to /usr/share/doc/, > this includes all the sources and test cases for the testsuite, instructions > how to run the testsuite, and so on. > > That place is meant for user documentation, or possibly examples. Thank you for reviewing the package. Initially I was thinking of the convenience of shipping the docs in the -dev package but the fact shows the docs are somewhat mess... I've split up those docs and examples into a separate package farmhash-doc, and uploaded the latest version to mentors: https://mentors.debian.net/debian/pool/main/f/farmhash/farmhash_0~20161014-g92e897b-1.dsc DoM-amd64 build is passing: http://debomatic-amd64.debian.net/distribution#experimental/farmhash/0~20161014-g92e897b-1/buildlog
