Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library
Hi Frederic, currently I'm short on time and as new packages are currently not the priority (won't be part of Stretch anyway) please let me defer that to past-freeze. Ping me again then and I'll take a look. -- tobi Am Mittwoch, den 11.01.2017, 09:58 +0100 schrieb Frederic Bonnard: > Hi Tobias, Gianfranco. > > Tobias, Thierry agreed and I change the owner, I hope it's better > now. > > Any of you would have time to review the package? > I added Gianfranco as is my usual sponsor, but I forgot to Cc him in > my > initial request. > Thanks, > > F. > > On Mon, 19 Dec 2016 08:12:06 +0100, Tobias Frost > wrote: > > Control: tags -1 wontfix > > Control: block 806720 by -1 > > > > Hi Frederick, > > > > the ITP is owned by Thierry Fauck, did you check with him if it is > > ok > > to take this ITP? (Should be done via the BTS and then the ITP's > > meta > > data should be corrected accordingly. > > > > Please remove the wontfix when this has been resolved. > > > > -- > > tobi > >
Bug#851937: RFS: farbfeld/2.20170109-1 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "farbfeld" * Package name : farbfeld Version : 2.20170109-1 Upstream Author : Laslo Hunhold * Url : http://tools.suckless.org/farbfeld * Licenses : ISC Programming Lang : C Section : graphics Farbfeld is a lossless image-format designed to be parsed and piped easily. It is designed to be as simple as possible, leaving the task of compression to outside tools, beating PNG's filesize in many cases. . This package contains tools for converting between farbfeld format and other image formats (png, jpeg, ppm, pam, git) It builds those binary packages: * farbfeld Please note, that package is maintained with dgit(1) tool using dgit-maint-merge(7) workflow. In particular, it means that quilt patches are squashed in source package and are not intended for review. For more information about how to sponsor this package, see dgit-sponsorship(7). Git repository: https://anonscm.debian.org/cgit/users/kaction-guest/farbfeld.git Git branch: master Orig tar.gz: from tag 2.20170109 With /bin/sh following commands should suffice: $ git clone https://anonscm.debian.org/cgit/users/kaction-guest/farbfeld.git farbfeld $ cd farbfeld $ git archive -o ../farbfeld_2.20170109.orig.tar.xz 2.20170109 $ dgit sbuild Regards, Dmitry Bogatov
Bug#851936: RFS: openmeca/2.1.5-1 [ITP: #850590]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my first package "openmeca" * Package name: openmeca * Version : 2.1.5-1 * Upstream Author : Damien André (myself) * URL : https://gitlab.com/damien.andre/openmeca * License : GPL v3 * Section : science It builds those binary packages: openmeca - Multibody mechanical simulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/openmeca Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/openmeca/openmeca_2.1.5-1.dsc A git repository of the debianized version of openmeca is also available on Alioth: https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/ More information about openmeca can be obtained from : https://gitlab.com/damien.andre/openmeca https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590 Best Regards,Damien andré -- http://www.unilim.fr/pages_perso/damien.andre/
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
Etienne Dysli-Metref writes: > Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the > holidays, I'm now backporting it to jessie. So far there is nothing to > change, however piuparts gives me the following error (which does not > appear on stretch): > >> 0m34.6s ERROR: FAIL: Package purging left files on system: >> /etc/systemd/system/multi-user.target.wants/shibd.service -> >> /lib/systemd/system/shibd.service not owned >> /etc/systemd/system/shibd.service -> /dev/null not owned >> /var/lib/systemd/deb-systemd-helper-enabled/not owned >> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ >> not owned >> >> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service >>not owned >> /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also not >> owned >> /var/lib/systemd/deb-systemd-helper-masked/ not owned >> /var/lib/systemd/deb-systemd-helper-masked/shibd.servicenot owned > > It looked like dh-systemd wasn't properly cleaning up despite > shibboleth-sp2-utils's postrm script looking like it would: [...] I couldn't reproduce this on a real jessie system, only in a piuparts chroot. I think the reason is that piuparts removes init-system-helpers (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm could instruct it to clean up. I'm not sure what we could do about this. > So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). Why? I mean, where did this version number come from? -- Feri
Re: mpgrafic - mpirun test program as root in automatic build
On Thu, Jan 19, 2017 at 08:21:36AM +0800, Paul Wise wrote: > On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote: > > > This is temporarily false: #852071 > > Is there a typo in that bug? I get a 404 #851071, sorry! -- Sean Whitton signature.asc Description: PGP signature
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
Hm, I'm now getting errors from dpkg-shlibdeps (i.e., and installation time): ``` dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12 needed by debian/libtrilinos-amesos12/usr/lib/powerpc64le-linux-gnu/libtrilinos_amesos.so.12.11 (ELF format: 'elf64-powerpcle'; RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib') ``` See [1] for full detail. (Btw, notice the RPATH settings from openmpi.) CMake I think installs the libraries in alphabetical order, so `libtrilinos_amesos.so.12.11` is handled before its dependency `libtrilinos_trilinosss.so.12` and cannot find the latter -- makes sense. What's the suggested workaround here? Cheers, Nico [1] https://launchpadlibrarian.net/303079195/buildlog_ubuntu-zesty-ppc64el.trilinos_12.11~20170119114916-33933755-1zesty1_BUILDING.txt.g z On Thu, Jan 19, 2017 at 3:03 PM Nico Schlömer wrote: I can confirm that the RPATH is ``` RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib' ``` I'll just wait for the next ompi upload then. Cheers, Nico On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry wrote: On 19/01/2017 11:20, James Cowgill wrote: > Hi, > > On 18/01/17 22:39, Nico Schlömer wrote: >> I'm co-maintaining the Trilinos package [1] in Debian and recently found >> a bunch of new lintian warnings of the kind >> binary-or-shlib-defines-rpath [2]. It say in the description of the warning: >> ``` >> To fix this problem, look for link lines like: >> >> gcc test.o -o test -Wl,--rpath,/usr/local/lib >> >> or >> >> gcc test.o -o test -R/usr/local/lib >> >> and remove the -Wl,--rpath or -R argument. >> ``` >> Indeed, the Trilinos installation contains many of those lines, but they >> are necessary too. When executing the test binaries (which are compiled >> in the build tree alongside the libraries), they have to find the linked >> shared libraries. Messing with the rpath is necessary. >> >> That's not true later on when the libraries are _installed_, of course. >> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which >> serves exactly that purpose. For some reason, lintian doesn't seem to be >> happy with that though. > The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake > itself inserts. It does not affect any rpaths manually added with other > -Wl,--rpath options. The culprit here is probably openmpi which adds all > of these rpath entries: > > $ mpicc -show > [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath > -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...] > > Maybe it shouldn't do that. The /usr//lib one is clearly useless and the > it seems that most of the libraries from > /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into > /usr/lib/x86_64-linux-gnu anyway. > Agreed. Will remove these on the next upload. Best regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#851799: RFS: hamlib/3.1.0-1
control: tag -1 +moreinfo control: owner -1 ! Dear Ervin, On Wed, Jan 18, 2017 at 10:39:34PM +0100, Ervin Hegedüs wrote: > I am looking for a sponsor for my package "hamlib" Thanks for your RFS. Some issues with this upload: - debhelper compat bump not in changelog - debhelper build-dep needs to be >9 - why not use debhelper compat 10? - did the std-ver bump require any changes? it's conventional to say in the changelog - "added lua binding" involves several changes, which should all be in the changelog (new binary packages; build-dep on dh_lua; many new files in debian/; lots of changes to rules) - new debian/trash (what is this file? why not debian/clean?) - just to confirm, have you verified that there is no ABI break with this new version of the library? I haven't checked yet. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#851884: RFS: fdkaac/0.6.3-1
Sean Whitton writes: > Dear Marius, > > Could you update your Vcs-Git repository with the new version, please? Dear Sean, My Vcs-Git ( https://git.ieval.ro/git/fdkaac.git ) already has the new version. -- Marius Gavrilescu signature.asc Description: PGP signature
Bug#851884: RFS: fdkaac/0.6.3-1
Dear Marius, Could you update your Vcs-Git repository with the new version, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#851884: RFS: fdkaac/0.6.3-1
Andrey Rahmatullin writes: > On Thu, Jan 19, 2017 at 03:30:39PM +, Marius Gavrilescu wrote: >> * Mark as XS-Autobuild: yes > Why do you think you need that in a contrib package? That... is a great point! It only makes sense for non-free packages. I believe I added that as I saw the package was BD-Uninstallable on all arches bug amd64. But that was because libfdk-aac-dev was not available on those arches when the buildds tried to build fdkaac (libfdk-aac-dev is now available on most arches). I've removed XS-Autobuild: yes from d/control and the corresponding changelog item. The new package is now on mentors. -- Marius Gavrilescu signature.asc Description: PGP signature
Bug#851884: RFS: fdkaac/0.6.3-1
On Thu, Jan 19, 2017 at 03:30:39PM +, Marius Gavrilescu wrote: > * Mark as XS-Autobuild: yes Why do you think you need that in a contrib package? -- WBR, wRAR signature.asc Description: PGP signature
Bonjour
Besoin d'argent pour un projet personnel??? Contactez nous pour plus d'informations pour obtenir un prêt. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Bug#851884: RFS: fdkaac/0.6.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "fdkaac" * Package name: fdkaac Version : 0.6.3-1 Upstream Author : nu774 * URL : https://github.com/nu774/fdkaac * License : Zlib Section : sound It builds those binary packages: fdkaac - command line encoder frontend for libfdk-aac To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fdkaac Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/f/fdkaac/fdkaac_0.6.3-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * New upstream version * Bump Standards-Version to 3.9.8 * Mark as XS-Autobuild: yes * Use hardening compilation options Regards, -- Marius Gavrilescu signature.asc Description: PGP signature
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
I can confirm that the RPATH is ``` RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib' ``` I'll just wait for the next ompi upload then. Cheers, Nico On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry wrote: > > > On 19/01/2017 11:20, James Cowgill wrote: > > Hi, > > > > On 18/01/17 22:39, Nico Schlömer wrote: > >> I'm co-maintaining the Trilinos package [1] in Debian and recently found > >> a bunch of new lintian warnings of the kind > >> binary-or-shlib-defines-rpath [2]. It say in the description of the > warning: > >> ``` > >> To fix this problem, look for link lines like: > >> > >> gcc test.o -o test -Wl,--rpath,/usr/local/lib > >> > >> or > >> > >> gcc test.o -o test -R/usr/local/lib > >> > >> and remove the -Wl,--rpath or -R argument. > >> ``` > >> Indeed, the Trilinos installation contains many of those lines, but they > >> are necessary too. When executing the test binaries (which are compiled > >> in the build tree alongside the libraries), they have to find the linked > >> shared libraries. Messing with the rpath is necessary. > >> > >> That's not true later on when the libraries are _installed_, of course. > >> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which > >> serves exactly that purpose. For some reason, lintian doesn't seem to be > >> happy with that though. > > The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake > > itself inserts. It does not affect any rpaths manually added with other > > -Wl,--rpath options. The culprit here is probably openmpi which adds all > > of these rpath entries: > > > > $ mpicc -show > > [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath > > -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...] > > > > Maybe it shouldn't do that. The /usr//lib one is clearly useless and the > > it seems that most of the libraries from > > /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into > > /usr/lib/x86_64-linux-gnu anyway. > > > Agreed. Will remove these on the next upload. > > Best regards > Alastair > > -- > Alastair McKinstry, , , > https://diaspora.sceal.ie/u/amckinstry > Misentropy: doubting that the Universe is becoming more disordered. > > >
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
On 19/01/2017 11:20, James Cowgill wrote: > Hi, > > On 18/01/17 22:39, Nico Schlömer wrote: >> I'm co-maintaining the Trilinos package [1] in Debian and recently found >> a bunch of new lintian warnings of the kind >> binary-or-shlib-defines-rpath [2]. It say in the description of the warning: >> ``` >> To fix this problem, look for link lines like: >> >> gcc test.o -o test -Wl,--rpath,/usr/local/lib >> >> or >> >> gcc test.o -o test -R/usr/local/lib >> >> and remove the -Wl,--rpath or -R argument. >> ``` >> Indeed, the Trilinos installation contains many of those lines, but they >> are necessary too. When executing the test binaries (which are compiled >> in the build tree alongside the libraries), they have to find the linked >> shared libraries. Messing with the rpath is necessary. >> >> That's not true later on when the libraries are _installed_, of course. >> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which >> serves exactly that purpose. For some reason, lintian doesn't seem to be >> happy with that though. > The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake > itself inserts. It does not affect any rpaths manually added with other > -Wl,--rpath options. The culprit here is probably openmpi which adds all > of these rpath entries: > > $ mpicc -show > [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath > -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...] > > Maybe it shouldn't do that. The /usr//lib one is clearly useless and the > it seems that most of the libraries from > /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into > /usr/lib/x86_64-linux-gnu anyway. > Agreed. Will remove these on the next upload. Best regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. signature.asc Description: OpenPGP digital signature
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
On 19/01/17 12:20, Thibaut Paumard wrote: > Le 19/01/2017 à 12:20, James Cowgill a écrit : >> On a separate note: does this interfere with the alternatives system >> which openmpi currently has? If an rpath is used, it will override any >> libraries in the default linker search path so even if the mpi >> alternative is changed, many applications will still use libmpi from >> /usr/lib/x86_64-linux-gnu/openmpi/lib. > > This is as it should be. The two alternative implementations (openmpi > and mpich) are not binary-compatible. Ahh sorry, I misread where the symlinks were pointing to. Indeed only the .so files from the -dev package are under the alternatives system. James signature.asc Description: OpenPGP digital signature
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
Le 19/01/2017 à 12:20, James Cowgill a écrit : > On a separate note: does this interfere with the alternatives system > which openmpi currently has? If an rpath is used, it will override any > libraries in the default linker search path so even if the mpi > alternative is changed, many applications will still use libmpi from > /usr/lib/x86_64-linux-gnu/openmpi/lib. This is as it should be. The two alternative implementations (openmpi and mpich) are not binary-compatible. Regards, Thibaut.
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
Hi, On 18/01/17 22:39, Nico Schlömer wrote: > I'm co-maintaining the Trilinos package [1] in Debian and recently found > a bunch of new lintian warnings of the kind > binary-or-shlib-defines-rpath [2]. It say in the description of the warning: > ``` > To fix this problem, look for link lines like: > > gcc test.o -o test -Wl,--rpath,/usr/local/lib > > or > > gcc test.o -o test -R/usr/local/lib > > and remove the -Wl,--rpath or -R argument. > ``` > Indeed, the Trilinos installation contains many of those lines, but they > are necessary too. When executing the test binaries (which are compiled > in the build tree alongside the libraries), they have to find the linked > shared libraries. Messing with the rpath is necessary. > > That's not true later on when the libraries are _installed_, of course. > For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which > serves exactly that purpose. For some reason, lintian doesn't seem to be > happy with that though. The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake itself inserts. It does not affect any rpaths manually added with other -Wl,--rpath options. The culprit here is probably openmpi which adds all of these rpath entries: $ mpicc -show [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...] Maybe it shouldn't do that. The /usr//lib one is clearly useless and the it seems that most of the libraries from /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into /usr/lib/x86_64-linux-gnu anyway. On a separate note: does this interfere with the alternatives system which openmpi currently has? If an rpath is used, it will override any libraries in the default linker search path so even if the mpi alternative is changed, many applications will still use libmpi from /usr/lib/x86_64-linux-gnu/openmpi/lib. Thanks, James signature.asc Description: OpenPGP digital signature
Re: question on binary-or-shlib-defines-rpath
Hello Nico, >I'm co-maintaining the Trilinos package [1] in Debian and recently found a >bunch of new lintian warnings of the kind binary-or-shlib-defines-rpath [2]. >It say in >the description of the warning: Usually lintian is right on such tags :p You can look at src:ettercap, where I have implemented such RPATH nightmare handling in cmake. I would wild guess something like "CMAKE_INSTALL_RPATH_USE_LINK_PATH" is set to TRUE and build logs agrees with me :) -- Trilinos_SET_INSTALL_RPATH='TRUE' -- CMAKE_INSTALL_RPATH_USE_LINK_PATH='TRUE' I'm too lazy to remember why I did the ettercap hack [1], somewhere we want people that build from source to be able to ./binary without having to install it (so the RPATH is needed), so I created a DISABLE_RPATH flag that disables such feature, and added it to the debian/rules file. I remember such USE_LINK_PATH being the culprit of my issue. [1] https://github.com/Ettercap/ettercap/commit/3c72c92cfe5870f47cfc9e1e021dcc26286ac710 HTH Gianfranco
Bug#851756: RFS: telegram-desktop/1.0.0-2
Hello >This is alpha version. It is not in upstream changelog on [1]. something I wondered too, maybe tagging it differently from official releases might help >To be noted upstream author does not always publish the tags in time. > >P.S.: I don't know how to put this remote changelog into the package. ask upstream to include a changelog in the source code/tarball and use dh_installchangelogs G.
Re: question on binary-or-shlib-defines-rpath
Thanks Sean for the reply. > If so, it's probably a Lintian bug. I thought it might be. Just filed a bug for it [1]. Cheers, Nico [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851833 On Thu, Jan 19, 2017 at 12:50 AM Sean Whitton wrote: Dear Nico, On Wed, Jan 18, 2017 at 10:39:47PM +, Nico Schlömer wrote: > That's not true later on when the libraries are _installed_, of course. For > this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly > that purpose. For some reason, lintian doesn't seem to be happy with that > though. I believe that this Lintian tag checks only the contents of your final binary packages. Are you absolutely sure that you do not install any of these test suite files? If so, it's probably a Lintian bug. -- Sean Whitton