Bug#956320: fabric ModuleNotFoundError: No module named 'invoke.vendor.six'
Package: fabric
Version: 2.5.0-0.2
Severity: important
Dear Maintainer,
After dist-upgrade, fab appears to be completely disfunctional, perhaps because
of missing dependencies:
% fab --version
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fabric/connection.py", line 5, in
from invoke.vendor.six import StringIO
ModuleNotFoundError: No module named 'invoke.vendor.six'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/fab", line 11, in
load_entry_point('fabric==2.5.0', 'console_scripts', 'fab')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489,
in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2852,
in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2443,
in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2449,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/fabric/__init__.py", line 3, in
from .connection import Config, Connection
File "/usr/lib/python3/dist-packages/fabric/connection.py", line 10, in
Subject: fabric ModuleNotFoundError: No module named 'invoke.vendor.six'
from decorator import decorator
ModuleNotFoundError: No module named 'decorator'
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: armhf (armv7l)
Kernel: Linux 4.9.99 (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages fabric depends on:
ii libjs-sphinxdoc1.8.5-9
ii python33.8.2-3
ii python3-fabric 2.5.0-0.2
ii python3-pkg-resources 44.0.0-1
fabric recommends no packages.
fabric suggests no packages.
-- no debconf information
Bug#920351: bash: exec in .profile suspends or loses stdin
Just hit this issue after upgrading my Debian sid systems. I can reproduce as follows: - log in at the console (with bash as the login shell) - set +m - exec /bin/sh -c 'read x; echo $x' For whatever reason I only hit the issue with the shells spawned directly by 'login', I cannot reproduce over ssh. As a workaround, running set -m immediately prior to exec avoids the bash bug. However, this regression has been fixed upstream for several months as of bash 5.0.7, would be nice to have up-to-date packages in Debian...
Bug#907277: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8
On 1/17/19, Paul Gevers wrote: > On 14-01-2019 11:57, Matthias Klose wrote: >> On 12.01.19 21:37, Chaim Zax wrote: >>> Because autoconf can be used outside a Debian environment this solution >>> might not work for everyone. Perhaps the AC_SEARCH_LIBS function should >>> be extended so function arguments needed to check a library could be >>> provided as well, or perhaps there is an other way to make it compatible >>> with g++ 8. >> >> g++ 8 got more strict. You could check if that's the case for g++ 9 as >> well (or >> gcc-snapshot). In any case, autoconf should be adjusted to avoid the >> warning/error. > > Do you happen to know why g++ 8 happens to fail on this library and > doesn't fail on other libraries we checked? Does g++ know which > libraries it includes and is it pickier on those? I'm not familiar with the library in question but the problem appears to be specific to these __atomic_xyz builtins which seem to get special treatment in g++. Other builtins I tested do not exhibit such failures. There is no obvious way to disable the error in GCC: -fno-buitlin appears not to affect these functions and -fpermissive does not resolve the error at the call site. AC_SEARCH_LIBS can present a simple interface based on the assumption that correct declarations are not required to test linking against a particular symbol in a library. Clearly this assumption is not valid for these particular functions in C++ mode, so it is likely that AC_SEARCH_LIBS simply cannot be used to reliably probe for __atomic_xyz functions in libatomic. In that case, configure authors must use an alternate approach. For example, - probing a different function from libatomic, if possible, - probing in C mode, if possible, - using AC_LINK_IFELSE with a valid test program, or - something else? Cheers, Nick
Bug#758905: valgrind: Valgrind needs updated suppressions
Package: valgrind Version: 1:3.9.0-7 Severity: important Dear Maintainer, After dist-upgrade, valgrind no longer has appropriate default suppressions. It worked before update; I suspect glibc update caused the problem. For example, running the command valgrind /bin/true produces hundreds of errors: ==19709== Memcheck, a memory error detector ==19709== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19709== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==19709== Command: /bin/true ==19709== ==19709== Use of uninitialised value of size 4 ==19709==at 0x401210C: memcpy (memcpy_impl.S:342) ==19709==by 0x4005BEB: fillin_rpath (dl-load.c:495) ==19709==by 0x40060B9: _dl_init_paths (dl-load.c:872) ==19709==by 0x40020D1: dl_main (rtld.c:1348) ==19709==by 0x400FA05: _dl_sysdep_start (dl-sysdep.c:249) ==19709==by 0x4003831: _dl_start_final (rtld.c:331) ==19709==by 0x40039D5: _dl_start (rtld.c:559) ==19709==by 0x4000BCD: ??? (in /lib/arm-linux-gnueabihf/ld-2.19.so) ==19709== ==19709== Use of uninitialised value of size 4 ==19709==at 0x4012180: memcpy (memcpy_impl.S:352) ==19709==by 0x4005BEB: fillin_rpath (dl-load.c:495) ==19709==by 0x40060B9: _dl_init_paths (dl-load.c:872) ==19709==by 0x40020D1: dl_main (rtld.c:1348) ==19709==by 0x400FA05: _dl_sysdep_start (dl-sysdep.c:249) ==19709==by 0x4003831: _dl_start_final (rtld.c:331) ==19709==by 0x40039D5: _dl_start (rtld.c:559) ==19709==by 0x4000BCD: ??? (in /lib/arm-linux-gnueabihf/ld-2.19.so) [SNIP] ==19709== HEAP SUMMARY: ==19709== in use at exit: 0 bytes in 0 blocks ==19709== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19709== ==19709== All heap blocks were freed -- no leaks are possible ==19709== ==19709== For counts of detected and suppressed errors, rerun with: -v ==19709== Use --track-origins=yes to see where uninitialised values come from ==19709== ERROR SUMMARY: 902 errors from 194 contexts (suppressed: 164 from 44) Expected result: no errors (all suppressed). Thanks, Nick -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: armhf (armv7l) Kernel: Linux 3.6.11+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages valgrind depends on: ii libc6 2.19-9 ii libc6-dbg 2.19-9 Versions of packages valgrind recommends: ii gdb 7.7.1+dfsg-3 ii valgrind-dbg 1:3.9.0-7 Versions of packages valgrind suggests: pn alleyoop none pn kcachegrind none pn valgrind-mpi none pn valkyrie none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735192: netpbm: pamdepth and many other applications missing
Package: netpbm Version: 2:10.0-15+b2 Severity: normal Dear Maintainer, I was surprised to discover that debian's netpbm package does not install the pamdepth application. In fact, most of the PAM-related applications appear to be missing. Certainly all the useful ones are not included. Here's an *incomplete* list of netpbm applications apparently NOT installed by Debian's package: pamaddnoise pamarith pamchannel pamcomp pamdepth pamditherbw pamedge pamendian pamenlarge pamfunc pamgauss pamgradient pamlookup pammasksharpen pammixinterlace pamperspective pampick pampop9 pamrgbatopng pamscale pamseq pamsharpmap pamsharpness pamslice pamsplit pamstereogram pamsumm pamsummcol pamthreshold pamtilt pamtodjvurle pamtofits pamtohdiff pamtohtmltbl pamtojpeg2k pamtopfm pamtopnm pamtosvg pamtotga pamtouil pamtoxvmini Please include the missing applications in the netpbm package. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages netpbm depends on: ii libc62.17-97 ii libjpeg8 8d-2 ii libnetpbm10 2:10.0-15+b2 ii libpng12-0 1.2.49-5 ii libtiff5 4.0.3-7 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages netpbm recommends: ii ghostscript 9.05~dfsg-8+b1 netpbm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691337: xdelta3: update 3.0.0.dfsg-1 (2011-01-01) to 3.04 (2012-08-18)
Package: xdelta3 Version: 3.0.0.dfsg-1 Followup-For: Bug #691337 The current xdelta3 version in Debian suffers from a non- termination bug when using external compression. The problem has been fixed upstream for some time now but remains in Debian. See the upstream bug report: https://code.google.com/p/xdelta/issues/detail?id=132 Please bump the package to the latest upstream version (3.0.6). Thanks, Nick -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xdelta3 depends on: ii libc6 2.13-38 xdelta3 recommends no packages. xdelta3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
