Bug#1063170: nettle: NMU diff for 64-bit time_t transition
Graham Inggs writes: > we have identified nettle as a source package shipping runtime > libraries whose ABI either is affected by the change in size of > time_t, or could not be analyzed via abi-compliance-checker (and > therefore to be on the safe side we assume is affected). It looks like these are the uses of time_t in nettle: $ git grep time_t pgp-encode.c: time_t timestamp) pgp.h: time_t timestamp); rsa2openpgp.c: time_t now = time(NULL); This is a bit unfortunate. This code was added in 2003 in an effort to provide support for public keys and signatures in openpgp format, but that code is neither in a good shape or at all documented. But the code *is* exposed by the shared library ABI, so I'm afraid the ABI technically depends on the size of time_t. However, this code is in the *libhogweed* so-file, so transitioning *libnettle* is probably not needed. In debian code search, I find exactly one match outside of nettle for the nettle/pgp.h header file declaring the affected functions: https://sources.debian.org/src/rust-nettle-sys/2.2.0-2/bindgen-wrapper.h/?hl=40#L40. I don't find any calls to the problematic functions themselves, which are rsa_keypair_to_openpgp and pgp_put_public_rsa_key. (The code in question wants to write the timestamp into an openpgp public key packet, and uses a 32-bit wire format for that. See https://sources.debian.org/src/nettle/3.9.1-2/pgp-encode.c/#L235. I have not been following openpgp developments, but I would hope there's some protocol update to support a larger time stamp?) Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#837108: gcc-mingw-w64-i686's libgcc dll is not found by wine
Stephen Kitt writes: > gcc-mingw-w64 ships different variants of libgcc, so it can’t just drop one > in a directory on the default Wine DLL path — Windows programs built with > gcc-mingw-w64 have to ensure that the appropriate DLLs are available > alongside them. And to be clear, what's a good way to do that? Add the appropriate mingw lib directory to WINEPATH? Is it fine to use a unix filename there, it should it somehow de translated to a windows file name? (For my use case, I'd prefer not copying the dll into the same directory as the executable, even though that's probably the way to go if I were to distribute executables to others). > What *is* possible is that previous versions of the compiler didn’t > produce binaries needing libgcc in as many cases, so you might end up > with a binary which just works whereas now you don’t. Ah, that's possible, in particular, since I'm not sure if my earlier use involved C++ at all. >> * The strace output also shows that wine attempts to open >> "/usr/lib/wine/../i386-linux-gnu/wine/./%1.dll.so" Out of curiosity, is there a good reason for this? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
王昊然 writes: > I have just installed a new Linux image with CONFIG_VSX=y, however nettle is > still triggering illegal instruction there. I've now realized that the vmrgow instruction indeed is invalid on power7, regardless of extensions (it's listed in the spec as added in ISA v2.07, and power7 corresponds to v2.06, if I've understood it correctly). Maamoun fixed it with https://git.lysator.liu.se/nettle/nettle/-/merge_requests/54 Can you check if that solves the problem for you? It might be a candidate for backporting into the debian package (there's no solid plan for next Nettle release, but if there will be any 3.8.1 bugfix release, this fix should be included). Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
王昊然 writes:
>> int main() {
>> unsigned long int hwcap = getauxval(AT_HWCAP);
>> printf("hwcap = 0x%lx\n", hwcap);
>> return 0;
>> }
>> whr@debian:~/src$ gcc -Wall cpu-feature-test.c
>> whr@debian:~/src$ ./a.out
>> hwcap = 0xdc0065c2
And the flags checked by nettle are (from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/uapi/asm/cputable.h?h=v6.1-rc1)
#define PPC_FEATURE_HAS_ALTIVEC 0x1000
#define PPC_FEATURE_HAS_VSX 0x0080
so both set in your case.
>>
>>> Is the program that crashes running under a vm, or is the kernel running
>>> on the bare metal? Each layer of vm tends to be ian opportunity to
>>> introduce
>>> errors in the list of available processor features.
>>
>> Operating systems on this machine are always running on the Power
>> Hypervisor,
>> which is a part of the server firmware.
>>
>
> I just checked the nettle source code, it is indeed correctly checked both
> PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX; and with my HWCAP has
> PPC_FEATURE_HAS_VSX set, I think it hits a limitation of this processor
> feature checking logic: hardware supporting it, but the kernel didn't.
>
> I will try to build a new kernel with CONFIG_VSX enabled by tomorrow.
My understanding is that AT_HWCAP should describe what instructions are
available to userspace processes. If an instruction set extension isn't
fully supported and enabled by all of hw/kernel/hypervisor, it should
not be listed in hwcap. So the alternative might be to leave VSX
disabled, but ensure it isn't advertised in hwcaps.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
WHR writes: > I think the Debian architecture I'm using (ppc64) should still supporting > POWER7, but apparently this library was built to use instructions unavailable > on POWER7. Nettle attempts to figure out at runtime which processor features are available. > => 0x3fffb72bedec <+76>:vmrgow v4,v0,v0 The ppc specification says "vmrgow is treated as a Vector instruction in terms of resource availability.", it's not entirely clear to me what that means, and if checking for altivec support should be enough. The fat setup for ppc is intended to enable the crashing code path only if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are both set in the status word returned from hwcap = getauxval(AT_HWCAP); This logic is in https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-ppc.c#L151 and used to selct chacha code here: https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-ppc.c#L232 > lscpu(1) output: > > Architecture:ppc64 > CPU op-mode(s):32-bit, 64-bit > Byte Order:Big Endian > CPU(s): 4 > On-line CPU(s) list: 0-3 > Model name: POWER7 (architected), altivec supported Would you expect to have the "vsx" feature mentioned there or not? You can get some diagnostics from the initialization process by setting the NETTLE_FAT_VERBOSE environment variable, and override the automatic detection with the NETTLE_FAT_OVERRIDE environment variable. Can you check what getauxval(AT_HWCAP) returns on your system? I'm not so familiar with powerpc variants. Cc:ing Maamoun who's more familiar with this arch. > Model: 2.3 (pvr 003f 0203) > Thread(s) per core:4 > Core(s) per socket:1 > Socket(s): 1 > Virtualization features: > Hypervisor vendor: pHyp > Virtualization type: para Is the program that crashes running under a vm, or is the kernel running on the bare metal? Each layer of vm tends to be ian opportunity to introduce errors in the list of available processor features. > Caches (sum of all): > L1d: 32 KiB (1 instance) > L1i: 32 KiB (1 instance) > L2:256 KiB (1 instance) > L3:4 MiB (1 instance) > NUMA: > NUMA node(s): 2 > NUMA node0 CPU(s): > NUMA node1 CPU(s): 0-3 > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable') > merged-usr: no > Architecture: ppc64 > Foreign Architectures: powerpc > > Kernel: Linux 4.1.42-rivoreo-powerpc64-largepage (SMP w/4 CPU threads) > Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), > LANGUAGE=zh_TW:zh_CN:zh:en_GB:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libnettle8 depends on: > ii libc6 2.35-3 > > libnettle8 recommends no packages. > > libnettle8 suggests no packages. > > -- no debconf information > Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#1011461: Instructions on how to install wine32 gets armhf rather than i386 packages
Package: wine Version: 5.0.3-3 Hi, I was trying to run a 32-bit windows executable using wine (which via /etc/alternatives is set to be wine-stable). This is what it looked like: $ file aes-test.exe aes-test.exe: PE32 executable (console) Intel 80386, for MS Windows $ wine aes-test.exe it looks like wine32 is missing, you should install it. multiarch needs to be enabled first. as root, please execute "dpkg --add-architecture i386 && apt-get update && apt-get install wine32" So error message is rather clear; wine32 is missing and I have to install it. However, when following the above instructions, apt-get wants to install armhf packages. This is what I get from the install command: # apt-get install wine32 Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: glib-networking:armhf gstreamer1.0-plugins-base:armhf gstreamer1.0-plugins-good:armhf gstreamer1.0-x:armhf libaa1:armhf libaom0:armhf libasound2:armhf libasound2-plugins:armhf libasyncns0:armhf libavahi-client3:armhf libavahi-common-data:armhf libavahi-common3:armhf libavc1394-0:armhf libavcodec58:armhf libavresample4:armhf libavutil56:armhf libblkid1:armhf libbrotli1:armhf libbsd0:armhf libbz2-1.0:armhf libcaca0:armhf libcairo-gobject2:armhf libcairo2:armhf libcap2:armhf libcapi20-3:armhf ... That doesn't seem right. My foreign architectures are # dpkg --print-foreign-architectures armhf arm64 ppc64el s390x i386 If I instead use # apt-get install wine32:i386 then I do get i386 packages, as I expected, including a working wine32. Not clear to me if apt-get is doing something unexpected, or when the existing wine32:armhf package is useful. But anyway, when wine fails to run a 32-bit (i386) windows executable, due to missing wine32, I'd suggest that the instructions it displays should be updated to say "apt-get install wine32:i386". Regards, /Niels Möller -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#872891: gcc-multilib conflicts with GCC cross toolchains
10.2.0-3cross2 all GCC
support library (i386)
ii libx32gcc-10-dev 10.2.0-7 amd64GCC
support library (x32 development files)
ii libx32gcc-10-dev-i386-cross 10.2.0-3cross2 all GCC
support library (x32 development files)
ii libx32gcc-s1 10.2.0-7 amd64GCC
support library (x32)
ii libx32gcc-s1-i386-cross 10.2.0-3cross2 all GCC
support library (i386) (x32)
I'm trying to compile the following hello.c program:
#include
#include
int main(int argc, char **argv) { printf("foo\n"); return 0; }
It works fine to compile it using
$ i686-linux-gnu-gcc hello.c
and that produces a 32-bit executable. However, with gcc -m32 I get
$ gcc -m32 hello.c
In file included from /usr/include/bits/errno.h:26,
from /usr/include/errno.h:28,
from hello.c:2:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file
or directory
1 | #include
| ^
compilation terminated.
(If I delete the errno.h include, it works, so it seems to only be a
problem with certain system header files missing). If I attempt to
solve the problem by installing gcc-multilib using
# apt-get install -t testing gcc-multilib
it wants to remove the arm and i686 cross compilers (but not the mingw
cross compilers),
The following packages will be REMOVED:
gcc-10-arm-linux-gnueabihf gcc-10-i686-linux-gnu
gcc-10-multilib-i686-linux-gnu
gcc-arm-linux-gnueabihf gcc-i686-linux-gnu gcc-multilib-i686-linux-gnu
Regarding the mentioned conflict over /usr/include/asm, I don't have that
directory at all on this machine. Related existing directories are
/usr/include/asm-generic/ (package linux-libc-dev:amd64)
/usr/include/x86_64-linux-gnu/asm (also package linux-libc-dev:amd64)
/usr/i686-linux-gnu/include/asm/ (linux-libc-dev-i386-cross)
/usr/arm-linux-gnueabihf/include/asm (linux-libc-dev-armhf-cross)
So the files belonging to the cross compiler packages shouldn't be in
the way, as far as I can tell. And I guess the proper location for the
missing asm/errno.h would be in /usr/include/i386-linux-gnu/asm/, but I
haven't been able to find what's the proper package to install to get
that directory (maybe linux-libc-dev:i386, but it's a bit unexpected to
have to add i386 as a foreign architecture just to get gcc -m32 to
work)?
Vagely related, I have duplicate, but not interfering, copies of some
foreign libc library files, e.g, I have both
/lib/arm-linux-gnueabihf/libc-2.31.so (package libc6:armhf)
/usr/arm-linux-gnueabihf/lib/libc-2.31.so (package libc6-armhf-cross)
I think the latter is needed by the cross compiler, and the former for
running arm binaries using qemu-arm. That's slightly annoying and a bit
wasted disk usage, but not causing any errors once I realized that both
packages are needed.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
Bug#959441: nettle: Please upload 3.6 to experimental and request a library transion slot
Magnus Holmgren writes: > --disable-dependency-tracking is for BSD make, it says, but we don't use that > even on Debian GNU/kFreeBSD And BSD make is no longer supported. The option might still be useful in some cases, but unlikely in the debian context. > But then there are the more interesting features: --enable-fat, --enable-arm- > neon, --enable-x86-aesni, and --enable-x86-sha-ni. Can you remind me why I > haven't enabled any of those? I recommend --enable-fat. And if you do that, I think the other flags you mention are useless. They're intended for manual compile-time config of which assembly files to use at compile time (and will break at runtime on processors not supporting selected processor features), while fat builds use them all and select at run time. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#956524: libhogweed5: Packaging cannot handle non-lockstep soname bumps of libnettle and libhogweed
Andreas Metzler writes: > Package: libhogweed5 > Version: 3.5.1+really3.5.1-2 > Severity: important > > Hello, > > Looking at libhogweed/libnettle deps on sid one finds this: > - > Package: libhogweed5 > Version: 3.5.1+really3.5.1-2 > Depends: libc6 (>= 2.14), libgmp10 (>= 2:6.0.0), > libnettle7 (= 3.5.1+really3.5.1-2) I think it makes sense to relax this dependency to libnettleX (>= corresponding version). However, nettle's own testsuite doesn't test the combination of linking an older hogweed library with the current libnettle. Not sure what to do about that, but some basic integration-level test would be nice. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#941150: Bug#933266: nettle 3.5.1
Daniel Kahn Gillmor writes: > The last message there is from pochu, saying "Other than that things are > looking good here, so please go ahead." Note that the symbol versioning added a while back is intended to make it easier to do an incremental upgrade, with no hard transition. E.g., it should work to link an executable both directly to libnettle.so.6 and indirectly (e.g., via gnutls) to the abi-incompatible libnettle.so.7. Or vice versa. Not very well tested, though. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#933266: nettle 3.5.1
Daniel Kahn Gillmor writes: > any chance that we can get 3.5.1+really3.5.1 into unstable soon? if > not, can you tell me what might be blocking it? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938959 (I don't know if the requested transition bug exists yet). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#884403: Patch for nettle-3.4
The below seems to be the minimal patch to enable compilation with
nettle-3.4 (and breaking support for earlier nettle versions in the
process). Something more elaborate based on NETTLE_VERSION_MAJOR,
NETTLE_VERSION_MINOR is possible, but I'm not sure it's needed.
Regards,
/Niels
diff --git a/src/dummy.c b/src/dummy.c
index c33c8869..72fd5185 100644
--- a/src/dummy.c
+++ b/src/dummy.c
@@ -113,14 +113,14 @@ base64_encode_init(struct base64_encode_ctx *ctx UNUSED)
size_t
base64_encode_update(struct base64_encode_ctx *ctx UNUSED,
-uint8_t *dst UNUSED,
+char *dst UNUSED,
size_t length UNUSED,
const uint8_t *src UNUSED)
{ abort(); }
size_t
base64_encode_final(struct base64_encode_ctx *ctx UNUSED,
- uint8_t *dst UNUSED)
+ char *dst UNUSED)
{ abort(); }
void
@@ -132,7 +132,7 @@ base64_decode_update(struct base64_decode_ctx *ctx UNUSED,
size_t *dst_length UNUSED,
uint8_t *dst UNUSED,
size_t src_length UNUSED,
-const uint8_t *src UNUSED)
+const char *src UNUSED)
{ abort(); }
int
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
Bug#881698: JPEG backgrounds fail to load in scratch
Package: scratch Version: 1.4.0.6~dfsg1-5 To reproduce: Start scratch. Select Scene and the Backgrounds tab, click the Import button. A file selector appears, with thumbnails of available backgrounds. Select Indoors --> kitchen (corresponding file is /usr/share/scratch/Media/Backgrounds/Indoors/kitchen.jpg). The image isn't loaded correctly, just a blank box instead of a thumbnail in the list of backgrounds (unlike the file selector which did show a correct thumbnail), and selecting the background has no effect, the scratch scene just stays blank. There are no error messages as far as I can find. This is in contrast to loading Indoors --> bedroom1 (/usr/share/scratch/Media/Backgrounds/Indoors/bedroom1.gif, a gif rather than a jpeg), which works fine. Which makes me think it's a problem with the jpeg support. The squeak wm appears to link with libjpeg.so.62: $ ldd /usr/lib/squeak/4.10.2-2614/squeakvm linux-vdso.so.1 (0x7ffe5ab67000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9838f72000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9838d6e000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x7f9838ab9000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f98388a2000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f983862f000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x7f98383c6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9838029000) /lib64/ld-linux-x86-64.so.2 (0x7f983954d000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f9837e0f000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x7f9837bdc000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f98379bf000) squeak-wm is version 1:4.10.2.2614-4.1, and libjpeg is package libjpeg62-turbo, version 1:1.5.2-2. I'm running on a debian gnu/linux x86_64, upgraded to stretch. For completeness, kernel 4.9.0-4-amd64, libc6 version 2.24-14. (But I think this is an old problem, I had the same experience last time I tried scratch, a few years ago, but it seems I unfortunately didn't bug report it properly at the time). Regards, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#856160: nettle-dev: Please transition nettle-dev to multi-arch
Magnus Holmgren writes: > Well, except that CHAR_BIT requires limits.h and there need to be parentheses > around the expression. I made the following fix upstream: https://git.lysator.liu.se/nettle/nettle/commit/b7052093931d69d3626a54d59783e0d9e48ea20f Not sure if you want something more minimal for a debian patch, but it would be nice if you can confirm it solves the problem. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#861632: nettle: Please configure with --enable-fat
David Gilman writes: > The feature's been out for a while but I don't know how much mainstream > use it's seen. Turning it on in Debian might be the first real > widespread use. There is some risk here, but if you change it when > testing opens up again it'll benefit from getting tested throughout the > entire release cycle. There's one reported problem, originally it used the glibc ifunc, and those custom resolver functions where sometimes called before libc was completely initialized. That code was disabled in nettle-3.2. Maybe there's beeen some recent progress with ifunc order on the glibc side, see https://sourceware.org/ml/libc-alpha/2017-01/msg00557.html Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#672936: lsh-server: does not respect umask
Sam Geeraerts writes:
> The default umask on a Squeeze system is 0022. However, when I
> connect via ssh to lsh-server on my Squeeze system the umask
> in the session is . It would make more sense to also have
> 0022 there.
Hi,
I had totally forgotten about this problem, but I was recently bitten by
it myself. And it turned out that it really has nothing to do with PAM,
it was a bug in lshd's daemon setup code, which cleared the umask for no
good reason. Which didn't matter much as long as we had /etc/profile and
other environment setup scripts set umask explicitly.
I just committed a fix and a test case to the stable branch
("lsh-2.0.4").
See
https://git.lysator.liu.se/lsh/lsh/commit/99b8bf8cf29a8a5e6cb63edd5c46bfa337b5a1d2,
and the next commit with the test case,
https://git.lysator.liu.se/lsh/lsh/commit/7f667afab075cf7cb3983bffa627e0c9345b9e72
With this change, shells spawned by lshd will inherit the umask the lshd
process was started with.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
Bug#819530: Bad interation with libstdc++ transition.
Adrian Bunk writes: > This sounds like a problem in apt to me, and I've seen issues like > that before. > > What does apt say for > apt-get install -t testing libstdc++6 build-essential > ? The following packages have unmet dependencies: perl : Depends: perl-base (= 5.20.2-3+deb8u6) but 5.24.1~rc3-3 is to be installed Depends: perl-modules (>= 5.20.2-3+deb8u6) Recommends: rename but it is not going to be installed perl-base : Breaks: perl (< 5.24.1~rc3~) but 5.20.2-3+deb8u6 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. > If it gives an error, manually add the packages it cannot install on the > commandline, until you either found the actual dependency problem or apt > found a way forward. If I add perl too, it's back to uninstalling kde. > When apt found a way forward, and if it still wants to remove packages > you want to keep, also add them on the commandline. I tried that earlier, but gave up since the number of dependency problems just seemed to grow. But if I keep doing that, without giving up, I eventually find a resolution not uninstalling lots of packages by using apt-get install -t testing libstdc++6 build-essential perl kde-standard \ juk libtag1v5 libtag1v5-vanilla akregator kio libkf5libkdepim-plugins \ libkf5libkdepim5 libkf5wallet5 libkwalletbackend5-5 libkf5notifications5 \ phonon4qt5 k3b vlc Thanks! (Now remaining problem is that I don't have the needed 1GB+ available space on /var, but I'll sort that out one way or the other). I still think it's unfortunate that the libicu upgrade requires all of that. Thanks for the help, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#819530: Bad interation with libstdc++ transition.
Hi,
as a user, I experience a pretty bad interaction between this transition
and the recent libstdc++ transition.
I have a system with a mix of packages from stable and testing, which
usually works fine. However, upgrading to the latest libstdc++ at this
point breaks a lot of things due to gcc-6 C++ incompatibilities (which I
don't fully understand, I usually don't care much about C++). What I see
is that apt-get install -t testing libstdc++6 would have to uninstall
*lots* of stuff, including build-essential, texlive, libreoffice and
most of kde. So I don't want to do that at this time.
Directly broken packages on my system are
$ aptitude search -F '%c %p %V'
'?and(?installed,?reverse-breaks(?and(?name("libstdc\\+\\+6$"),?version("6\\.2\\..*"'
i libboost-date-time1.55.0 1.55.0+dfsg-3
i libkolabxml1 1.0.2-2
i libreoffice-core 1:4.3.3-2+deb8
i libstdc++6 4.9.2-10
i libstdc++6:i386
This is the background, and now I would like to upgrade to libicu57,
because that blocks upgrade of wget, making it a "kept back" packet.
Dependency chain: wget-1.18 -> libpsl5 -> libicu57.
Now the interesting part: libicu57 has a dependency on libstdc++6 (>=
5.2). So it doesn't need gcc-6, gcc-5 is good enough. But the
libstdc++6 packages for gcc-5 are no longer in the archive, the only
versions available as far as I can find are 4.9.2-10 (which I have
installed), and 6.2.0-6, and the latter one breaks half of the world, as
described above. And then non-existence of version 5.x (x >= 2) of
libstdc++6 makes the libicu upgrade depend on upgrading libstdc++6 to
gcc-6, even though it shouldn' have to.
I've looked at the mirror I use, I'd expect libstdc++6 version 5.x to be
located in main/g/gcc-5/, but it's not there. I don't really understand
the process, but I guess the packages were deleted when gcc-6 migrating
to testing?
I don't know what to do about it, maybe it is an issue for the release
team, but I though I should raise the problem here first. To untangle
the transitions, one would need an libicu57 with a libstdc++6 dependency
which can be satisfied by some package which (i) is older than gcc-6 and
(ii) is actually installable from the package archive. Options I see
(not sure what's possible):
* Recompile libicu57 with gcc-4.
* Resurrect gcc-5 libstdc++6 library packages in the archive.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
Bug#837665: lsh-utils: FTBFS with bindnow and PIE enabled
Magnus Holmgren writes: > The problem rather seems to be the missing #include "lsh_string.h". Implicit > declarations probably are extra bad with -fPIE. Thanks! I just tried compiling after ./configure --with-tcpwrappers. Which results in an warning on lsh_get_cstring being undeclared. It compiles without warnings after adding that missing include. (Apparently no warnings about the incorrect UNUSED...). Let me see if I can understand the way it fails (the fix, adding the missing include, is the same either way, of course). lsh_get_cstring returns a pointer, while an implicitly declared function will be assumed to return int. And on x86_64, int is of a smaller size than a pointer, so it's a very real difference. And the compiler is free to ignore the high part, so it compiles it to something like call lsh_get_cstring mov %eax, %edx ;; pass 32-bit return value as argument for next call ... setup other args for the call ... call request_init while with a correct declaration, it must generate mov %rax, %rdx ;; copy all 64 bits The 32-bit mov above doesn't leave the high half of %rdx unchanged, instead, it is always cleared. Which means that the above code will work nonetheless in case all pointers occuring at runtime happen to have the high 32-bits all zeros. In this case, memory for strings are always allocated using malloc. So my guess is that traditionally, malloc returns small addresses if possible, while -fPIE implies that memory returned by malloc is mapped at randomized locations where the high 32 bits are almost never zero? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Bug#837665: lsh-utils: FTBFS with bindnow and PIE enabled
Steve Beattie writes:
> This is an issue for lsh-utils in Ubuntu as well. I attempted to
> manually reproduce the lsh-2-test failure and this is the backtrace I
> got when the lsh server segv'ed:
Thanks alot! This narrows it down quite a bit.
> (gdb) bt full
> #0 __strncpy_sse2_unaligned () at
> ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
> No locals.
> #1 0x7fb1fe1ec0aa in ?? () from /lib/x86_64-linux-gnu/libwrap.so.0
> No symbol table info available.
> #2 0x7fb1fe1ec2c9 in request_init () from
> /lib/x86_64-linux-gnu/libwrap.so.0
> No symbol table info available.
> #3 0x557c03c3abaa in do_tcp_wrapper (s=0x557c045eba20, a=0x557c045ec740,
> c=0x557c045ec7c0, e=) at io_commands.c:347
> lv = 0x557c045ec740
> res = {fd = -1, user = '\000' , daemon =
> "unknown", '\000' , pid = "15613\000\000\000\000", client
> = {{
> name = '\000' , addr = '\000' times>, sin = 0x0, unit = 0x0, request = 0x7ffc87252000}}, server = {{
> name = '\000' , addr = '\000' times>, sin = 0x0, unit = 0x0, request = 0x7ffc87252000}}, sink = 0x0,
> hostname = 0x0, hostaddr = 0x0, cleanup = 0x0, config = 0x0}
> #4 0x557c03c382ab in do_listen_callback (s=0x557c045ec370, fd= out>) at io.c:769
> self = 0x557c045ec370
> peer = {ss_family = 2,
> __ss_padding = "\266\n\177\000\000\001", '\000' ,
> "\a\000\000\000\000\000\000\000\201J\305\003|U\000\000\360\303^\004|U",
> '\000' , "\001", '\000' ,
> "\360$%\207\374\177\000\000\001\000\000\000\000\000\000\000\003\000\000\000\374\177\000\000$\000\000\000\000\000\000\000\b\000\000\000\000\000\000",
> __ss_align = 140722575844800}
> addr_len = 16
> conn =
I see nothing obviously wrong here, except that I don't understand where
gdb picks up the peer, addr_len and conn variables at the end.
I would probably be helpful to add a break point on do_tcp_wrapper and
examine the variables.
Assuming that the bug is not inside tcpwrappers itself, I think the most
likely way this can crash is if the service name,
lsh_get_cstring(self->name), is NULL when passed to request_init, since
that's the only pointer argument to the function. It shouldn't be NULL,
of course.
I see one other odd thing when reading this code. The UNUSED declaration
of the first argument is wrong; maybe recent gcc omits code related to
that argument? You could try deleting that, and see if it makes a
difference.
It may also be useful to run lshd under valgrind, in case the crash is
caused by some earlier invalid memory accesses.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
Bug#837665: lsh-utils: FTBFS with bindnow and PIE enabled
Balint Reczey writes: > The rebuild tested if packages are ready for a transition > enabling PIE and bindnow for amd64. > > For more information about the changes to sid's dpkg and GCC please > visit: > https://wiki.debian.org/Hardening/PIEByDefaultTransition > > Relevant part (hopefully): > ... > Testing lshd > lshd pid: 28352 > Testing /<>/src/testsuite/rapid7-ssh-pdu/001.pdu > ./rapid7-lshd-test: 20: kill: No such process > > Server died Some kind of backtrace or the like would help to understand why the server (lshd) died unexpectedly). I don't fully understand what "bindnow" means here. Only related known problem I'm aware of is nettle's use of ifunc, which doesn't work quite as expected. Use of ifunc was disabled in nettle-3.2, but breaks --enable-fat builds of nettle-3.1 and 3.1.1; they crash if dlopen:ed with RTLD_NOW. lsh itself does nothing special as far as I'm aware. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
Bug#837108: gcc-mingw-w64-i686's libgcc dll is not found by wine
Package: gcc-mingw-w64-i686
Version: 4.9.1-19+14.3
The default dll search path used by wine32 does not include the location
of the libgcc_s_sjlj-1.dll library supplied with gcc-mingw-w64-i686.
I can't say if it's wine, mingw, or both, which are wrong here. Wine's
dll directory, /usr/lib/i386-linux-gnu/wine/, seems reasonable, so I'm
filing it on mingw. But maybe it's no good idea to have
gcc-mingw-w64-i686 install files in the same directory. So we might need
to extend wine's dll path to add some suitable directory for other
packages to install dlls in.
My expectation is that if I compile a program using i686-w64-mingw32-gcc
or i686-w64-mingw32-g++, I should be able to run that executable using
wine. I've used to be able to do that, not sure at which package upgrade
it stopped working. Here's an example where this fails:
#include
#include
int
main(int argc, char **argv)
{
printf("foo\n");
return 0;
}
To reproduce, save into a file "hello.cxx", compile using
i686-w64-mingw32-g++ hello.cxx
and run it using
WINEDEBUG=err+all wine ./a.exe
Expected result is a line "foo" written to stdout. Instead, I get
the error
err:module:import_dll Library libgcc_s_sjlj-1.dll (which is needed by
L"Z:\\home\\nisse\\hack\\test\\a.exe") not found
err:module:LdrInitializeThunk Main exe initialization for
L"Z:\\home\\nisse\\hack\\test\\a.exe" failed, status c135
By strace (strace -f -e open wine a.exe), I see that wine attempts to open
[pid 31177]
open("/usr/lib/wine/../i386-linux-gnu/wine/./libgcc_s_sjlj-1.dll.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 31177]
open("/usr/lib/wine/../i386-linux-gnu/wine/./libgcc_s_sjlj-1.dll.so",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
which seems ok, /usr/lib/i386-linux-gnu/wine/ exists and there
are a lot of dll files there. But not libgcc.
$ apt-file search libgcc_s_sjlj
gcc-mingw-w64-i686:
/usr/lib/gcc/i686-w64-mingw32/4.9-posix/libgcc_s_sjlj-1.dll
gcc-mingw-w64-i686:
/usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc_s_sjlj-1.dll
I have this package installed, and the files exist on my system, they
just aren't found by wine. Besides the different location, also note the
different file name, ".dll" vs ".dll.so".
The debian wine* packages I have installed are wine, wine32 and wine64,
all version 1.8.4-1.
The debian gcc-mingw* packages installed are gcc-mingw-w64,
gcc-mingw-w64-base, gcc-mingw-w64-i686, gcc-mingw-w64-x86-64, all
version 4.9.1-19+14.3.
I'm running this on an x86_64 machine running mostly debian stable,
but certain packages, including wine, installed from testing (apt-get
install -t testing wine).
Some curiosities:
* Switching the order of the two includes, or deleting the include of
, makes this example work. It then prints out the message
"foo", as expected. (The executable then no longer depends on the
libgcc dll, I guess).
* The strace output also shows that wine attempts to open
"/usr/lib/wine/../i386-linux-gnu/wine/./%1.dll.so"
^^
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Bug#787893: closed by Magnus Holmgren (Re: Bug#787620: libnettle.so.4: mpv gives segmentation fault after update this morgning)
Alfred Pengelly writes: > It is the only version of libnettle6, but there is a libnettle4. If I > remove either of these, KDE, among other things, will also uninstall > (or break). I'm not sure if I have understood the reason this bug was > closed off; is there a solution or not? Is the nominated version > (3.1.1-3) of libnettle6 the one that should or should not be used? > There does not appear to be an upgrade for it. There's an incompatibility between libnettle4 and libnettle6, when both are linked into the same process. Which typically hapens if a program links explicitly to both nettle ant gnutls and gnutls in turn links with a different version of nettle. So there's a transition where things break in the middle of it. As far as I understand (I'm not a debian maintainer) the idea was to have all packages using nettle rebuilt to link with libnettle6, and not let libnettle6 migrate from unstable to testing until those rebuilds are complete so that all the packages can migrate to testing more or less simultaneously. Have you done a apt-get update && apt-get upgrade, to make sure the kde packages and their dependencis are up-to-date? Maybe it would help to describe whick packages you have installed which still depends on libnettle4, something like apt-cache rdepends --installed libnettle4 And as for starting gimp, kde packages using libnettle4 shouldn't matter, the important thing is if any of the libraries or plugins used by gimp still link to libnettle4. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787893: closed by Magnus Holmgren (Re: Bug#787620: libnettle.so.4: mpv gives segmentation fault after update this morgning)
Alfred Pengelly writes: > So what can I do to run gimp? Is this just a "tough luck it's not > going to work"? I already have version the specified version of > libnettle6. Is that the *only* version of libnettle* which is installed? Try uninstalling the old version, or at least check which packages you still have around which depend on it. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783699: nettle-dev is not Multi-Arch compatible
[I'm cross-posting to the nettle list and a debian bug, so please take care when replying] The issue is that there are some differences in generated nettle header files depending on architecture and compiler version. Francois Gouget writes: > Here is a proposed patch for the compiler version issue in nettle-stdint.h: > > $ cat debian/patches/multiarch.patch > --- a/aclocal.m4 > +++ b/aclocal.m4 > @@ -857,7 +857,7 @@ > fi # shortcircut to system "stdint.h" > # -- PREPARE VARIABLES -- > if test "$GCC" = "yes" ; then > -ac_cv_stdint_message="using gnu compiler "`$CC --version | head -1` > +ac_cv_stdint_message="using gnu compiler $CC" > else > ac_cv_stdint_message="using $CC" > fi If we go this path, maybe just drop the conditional and unconditionally print "using $CC"? I'm not sure about the reason for displaying the version, but I guess some older gcc versions did stdint and/or inttypes.h differently. If you have the time, it would be helpful to look at the latest version of AX_CREATE_STDINT_H (from autoconf archive) and see if it does anything differently. Nettle uses a pretty old version (which seems to work fine). > For GMP_NUMB_BITS here are some thoughts: You must understand that nettle defines GMP_NUMB_BITS only if configured with --enable-mini-gmp. This configuration is not intended to be compatible with anything else, and should never be installed on a normal debian system. It's intended for small embedded systems which needs to verify digital signatures, but which consider the real libgmp too large. > * Is it really necessary to install version.h? >IMHO the right place for other packages to figure out library versions is > through >some scripting in the configure script rather than through a >header. This has been requested by users. Not everyone uses autoconf. And it's very common practice, I think both gmp and gnutls have similar version defines. > * GMP_NUMB_BITS is already defined by libgmp-dev in gmp.h. More > preceisely Exactly, and when not configuring with --enable-mini-gmp, that's the definitions which is used. Getting into the details, Nettle's definition of GMP_NUMB_BITS conceptually belongs in mini-gmp.h. However, mini-gmp is a standalone package which doesn't use autoconf. And it has to be a preprocessor *constant*, so definiting it like sizeof(unsigned long) * CHAR_BIT won't cut it, since the preprocessor doesn't understand sizeof. Therefore the definition, for the --enable-mini-gmp configuration which needs it, should be in a nettle include file. Then the cleanest way would be to omit the definition completely when not using --enable-mini-gmp. I haven't done that, because it would make the substitution logic harder, and because I was thinking that #define NETTLE_USE_MINI_GMP 0 #if NETTLE_USE_MINI_GMP # define GMP_NUMB_BITS 64 #endif is harmless whatever value appears in the second define. If it helps, I guess this could be changed into the architecture independent #define NETTLE_USE_MINI_GMP 0 #if NETTLE_USE_MINI_GMP # define GMP_NUMB_BITS the moon is made of green cheese #endif Opinions? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
Andreas Metzler writes: > No, that does not work. wget would be looking for unversioned > references to nettle-symbols, and given the choice ot two differently > versioned ones it will not prefer either over the other. I see. So for a really smooth transition from jessie and up, including partial upgrades, one would need an update with nettle-2.7.x with versioned symbols, and all packages linking explicitly with nettle rebuilt against that version (about 30 packages, if apt-cache rdepends libnettle4 is a good way to list them). And try to ensure all of these packages are upgraded *before* the packages with nettle-3.1 and current gnutls are installed. Maybe too complicated to be worth the effort? Are there any shortcuts, which improve the situation over the status quo? For clarity, I'm the "upstream" here. I'm a also debian user, but not very familiar with debian packaging. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
Magnus Holmgren writes: > Not sure how this situation is normally handled, but when Nettle 3.1 is > uploaded to sid, new versions of GnuTLS and other packages linking against it > should follow soon after [1], so the problem is temporary. As I understand it, the problem is applications like wget which link explicitly with both gnutls and nettle (and this is the usecase I had in mind when I at last decided to do symbol versioning in nettle). To be able to install new nettle and gnutls without crashing wget, either wget has to be relinked first, or we need some magic packaging dance. > [1] That is, Nettle 3.1 will be uploaded to sid when the current upload to > experimental has been cleared by the FTP masters and GnuTLS is ready to > follow, The question is, when will an updated version of wget (and other applications) follow? I don't fully understand debian transitions either, but to be able to get a smooth upgrade to nettle-3.x in the next release (and for users that mix wget from jessie and nettle from testing), I suspect one has to do something like: 1. Package a new "libnettle4" package which is a nettle-2.7.x with versioned symbols. For now, let's call it nettle-2.7.2. 2. Get this package into jessie as an update. 3. Package nettle-3.x (x >= 1) as "libnettle5", and declare some kind of package conflict with libnettle4 versions earlier than the one prepared in (1). Now, it's still a bit unclear to me how versioned symbols really work. Is it still necessary to relink the wget executable? Or will the combination of * Current wget package, linking to gnutls and libnettle4.so, * a new gnutls package, linking to a libnettle5-package containing nettle-3.1 * libnettle4.so from the nettle-2.7.2 release under consideration, i.e., with versioned symbols, work and resolve all symbols correctly? I.e., all direct references to nettle symbols in wget should get definitions in libnettle4.so, and all references via gnutls should get definitions in libnettle5.so. BTW, Magnus, are you subscribed to the nettle-bugs list? Some of this discussion belongs there. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
Andreas Metzler writes: > Looks like we need a two-step transition: nettle 2.7 -> nettle > 2.7+versioned_symbols , nettle 2.7+versioned_symbols -> nettle 3.1. I'm considering making a nettle-2.7.2 release with version symbols. The version string would simply be derived from the version in the soname, "NETTLE_4" and "HOGWEED_2". Would that help? Also see http://lists.lysator.liu.se/pipermail/nettle-bugs/2015/003383.html (not sure crossposting between the nettle list and debbugs is a good idea). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783699: nettle-dev is not Multi-Arch compatible
Francois Gouget writes: > The amd64 version conflicts with the i386 one which makes it impossible to > install both. > In turn this makes it impossible to install libgnutls28-dev:i386 which is > needed for > building the 32 bit version of Wine on a 64 bit system. > > A look at the package shows only one minor header conflict so fixing this > should not be > too hard: > > --- nettle-dev-amd64/usr/include/nettle/nettle-stdint.h 2014-07-05 > 17:02:34.0 +0200 > +++ nettle-dev-i386/usr/include/nettle/nettle-stdint.h 2014-07-05 > 18:00:37.0 +0200 > @@ -2,7 +2,7 @@ > #define __NETTLE_STDINT_H 1 > #ifndef _GENERATED_STDINT_H > #define _GENERATED_STDINT_H " " > -/* generated using gnu compiler gcc (Debian 4.9.0-9) 4.9.0 */ > +/* generated using gnu compiler gcc (Debian 4.9.0-7) 4.9.0 */ > #define _STDINT_HAVE_STDINT_H 1 > > /* ... shortcircuit part ... */ There's going to be another minor header conflict in nettle-3.1, in version.h or bignum.h, on an line which is #if:ed out in standard configurations (more precisely the line matters only in builds configured with --enable-mini-gmp). No idea how to handle such unimportant differences in generated headers in debian. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763494: squeak-vm: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)
Ondřej Surý writes: > I have no idea if it fixes the #744289, but if the bundled library is > the original libjpeg6b then it might. I've now tested (after upgrading squeak-vm to version "1:4.10.2.2614-1.1+b1"). jpeg files still don't work in scratch, and I get no error messages. To reproduce (with an English locale): Start scratch. For me, this displays a message Executing: /usr/lib/squeak/4.10.2-2614/squeakvm -encoding UTF-8 -vm-display-x11 -plugins /usr/lib/scratch/plugins/:/usr/lib/squeak/4.10.2-2614/ /usr/share/scratch/Scratch.image and then the scratch window appears. Click "Stage" on the right. In the middle, we get three tabs, including a "Backgrounds" tab. Select the "Backgrounds" tab. Click the "Import" button. A file selector appears. Select the "Indoors" folder and the file "party-room" (in the file system, that's /usr/share/scratch/Media/Backgrounds/Indoors/party-room.jpg), and click "Ok". We get a new entry in the list of backgrounds, but the thumbnail is an empty image. Interestingly, I do get a correct thumbnail for the party-room image in the file selector, but I guess the thumbnails are stored separately in scratchthumbs.db. For contrast, click the "Import" button again, and select Indoors/bedroom1 (corresponding to the file "bedroom1.gif"). We get a new entry in the list, with a correct thumbnail image, and since it is selected, we also get a larger version on the right as the stage background. So something is still broken with jpg support in squeak-vm and/or scratch. And I think backgrounds are a quite important feature in scratch. Maybe someone more familiar with smalltalk and squeak can cook up a simpler jpeg test case. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763494: squeak-vm: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)
Ondřej Surý writes: > I am in process of testing each package in question to compile against > libjpeg-turbo and I will provide a suitable patch for each package > when I will succeed. Does the move to libjpeg-turbo also address the problem described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744289, i.e., that the scratch package is unable to load any jpeg files, e.g., scene backgrounds? (And maybe that bug ought to be reassigned to the squeak-vm package?) Best regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764157: lsh-utils: [kfreebsd] testsuite fails sometimes
Steven Chamberlain writes:
> lsh-utils sometimes fails to run the testsuite on the kfreebsd buildds:
>
> * 2.1-4 on kfreebsd-i386
> https://buildd.debian.org/status/fetch.php?pkg=lsh-utils&arch=kfreebsd-i386&ver=2.1-4&stamp=1412538954
> | Testing /«PKGBUILDDIR»/src/testsuite/rapid7-ssh-pdu/431.pdu
> | tcpconnect: shutdown failed: Connection reset by peer
> | Connect failed
> | FAIL: rapid7-lshd
What this test does, it starts lshd, then uses tcpconnect to connecct
and send some 666 ssh messages broken in different ways, and then the
expected behaviour is that lshd should disconnect each attempt in a
controlled way, and not crash.
Now, my guesss is that there's a race condition, the client (tcpconnect)
calls shutdown on the socket after it has sent its data. If I understand
this correctly, the server responds with a TCP reset in case that socket
has been closed before the client's TCP fin arrives. Does that make
sense?
The linux man page for shutdown(2) doesn't list ECONNRESET as a possible
error, only ENOTCONN. So it seems bsd and linux uses different errno
values for this TCP error case?
Can you try the below patch for tcpconnect (located in
lsh/src/testsuite)?
Regards,
/Niels
diff --git a/src/testsuite/tcpconnect.c b/src/testsuite/tcpconnect.c
index 73398ae..c7dfa02 100644
--- a/src/testsuite/tcpconnect.c
+++ b/src/testsuite/tcpconnect.c
@@ -307,7 +307,8 @@ main (int argc, char **argv)
wait_stdin_eof = 0;
if (!wait_remote_eof)
break;
- if (shutdown (fd, SHUT_WR) < 0 && errno != ENOTCONN)
+ if (shutdown (fd, SHUT_WR) < 0
+ && errno != ENOTCONN && errno != ECONNRESET)
die("shutdown failed: %s\n", strerror(errno));
}
else
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753423: libhogweed2 symbol problems with curl and virtualbox too
Alan James writes: > Both these programs link to /usr/local/lib/libgmp.so.10 > > $ objdump -T /usr/local/lib/libgmp.so.10 |grep cnd > 00027990 gDF .text0136 Base > __gmpn_addcnd_n > 00027ad0 gDF .text0136 Base > __gmpn_subcnd_n And that's an older version of gmp (these symbols were renamed when they were added to the public and documented GMP interface). If you remove this local gmp installation and let the programs link to /usr/lib//libgmp.so.10 from the debian package instead, does it work better? Alternatively, upgrade the version under /usr/local to gmp-6.0.0. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753423: libhogweed2 symbol problems with curl and virtualbox too
Alan James writes: > PHP Warning: PHP Startup: Unable to load dynamic library > '/usr/lib/php5/20131226/curl.so' - > /usr/lib/x86_64-linux-gnu/libhogweed.so.2: undefined symbol: > __gmpn_cnd_sub_n in Unknown on line 0 Can you run ldd on some failing program, to see which version of gmp it really tries to link with? The symbol should be in gmp-6.0.0, e.g., $ objdump -T /usr/lib/x86_64-linux-gnu/libgmp.so.10.2.0 |grep cnd 0002c4d0 gDF .text 0136 Base __gmpn_cnd_sub_n 0002c390 gDF .text 0136 Base __gmpn_cnd_add_n Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753423: libhogweed: git push to remote not working because of a symbol lookup error.
"Richard G. Riley" writes: > git-remote-https: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n [...] > Versions of packages libhogweed2:amd64 depends on: > ii libc6 2.19-4 > ii libgmp10 2:6.0.0+dfsg-4 > ii libnettle4 2.7.1-2+b1 > ii multiarch-support 2.19-4 For what it's worth, that symbol should be defined by libgmp-6.0.0. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745233: libhogweed2: should have versioned depend on newer libgmp10
Magnus Holmgren writes: > Oh well, I went ahead and did it for you. However, as you can see, some > symbols went missing in both 5.1 and 6.0. Are those the ones in the #MISSING: lines in your file? They are all undocumented internal functions in GMP. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743087: nettle: FTBFS: missing symbols
David Suárez writes: > Source: nettle > Version: 2.7.1-1 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20140329 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. >> --- debian/libhogweed2.symbols (libhogweed2_2.7.1-1_amd64) >> +++ dpkg-gensymbolsi_VY4I2014-03-30 00:28:48.397249583 + >> @@ -26,12 +26,12 @@ >> _nettle_mpn_set_base256@Base 2.7 >> _nettle_mpz_limbs_cmp@Base 2.7 >> _nettle_mpz_limbs_copy@Base 2.7 >> - _nettle_mpz_limbs_finish@Base 2.7 >> - _nettle_mpz_limbs_modify@Base 2.7 >> - _nettle_mpz_limbs_read@Base 2.7 >> +#MISSING: 2.7.1-1# _nettle_mpz_limbs_finish@Base 2.7 >> +#MISSING: 2.7.1-1# _nettle_mpz_limbs_modify@Base 2.7 >> +#MISSING: 2.7.1-1# _nettle_mpz_limbs_read@Base 2.7 Are you by any chance linking with gmp-6.0.0, released a few days ago? _nettle_mpz_limbs_finish, _nettle_mpz_limbs_modify, and _nettle_mpz_limbs_read are internal functions in nettle, which aren't needed with gmp-6.0.0. Then, Nettle-2.7.1 has not been tested with gmp-6.0.0. I hope there should be no real problems. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Bits from linux.conf.au
Martin Pitt writes:
> I think that would be the worst possible (non-)decision that could be
> made. We already have more than enough bugs in Debian; officially
> trying to support 3 init systems is going to end up being a
> combinatorial explosion of testing and bugs, for no obvious benefit
> for the user ("pick your set of bugs").
One of the init systems is the *default*, and that's likely the only one
that will see testing and quality that is up to debian's standards.
Users should not select a non-default init system lightly. I think it's
going to be a bit like using the "non-default" kfreebsd or hurd kernel.
It's not for the average user who wants as much software as possible to
work as well as possible. It's for the user who is curious, or really
likes to use or hack that piece of software, or maybe hopes that it's
going to replace the current default component sometime in the future.
Then there are differences of course. On one hand, I imagine both
upstart and systemd are more mature than the hurd, and they definitely
have more users. And on the other hand, the needed porting to get a
random daemon to work well with a new init system might be slightly more
work than for porting the same random daemon to work on the hurd or
kfreebsd.
(And it's going to be at least 4 init systems, not 3, right? systemd,
upstart, sysv and openrc. With support for sysv possibly dropped after a
few release cycles).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721187: nettle-dev: CFB block cipher mode
Clint Adams writes: > Decrypting ciphertext generated with "OpenPGP's variant of > Cipher Feedback (CFB) mode." (See RFC4880 section 5.7) Good to know, it's a long time since I looked at either OPENPGP or CFB, so I was unaware of that connection. Maybe some care is needed to define CFB in nettle so that it can be used for both openpgp and "standard" CFB. Test vectors seem to be available at http://csrc.nist.gov/publications/nistpubs/800-20/800-20.pdf. Are there any test vectors specifically for openpgp use of CFB? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721187: nettle-dev: CFB block cipher mode
Clint Adams writes: > Please add Cipher feedback (CFB) mode. Any particular application you have in mind, which needs this mode? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698539: nettle: Patch for x32 port
Daniel Schepler writes: > Here's the interim patch I'm currently using to build nettle on the > unofficial > Debian x32 port. Two issues it addresses: > - The camellia test fails. I'm currently working around this by passing > --disable-assembler to configure on x32. Can be a bit tedious to track down. I usually print out intermediate values from a working build, and then step through the assembly in gdb to see in which round, and where in the round, values depart. Could also be some ABI issue (not necessarily limited to x32), like clobbering some register which is supposed to be preserved. Does x32 use the same ABI and calling conventions as plain x86_64? > - The des-compat test segfaults. It turns out compiling with -O1 instead of - > O2 fixes this, so this might be a compiler bug with the version of gcc I'm > currently using. Until proven otherwise, that sounds a bit like a compiler bug. Where does it crash (backtrace)? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689441: Conflicting initializers of variable argp_program_bug_address
Michael Tautschnig writes: > I'm sorry, I've only got the online version (from http://www.iecc.com/linker/) > at hand right now, which doesn't seem to have subsection numbers. Under which > heading would I find that information? Under the heading "Searching libraries", Chapter 6, http://www.iecc.com/linker/linker06.html. > Well, the error is not raised by ld, but only by our research tool chain. I > don't think this is what you were looking for, but anyhow: > > error: conflicting initializers for variable `c::argp_program_bug_address' > old value: &""[0] > Module: ex3 > new value: NULL > Module: argp-ba Then I'm afraid that tool chain simply has a different idea on how libraries work, compared to unix ld. Libraries should be handled differently than ordinary object files. If your tool chain is given equivalent arguments to what you pass to gcc/ld, then it has no reason to use the definition of the symbol argp_program_bug_address provided by libargp.a/argp-ba.o, since that symbol is already defined by an earlier object file. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689441: Conflicting initializers of variable argp_program_bug_address
Michael Tautschnig writes: > I'm not sure where such behaviour would be specified for a unix > linker!? Not sure, either. It is described quite clearly in Levine's "Linkers and Loaders" (see sec 6.4). Which is recommended reading for anything linker-related. I haven't tried checking posix specs, but I imagine it might be specified there. > gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -ggdb3 -Wall -W -Wmissing-prototypes > -Wmissing-declarations -Wstrict-prototypes -Waggregate-return > -Wpointer-arith -Wbad-function-cast -Wnested-externs -Wl,-z,defs > -Wl,--as-needed -Wl,-z,relro -o ex3 ex3.o ../libargp.a I'm not entirely sure what the specified linker flags mean, but order looks correct. What was the error message, precisely? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689441: Conflicting initializers of variable argp_program_bug_address
Michael Tautschnig writes: > src/argp/testsuite/ex3.c:const char *argp_program_bug_address = > ""; > src/argp/argp-ba.c:const char *argp_program_bug_address = 0; > (The latter goes in src/argp/libargp.a.) > > The linker is free to pick either of the values; No, the linker does *not* have that freedom. A unix linker is supposed to process arguments in order, and bring in argp-ba.o from libargp.a if and only if the symbol argp_program_bug_address (the *only* symbol defined in that file) is referenced in the earlier objects, but *not* defined in the earlier objects. What does your linker command line look like? Order matters, and -largp must be placed after ex3.o. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686212: [LCFC] templates://lsh-utils/{lsh-server.templates,control}
Justin B Rye writes: > (Not to mention "Why The Name", or at any rate "Why The Initial L".) I honestly can't remember exactly how I was thinking back in 1998. The L may stand for "Lysator" (a computer club at Linköping university). Or it can stand for liberty. Or lsh can be the left shell if the old rsh program is the right shell. None of the alternatives appear very compelling, I guess. Happy hacking, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672936: lsh-server: does not respect umask
Sam Geeraerts writes: > The comments in doc/NOTES indicate that's it's not going to happen in > the future either. It's some years since I wrote that... There was also some discussion on debian lists at the time. I'm still not very fond of PAM, and I think it is unfortunate if its use is mandatory on debian. Nevertheless, if you look at the code intended to become lsh-3.0, it would be a bit more reasonable to add real PAM support, since the user authentication will run as a spearate process (lshd-userauth), which can even use blocking i/o. But that's not going to happen soon, so it's of little help for the debian package of current lsh. > Although the code does seem to have some PAM support in the form of > lsh-pam-checkpw. That somewhat crude hack is only for verifying passwords against PAM. > But that probably wouldn't set the umask if it were enabled. You're right. It doesn't do anything related to the state of login sessions. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672936: lsh-server: does not respect umask
Sam Geeraerts writes:
> The default umask on a Squeeze system is 0022. However, when I
> connect via ssh to lsh-server on my Squeeze system the umask
> in the session is . It would make more sense to also have
> 0022 there.
I think traditionally, setting up the default umask was a job for the
login shell, typicallly configured in /etc/profile.
>From a quick look, it seems umask is no longer set up i /etc/profile,
but by some PAM module, configured via /etc/login.defs. Not sure exactly
where, though. The documentation says its "pam_umask", but no such
module is mentioned in any file under /etc/pam.d/*, as far as I can see.
And now enter lshd, which is *not* PAMified.
I'm not sure what the status of PAM is in debian. Does policy say that
all login-like services must use PAM, and if you don't use PAM, you're
on your own? Or is there some recommended way for non-PAM-services to
get this right on Debian?
One possible workaround might be to add a script to /etc/profile.d which
does something like
while read key value rest_of_line ; do
if [ "$key" = "UMASK" ] ; then
umask "$value"
fi
done << EOF
`cat /etc/login.defs`
EOF
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648014: Too strict dependencies on binutils, maybe due to inappropriate dynamic linking with binutils libraries?
Yaroslav Halchenko writes: > you could try demos from > /usr/share/lush/demos/ Ok, I have now tried a few of them (calculator, life, lunar-lander), and they seems to work fine. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648043: Too strict dependencies on binutils, maybe due to inappropriate dynamic linking with binutils libraries?
Package: nitpic
Version: 0.1-12
The nitpic package seems to depend on a very particular version of
binutils,
# info: nitpic depends on binutils << 2.21.90.20111005 (ok, testing has
version 2.21.90.20111004-2)
# info: nitpic depends on binutils >= 2.21.90.20111004 (ok, testing
has version 2.21.90.20111004-2)
hence blocking migration of newer binutils to testing ("Updating
binutils makes 2 non-depending packages uninstallable on i386: lush,
nitpic", see
http://release.debian.org/migration/testing.pl?package=binutils), and
also blocking anything which depends on newer binutils, e.g., version
3.0.0-6 of the linux-2.6 package.
I suspect the dependencies are put in automagically because of
dynamically (rather than statically) linking to one or both of libbfd
and libopcodes. Which is a bad thing to do, as explained in the thread
http://lists.debian.org/debian-devel/2005/05/msg01085.html.
I have already filed a similar bug report on the other package, lush,
which blocks binutils in a similar way, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648014.
Regards,
/Niels Möller
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648014: Too strict dependencies on binutils, maybe due to inappropriate dynamic linking with binutils libraries?
Yaroslav Halchenko writes:
> if you are a DD -- just proceed with NMU fixing this issue... I have no
> time atm for lush
I'm not a DD. But I checked out your git tree, installed the build
dependencies, and had a look.
I'm not at all familiar with building debian packages, but I tried
running dpkg-buildpackage -b -uc -us, and it seemd to work. I'm having a
debian stable x86_64 machine.
It seems configure already tries to setup static linking with bfd,
but fails, because bfd also depends on zlib.
The below patch to configure.ac seems to solve the problem (ldd src/lush
shows no dependence on libbfd, and binutils is no longer mentioned in
debian/lush.substvars). Maybe it would be better to test if -lz is
needed or not, similarly to -lintl.
I haven't tested the resulting executable; I have never used lush, and
there seemed to be no make check target.
Regards,
/Niels
diff --git a/configure.ac b/configure.ac
index 35ef84b..bfb2611 100644
--- a/configure.ac
+++ b/configure.ac
@@ -151,7 +151,7 @@ if test x$has_bfd = xyes ; then
has_intl=
AC_CHECK_LIB(intl, dcgettext, [has_intl=yes],[has_intl=no])
i_LIBS=`echo $n_LIBS | sed -e 's/-liberty/& -lintl/'`
-sn_LIBS=`echo $n_LIBS | sed -e 's/-lbfd\( -liberty\)*/-Wl,-Bstatic &
-Wl,-Bdynamic/'`
+sn_LIBS=`echo $n_LIBS | sed -e 's/-lbfd\( -liberty\)*/-Wl,-Bstatic &
-Wl,-Bdynamic -lz/'`
si_LIBS=`echo $i_LIBS | sed -e 's/-lbfd\( -liberty\)*/-Wl,-Bstatic &
-Wl,-Bdynamic/'`
LIBS=$sn_LIBS
AC_MSG_CHECKING([whether bfd works with -Bstatic])
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648014: Too strict dependencies on binutils, maybe due to inappropriate dynamic linking with binutils libraries?
Package: lush
Version: 1.2.1-9+cvs20110227
The lush package seems to depend on a very particular version of
binutils,
# info: lush depends on binutils << 2.21.90.20111005 (ok, testing has
version 2.21.90.20111004-2)
# info: lush depends on binutils >= 2.21.90.20111004 (ok, testing has
version 2.21.90.20111004-2)
hence blocking migration of newer binutils to testing ("Updating
binutils makes 2 non-depending packages uninstallable on i386: lush,
nitpic", see
http://release.debian.org/migration/testing.pl?package=binutils), and
also blocking anything which depends on newer binutils, e.g., version
3.0.0-6 of the linux-2.6 package.
I had a look at lush's debian/control file, and I suspect the
dependencies are put in automagically because lush links dynamically
(rather than statically) to one or both of libbfd and libopcodes. Which
is a bad thing to do, as explained in the thread
http://lists.debian.org/debian-devel/2005/05/msg01085.html.
There's one other package which appears to have a similar problem:
nitpic. If you think this bug report makes sense, I can file an identical
one on that package.
Regards,
/Niels Möller
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600286: linux-image-2.6.32-5-amd64: atl1c driver hangs after "NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out"
Moritz Mühlenhoff writes: > Niels, did you try the patch or has this been resolved in more recent kernels? I built and installed a custom kernel with this patch. I think I've seen the same (or very similar) problem a few times with the patched kernel, but I haven't really tried to provoke it. Since I built this custom kernel, I have not tried any newer debian packaged kernels. I'm sorry I haven't had much time to look further into this. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600286: linux-image-2.6.32-5-amd64: atl1c driver hangs after "NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out"
Package: linux-2.6 Version: 2.6.32-23 Severity: important *** Please type your report below this line *** My wired network interface stops working (not able to transmit any packets, I think, but it might be reception which is broken. Anyway, ping to hosts on the local network results in a No route to host error, which means that sending or receiving arp packets fail). I see the following traceback in dmesg: [73228.976129] device eth0 entered promiscuous mode [73247.596111] device eth0 left promiscuous mode [74027.804522] [ cut here ] [74027.804536] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261 dev_watchdog+0xe2/0x194() [74027.804541] Hardware name: Aspire 1810TZ [74027.804544] NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out [74027.804547] Modules linked in: acpi_cpufreq cpufreq_stats cpufreq_powersave cpufreq_userspace cpufreq_conservative sco bridge stp bnep rfcomm l2cap crc16 binfmt_misc uinput fuse coretemp loop snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss arc4 ecb snd_pcm snd_seq_midi snd_rawmidi iwlagn snd_seq_midi_event joydev iwlcore snd_seq snd_timer uvcvideo snd_seq_device i915 drm_kms_helper drm btusb snd videodev acer_wmi mac80211 v4l1_compat i2c_i801 i2c_algo_bit psmouse v4l2_compat_ioctl32 led_class bluetooth soundcore video cfg80211 rfkill snd_page_alloc output wmi i2c_core pcspkr evdev serio_raw processor battery ac button ext3 jbd mbcache sd_mod crc_t10dif uhci_hcd ahci libata thermal thermal_sys ehci_hcd atl1c scsi_mod usbcore nls_base [last unloaded: scsi_wait_scan] [74027.804649] Pid: 0, comm: swapper Tainted: GW 2.6.32-5-amd64 #1 [74027.804652] Call Trace: [74027.804655][] ? dev_watchdog+0xe2/0x194 [74027.804666] [] ? dev_watchdog+0xe2/0x194 [74027.804672] [] ? warn_slowpath_common+0x77/0xa3 [74027.804678] [] ? dev_watchdog+0x0/0x194 [74027.804683] [] ? warn_slowpath_fmt+0x51/0x59 [74027.804689] [] ? enqueue_task_fair+0x24/0x68 [74027.804696] [] ? activate_task+0x20/0x26 [74027.804701] [] ? try_to_wake_up+0x249/0x259 [74027.804707] [] ? netif_tx_lock+0x3d/0x69 [74027.804713] [] ? netdev_drivername+0x3b/0x40 [74027.804718] [] ? dev_watchdog+0xe2/0x194 [74027.804724] [] ? __wake_up+0x30/0x44 [74027.804731] [] ? run_timer_softirq+0x1c9/0x268 [74027.804738] [] ? __do_softirq+0xdd/0x1a2 [74027.804744] [] ? lapic_next_event+0x18/0x1d [74027.804750] [] ? call_softirq+0x1c/0x30 [74027.804756] [] ? do_softirq+0x3f/0x7c [74027.804761] [] ? irq_exit+0x36/0x76 [74027.804766] [] ? smp_apic_timer_interrupt+0x87/0x95 [74027.804772] [] ? apic_timer_interrupt+0x13/0x20 [74027.804775][] ? acpi_idle_enter_c1+0x9d/0xb8 [processor] [74027.804794] [] ? acpi_idle_enter_c1+0x78/0xb8 [processor] [74027.804801] [] ? cpuidle_idle_call+0x94/0xee [74027.804808] [] ? cpu_idle+0xa2/0xda [74027.804812] ---[ end trace a7919e7f17c0a727 ]--- It has hanged in this way twice today, each time after I did two things which might be related: 1. I sent some large packets (tcp over ipv4 over ethernet) of size up to roughly 2 bytes and at a rate close to the links capacity of 100Mbit/s. One such packet, displayed by tcpdump: 13:58:15.872214 00:26:9e:b3:2f:3b (oui Unknown) > 00:11:25:85:b0:1a (oui Unknown), ethertype IPv4 (0x0800), length 22790: 192.168.1.135.47058 > 192.168.1.108.4711: Flags [.], seq 1079380:1102104, ack 1, win 32, options [nop,nop,TS val 19304579 ecr 1030215], length 22724 I have no idea why the kernel sent such large packets. According to ifconfig eth0, the MTU is 1500 bytes. Is it supposed to work like that, or is this another bug? 2. I used tcpdump, switching the interface to promiscuous mode and back (default behaviour, tcpdump -p would have worked just as fine for me). Taking the interface down and up (ifdown eth0 ; ifup eth0) didn't help. After hibernating the computer and wakening it up, the network interface started working again. The version of the atl1c network driver is "1.0.0.1-NAPI". There seems to be a newer one in Linus' kernel tree, "1.0.1-0-NAPI", but I haven't been able to figure out if there are any changes which might fix this problem, and I haven't tried booting any other kernel. Regards, /Niels Möller -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-23) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-3) ) #1 SMP Fri Sep 17 21:50:19 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=a46a5dc6-1945-4448-ba25-7cf440d80b30 ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [77367.451298] Initializing CPU#1 [77367.451298] CPU: L1 I cache: 32K, L1 D cache: 32K [77367.451298] CPU: L2 cache: 2048K [77367.451298] CPU 1/0x1 -> Node 0 [77367.451298] CPU: Physi
Bug#301968: lsh-server fails to create the hostkey
Stefan Pfetzing <[EMAIL PROTECTED]> writes: > lsh-server fails to create the hostkey, possibly because the lsh-keygen > options are changed. --nist-level now is the length in bit of the rsa > key. I think it's because lsh-keygen defaults to RSA keys now; in earlier versions DSA keys were the default (and before that, DSA was the only supported type). The DSA specific long option --nist-level seemed like a good idea at the time, but I'm sorry it's poor user interface now. Anyway, if you don't want to use the default key size, I think it's best to use *both* type and length options, e.g. lsh-keygen --server -a rsa -l 2048 or lsh-keygen --server -a dsa --nist-level 8 Regards, /Niels
Bug#300874: lsh-utils_2.0.1-1_sparc: FTBFS: m4: command not found
Steve Langasek <[EMAIL PROTECTED]> writes: > The most recent attempt to build lsh-utils on sparc has failed with the > following error: > > m4 /build/buildd/lsh-utils-2.0.1/src/nettle/asm.m4 machine.m4 config.m4 \ > aes.asm >aes.s > /bin/sh: m4: command not found > make[6]: *** [aes.o] Error 127 [...] > Other architectures seem to build the > package just fine, because this m4 command is not executed there -- it seems > to be some sparc-specific assembly? Nettle contains assembler for sparc and for x86 (or really ia32, there's no assembler for any of the 64-bit variants of x86). So m4 ought to be executed also on the common x86 architecture. Regards, /Niels
Bug#293020: lsh-utils: FTBFS (amd64/gcc-4.0): static declaration of 'des_keymap' follows non-static declaration
Andreas Jochens <[EMAIL PROTECTED]> writes: > Package: lsh-utils > Severity: normal > Tags: patch > > When building 'lsh-utils' on amd64 with gcc-4.0, > I get the following error: If you have the time, it would be nice if you could try to build the latest version of nettle or lsh, i.e. http://www.lysator.liu.se/~nisse/archive/lsh-2.0.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-1.12.tar.gz I think this bug was fixed in August 2003, and that the correct solution was to delete the non-static declaration. See patches below. Regards, /Niels $ cvs diff -u -r1.2 -r1.3 desCode.h Index: desCode.h === RCS file: /cvsroot/lsh/lsh/src/nettle/desCode.h,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- desCode.h 14 Jan 2002 16:03:04 - 1.2 +++ desCode.h 17 Aug 2003 15:31:51 - 1.3 @@ -1,6 +1,6 @@ /* desCode.h * - * $Id: desCode.h,v 1.2 2002/01/14 16:03:04 nisse Exp $ */ + * $Id: desCode.h,v 1.3 2003/08/17 15:31:51 nisse Exp $ */ /* des - fast & portable DES encryption & decryption. * Copyright (C) 1992 Dana L. How @@ -9,9 +9,6 @@ #include "des.h" -extern const uint32_t des_keymap[]; -extern const uint32_t des_bigmap[]; - /* optional customization: * the idea here is to alter the code so it will still run correctly * on any machine, but the quickest on the specific machine in mind. $ cvs diff -u -r1.7 -r1.8 des.c Index: des.c === RCS file: /cvsroot/lsh/lsh/src/nettle/des.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- des.c 12 May 2003 19:39:50 - 1.7 +++ des.c 17 Aug 2003 15:31:51 - 1.8 @@ -2,7 +2,7 @@ * * The des block cipher. * - * $Id: des.c,v 1.7 2003/05/12 19:39:50 nisse Exp $ + * $Id: des.c,v 1.8 2003/08/17 15:31:51 nisse Exp $ */ /* nettle, low-level cryptographics library @@ -40,9 +40,6 @@ #include "desCode.h" -static ENCRYPT(DesSmallFipsEncrypt,TEMPSMALL, LOADFIPS,KEYMAPSMALL,SAVEFIPS) -static DECRYPT(DesSmallFipsDecrypt,TEMPSMALL, LOADFIPS,KEYMAPSMALL,SAVEFIPS) - /* various tables */ static const uint32_t @@ -60,6 +57,9 @@ #include "parity.h" }; +static ENCRYPT(DesSmallFipsEncrypt,TEMPSMALL, LOADFIPS,KEYMAPSMALL,SAVEFIPS) +static DECRYPT(DesSmallFipsDecrypt,TEMPSMALL, LOADFIPS,KEYMAPSMALL,SAVEFIPS) + void des_fix_parity(unsigned length, uint8_t *dst, const uint8_t *src) Regards, /Niels
Bug#291010: lsh-utils: Remaining symlink prevents rebuilding the package when it has already been built once
Christian Perrier <[EMAIL PROTECTED]> writes: > Asyou quickly answered this bug report, I'm wondering whether I should > stop this process or not. If I stop, are the l10n bugs likely to be fixed? Maybe there's some confusion here. I'm the lsh "upstream author". I subscribe to lsh-related in the debian package tracking system to see what's going on with the debian package, and I try to help when there are questions I feel I can answer. In this case, why the assembler symlinks aren't deleted by make clean. I don't know much about the debian processes, and I also don't know anything about the l10n bugs you are working on (there's no localization at all in the upstream source package). Sorry for any confusion. Best regards, /Niels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291010: lsh-utils: Remaining symlink prevents rebuilding the package when it has already been built once
Christian Perrier <[EMAIL PROTECTED]> writes: > Package: lsh-utils > Severity: minor I'm afraid I need some more context to really understand what the problem is. But anyway, I have one comment: > dpkg-source: cannot represent change to src/nettle/aes.asm: > dpkg-source: new version is symlink > dpkg-source: old version is nonexistent > dpkg-source: warning: ignoring deletion of file contrib/lsh.spec > dpkg-source: building lsh-utils in lsh-utils_1.4.2-8.1.dsc > dpkg-source: unrepresentable changes to source > > Removing the culprit symlink allows the build process to go on but this > should probably be done in the clean target The symlinks to assembler files are created by configure (or more precisely, by config.status). Hence they should *not* be deleted by make clean; "make clean" should only delete files were created by running make. Regards, /Niels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
