Bug#880412: marked as done (RFS: python-h5netcdf/0.5.0-1)
Your message dated Tue, 14 Nov 2017 04:20:26 + with message-id and subject line closing RFS: python-h5netcdf/0.5.0-1 has caused the Debian Bug report #880412, regarding RFS: python-h5netcdf/0.5.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.) -- 880412: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880412 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 following package: * Package name: python-h5netcdf Version : 0.5.0-1 Upstream Author : Stephan Hoyer * URL : https://github.com/shoyer/h5netcdf * License : BSD Section : python Please check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/python-h5netcdf.git Changes since the last upload: * New upstream version 0.5.0 * Add recommended get-orig-source target Regards, Ghis --- End Message --- --- Begin Message --- Package python-h5netcdf version 0.5.0-1 is in unstable now. https://packages.qa.debian.org/python-h5netcdf--- End Message ---
Bug#880408: marked as done (RFS: python-pymeasure/0.5-1)
Your message dated Tue, 14 Nov 2017 04:20:28 + with message-id and subject line closing RFS: python-pymeasure/0.5-1 has caused the Debian Bug report #880408, regarding RFS: python-pymeasure/0.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.) -- 880408: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880408 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 following package: * Package name: python-pymeasure Version : 0.5-1 Upstream Author : PyMeasure Developers * URL : https://github.com/ralph-group/pymeasure * License : Expat Section : python Please check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/python-pymeasure.git Changes since last upload: * New upstream version 0.5 * Refresh the patch queue * Bump the standards version to 4.1.1 * Add recommended get-orig-source target Regards, Ghis --- End Message --- --- Begin Message --- Package python-pymeasure version 0.5-1 is in unstable now. https://packages.qa.debian.org/python-pymeasure--- End Message ---
Bug#880577: marked as done (RFS: shark/3.1.4+ds1-1 [RC])
Your message dated Tue, 14 Nov 2017 04:20:26 + with message-id and subject line closing RFS: shark/3.1.4+ds1-1 [RC] has caused the Debian Bug report #880577, regarding RFS: shark/3.1.4+ds1-1 [RC] 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.) -- 880577: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880577 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 the following package: * Package name: shark Version : 3.1.4+ds1-1 Upstream Author : Christian Igel * URL : http://image.diku.dk/shark/ * License : LGPL-3 Section : science Please check out the package by visiting the following URL: https://anonscm.debian.org/cgit/debian-science/packages/shark.git Changes since the last upload: * New upstream version 3.1.4+ds1 (Closes: #853658) * Add missing Built-Using metadata for the docs * Add support for the nodoc build profile * Build the docs with Python 3 * Bump the standards version to 4.1.1 Regards, Ghis --- End Message --- --- Begin Message --- Package shark version 3.1.4+ds1-1 is in unstable now. https://packages.qa.debian.org/shark--- End Message ---
Bug#880406: marked as done (RFS: python-bayespy/0.5.12-1)
Your message dated Tue, 14 Nov 2017 04:20:28 + with message-id and subject line closing RFS: python-bayespy/0.5.12-1 has caused the Debian Bug report #880406, regarding RFS: python-bayespy/0.5.12-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.) -- 880406: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880406 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 following package: * Package name: python-bayespy Version : 0.5.12-1 Upstream Author : Jaakko Luttinen * URL : https://www.bayespy.org * License : Expat Section : python Please check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/python-bayespy.git Changes since the last upload: * New upstream version 0.5.12 * Bump the standards version to 4.1.1 * Add recommended get-orig-source target Regards, Ghis --- End Message --- --- Begin Message --- Package python-bayespy version 0.5.12-1 is in unstable now. https://packages.qa.debian.org/python-bayespy--- End Message ---
Bug#880405: marked as done (RFS: python-meshio/1.8.17-1)
Your message dated Tue, 14 Nov 2017 04:20:28 + with message-id and subject line closing RFS: python-meshio/1.8.17-1 has caused the Debian Bug report #880405, regarding RFS: python-meshio/1.8.17-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.) -- 880405: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880405 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 following package: * Package name: python-meshio Version : 1.8.17-1 Upstream Author : Nico Schlömer * URL : https://github.com/nschloe/meshio * License : Expat Section : python Please check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/python-meshio.git Changes since last upload: * New upstream version 1.8.17 * Bump the standards version to 4.1.1 Regards, Ghis --- End Message --- --- Begin Message --- Package python-meshio version 1.8.17-1 is in unstable now. https://packages.qa.debian.org/python-meshio--- End Message ---
Bug#881644: RFS: codemirror-js/5.19.0
Package: sponsorship-requests Severity: normal I am looking for a sponsor for a (team) update to codemirror-js. The current version in unstable is 5.4.0 (from July 2015). This update is not to the latest upstream version (currently 5.31.0), but to the most recent version (5.19.0, from September 2016) before upstream changed to building using rollup (not yet available, but packaging work is currently being done). This is a dependency for jupyter-notebook, amongst others. The packaging is trivial: no build, file copy only. [git]: https://anonscm.debian.org/cgit/pkg-javascript/codemirror-js.git [mentors]: https://mentors.debian.net/package/codemirror-js dget -x https://mentors.debian.net/debian/pool/main/c/codemirror-js/codemirror-js_5.19.0-1.dsc Gordon Ball (irc: chronitis)
Bug#881522: marked as done (RFS: fracplanet/0.4.0-6 [ITA])
Your message dated Mon, 13 Nov 2017 20:57:56 +0100 with message-id <20171113195756.36rrd444zrhmg...@sk2.org> and subject line Re: Bug#881522: RFS: fracplanet/0.4.0-6 [ITA] has caused the Debian Bug report #881522, regarding RFS: fracplanet/0.4.0-6 [ITA] 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.) -- 881522: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881522 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 "fracplanet" * Package name: fracplanet Version : 0.4.0-6 Upstream Author : Tim Day * URL : http://www.bottlenose.demon.co.uk/share/fracplanet/ * License : GPL-2 Section : graphics It builds those binary packages: fracplanet - Fractal planet generator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fracplanet Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fracplanet/fracplanet_0.4.0-6.dsc Changes since the last upload: * New maintainer (Closes: #661455). + Rewrite debian/copyright on format 1.0. * Migrated build to Qt5 (Closes: #874885 ; LP: #941062): + Changes build-depends to qtbase5-dev, qt5-qmake and libqt5opengl5-dev. + Add patch migrated-build-to-Qt5.patch. + Changed QTDIR on debian/rules. * Updated to Standards-Version 4.1.1. * Added debian/fracplanet.xpm (LP: #926832). + Added Icon field on debian/fracplanet.desktop file. + Install on usr/share/pixmaps: add on debian/rules. * Added keywords field on fracplanet.desktop file. * Added debian/watch file. * Repackaging the sources to add the version in the name of the directory. * Added hardening options on debian/rules. * Added fix-tipo-error.patch to fit tipo error. Regards, Innocent De Marchi --- End Message --- --- Begin Message --- On Sun, Nov 12, 2017 at 06:23:21PM +0100, Innocent De Marchi wrote: > I am looking for a sponsor for my package "fracplanet" This was sponsored by Jonathan Carter, closing. Regards, Stephen--- End Message ---
Re: How to determine the filename for dlopen()
Hi,
Am 2017-11-13 13:23, schrieb wf...@niif.hu:
I'm packaging a program which wants to dlopen() some library. It finds
this library via pkg-config (PKG_CHECK_MODULES). How to best determine
the filename to use in the dlopen() call? It should work cross-distro,
for cross-compilation and whatnot. Is it always safe to use the SONAME
as the filename?
The SONAME is the right thing to do here, as that is what's encoded in
the DT_NEEDED field by the linker.
I'm currently considering something like
ld -shared -o dummy.so $(my_LIBS)
objdump -p dummy.so | fgrep NEEDED
That might work, but I'm not sure that's very stable.
I've created the following example code that works for me with libpng:
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(example)
enable_language(C)
find_library(PNG_LIBRARY_FILE NAMES png)
if(PNG_LIBRARY_FILE)
execute_process(COMMAND objdump -p "${PNG_LIBRARY_FILE}"
OUTPUT_VARIABLE PNG_CONTENTS)
if (PNG_CONTENTS)
string(REGEX MATCH "\n[ \t]*SONAME[ \t]+([^ \t\r\n]*)"
DUMMY "${PNG_CONTENTS}")
if (DUMMY)
set(PNG_SONAME "${CMAKE_MATCH_1}" CACHE STRING "The SONAME of the
PNG library")
message(STATUS "Got libpng soname: ${PNG_SONAME}")
else()
message(FATAL_ERROR "Could not extract SONAME from
${PNG_LIBRARY_FILE}")
endif()
else()
message(FATAL_ERROR "Could not run objdump -p on
${PNG_LIBRARY_FILE}")
endif()
else()
message(FATAL_ERROR "Could not find -lpng")
endif()
Important:
- This assumes that objdump -p actually works. This is basically only
true if you use the GNU toolchain on ELF systems. If you have another
platform then you need to call different things:
- On Mac OS X you need to do otool -D $LIBRARY and then parse that
(it will give you back something like (notice the newline!)
$filename:\n$library_id_abspath
The base name of the second line of that output is what you're
looking for for dlopen().
- On other UNIX platforms I don't really know.
- On Windows with the MinGW toolchain, when you have an import
library (*.dll.a MinGW style or *.lib Microsoft style) then you
may use dlltool -I $IMPORTLIB to extract the DLL name from
that. However, MinGW does support linking directly against DLLs
in some cases (when they were also compiled with MinGW, for
example, and fulfill some additional criteria), and it may be
the case that your linker finds the DLL directly if no import
library is found, in which case dlltool -I will fail, but you
can just use the basename of the DLL.
Note that objdump -p does work on MinGW on Windows, but doesn't
give you a SONAME. (It does mention the DLL name multiple times,
but I'm not sure that's easy to parse.)
- On Windows with MSVC I have no idea how to get the DLL name
from an import library (*.lib), but there's definitely going
to be a tool you'll be able to use.
- No idea on yet other operating systems.
- I'm hacked this together and am not sure this is the sanest way of
parsing this in CMake... YMMV.
- CMake might only find a static library depending on how your search
path is set up (*.a on UNIX systems including Mac OS X, as well as
on MinGW, but *.lib on Windows system with MSVC). On Windows the
fact that import libraries and static libraries share the same
extension actually makes it quite difficult to handle this case
properly.
- If you do manage to write some relatively generic code, I would
urge you to contribute that to CMake as a macro, so that other
people could also profit from it.
Regards,
Christian
How to determine the filename for dlopen()
Hi, I'm packaging a program which wants to dlopen() some library. It finds this library via pkg-config (PKG_CHECK_MODULES). How to best determine the filename to use in the dlopen() call? It should work cross-distro, for cross-compilation and whatnot. Is it always safe to use the SONAME as the filename? I'm currently considering something like ld -shared -o dummy.so $(my_LIBS) objdump -p dummy.so | fgrep NEEDED coded up properly for Automake. I'd be grateful for any insight. -- Thanks, Feri
