Bug#1040862: hdf5: S3 VFD pulls in networking dependencies (libcurl), please package it as a VFD plugin
Source: hdf5 Version: 1.10.7+repack-4ubuntu2 Severity: wishlist Dear Maintainer, currently, libhdf5_serial.so compiles the s3 Virtual File Driver (VFD) support into the library itself, which leads to inflated .so dependencies: libcurl.so pulls in about 20 other (networking, crypto) libs -- below is the output from lddtree. Starting from version 1.13.0, HDF5 should support virtual file drivers (VFDs) as plugins [1], similar to already existing filtering plugins. This report suggests to package the S3 VFD as a plugin, if possible, considering that most HDF5 users won't use s3 and the number of indirect dependencies is high. Thank you for considering this option. Your packaging work is appreciated. $ lddtree /lib/x86_64-linux-gnu/libhdf5_serial.so.103 libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103 (interpreter => none) libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2 libaec.so.0 => /lib/x86_64-linux-gnu/libaec.so.0 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 [1] https://www.hdfgroup.org/wp-content/uploads/2021/10/HDF5-VFD-Plugins-HUG.pdf -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy-backports'), (500, 'jammy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-71-generic (SMP w/16 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=en_US:cs:sk Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#817785: libqglviewer2: libs built against qt5 should have -qt5 appended
Package: libqglviewer2 Version: 2.6.3+dfsg1-1 Severity: normal Dear Maintainer(s), the current state of QGLViewer is that the version linking against qt5 is called libQGLViewer while the older version linking against qt4 is called libQGLViewer-qt4. While this is a fair short-term solution, it has some shortcomings. In particular, to support multiple Debian versions, one has to check whether QGLViewer links against qt4 (older versions) or qt5 (newer version). Second, when qt6 comes, what will happen? Following the principle that "explicit is better than implicit", I'd be for appending "-qt5" to the package name (libqglviewer2-qt5, libqglviewer2-qt5-dev) and also the the library name (libQGLViewer-qt5.so) so that those are unambiguous. As side-effect, this might remove the highly undesirable conflict between libglviewer-qt4-dev and libqtglviewer-dev. Just like I need both Qt4 and Qt5 dev files installed, I would like to install headers for both version of QGLViewer and there is no reason why this should not be supported. Best regards, Václav -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial'), (500, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386, k1om Kernel: Linux 3.19.0-49-lowlatency (SMP w/6 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqglviewer2 depends on: ii libc6 2.21-0ubuntu6 ii libgcc1 1:6-20160227-0ubuntu1 ii libgl1-mesa-glx [libgl1] 11.1.2-1ubuntu1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libqt5core5a 5.5.1+dfsg-15ubuntu1 ii libqt5gui55.5.1+dfsg-15ubuntu1 ii libqt5opengl5 5.5.1+dfsg-15ubuntu1 ii libqt5widgets55.5.1+dfsg-15ubuntu1 ii libqt5xml55.5.1+dfsg-15ubuntu1 ii libstdc++65.3.1-10ubuntu2 libqglviewer2 recommends no packages. libqglviewer2 suggests no packages. -- no debconf information
Bug#678033: hotfix
The fix Sami mentioned works only when _compiling_ glibc with clang, not
when clang uses headers which were otherwise compiled for use with gcc.
The attached patch is a trivial hotfix modifying an already installed
file, for those who need the fix right now.
--- /usr/include/c++/4.7/type_traits.orig 2012-08-30 11:41:05.328540761 -0400
+++ /usr/include/c++/4.7/type_traits 2012-08-30 11:41:59.404541874 -0400
@@ -252,7 +252,7 @@
struct __is_floating_point_helperlong double
: public true_type { };
-#if !defined(__STRICT_ANSI__) defined(_GLIBCXX_USE_FLOAT128)
+#if !defined(__STRICT_ANSI__) defined(_GLIBCXX_USE_FLOAT128) !defined(__clang__)
template
struct __is_floating_point_helper__float128
: public true_type { };
Bug#490432: fixed where?
Arthur, could you please provide version where it was fixed or link to the changelog? Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#296811: ssh hangning caused by buggy ADSL modem firmware here
I resolved the problem here, buggy firmware is to be blamed: every packet having the flag ToS!=0 is silently discarded. More details: http://www.thp.uni-duisburg.de/~fred/DSL-G664T.html and http://www.magwag.plus.com/jim/tips-300t.html. The end of http://www.abclinuxu.cz/hardware/show/112501 quotes the reply from dlink support (copy and paste the relevant part): It is correct that SSH passthrough don't work with DSL-xxxT devices when they are running with PPPoE and with Linux or MacOS SSH client. With Windows SSH client, e.g. PUTTY, the SSH passthrough works fine. Only if the devices work as an ordinary DSL modem in Bridge mode it works with Linux or MacOS SSH, because in this mode the DSL-362T is fully transparent. We already reported this behavior to teh development a long time ago, but it seems to be a chipset limitation, the colleagues in the development department can not fix it. Sorry we don't have a solution for this. The box is running Linux and netfilter mangling could do the trick on the router; but mangling table is not compiled into the kernel in my specific case (dlink dsl-g664t). So I have to mangle when packets leave the client. Regards, Vaclav Smilauer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
