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]
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#823478: python3-protobuf3
hi, so the advice i received regarding the name was that i must get it renamed upstream[1]. i don't think this will be possible because: - upstream is an established package, present in PYPI and macports - the developer is MIA (additionally, the official Protocol Buffers 3 supports Python 3 [2] and should be coming to debian soon[3]. as the main point of this package was to allow the use of protocol buffers with Python 3, this reduces the need for this package). hence, i propose to withdraw the package, the RFS and the ITP. also happy to proceed, the work is basically done, but i can't see a way to make it work. with thanks jonathon [1] https://lists.debian.org/debian-mentors/2016/05/msg00462.html [2] https://lists.debian.org/debian-mentors/2016/05/msg00491.html [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool
Cheers for the review Mattia! I'll look into all of this. A few comments: On Sun, May 15, 2016 at 9:19 AM, Mattia Rizzolowrote: > ... > * d/patches/01_makefile_fixes.patch: > + Probably use += instead of ?= in the first CFLAGS? > + I'd rather use install(1) instead of cp(1) > + Really forward at least the DESTDIR/INSTALL change > Yes, thanks for reminding me -- do intend to follow up with upstream. I'm curious if this makefile was perhaps written for some crusty old version of make that doesn't do well with the "optional assignment" syntax used for DESTDIR/INSTALL. I had similar questions about the use of cp vs. install. I'll see if upstream has any strong attachment to any of this. > * d/patches/02_manpage_fixes.patch: > + what's blocking you from forwarding this patch? > Nothing at all, it just hasn't been done yet. > * d/rules: > + get rid of all those useless comments > + DPKG_EXPORT_BUILDFLAGS and the inclusion of buildflags.mk is > useless, please read debhelper(7) > + trailing whitespace at line 22 > + what's wrong with using --sourcedirectory on the dh(1) call instead > of overriding everything like that? > Oh much better idea, didn't know I could do that. > + I'd avoid that "INSTALL=install -D" by patching correctly the > makefile to default INSTALL on install(1) instead of cp(1) (as I > said above) > Sure. Thanks again!
Bug#824713: marked as done (RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-1)
Your message dated Thu, 19 May 2016 01:48:18 +0200 with message-id <20160518234818.ga17...@angband.pl> and subject line Re: Bug#824713: RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-1 has caused the Debian Bug report #824713, regarding RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-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.) -- 824713: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824713 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear Mentors, I am looking for a sponsor for my package "rhythmbox-plugin-alternative-toolbar" * Package name: rhythmbox-plugin-alternative-toolbar Version : 0.17.1-1 Upstream Author : David Mohammed* URL : https://github.com/fossfreedom/alternative-toolbar * License : GPL3+ Section : gnome It builds the binary package: rhythmbox-plugin-alternative-toolbar - Enhanced play controls and interface for Rhythmbox To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.16.3-1.dsc More information about rhythmbox-plugin-alternative-toolbar can be obtained from https://github.com/fossfreedom/alternative-toolbar. Additionally I have a blog post about this work here: https://xpressubuntu.wordpress.com/2015/11/02/rhythmbox-alternative-toolbar-updated/ Notes - this is an update to my previous version v0.16.3 that is in unstable - https://packages.debian.org/sid/rhythmbox-plugin-alternative-toolbar Changes since the last upload: * New upstream release. (Closes: #824708) - Option for dark theme - Display Browse Categories horizontally or vertically - Display app-menu correctly in budgie-desktop - Updated translations from Launchpad.net - correctly toggle search button via CTRL+F - option to force the display of the app-menu if required Tests Run: grep -riE 'fixme|todo|hack|xxx' . suspicious-source pyflakes . pyflakes3 . pep8 --ignore W191 . find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check --check-compatibility --check-accelerators --output-file=/dev/null {} \; from the built and installed package: adequate rhythbox-plugin-alternative-toolbar Regards, David Mohammed (fossfreedom) --- End Message --- --- Begin Message --- On Thu, May 19, 2016 at 12:09:25AM +0100, David Mohammed wrote: > * Package name: rhythmbox-plugin-alternative-toolbar > Version : 0.17.1-1 It's in. -- A tit a day keeps the vet away.--- End Message ---
Bug#824714: marked as done (RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators)
Your message dated Thu, 19 May 2016 01:27:37 +0200 with message-id <20160518232737.ga15...@angband.pl> and subject line Re: Bug#824714: RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators has caused the Debian Bug report #824714, regarding RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators 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.) -- 824714: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824714 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear Sponsors, I am looking for a sponsor for the Debian package testu01 [1], an applied mathematical suite for testing URNG. This very version is a refreshment of the Debian material. Thanks in advance, Jerome [1] https://anonscm.debian.org/cgit/debian-science/packages/testu01.git/ -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) --- End Message --- --- Begin Message --- On Thu, May 19, 2016 at 12:13:13AM +0100, Jerome Benoit wrote: > I am looking for a sponsor for the Debian package testu01 [1], an > applied > mathematical suite for testing URNG. This very version is a refreshment > of > the Debian material. Looks fine, uploaded! Thanks for your contribution to Debian. -- A tit a day keeps the vet away.--- End Message ---
Bug#824714: RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators
Package: sponsorship-requests Severity: normal Dear Sponsors, I am looking for a sponsor for the Debian package testu01 [1], an applied mathematical suite for testing URNG. This very version is a refreshment of the Debian material. Thanks in advance, Jerome [1] https://anonscm.debian.org/cgit/debian-science/packages/testu01.git/ -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#824713: RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-1
Package: sponsorship-requests Severity: wishlist Dear Mentors, I am looking for a sponsor for my package "rhythmbox-plugin-alternative-toolbar" * Package name: rhythmbox-plugin-alternative-toolbar Version : 0.17.1-1 Upstream Author : David Mohammed* URL : https://github.com/fossfreedom/alternative-toolbar * License : GPL3+ Section : gnome It builds the binary package: rhythmbox-plugin-alternative-toolbar - Enhanced play controls and interface for Rhythmbox To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.16.3-1.dsc More information about rhythmbox-plugin-alternative-toolbar can be obtained from https://github.com/fossfreedom/alternative-toolbar. Additionally I have a blog post about this work here: https://xpressubuntu.wordpress.com/2015/11/02/rhythmbox-alternative-toolbar-updated/ Notes - this is an update to my previous version v0.16.3 that is in unstable - https://packages.debian.org/sid/rhythmbox-plugin-alternative-toolbar Changes since the last upload: * New upstream release. (Closes: #824708) - Option for dark theme - Display Browse Categories horizontally or vertically - Display app-menu correctly in budgie-desktop - Updated translations from Launchpad.net - correctly toggle search button via CTRL+F - option to force the display of the app-menu if required Tests Run: grep -riE 'fixme|todo|hack|xxx' . suspicious-source pyflakes . pyflakes3 . pep8 --ignore W191 . find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check --check-compatibility --check-accelerators --output-file=/dev/null {} \; from the built and installed package: adequate rhythbox-plugin-alternative-toolbar Regards, David Mohammed (fossfreedom)
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
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. why some of them are outside that shlibs:Depends and not picked up automatically? talking about python-skimage and python-protobuf 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. 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? 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 ) Gianfranco
Re: upload vsftpd
Hello Jörg, In advance thank you for your work in this package. >vsftpd (3.0.3-4) unstable; urgency=medium > > * Orphan this package. > * Set maintainer to Debian QA Group (See: #824694). You already reported an orphan bug. It's not necessary the upload. Kind regards, -- Julián Moreno Patiño Debian Developer .''`. Debian GNU/{Linux,KfreeBSD} : :' : Free Operating Systems `. `' http://debian.org/ `- GPG Fingerprint: C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60 Registered GNU Linux User ID 488513 signature.asc Description: PGP signature
Re: upload vsftpd
hi, sponsoring soon. g. Il Mercoledì 18 Maggio 2016 21:39, Jörg Frings-Fürstha scritto: Hi, please can someone upload the package vsftpd? The includes only this changes: vsftpd (3.0.3-4) unstable; urgency=medium * Orphan this package. * Set maintainer to Debian QA Group (See: #824694). -- Jörg Frings-Fürst Wed, 18 May 2016 21:11:49 +0200 The package is uploaded to mentors[1]. Many thanks.. CU Jörg [1] https://mentors.debian.net/debian/pool/main/v/vsftpd/vsftpd_3.0.3-4.dsc -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54538 Bausendorf Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home.
upload vsftpd
Hi, please can someone upload the package vsftpd? The includes only this changes: vsftpd (3.0.3-4) unstable; urgency=medium * Orphan this package. * Set maintainer to Debian QA Group (See: #824694). -- Jörg Frings-FürstWed, 18 May 2016 21:11:49 +0200 The package is uploaded to mentors[1]. Many thanks.. CU Jörg [1] https://mentors.debian.net/debian/pool/main/v/vsftpd/vsftpd_3.0.3-4.dsc -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54538 Bausendorf Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#824688: marked as done (RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-1)
Your message dated Wed, 18 May 2016 18:08:06 + with message-id <20160518180805.gi20...@chase.mapreri.org> and subject line Re: Bug#824688: RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-1 has caused the Debian Bug report #824688, regarding RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-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.) -- 824688: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824688 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 the package "golang-gopkg-tylerb-graceful.v1": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-tylerb-graceful.v1.git cd golang-gopkg-tylerb-graceful.v1 && pristine-tar checkout ../golang-gopkg-tylerb-graceful.v1_1.2.5.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads b2f4a085a5d8871281e112da84c5296514731588 refs/heads/master 987b060cdd463d2ebb35308cee655719f84fdef9 refs/heads/pristine-tar 8627cf224c607b547894104956ee0e863594aace refs/heads/upstream It builds these binary packages: golang-gopkg-tylerb-graceful.v1-dev -- Go package for gracefully shutting down HTTP server Changes since the last upload: golang-gopkg-tylerb-graceful.v1 (1.2.5-1) unstable; urgency=medium * New upstream release * Drop patches applied upstream * Update Standards-Version to 3.9.8 -- Peter ColbergWed, 18 May 2016 07:25:08 -0400 Regards, Peter --- End Message --- --- Begin Message --- . On Wed, May 18, 2016 at 01:34:24PM -0400, Peter Colberg wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for the package "golang-gopkg-tylerb-graceful.v1": > > git clone > https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-tylerb-graceful.v1.git > > > cd golang-gopkg-tylerb-graceful.v1 && pristine-tar checkout > ../golang-gopkg-tylerb-graceful.v1_1.2.5.orig.tar.gz > > For verification, these are the current branch heads: > > git show-ref --heads > b2f4a085a5d8871281e112da84c5296514731588 refs/heads/master > 987b060cdd463d2ebb35308cee655719f84fdef9 refs/heads/pristine-tar > 8627cf224c607b547894104956ee0e863594aace refs/heads/upstream > > It builds these binary packages: > > golang-gopkg-tylerb-graceful.v1-dev -- Go package for gracefully shutting > down HTTP server > > Changes since the last upload: > > golang-gopkg-tylerb-graceful.v1 (1.2.5-1) unstable; urgency=medium > > * New upstream release > * Drop patches applied upstream > * Update Standards-Version to 3.9.8 > > -- Peter Colberg Wed, 18 May 2016 07:25:08 -0400 > > Regards, > Peter > -- 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 ---
Bug#824687: marked as done (RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-1)
Your message dated Wed, 18 May 2016 17:44:58 + with message-id <20160518174456.gg20...@chase.mapreri.org> and subject line Re: Bug#824687: RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-1 has caused the Debian Bug report #824687, regarding RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-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.) -- 824687: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824687 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 the package "golang-gopkg-hlandau-easyconfig.v1": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git cd golang-gopkg-hlandau-easyconfig.v1 && pristine-tar checkout ../golang-gopkg-hlandau-easyconfig.v1_1.0.14.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads 9a37627b6a6c43aa818c2d8da40ba8987ce43675 refs/heads/master a15ce4216ac401431e1d9d9935e01cfc81370ab9 refs/heads/pristine-tar 0a93297ad92a0049ea00267d930da2dbdb62c51b refs/heads/upstream It builds these binary packages: golang-gopkg-hlandau-easyconfig.v1-dev -- Go package with easy bindings for configurable Changes since the last upload: golang-gopkg-hlandau-easyconfig.v1 (1.0.14-1) unstable; urgency=medium * New upstream release * Update Standards-Version to 3.9.8 -- Peter ColbergWed, 18 May 2016 07:21:33 -0400 Regards, Peter --- End Message --- --- Begin Message --- . On Wed, May 18, 2016 at 01:31:17PM -0400, Peter Colberg wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for the package > "golang-gopkg-hlandau-easyconfig.v1": > > git clone > https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git > > > cd golang-gopkg-hlandau-easyconfig.v1 && pristine-tar checkout > ../golang-gopkg-hlandau-easyconfig.v1_1.0.14.orig.tar.gz > > For verification, these are the current branch heads: > > git show-ref --heads > 9a37627b6a6c43aa818c2d8da40ba8987ce43675 refs/heads/master > a15ce4216ac401431e1d9d9935e01cfc81370ab9 refs/heads/pristine-tar > 0a93297ad92a0049ea00267d930da2dbdb62c51b refs/heads/upstream > > It builds these binary packages: > > golang-gopkg-hlandau-easyconfig.v1-dev -- Go package with easy bindings for > configurable > > Changes since the last upload: > > golang-gopkg-hlandau-easyconfig.v1 (1.0.14-1) unstable; urgency=medium > > * New upstream release > * Update Standards-Version to 3.9.8 > > -- Peter Colberg Wed, 18 May 2016 07:21:33 -0400 > > Regards, > Peter > -- 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 ---
Bug#824688: RFS: golang-gopkg-tylerb-graceful.v1/1.2.5-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "golang-gopkg-tylerb-graceful.v1": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-tylerb-graceful.v1.git cd golang-gopkg-tylerb-graceful.v1 && pristine-tar checkout ../golang-gopkg-tylerb-graceful.v1_1.2.5.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads b2f4a085a5d8871281e112da84c5296514731588 refs/heads/master 987b060cdd463d2ebb35308cee655719f84fdef9 refs/heads/pristine-tar 8627cf224c607b547894104956ee0e863594aace refs/heads/upstream It builds these binary packages: golang-gopkg-tylerb-graceful.v1-dev -- Go package for gracefully shutting down HTTP server Changes since the last upload: golang-gopkg-tylerb-graceful.v1 (1.2.5-1) unstable; urgency=medium * New upstream release * Drop patches applied upstream * Update Standards-Version to 3.9.8 -- Peter ColbergWed, 18 May 2016 07:25:08 -0400 Regards, Peter
Bug#824687: RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.14-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "golang-gopkg-hlandau-easyconfig.v1": git clone https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-hlandau-easyconfig.v1.git cd golang-gopkg-hlandau-easyconfig.v1 && pristine-tar checkout ../golang-gopkg-hlandau-easyconfig.v1_1.0.14.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads 9a37627b6a6c43aa818c2d8da40ba8987ce43675 refs/heads/master a15ce4216ac401431e1d9d9935e01cfc81370ab9 refs/heads/pristine-tar 0a93297ad92a0049ea00267d930da2dbdb62c51b refs/heads/upstream It builds these binary packages: golang-gopkg-hlandau-easyconfig.v1-dev -- Go package with easy bindings for configurable Changes since the last upload: golang-gopkg-hlandau-easyconfig.v1 (1.0.14-1) unstable; urgency=medium * New upstream release * Update Standards-Version to 3.9.8 -- Peter ColbergWed, 18 May 2016 07:21:33 -0400 Regards, Peter
Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information
On Wed, May 18, 2016 at 03:29:33PM +, Gianfranco Costamagna wrote: > Hi, > > >Done. I removed the override in debian/rules. > > wonderful > > >I went with a mixture of both patches you proposed. I also forwarded>the > >patches to upstream & removed the now useless exports in > >debian/rules. > > > >I've reuploaded the new package to Mentors (same URL). > > > actually that was mostly the same patch I did at the begin, but I didn't send > it > to you by purpose :) > I wanted to see your skills, and see if your conclusion were eventually the > same as mine. > > I have to say I'm satisfied and happy with your changes, so I uploaded it on > unstable. Great. Thank you! > I put it on deferred/1, so the package will show up in ~24 hours or so. > > Sorry for that deferred, but I would like to have one more day of testing :) Sure. > thanks for the nice contribution to Debian, and sorry for being so pedantic > in my > reviews :) > > please continue the nice job you did as new shiny maintainer of the package I'll try my best! Cheers, Fabian
Bug#824489: marked as done (RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information)
Your message dated Wed, 18 May 2016 15:29:33 + (UTC) with message-id <1909380391.7270110.1463585373317.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information has caused the Debian Bug report #824489, regarding RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information 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.) -- 824489: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824489 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 "dwarfutils", which is currently orphaned and which I would like to adopt. * Package name: dwarfutils Version : 20160507-1 Upstream Author : David Anderson * URL : https://www.prevanders.net/dwarf.html License : GPL-2, LGPL-2.1, BSD-3-clause, BSD-2-clause Section : libs It builds those binary packages: dwarfdump - utility to dump DWARF debug information from ELF objects libdwarf-dev - library to consume and produce DWARF debug information To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarfutils Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarfutils/dwarfutils_20160507-1.dsc Changes since the last upload: * New Maintainer (Closes: #822614). * New upstream release (Closes: #822154, #811817, #681748). - Fixes CVE-2016-2091 (Closes: #813148). - Fixes CVE-2015-8750 (Closes: #813182). - Fixes CVE-2015-8538 (Closes: #807817). * Upgrade to source format 3.0 (quilt). * Upgrade to Standards version 3.9.8. * Clean up debian/rules. * Improve long description of dwarfdump (Closes: #659319). * Perform complete copyright review. * Update patches to DEP-3 format. * Add doc-base file for libdwarf-dev. * Compile with -fPIC. Regards, Fabian Wolff --- End Message --- --- Begin Message --- Hi, >Done. I removed the override in debian/rules. wonderful >I went with a mixture of both patches you proposed. I also forwarded>the >patches to upstream & removed the now useless exports in >debian/rules. > >I've reuploaded the new package to Mentors (same URL). actually that was mostly the same patch I did at the begin, but I didn't send it to you by purpose :) I wanted to see your skills, and see if your conclusion were eventually the same as mine. I have to say I'm satisfied and happy with your changes, so I uploaded it on unstable. I put it on deferred/1, so the package will show up in ~24 hours or so. Sorry for that deferred, but I would like to have one more day of testing :) thanks for the nice contribution to Debian, and sorry for being so pedantic in my reviews :) please continue the nice job you did as new shiny maintainer of the package Gianfranco--- End Message ---
Re: a few questions on ITP shadowsocks-libev before formal RFS
Hi, alternative proposal >Now I understand my todo-list, briefly: >- package libraries first: libcork/ipset >- create debian/watch and ds repack >- RFS shadowsocks-libev >- apply for collab-maint access - open ITP bugs for all the libraries (search for wnpp and ITP on google) - package libcork/ipset/shadowsocks-libev all at the same time - RFS for all of the three packages and make them blocked by each other e.g. block shadowsocks-libev RFS bug by the other two. - show your git skills in the meanwhile, and ask for collab-maint access (BTW it isn't requested to have the repo in collab-maint by the current policy) Gianfranco
Re: a few questions on ITP shadowsocks-libev before formal RFS
On Thu, May 19, 2016 at 12:04 AM, Gianfranco Costamagnawrote: > > Hi, > > >>If so, here's our alioth account: rosh-guest, hosiet-guest, >>madeye-guest.>Thank you! > > > you need to send a request to join collab-maint, an alioth account doesn't > grant > your permissions automatically. > I suggest you to use an external repository to show your skills, and then ask > to join > (consider that to join you have to be a Debian Maintainer or to have a Debian > Developer > advocating you) > >>Is this (package the libraries separately) required? or something can >>be done afterwards? > > > up to your eventual sponsor, I personally require that, because it is trivial > to do, > and makes lifes of ftpmasters easier and for other people too. > (unless the library is strictly private for the tool, there is no need to > have an embedded copy) > > you might however try to persuade your sponsor about having them embedded ;) > >>I see source of some packages are repacked as -dfsg, but I didn't find >>how to do "ds" repack. >>It would be helpful if there's a wiki entry or manual. > > > just call it ds, have a README.source in debian directory explaining why, and > the dversionmangle in watch > file should be enough. > Probably somebody should write some wiki :) Dear Gianfranco, Thanks for your reply! Now I understand my todo-list, briefly: - package libraries first: libcork/ipset - create debian/watch and ds repack - RFS shadowsocks-libev - apply for collab-maint access Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information
On Wed, May 18, 2016 at 06:59:10AM +, Gianfranco Costamagna wrote: > I don't see why it can't be patched to work like almost every other tool > that uses a build system, but I don't care a lot about upstream. > > The (possible) issue I foresee is: somebody updates the upstream build system > to install the files too, you update the packaging without checking > that, the Debian upload is buggy because some files are missing. > > in short words, I prefer an useless call, rather than a broken package! Done. I removed the override in debian/rules. > I'm not fluent too, thanks for checking and replying about that, it was > already > fine, but I just wanted to be sure there was a rationale for the change! > > let me know your opinion about the install step, and I'll do the final checks > + sponsoring > > > BTW, I like when a patch/fix can be upstream, so I propose another one (feel > free to reject of course, you are > the maintainer, not me!) > --- dwarfutils-20160507.orig/libdwarf/configure.in > +++ dwarfutils-20160507/libdwarf/configure.in > @@ -127,11 +127,11 @@ AC_TRY_COMPILE([#include ],[ Elf > dnl default-disabled shared > AC_SUBST(build_shared,[none]) > AC_SUBST(dwfpic,[]) > +AC_SUBST(dwfpic,[-fPIC]) > AC_ARG_ENABLE(shared,AC_HELP_STRING([--enable-shared], > [build shared library libdwarf.so])) > AS_IF([ test "x$enable_shared" = "xyes"], [ > AC_SUBST(build_shared,[libdwarf.so]) > - AC_SUBST(dwfpic,[-fPIC]) > ]) > > dnl default-enabled nonshared > > > maybe it makes sense to enable it alsofor static libs then anyway. > (probably all the if block can be removed this way, but this is something > that upstream has to investigate ;)) I went with a mixture of both patches you proposed. I also forwarded the patches to upstream & removed the now useless exports in debian/rules. I've reuploaded the new package to Mentors (same URL).
Re: a few questions on ITP shadowsocks-libev before formal RFS
Hi, >If so, here's our alioth account: rosh-guest, hosiet-guest, >madeye-guest.>Thank you! you need to send a request to join collab-maint, an alioth account doesn't grant your permissions automatically. I suggest you to use an external repository to show your skills, and then ask to join (consider that to join you have to be a Debian Maintainer or to have a Debian Developer advocating you) >Is this (package the libraries separately) required? or something can >be done afterwards? up to your eventual sponsor, I personally require that, because it is trivial to do, and makes lifes of ftpmasters easier and for other people too. (unless the library is strictly private for the tool, there is no need to have an embedded copy) you might however try to persuade your sponsor about having them embedded ;) >I see source of some packages are repacked as -dfsg, but I didn't find >how to do "ds" repack. >It would be helpful if there's a wiki entry or manual. just call it ds, have a README.source in debian directory explaining why, and the dversionmangle in watch file should be enough. Probably somebody should write some wiki :) G.
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
* lumin, 2016-05-18, 12:44: * 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 I've just commited fix for Lintian to include validation error in the output, so in the next version it will be: W: caffe source: upstream-metadata-yaml-invalid mapping values are not allowed in this context (at document 1, line 3, column 16) ...which is (hopefully) more helpful. But in the future, don't count on Lintian contributors reading debian-mentors. If you find Lintian output misleading or unhelpful, please file bugs! :-) -- Jakub Wilk
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.
Re: a few questions on ITP shadowsocks-libev before formal RFS
[Add Max and Boyuan from upstream to CC] Thanks Gianfranco and Jakub! I comment when I still have question, for other parts I'll follow your suggestion. On Wed, May 18, 2016 at 7:13 PM, Jakub Wilkwrote: > * Roger Shimizu , 2016-05-18, 02:14: >> >> 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? > > It doesn't matter who maintained the package in the package. What matters is > who is going to maintain it now for Debian. Did you ask upstream to > co-maintain it with you? You certainly shouldn't put anyone to > Maintainer/Uploaders without their consent. I contacted the upstream (now they're in CC), and they're happy to co-maintain this with me. BTW. I have a few packages uploaded by sponsorship, but I have no experience on collab-maint. I'm not sure whether I can ask you to help to set up a repo on alioth/collab-maint for us? If so, here's our alioth account: rosh-guest, hosiet-guest, madeye-guest. Thank you! >> - The package is mainly GPLv3, but it links to OpenSSL library, is that >> OK? > > GPL+OpenSSL is no-no. > > README says that mbedtls, which is GPL-compatible, can be used as an > alternative to OpenSSL, so you should try it. Yes, it seems I have to try it anyway. >> - 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? > > As long as they are DFSG-free, you can keep them in the source package. Just > make sure they are not used at build time. This is best achieved by "rm > -rf"ing them early in the build process. (If you're using dh, then beginning > of override_dh_auto_build is probably the best place.) This works well. Thank you! >> - 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 > > > This seems to be caused by passing --no-start to dh_installinit: > > dh_installinit --no-start --name=shadowsocks-libev-server@ > dh_installinit --no-start --name=shadowsocks-libev-tunnel@ > dh_installinit --no-start --name=shadowsocks-libev-redir@ > dh_installinit --no-start --name=shadowsocks-libev-local@ > > My initsystem-fu is too weak to tell whether it's a d/rules bug, debhelper > bug, or Lintian bug, or just something that should be overridden. Upstream came to help. After remove the above block (only to use the default debhelper), now lintian is happy on everything. On Wed, May 18, 2016 at 4:05 PM, Gianfranco Costamagna wrote: > >>- 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? > > as long as you don't use them it is fine, please try to package them > separately > and use the system versions, not bundled code Is this (package the libraries separately) required? or something can be done afterwards? > BTW the copyright file has to list them, so there is a tradeoff between > removing files to > have a more readable /easy to maintain copyright file and tarball, and having > a pristine tarball from > upstream. > >>- The answer of above question may affect: whether I should remove>copyright >>of library libev, libsodium, libudns from debian/copyright? > > oops answered above :) > (BTW a repack done not because of non-dfsg files is a "ds" aka Debian Source > repack) I see source of some packages are repacked as -dfsg, but I didn't find how to do "ds" repack. It would be helpful if there's a wiki entry or manual. Thanks again for your helpful advice! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
> On 18 May 2016, at 14:15, James Clarkewrote: > >> On 18 May 2016, at 13:44, lumin wrote: >> * 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 > > You need to quote the colon in "Caffe:”. The entire field, that is (you can’t quote a subset of it afaik), i.e. Title: 'Caffe: Convolutional Architecture for Fast Feature Embedding' > https://wiki.debian.org/UpstreamMetadata recommends > http://yaml-online-parser.appspot.com/ for validation. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
> On 18 May 2016, at 13:44, luminwrote: > * 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 You need to quote the colon in "Caffe:". https://wiki.debian.org/UpstreamMetadata recommends http://yaml-online-parser.appspot.com/ for validation. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
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]
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#824262: marked as done (RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system)
Your message dated Wed, 18 May 2016 11:11:02 + (UTC) with message-id <1807413204.7088758.1463569862453.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system has caused the Debian Bug report #824262, regarding RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system 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.) -- 824262: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824262 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "gnustep-make" * Package name: gnustep-make Version : 2.6.8-1 Upstream Author : GNUstep Maintainer* URL : http://gnustep.org * License : GPL-3+ Section : gnustep It builds those binary packages: gnustep-common - Common files for the core GNUstep environment gnustep-make - GNUstep build system gnustep-make-doc - Documentation for GNUstep Make To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gnustep-make Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc More information about GNUstep can be obtained from http://gnustep.org/information/aboutGNUstep.html Changes since the last upload: gnustep-make (2.6.8-1) unstable; urgency=low . * Team upload. * Add myself as new Co-Maintainer. * New upstream version * Rremove 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-timestampss.patch. * Update use-makeinfo.patch. * Bump Standards-Version to 3.6.8 in debian/control. * Set debhelper combatibility level to 9. * Update Vcs-* fields in debian/control * Remove no more needed {gnustep:Depends} var in debian/control. * Rewrite debian/rules: + Use dh $@ --with autotools-dev, autoreconf and buiddirectory + 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 * Provide a nex 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. * Provide a new debian/gnustep-make.docs file. * Rename debian/fhs dir to debian/dh_gnustep. * New debian/addons dir: move gs_make and config.mk to it. * Update debian/gnustep-common.dirs and debian/gnustep-common.links. * 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. * Move gnustep-config.1 manpage to gnustep-make package: gnustep-make now Replaces: gnustep-common (<< 2.6.8-1). Regards, Eric Heintzmann --- End Message --- --- Begin Message --- Hi Eric, >What is the second question ? I don't remember, probably I had two questions, one was fixed by myself looking at the package, I edited the email and I forgot about that bit :) >Iain R. Learmonth has uploaded gnustep-make. > >Thanks to you for helping me to improve gnustep-make packaging. thank him from my side too! Happy to have been a little bit helpful, and have fun in maintaining your new shiny package! (of course I'll be there in case of regressions or questions). BTW the autoreconf change seems to work correctly, it is mostly built everywhere! Gianfranco--- End Message ---
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi Gianfranco, Le 16/05/2016 15:16, Gianfranco Costamagna a écrit : > Hi Eric, > > nice indeed, so please wait some more time, and ping me back in 7-15 days if > nobody > picked up the work in the meanwhile. > > Iain R. Learmonth has uploaded gnustep-make. Thanks to you for helping me to improve gnustep-make packaging. Eric
Bug#806815: RFS: lirc/0.9.4~pre1-1.3 [NMU]
On 15/05/16 17:19, Mattia Rizzolo wrote: On Sun, May 15, 2016 at 03:16:01PM +, Mattia Rizzolo wrote: Given that nothing happened here in the last 6 months, I'm closing this RFS ticket. Feel free to open a new one if/when you'll come back. I mean, Stefan is (at least in Debian) very much inactive; so you either go ahead without his review (and so reopen this RFS), or give up this quest :) To be honest I havn't bee too active myself the last few months. That said, I keep updating the packaging at mentors aiming to submit a new request once the upstream lirc 0.9.4 is out. Cheers! --alec
Re: Binaries under "/usr/lib/"
Hi all, On 18/05/2016 11:48, Ben Finney wrote: > On 18/05/2016 10:21, Tiago Ilieve wrote: >> On 17 May 2016 at 21:06, Ben Finneywrote: >>> How many process calls are there? The ideal solution IMO is to: >> Not much of them. In my case, there's just one. I was thinking about a >> corner case, where there would be multiple process calls, possible >> making a patch like this somewhat hard to maintain. >>> * 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. >> Thanks for your input. I like your suggestions, as they look pretty >> straightforward, but this is how this is being done for other >> packages? > > Differently, depending on the state of upstream. I agree with Ben, that it depends on the package. One approach that usually fits my needs is the one proposed by Thibaut Paumard [1], that I am reproposing here with minimal changes: 1) install the binaries with the original names into /usr/lib//bin 2) install a small script (possibly named ) in /usr/bin this script should provide an interface so that calling: will grant that any required variable is set to the right value and that /usr/lib//bin/ is executed; it is also possible to drop extensions in the new interface; 3) ideally add "help" and "path" command, in order to simplify the life of the users. This approach works well also in case of binary names conflicts, is usually not invasive and allows smooth transitions to the new approach. For an example you can see irstlm [2]. I think the example is nice as: - irstlm has many scripts with extensions that people are using in their own scripts; - it has a "dict" command (so we have a nice conflict with a famous tool); - recently upstream introduced "plsa" and "plsa.sh" commands, so, after extension removal it has a collision with itself; - there are "compile-lm" and "score-lm" commands that are very likely to conflicts with many other frameworks in this field; - I provided a bash-autocompletion file for it. Bests, Giulio [1] https://lists.debian.org/debian-mentors/2012/04/msg00012.html [2] https://anonscm.debian.org/git/debian-science/packages/irstlm.git/
Re: a few questions on ITP shadowsocks-libev before formal RFS
* Roger Shimizu, 2016-05-18, 02:14: 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? It doesn't matter who maintained the package in the package. What matters is who is going to maintain it now for Debian. Did you ask upstream to co-maintain it with you? You certainly shouldn't put anyone to Maintainer/Uploaders without their consent. - The package is mainly GPLv3, but it links to OpenSSL library, is that OK? GPL+OpenSSL is no-no. README says that mbedtls, which is GPL-compatible, can be used as an alternative to OpenSSL, so you should try it. - 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? As long as they are DFSG-free, you can keep them in the source package. Just make sure they are not used at build time. This is best achieved by "rm -rf"ing them early in the build process. (If you're using dh, then beginning of override_dh_auto_build is probably the best place.) - The answer of above question may affect: whether I should remove copyright of library libev, libsodium, libudns from debian/copyright? If you keep them in .orig.tar, then you must also keep them in debian/copyright. If you remove them from .orig.tar, then remove them from debian/copyright too. - Is it needed to add "dh_autoreconf" in debian/rules? It's not required by policy, but many sponsors will (rightfully!) insist to regenerate autotools stuff from source. - 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 This seems to be caused by passing --no-start to dh_installinit: dh_installinit --no-start --name=shadowsocks-libev-server@ dh_installinit --no-start --name=shadowsocks-libev-tunnel@ dh_installinit --no-start --name=shadowsocks-libev-redir@ dh_installinit --no-start --name=shadowsocks-libev-local@ My initsystem-fu is too weak to tell whether it's a d/rules bug, debhelper bug, or Lintian bug, or just something that should be overridden. -- Jakub Wilk
Re: Bug#823478: python3-protobuf3
Hi, >I know exactly what Mattia felt. :-( git reflog is a good friend in this case :) G.
Re: Binaries under "/usr/lib/"
Tiago Ilievewrites: > Thanks for your input. I like your suggestions, as they look pretty > straightforward, but this is how this is being done for other > packages? Differently, depending on the state of upstream. > I was looking at § 9.1.1 File System Structure[1] from the Debian > Policy Manual and it states that the need to put object files, > internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}" > is a requirement - however, it doesn't says how this should be done. Right. Debian Policy states how things should be; it is not the job of Policy to say exactly how to implement most policy requirements, because there must be plenty of room to evolve better solutions. So, if you want more specifics, you will need to point us to the exact code base we're discussing so advice can be given in context. -- \ “People are very open-minded about new things, as long as | `\ they're exactly like the old ones.” —Charles F. Kettering | _o__) | Ben Finney
Re: Bug#823478: python3-protobuf3
Jonathon, On 18 May 2016 at 05:52, Jonathon Lovewrote: >> umh, you force pushed everything, master, upstream and pristine-tar >> branches. WHY? what did you do? > > oh, sorry, i never intended for you to look at that repo, assuming you'd > look at the debian-mentors one. This is something I've seen on "debian-mentors" mailing list more than one time and we should urge people to don't do it: if you pushed changes to a public repository please, never, ever "--force" a new push. It's OK if you are doing this on a private location for yourself (as the forced push won't affect anyone else), but it doesn't make any sense to mention a repository in a public mailing list and then assume that no one would clone/fetch it. I know exactly what Mattia felt. :-( Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: package name for what upstream calls protobuf3
* Jonathon Love, 2016-05-18, 18:45: i'm in the process of packaging protobuf3: https://github.com/Pr0Ger/protobuf3 this is an implementation of protocol buffers 2 for python 3. according to debian policy, this should be named python3-protobuf3, but i think this name isn't ideal I don't know anything about anything about Python, but if packaging policy says that the package name should be named after the module name, and it turns out that the package name is too generic or misleading or otherwise inadequate, then that's only because the module name had exactly the same problem. So please get it renamed upstream. This is not something that should be papered over by deviating from the usual naming policy. -- Jakub Wilk
package name for what upstream calls protobuf3
hi, i'm in the process of packaging protobuf3: https://github.com/Pr0Ger/protobuf3 this is an implementation of protocol buffers 2 for python 3. according to debian policy, this should be named python3-protobuf3, but i think this name isn't ideal, because it could be mistaken for: a) an implementation of protocol buffers 3 b) the official google protocol buffers implementation i'm proposing to call it: python3-pr0ger-protobuf3 what should i call it? with thanks jonathon
Bug#823478: python3-protobuf3
umh, you force pushed everything, master, upstream and pristine-tar branches. WHY? what did you do? oh, sorry, i never intended for you to look at that repo, assuming you'd look at the debian-mentors one. And still it doesn't build, if that was meant to fix it. Without thinking of it I already overwrote the older files, so I can't diff anymore :S yeah, i've got it building on debian now, but i'm waiting for confirmation of what it should be called before pushing. i've asked on d-mentors. sorry for the inconvenience, and thanks for your patience. jonathon
Re: Binaries under "/usr/lib/"
Hi Ben, On 17 May 2016 at 21:06, Ben Finneywrote: > How many process calls are there? The ideal solution IMO is to: Not much of them. In my case, there's just one. I was thinking about a corner case, where there would be multiple process calls, possible making a patch like this somewhat hard to maintain. > * 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. Thanks for your input. I like your suggestions, as they look pretty straightforward, but this is how this is being done for other packages? I was looking at § 9.1.1 File System Structure[1] from the Debian Policy Manual and it states that the need to put object files, internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}" is a requirement - however, it doesn't says how this should be done. So, even appreciating your suggestions, I would like to hear from some maintainers that are used to do this on their packages. This way we can possible mix both some battle-tested approaches and your nice tips as well. Regards, Tiago. [1]: https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Bug#823478: python3-protobuf3
On Tue, May 17, 2016 at 01:07:05PM +1000, Jonathon Love wrote: > thanks for the review, and sorry for the embarrassing "does not build" > situation. i was packaging on ubuntu, and my experience has been that if it > works there, it will work on debian - but apparently not, i'll be more > careful in future. umh, you force pushed everything, master, upstream and pristine-tar branches. WHY? what did you do? And still it doesn't build, if that was meant to fix it. Without thinking of it I already overwrote the older files, so I can't diff anymore :S > i'm actually writing to ask your advice about the name of the package. > > upstream is called protobuf3, but it's an implementation of protocol buffers > 2 for python 3 Then name made me wonder too. I would like for somebody else on the mentors list to comment on it, but also keep in mind that there is a python policy that says the name should be python(3)-${module name}, that is, whatever you import. > python3-pr0ger-protobuf3 > > after the developer's nick: This golang-style name would actually turn me mad :| -- 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
Bug#824619: marked as done (RFS: golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-1)
Your message dated Wed, 18 May 2016 08:04:55 + with message-id <20160518080454.ge20...@chase.mapreri.org> and subject line Re: Bug#824619: RFS: golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-1 has caused the Debian Bug report #824619, regarding RFS: golang-github-hlandau-degoutils/0.0~git20160421.0.389a847-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.) -- 824619: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824619 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 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 ColbergTue, 17 May 2016 22:46:54 -0400 Regards, Peter --- End Message --- --- Begin Message --- On Tue, May 17, 2016 at 11:02:30PM -0400, Peter Colberg wrote: > I am looking for a sponsor for the package "golang-github-hlandau-degoutils": o/ > git clone > https://anonscm.debian.org/git/pkg-go/packages/golang-github-hlandau-degoutils.git Finally something that doesn't need NEW and a binary upload! ;) Uploaded! -- 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 ---
Bug#824621: marked as done (RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-1)
Your message dated Wed, 18 May 2016 08:00:32 + with message-id <20160518080027.gd20...@chase.mapreri.org> and subject line Re: Bug#824621: RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-1 has caused the Debian Bug report #824621, regarding RFS: golang-gopkg-cheggaaa-pb.v1/1.0.3-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.) -- 824621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824621 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 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 ColbergTue, 17 May 2016 22:45:21 -0400 Regards, Peter --- End Message --- --- Begin Message --- On Tue, May 17, 2016 at 11:17:04PM -0400, Peter Colberg wrote: > I am looking for a sponsor for the package "golang-gopkg-cheggaaa-pb.v1": o/ > git clone > https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-cheggaaa-pb.v1.git uploaded! -- 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 ---
Bug#824622: marked as done (RFS: golang-gopkg-square-go-jose.v1/1.0.2-1)
Your message dated Wed, 18 May 2016 07:53:09 + with message-id <20160518075307.gc20...@chase.mapreri.org> and subject line Re: Bug#824622: RFS: golang-gopkg-square-go-jose.v1/1.0.2-1 has caused the Debian Bug report #824622, regarding RFS: golang-gopkg-square-go-jose.v1/1.0.2-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.) -- 824622: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824622 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 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 ColbergTue, 17 May 2016 22:46:10 -0400 Regards, Peter --- End Message --- --- Begin Message --- On Tue, May 17, 2016 at 11:21:38PM -0400, Peter Colberg wrote: > I am looking for a sponsor for the package "golang-gopkg-square-go-jose.v1": o/ > git clone > https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-square-go-jose.v1.git ... > * Rename source package to golang-gopkg-square-go-jose.v1 > * Rename binary package to golang-gopkg-square-go-jose.v1-dev meh, golang. Assuming you are going to have the older one removed, I uploaded this one! -- 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 ---
Bug#820383: marked as done (RFS: photocollage/1.4.0-1 [ITP])
Your message dated Wed, 18 May 2016 07:39:18 + with message-id <20160518073917.gb20...@chase.mapreri.org> and subject line Re: Bug#820383: RFS: photocollage/1.4.0-1 [ITP] has caused the Debian Bug report #820383, regarding RFS: photocollage/1.4.0-1 [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.) -- 820383: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820383 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "photocollage" Package name: photocollage Version : 1.4.0-1 Upstream Author : Adrien Vergé URL : https://github.com/adrienverge/PhotoCollage License : GPL-2+ Section : graphics It builds this binary package: photocollage - Graphical tool to make photo collage posters To access further information about this package, please visit the following URL: http://mentors.debian.net/package/photocollage Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/photocollage/photocollage_1.4.0-1.dsc More information about PhotoCollage can be obtained from https://github.com/adrienverge/PhotoCollage and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820377 Regards, Adrien Vergé --- End Message --- --- Begin Message --- On Tue, May 17, 2016 at 10:31:32PM +0200, Adrien Vergé wrote: > Thanks for your remarks. I've addressed all of them, as well as > another warning output by `pbuilder --build`. Cool, uploaded! :) Thanks for your contribution to Debian! -- 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 ---
Bug#824625: marked as done (RFS: pentobi/12.0-1)
Your message dated Wed, 18 May 2016 07:10:09 + with message-id <20160518071007.ga20...@chase.mapreri.org> and subject line Re: Bug#824625: RFS: pentobi/12.0-1 has caused the Debian Bug report #824625, regarding RFS: pentobi/12.0-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.) -- 824625: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824625 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 "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 --- End Message --- --- Begin Message --- On Wed, May 18, 2016 at 08:16:12AM +0300, Juhani Numminen wrote: > I am looking for a sponsor for my package "pentobi". o/ > https://anonscm.debian.org/git/pkg-games/pentobi.git Uploaded! :) -- 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 ---
Re: a few questions on ITP shadowsocks-libev before formal RFS
Hi, >I have set up a git repo on github: >https://github.com/rogers0/shadowsocks-libev >My current changes are pushed to branch: RFC (I won't clone that right now, only answering questions) >Package builds fine with command: gbp buildpackage -us -uc --git-ignore-branch you should also try pbuilder or sbuild clean environments >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? I would remove the upstream packaging, we use changelog to keep track of changes that went in Debian, not changes that were done by somebody else. >- The package is mainly GPLv3, but it links to OpenSSL library, is>that OK? >Since there's concern mentioned in debian/README.Debian please read that page https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ >- 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? as long as you don't use them it is fine, please try to package them separately and use the system versions, not bundled code BTW the copyright file has to list them, so there is a tradeoff between removing files to have a more readable /easy to maintain copyright file and tarball, and having a pristine tarball from upstream. >- The answer of above question may affect: whether I should remove>copyright >of library libev, libsodium, libudns from debian/copyright? oops answered above :) (BTW a repack done not because of non-dfsg files is a "ds" aka Debian Source repack) please check copyright Files-Excluded: keyword >- Is it needed to add "dh_autoreconf" in debian/rules? I have tested>it, it >builds well. add dh-autoreconf to control file and "dh $@ --with autoreconf" in the default call (rules file) >- 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 > maybe the broken files comes from upstream? G.
Bug#824489: RFS: dwarfutils/20160507-1 [ITA] -- utility and library to work with DWARF debug information
Hi Fabian >dh_auto_install does not do anything useful here: `make install` for >some reason does not actually install anything but just compiles some >examples (that won't be part of the Debian package) and then finishes >with the note > >"No install provided, see comments in the README" > >The README basically says that the installation should be performed >manually by copying the desired files to the desired directories, >which is what dh_install will do in the next step. Therefore, calling >dh_auto_install probably won't hurt, but it does waste time, which is >why I have overwritten it with an empty rule. I don't see why it can't be patched to work like almost every other tool that uses a build system, but I don't care a lot about upstream. The (possible) issue I foresee is: somebody updates the upstream build system to install the files too, you update the packaging without checking that, the Debian upload is buggy because some files are missing. in short words, I prefer an useless call, rather than a broken package! >The hardening rules do export -fPIE, but not -fPIC. Without -fPIC, I >get the following error when trying to link the static library into >another shared library: > >/usr/bin/ld: /tmp/[...]/usr/lib/libdwarf.a(dwarf_alloc.o): relocation >R_X86_64_PC32 against symbol `dwarf_dealloc' can not be used when making a >shared object; >recompile with -fPIC >/usr/bin/ld: final link failed: Bad value >collect2: error: ld returned 1 exit status ok >Your patch doesn't fix that, either (although I might have missed >something there; I'm not exactly fluent in Autotools), whereas if I'm >building libdwarf with -fPIC, the shared library builds and links just >fine. I'm not fluent too, thanks for checking and replying about that, it was already fine, but I just wanted to be sure there was a rationale for the change! let me know your opinion about the install step, and I'll do the final checks + sponsoring BTW, I like when a patch/fix can be upstream, so I propose another one (feel free to reject of course, you are the maintainer, not me!) --- dwarfutils-20160507.orig/libdwarf/configure.in +++ dwarfutils-20160507/libdwarf/configure.in @@ -127,11 +127,11 @@ AC_TRY_COMPILE([#include ],[ Elf dnl default-disabled shared AC_SUBST(build_shared,[none]) AC_SUBST(dwfpic,[]) +AC_SUBST(dwfpic,[-fPIC]) AC_ARG_ENABLE(shared,AC_HELP_STRING([--enable-shared], [build shared library libdwarf.so])) AS_IF([ test "x$enable_shared" = "xyes"], [ AC_SUBST(build_shared,[libdwarf.so]) - AC_SUBST(dwfpic,[-fPIC]) ]) dnl default-enabled nonshared maybe it makes sense to enable it alsofor static libs then anyway. (probably all the if block can be removed this way, but this is something that upstream has to investigate ;)) thanks! Gianfranco