Bug#824625: RFS: pentobi/12.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pentobi". Package name: pentobi Version : 12.0-1 Upstream Author : Markus Enzenberger URL : http://pentobi.sourceforge.net/ License : GPL-3.0+ Section : games It builds those binary packages: pentobi - clone of the strategy board game Blokus pentobi-kde-thumbnailer - clone of the strategy board game Blokus - KDE thumbnailer To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pentobi Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pentobi/pentobi_12.0-1.dsc Git repository can be viewed online at https://anonscm.debian.org/git/pkg-games/pentobi.git Changes since the last upload: pentobi (12.0-1) unstable; urgency=medium * New upstream release. * d/control: - Bump Standards-Version to 3.9.8, no changes needed. - Unify Vcs-Git and Vcs-Browser. - Konqueror is not KDE Frameworks 5 application and thus cannot use pentobi-kde-thumbnailer; removed Enhances. * d/copyright: Update copyright years. * d/patches/desktop-semicolon.patch: Add a missing ; in desktop file. * d/rules: Enable all hardening flags. Regards, Juhani Numminen
Bug#824622: RFS: golang-gopkg-square-go-jose.v1/1.0.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "golang-gopkg-square-go-jose.v1": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-square-go-jose.v1.git cd golang-gopkg-square-go-jose.v1 && pristine-tar checkout ../golang-gopkg-square-go-jose.v1_1.0.2.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads 706c5da0100d600139b62485fb23b771b3733e3d refs/heads/master 2773f950f3b6e98fe7f5311e2c7a845a60665817 refs/heads/pristine-tar 37ea841cb4b46d87a6b0b8fd9d77efc95ff06d33 refs/heads/upstream It builds these binary packages: golang-gopkg-square-go-jose.v1-dev -- Javascript Object Signing and Encryption (JOSE) for Go This package is a prerequisite for building acmetool version 0.0.51. Changes since the last upload: golang-gopkg-square-go-jose.v1 (1.0.2-1) unstable; urgency=medium * New upstream release (Closes: #824600) * Update debian/copyright * Rename source package to golang-gopkg-square-go-jose.v1 * Rename binary package to golang-gopkg-square-go-jose.v1-dev * Update XS-Go-Import-Path * Update Standards-Version to 3.9.8 -- Peter Colberg Tue, 17 May 2016 22:46:10 -0400 Regards, Peter
Bug#824621: RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "golang-gopkg-cheggaaa-pb.v1": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-cheggaaa-pb.v1.git cd golang-gopkg-cheggaaa-pb.v1 && pristine-tar checkout ../golang-gopkg-cheggaaa-pb.v1_1.0.3.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads 1c9792371b8fa578383976e5392413faab17ac31 refs/heads/master 14a3ae47662f09852fd6c3928f80ace87d25ccb6 refs/heads/pristine-tar ffedb36e7531cf0a94972deba4b39bc2e1c3ee6e refs/heads/upstream It builds these binary packages: golang-gopkg-cheggaaa-pb.v1-dev -- simple console progress bar for This package is a prerequisite for building acmetool version 0.0.51. Changes since the last upload: golang-gopkg-cheggaaa-pb.v1 (1.0.3-1) unstable; urgency=medium * New upstream release (Closes: #824601) * Rename source package to golang-gopkg-cheggaaa-pb.v1 * Rename binary package to golang-gopkg-cheggaaa-pb.v1-dev * Update XS-Go-Import-Path * Drop Conflicts/Provides/Replaces for golang-pb-dev * Update Standards-Version to 3.9.8 -- Peter Colberg Tue, 17 May 2016 22:45:21 -0400 Regards, Peter
Bug#824619: RFS: golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "golang-github-hlandau-degoutils": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-degoutils.git cd golang-github-hlandau-degoutils && pristine-tar checkout ../golang-github-hlandau-degoutils_0.0~git20160421.0.389a847.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads f514bc6ba949df1503ee7256c9e8089221ddf8e9 refs/heads/master 2c81f74b4a06ab6aaf08b2de2f64d9c67a44135b refs/heads/pristine-tar 308bab8ebaaa97988cc3a2c692cbfae207262326 refs/heads/upstream It builds these binary packages: golang-github-hlandau-degoutils-dev -- miscellaneous utilities for Go This package is a prerequisite for building acmetool version 0.0.51. Changes since the last upload: golang-github-hlandau-degoutils (0.0~git20160421.0.389a847-1) unstable; urgency=medium * New upstream snapshot * Update Standards-Version to 3.9.8 -- Peter Colberg Tue, 17 May 2016 22:46:54 -0400 Regards, Peter
Re: Binaries under "/usr/lib/"
Tiago Ilieve writes: > Hi Mattia, > > (Moving the discussion from BTS to "debian-mentors" mailing list.) > > On 15 May 2016 at 20:25, Mattia Rizzolo wrote: > > Given that in your case you say the binary is not called by anything > > else than the application itself, then why keep it in /usr/bin? > > As "/usr/lib/" is not part of $PATH, how should we deal with this? > Patch every process call to the internal binaries in the upstream > source? Or is there an easier way to work around this? How many process calls are there? The ideal solution IMO is to: * Make the location of application-private binaries configurable at build time, with a simple one-point-of-truth (e.g. a Makefile variable). * Patch every call to those application-private binaries to use the configured location. * Submit that patch upstream, explaining why it's superior behaviour. * Maintain the patch in Debian for the (short?) time while upstream incorporates the patch. -- \ “Having sex with Rachel is like going to a concert. She yells a | `\ lot, and throws frisbees around the room; and when she wants | _o__)more, she lights a match.” —Steven Wright | Ben Finney
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
oops ! accidentally removed gsdh_gnustep symlinks ! Fixed and reuploaded add this line to changelog * Provide a new debian/gnustep-make.links. https://mentors.debian.net/package/gnustep-make or dget -x https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi
Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
>
>
> Depends: gnustep-common (>= ${source:Version}),
> gnustep-common (<< ${source:Version}.1~),
> gobjc,
> -autotools-dev,
> ${misc:Depends},
> -${gnustep:Depends}
> +${perl:Depends}
> +Replaces: gnustep-common (<< 2.6.8-1)
> +Breaks: gnustep-common (<< 2.6.8-1)
>
>
>
> seems fine [1], just two questions: why did you drop gnustep:Depends?
What is the second question ?
Thanks
Eric
Bug#819391: marked as done (RFS: toulbar2/0.9.8 debian-science [ITP])
Your message dated Tue, 17 May 2016 23:36:21 +0200 with message-id <573b8ed5.3050...@debian.org> and subject line Re: Bug#819391: RFS: toulbar2/0.9.8 debian-science [ITP] has caused the Debian Bug report #819391, regarding RFS: toulbar2/0.9.8 debian-science [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 819391: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819391 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, We are looking for a sponsor for the "toulbar2" software, in the debian-science project. A current version of its git repository is available on alioth, in the debian- science/pkg-toulbar2 git repository. Toulbar2 is an open source exact discrete optimization software targeted at solving optimization problems that are described as "Graphical Models" including Cost Function Networks, aka Weighted cConstraint Satisfaction Problems, Markov Random Fields (MAP/MRF), Bayesian Nets (MPE), Weighted MaxSAT, pre linkage files and Quadratic Pseudo Boolean Optimization problems. On such problems, toulbar2 is often more efficient than expensive commercial ILP (Integer Linear Programming) solvers. Toulbar2 has won international solver competitions: the Weighted CSP competition (first, in 2007 and 2008), the Uncertainly in AI challenge (first, in 2010 and 2014) and the Pascal Inference challenge (second, in 2011). It has been used in several scientific publications in machine learning, theoretical computer science, statistical physics, genetics and structural biology. It has been developed for more than 10 years on our FusionForge server, hosted by the MIA (Applied mathematics and Computer Science) Departement of INRA, offering a stable and reliable environment. The forge also hosts the associated costfunctionlib benchmark library: https://mulcyber.toulouse.inra.fr/projects/toulbar2/ https://mulcyber.toulouse.inra.fr/projects/costfunctionlib As a preliminary test, a prerelease of a debian source package can be obtained at https://launchpad.net/~thomas-schiex/+archive/ubuntu/toulbar2 -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-14-generic (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- already sponsored by tille. closing On Wed, 6 Apr 2016 13:15:00 + (UTC) Gianfranco Costamagna wrote: > control: owner -1 ! > control: tags -1 moreinfo > > Hi, lets review! > > rules: > > >-DCMAKE_BUILD_TYPE:STRING=Release > > > please RelWithDebInfo here > > >override_dh_auto_test: > > # Don't run CTest > > > please explain > > changelog: > >Bug#780516 > syntax error. bug: #780516 is right > > control: > priority -> optional > > >Vcs-Git: git://anonscm.debian.org/debian-science/packages/toulbar2.git > >Vcs-Browser: > >http://anonscm.debian.org/gitweb/?p=debian-science/packages/toulbar2.git > > > insecure vcs, deprecated gitweb (cgit now) > > > >Standards-Version: 3.9.6 > 3.9.7 now > > >Architecture: amd64 i386 > > why? > > copyright: please convert in machine-readable format 1.0 > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > (mostly done, but some bits are missing) > > " > > Copyright (c) 2008 Olivier ROUSSEL (olivier.roussel cril.univ-artois.fr > " > > not mentioned in copyright file. > > missing licenses: > > src/SimpleGlob.h: *No copyright* MIT/X11 (BSD like) > > src/xmlcsp/XMLParser_libxml2.hh: MIT/X11 (BSD like) > src/xmlcsp/XMLParser_constants.h: MIT/X11 (BSD like) > src/xmlcsp/XMLParser.hh: MIT/X11 (BSD like) > src/xmlcsp/ExpressionParser.hh: MIT/X11 (BSD like) > src/xmlcsp/CostRepresentation.hh: MIT/X11 (BSD like) signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#820383: RFS: photocollage/1.4.0-1 [ITP]
Hi Mattia,
Thanks for your remarks. I've addressed all of them, as well as
another warning output by `pbuilder --build`.
Cheers,
Adrien
2016-05-15 18:41 GMT+02:00 Mattia Rizzolo :
> control: tag -1 moreinfo
> control: owner -1 !
>
> On Thu, Apr 07, 2016 at 09:33:15PM +0200, Adrien Vergé wrote:
>> I am looking for a sponsor for my package "photocollage"
>
> o/
>
>> dget -x
>> http://mentors.debian.net/debian/pool/main/p/photocollage/photocollage_1.4.0-1.dsc
>
> * d/control:
> + Vcs-* is meant to host the *debian packaging*, not whatever stuff
> upstream does. Cloning it hoping to avoid having to deal with
> tarballs and not fiding what I expected was like => -.- :)
> + Std-Version is 3.9.8 nowadays, please check against it
> * d/copyright:
> + it can't be only 2016. It's in fedora since 2015, and setup.py only
> (?) has 2013. Please be diligent when taking care of copyright
> stuff.
> + you should also consider all the people that submitted translations
> * this is 1.4.0, you already released 1.4.2, care to update?
> * `find -type f -iname '*.desktop' -exec desktop-file-validate {} \;`
> ./data/photocollage.desktop: warning: key "Encoding" in group "Desktop
> Entry" is deprecated
> * `find -type f \( -iname '*.po' -o -iname '*.pot' -o -iname '*.mo' -o -iname
> '*.gmo' \) -exec i18nspector {} +`
> has quite something to say
> * `find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check
> --check-compatibility --check-accelerators --output-file=/dev/null {} \;`
> too.
> * d/watch:
> + you used github, but apparently the tarball comes from pypi. Maybe
> you should use pypi.debian.net instead?
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
> more about me: https://mapreri.org : :' :
> Launchpad user: https://launchpad.net/~mapreri `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 17/05/2016 19:27, Eric Heintzmann a écrit :
> Hi,
> Reuploaded !
https://mentors.debian.net/package/gnustep-make
or
dget -x
https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
Updated changelog:
gnustep-make (2.6.8-1) unstable; urgency=low
* Team upload.
* In agreement with the Debian GNUstep maintainers,
add myself as new Co-Maintainer.
* New upstream version
* Remove patches applied upstream:
+ honor-CFLAGS.patch
+ info-document-missing-direntry.patch
+ library-combo-whatis-entry.patch
+ manpage-spelling-errors.patch
+ test-clean-core.patch
+ texi-section-level.patch
* Update no-gzip-timestamps.patch.
* Update use-makeinfo.patch.
* Bump Standards-Version to 3.6.8 in debian/control.
* Set debhelper compatibility level to 9.
* Update Vcs-* fields in debian/control
* Rewrite debian/rules:
+ Use dh $@ --with autoreconf and --buiddirectory
+ No more use autotools-dev: drop dependencies
+ Disable strict gnustep-make version 2 mode for now
+ Build and install doc in *-indep sequence (Closes: #823281, #806197)
+ Use --with-layout=debian in configure scripts:
- remove fhs-system-includedir.patch
- remove obsolete {gnustep:Depends} var in debian/control
+ Remove debian/control.in file, useless now
+ Remove debian/fhs/gnustep-common.disr.in, now useless
+ Remove debian/fhs/gnustep-common.links.in, now useless
+ Remove debian/gnustep-make.dirs.in, now useless
* Provide a new debian/clean file.
* Update debian/copyright file.
* Update debian/watch file to version 4.
* Replace debian/upstream/signig-key.pgp by signing-key.asc:
remove debian/source/include-binaries file.
* Provide a new debian/gnustep-make-doc.install file.
* Provide a new debian/gnustep-make-doc.info file.
* Rename debian/gnustep-make-doc.doc-base to
debian/gnustep-make-doc.doc-base.gnustep-make.
* Provides new debian/gnustep-make-doc.doc-base.* files.
* Provide a new debian/gnustep-make.install file.
* Provide a new debian/gnustep-make.lintian-overrides file.
* Provide a new debian/gnustep-make.manpages file:
remove debian/gnustep-test.1 file, useless now.
* Provide a new debian/gnustep-make.docs file.
* Rename debian/fhs dir to debian/dh_gnustep.
* gnustep-make now Depends on {perl:Depends}
* New debian/addons dir:
+ remove debian/gs_make.in and debian/config.mk.in, now useless
+ new gs_make and config.mk files in debian/addons dir
+ move debian/gs_make.1 to debian/addons dir
* Remove debian/gnustep-make.dirs.in, useless now.
* Provide a new debian/gnustep-common.maintscript file.
* Provide a new debian/gnustep-common.install file.
* Provide a new debian/gnustep-common.manpages file.
* Provide a new debian/gnustep-common.docs file.
* Provide a new debian/gnustep-common.dirs file.
* Provide a new debian/gnustep-common.links file.
* Provide a new debian/gnustep-common.lintian-overrides file.
* Move gnustep-config.1 manpage to gnustep-make package:
gnustep-make now Replaces and Breaks gnustep-common (<<2.6.8-1).
-- Eric Heintzmann Tue, 03 May 2016 22:13:30
+0200
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi,
Reuploaded !
Le 17/05/2016 18:58, Eric Heintzmann a écrit :
>
>
> Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
>> Hi,
>>> switch to autoreconf done
>>
>> nice!
>>
>> little nitpick before answering to the open points:
>> * debian/patches/manpage-spelling-errors.patch: New, fix two spelling
>> +
>> errors.
>>
>>
>> there is a new space in changelog
>> (pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff
>> the debian changes, you will
>> see it)
>>
> Fixed, thanks
>
>
>>> Breaks + Replace done
>> Depends: gnustep-common (>= ${source:Version}),
>> gnustep-common (<< ${source:Version}.1~),
>> gobjc,
>> -autotools-dev,
>> ${misc:Depends},
>> -${gnustep:Depends}
>> +${perl:Depends}
>> +Replaces: gnustep-common (<< 2.6.8-1)
>> +Breaks: gnustep-common (<< 2.6.8-1)
>>
>>
>>
>> seems fine [1], just two questions: why did you drop gnustep:Depends?
> Let see at dh_gnustep manpage:
>
> "dh_gnustep is a program based on debhelper that is responsible for
> doing GNUstep-specific modifications, such as moving files in the
> GNUstep hierarchy within the System domain, rooted at
> /usr/lib/GNUstep/System, to Filesystem Hierarchy Standard
> (FHS)-compliant locations."
>
> it is obsoleted by configure option --with-layout=debian
> And I have no perl skills to update it.
>
>
> Let s look again at dh_gnustep manpage:
>
> "GNUstep dependencies:
> Adds any extra dependencies needed for GNUstep. Currently, the
> only dependency added is to ensure that the package uses the same
> filesystem layout as the other GNUstep packages installed on the
> system."
>
> In reality {gnustep:Depends} just add a dependencies to virtual package
> provided by gnustep-common: gnustep-fslayout-fhs
> Of course I can add a dependency to gnustep-fslayout-fhs,
> but since gnustep-make depends on latest gnustep-common,
> it is not needed.
>
> I will update changelog like that:
>
> + Use --with-layout=debian in configure scripts:
> - remove fhs-system-includedir.patch
> - remove obsolete {gnustep:Depends} var in debian/control
>> [1]
>> http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts
>
> Thanks for the link
>
> Thanks,
> Eric
>
>
>
>
a few questions on ITP shadowsocks-libev before formal RFS
Dear mentors list, I'm doing ITP packaging on shadowsocks-libev. I have a few questions in detail. I have set up a git repo on github: https://github.com/rogers0/shadowsocks-libev My current changes are pushed to branch: RFC Package builds fine with command: gbp buildpackage -us -uc --git-ignore-branch Some questions/issues that I'm not sure: - Upstream maintained debian/ folder long before, I'm going to keep the original debian/changelog. So I should also keep the upstream as maintainer, and add myself as the uploader? - The package is mainly GPLv3, but it links to OpenSSL library, is that OK? Since there's concern mentioned in debian/README.Debian - Upstream repo includes library source code of libev, libsodium, libudns. Is it OK to keep as it is, or have to remove and make another source tarball? - The answer of above question may affect: whether I should remove copyright of library libev, libsodium, libudns from debian/copyright? - Is it needed to add "dh_autoreconf" in debian/rules? I have tested it, it builds well. - I have no idea on the following lintian error, because postrm/postinst scripts are generated by dh E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls etc/init.d/shadowsocks-libev-local E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls etc/init.d/shadowsocks-libev-tunnel E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls etc/init.d/shadowsocks-libev-server E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls etc/init.d/shadowsocks-libev-redir Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
> Hi,
>> switch to autoreconf done
>
>
> nice!
>
> little nitpick before answering to the open points:
> * debian/patches/manpage-spelling-errors.patch: New, fix two spelling
> +
> errors.
>
>
> there is a new space in changelog
> (pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff the
> debian changes, you will
> see it)
>
Fixed, thanks
>> Breaks + Replace done
>
> Depends: gnustep-common (>= ${source:Version}),
> gnustep-common (<< ${source:Version}.1~),
> gobjc,
> -autotools-dev,
> ${misc:Depends},
> -${gnustep:Depends}
> +${perl:Depends}
> +Replaces: gnustep-common (<< 2.6.8-1)
> +Breaks: gnustep-common (<< 2.6.8-1)
>
>
>
> seems fine [1], just two questions: why did you drop gnustep:Depends?
Let see at dh_gnustep manpage:
"dh_gnustep is a program based on debhelper that is responsible for
doing GNUstep-specific modifications, such as moving files in the
GNUstep hierarchy within the System domain, rooted at
/usr/lib/GNUstep/System, to Filesystem Hierarchy Standard
(FHS)-compliant locations."
it is obsoleted by configure option --with-layout=debian
And I have no perl skills to update it.
Let s look again at dh_gnustep manpage:
"GNUstep dependencies:
Adds any extra dependencies needed for GNUstep. Currently, the
only dependency added is to ensure that the package uses the same
filesystem layout as the other GNUstep packages installed on the
system."
In reality {gnustep:Depends} just add a dependencies to virtual package
provided by gnustep-common: gnustep-fslayout-fhs
Of course I can add a dependency to gnustep-fslayout-fhs,
but since gnustep-make depends on latest gnustep-common,
it is not needed.
I will update changelog like that:
+ Use --with-layout=debian in configure scripts:
- remove fhs-system-includedir.patch
- remove obsolete {gnustep:Depends} var in debian/control
>
> [1]
> http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts
Thanks for the link
Thanks,
Eric
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
On 17/05/16 15:42, lumin wrote:
Thank you for this careful and thorough review!
>
2) why the python3 support is disabled? note: this will require a trip in new
queue, so if possible
I would prefer a python3-only build
Same here. Since the build system leaves you the choice, please consider
packaging the Python 3 version. Python 2 has an expiration date anyway.
As said in Debian's python policy I'm aware of it. Let me
clarify this point here. one of the build dependencies of
python-caffe-* is python*-protobuf, and python3-protobuf
is not possible for current protobuf version in Debian.
In a word, build dependencies not satisfied for python3-caffe-*.
You're right, I think I saw a post on d-devel of someone attempting to
package protobuf for Py3. My bad.
* On a different note, caffe seems to support building the documentation
from source with doxygen. Please consider packaging it in a separate
binary package (caffe-doc). The content of examples/* and models/*
might also fit in this -doc package.
Yeah but I'm thinking about the latex(pdf) document generation,
I don't know should I add Build-Indep on texlive or is there
a "core" package to complete doxygen latex compiling.
doxygen-latex [1]?
[1] https://packages.debian.org/sid/doxygen-latex
I'll build caffe-doc package from "caffe" source, and also recommend
"caffe-doc" package in packages from "caffe-contrib".
We usually put -doc in Suggests for the -dev or -bin package, depending
on what the docs cover (API, user guide...).
* You should consider adding a packaging testsuite. You could start with
a script running part or all the examples shipped in the -doc package,
which would verify that the packaged software run as intended.
Caffe has complete gtest testing routings. According to my
experience of using Caffe, it should be working
if it passed the dh_auto_test.
Just to clarify, I meant this sort of packaging testsuite [2].
[2] https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
What happens during dh_auto_test is completely different. The packaging
testsuite is for CI purposes.
Adding more test is easy, and I think some more testsuite
from me will benifit other maintainers since they can learn
from it how to test this software by hand.
I'll do this.
As said earlier, the minimum is to test what you **install**. Making
sure the packaged examples can be built and run from the packaged
library is an example of such test case.
* You should consider adding some upstream metadata as described in [1].
I am sure the Caffe guys would appreciate that we appropriately forward
the citation information displayed on their README.
I didn't know Debian has such a cool thing. Will do this.
Later, you'll be able to watch the results on the d-science sentinel
for the machine-learning task [3]. The citation will appear at the
bottom of the description, like in other packages.
[3] http://blends.debian.org/science/tasks/machine-learning
* What is the purpose of keeping unapplied patches in d/patches?
Uh I forgot to remove them ... Will fix it.
* Missing uversionmangling in d/watch for appropriate tracking of
release candidate releases.
Since uscan(1) describes uversionmangle I think I can manage it.
* Consider using libblas-dev | libblas.so as Build-Depends instead of
libopenblas-dev. Not everyone is using openblas as its prefered blas
implementation and upstream does not force to use this specific vendor
(do they?), so no reason to force it here either.
No, I don't agree using libblas-dev as build-dep. Caffe only supports
3 BLAS backends: atlas, openblas and Intel MKL. Besides, openblas surpasses
basic BLAS by a large margin on performance, we should not switch
build-dep from openblas/atlas back to basic blas for a computational
intensive application, which would be awkward.
There is a discussion thread about which BLAS to use for the debian package.
Some caffe user believes that, it doesn't matter what BLAS the
maintainer choose, any high-performance one will do.
So I chose openblas after an investigation.
see
https://github.com/BVLC/caffe/issues/2601
You have heard of alternatives [4], haven't you?
[4] https://wiki.debian.org/DebianAlternatives
So, if you b-dep on libopenblas-dev, you will force a linkage on one
specific vendor for blas, and bypass the alternatives concept. This is
what you noticed with `readelf -d` in the issue.
Instead, you should be using libblas-dev | libblas.so, which will
provide a virtual dependency (libblas.so.3) which can be satisfied by
either vendors of blas. See the result with ArrayFire [5].
[5] https://packages.debian.org/sid/libarrayfire-cpu3
* For the future, seems like additional caffe-tools and octave-caffe
binary packages could be created from the content generated by the
matlab/ and tools/ leaves of the source tree. I guess that's what is
acknowledged in debian/TODO.
ELFs under tools/ are shipped in package "caffe-{cpu,cuda}". I prefer this
scheme rather tha
Re: Which libstdc++ library?
On Tue, May 17, 2016 at 04:26:21PM +0200, Ole Streicher wrote: > Or is the correct libstdc++-dev package automatically installed with > g++? You could look at the dependencies yourself. g++-5 Depends: libstdc++-5-dev -- WBR, wRAR signature.asc Description: PGP signature
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 computational intensive application, which would be awkward. There is a discussion thread about which BLAS to use for the debian package. Some caffe user believes that, it doesn't matter what BLAS the maintainer choose, any high-performance one will do. So I chose openblas after an investigation. see https://github.com/BVLC/caffe/issues/2601 > * For the future, seems like
Which libstdc++ library?
Hi, I have a package (dpuser [1]), that during execution may call the c++ compiler g++ for some on-the-fly-generated C++ files that use the standard C++ library. I am now curious on how I need to specify the runtime dependency from the -dev library? The C++ compiler is probably just the "g++" package, but how do I specify the corresponding stdc++ lib? Using libstdc++-5-dev is not nice since it will break if the default gcc switches to version 6 (and also if on some backport version 4 is required). Or is the correct libstdc++-dev package automatically installed with g++? Best regards Ole [1] http://anonscm.debian.org/cgit/debian-astro/packages/dpuser.git/
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
Dear all, On 16/05/16 15:50, Gianfranco Costamagna wrote: Hi Lumin Done. Updated package has been uploaded to mentors: https://mentors.debian.net/package/caffe 1) did you try to enable the Debug build too? without CMAKE_BUILD_TYPE=RelWithDebInfo you won't be able to get automatic debug packages I think I don't think it is true (anymore?), since Debian injects its own "None" build configuration + DEB_*_MAINT_FLAGS. 2) why the python3 support is disabled? note: this will require a trip in new queue, so if possible I would prefer a python3-only build Same here. Since the build system leaves you the choice, please consider packaging the Python 3 version. Python 2 has an expiration date anyway. 3) all the "debian/tmp" strings in install files should/can be removed I guess Indeed, they should probably be removed. (I didn't review all the packaging, just something that might/should be fixed. I'll wait for Ghislain to finish his review ;) * I am really not a fan of the templated configuration of the dh_install files. Worst case, do it programmatically in d/rules rather than declaratively with templates + a call to yet another custom script. AFAIC, this creates a lot of overhead for no obvious benefits from a team-maintenance point-of-view. * Thinking long-term solution, one should just bite the bullet and make the build system multi-arch aware. It's just one module in CMake (GnuInstallDirs) and substituting hardcoded DESTINATION paths with the appropriate CMake variables. I am sure upstream would accept such patch, and all distributions could benefit from it. I have done it multiple times and never encountered resistance upstream. Plus the significant simplification of the debian files... * On a different note, caffe seems to support building the documentation from source with doxygen. Please consider packaging it in a separate binary package (caffe-doc). The content of examples/* and models/* might also fit in this -doc package. * You should consider adding a packaging testsuite. You could start with a script running part or all the examples shipped in the -doc package, which would verify that the packaged software run as intended. * You should consider adding some upstream metadata as described in [1]. I am sure the Caffe guys would appreciate that we appropriately forward the citation information displayed on their README. * What is the purpose of keeping unapplied patches in d/patches? * Missing uversionmangling in d/watch for appropriate tracking of release candidate releases. * Consider using libblas-dev | libblas.so as Build-Depends instead of libopenblas-dev. Not everyone is using openblas as its prefered blas implementation and upstream does not force to use this specific vendor (do they?), so no reason to force it here either. * For the future, seems like additional caffe-tools and octave-caffe binary packages could be created from the content generated by the matlab/ and tools/ leaves of the source tree. I guess that's what is acknowledged in debian/TODO. [1] https://wiki.debian.org/UpstreamMetadata Ghis
Re: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
Hello, After start of packaging and the release of the first 3 versions after port from java to python, I am still looking for a mentor for package inclusion. I have written fixes for open points from first review but there are still some questions open, where I am not sure, how to address them. http://mentors.debian.net/package/logdata-anomaly-miner https://launchpad.net/logdata-anomaly-miner PS: As the miner should ease detection, analysis but of security relevant information, e.g. it was useful to (re)discover and develop a POC for the following kernel crash: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1508737/comments/5 By adding logdata-anomaly-miner to Debian, it might help others to also discover strange behaviour. smime.p7s Description: S/MIME cryptographic signature
Bug#824555: marked as done (RFS: python-arrayfire/3.3.20160516-1)
Your message dated Tue, 17 May 2016 13:26:06 + (UTC) with message-id <1975164854.5942837.1463491566836.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#824555: RFS: python-arrayfire/3.3.20160516-1 has caused the Debian Bug report #824555, regarding RFS: python-arrayfire/3.3.20160516-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 824555: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824555 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-arrayfire" * Package name: python-arrayfire Version : 3.3.20160516-1 Upstream Author : ArrayFire * URL : https://github.com/arrayfire/arrayfire-python * License : BSD Section : python It builds those binary packages: python-arrayfire - Python wrappers for the ArrayFire library (Python 2) python-arrayfire-doc - examples for the ArrayFire Python wrappers python3-arrayfire - Python wrappers for the ArrayFire library (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-arrayfire Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-arrayfire/python-arrayfire_3.3.20160516-1.dsc Successful build log on debomatic is available here: http://debomatic-amd64.debian.net/distribution#unstable/python-arrayfire/3.3.20160516-1/buildlog Changes since the last upload: * New upstream release. * d/copyright: add upstream contact information. * Add upstream metadata. Regards, Ghislain Vaillant --- End Message --- --- Begin Message --- hi, done! g. Il Martedì 17 Maggio 2016 14:57, Ghislain Vaillant ha scritto: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-arrayfire" * Package name: python-arrayfire Version : 3.3.20160516-1 Upstream Author : ArrayFire * URL : https://github.com/arrayfire/arrayfire-python * License : BSD Section : python It builds those binary packages: python-arrayfire - Python wrappers for the ArrayFire library (Python 2) python-arrayfire-doc - examples for the ArrayFire Python wrappers python3-arrayfire - Python wrappers for the ArrayFire library (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-arrayfire Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-arrayfire/python-arrayfire_3.3.20160516-1.dsc Successful build log on debomatic is available here: http://debomatic-amd64.debian.net/distribution#unstable/python-arrayfire/3.3.20160516-1/buildlog Changes since the last upload: * New upstream release. * d/copyright: add upstream contact information. * Add upstream metadata. Regards, Ghislain Vaillant--- End Message ---
Bug#824555: RFS: python-arrayfire/3.3.20160516-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-arrayfire" * Package name: python-arrayfire Version : 3.3.20160516-1 Upstream Author : ArrayFire * URL : https://github.com/arrayfire/arrayfire-python * License : BSD Section : python It builds those binary packages: python-arrayfire - Python wrappers for the ArrayFire library (Python 2) python-arrayfire-doc - examples for the ArrayFire Python wrappers python3-arrayfire - Python wrappers for the ArrayFire library (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-arrayfire Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-arrayfire/python-arrayfire_3.3.20160516-1.dsc Successful build log on debomatic is available here: http://debomatic-amd64.debian.net/distribution#unstable/python-arrayfire/3.3.20160516-1/buildlog Changes since the last upload: * New upstream release. * d/copyright: add upstream contact information. * Add upstream metadata. Regards, Ghislain Vaillant
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi,
>switch to autoreconf done
nice!
little nitpick before answering to the open points:
* debian/patches/manpage-spelling-errors.patch: New, fix two spelling
+
errors.
there is a new space in changelog
(pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff the
debian changes, you will
see it)
>Breaks + Replace done
Depends: gnustep-common (>= ${source:Version}),
gnustep-common (<< ${source:Version}.1~),
gobjc,
-autotools-dev,
${misc:Depends},
-${gnustep:Depends}
+${perl:Depends}
+Replaces: gnustep-common (<< 2.6.8-1)
+Breaks: gnustep-common (<< 2.6.8-1)
seems fine [1], just two questions: why did you drop gnustep:Depends?
[1]
http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts
cheers,
Gianfranco
Bug#821323: marked as done (RFS: reniced/1.20-1)
Your message dated Tue, 17 May 2016 08:49:06 + with message-id <20160517084905.gb10...@chase.mapreri.org> and subject line Re: Bug#821323: RFS: reniced/1.20-1 has caused the Debian Bug report #821323, regarding RFS: reniced/1.20-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 821323: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821323 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "reniced" * Package name: reniced Version : 1.20-1 Upstream Author : Christian Garbs * URL : https://github.com/mmitch/reniced * License : GPL-2 Section : utils It builds those binary packages: reniced- renice running processes based on regular expressions To access further information about this package, please visit the following URL: http://mentors.debian.net/package/reniced Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/reniced/reniced_1.20-1.dsc More information about reniced can be obtained from https://github.com/mmitch/reniced Changes since the last upload: * New upstream release. * debian/compat: - bump version number vom 5 to 9 (no changes) * debian/control: - bump policy version from 3.9.1 to 3.9.7 (no changes) - update Homepage: - bump Build-Depends: debhelper to >= 9 * debian/reniced.init: - switch Required-Stop: from $all to $remote_fs because the 'stop' command does nothing at all * debian/source/format: - add file and set to "3.0 (quilt)" * debian/rules: - remove deprecated DEB_UPDATE_RCD_PARAMS setting - switch from DEB_INSTALL_DOCS_ALL to DEB_INSTALL_CHANGELOGS_ALL to install the HISTORY file as changelog.gz Lintian status: The remaining lintian error "init.d-script-depends-on-all-virtual-facility" is expected and IMHO ok in this case: reniced should be run once after all other daemons have been started in order to set their nice level. This is exactly what the "all" facility is for, as described in the first question on https://wiki.debian.org/LSBInitScripts#Frequent_questions Regards, Christian Garbs -- Christian.Garbshttps://www.cgarbs.de Verallgemeinerungen sind immer falsch. signature.asc Description: Digital signature --- End Message --- --- Begin Message --- On Mon, May 16, 2016 at 05:01:29PM +0200, Christian Garbs wrote: > dget -x > http://mentors.debian.net/debian/pool/main/r/reniced/reniced_1.21-1.dsc uploaded! PS: did you peraphs uploaded to ftp-master by error? There were stale files I had to remove before being able to upload mine :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature --- End Message ---
