Bug#1063890: libzydiscore-dev: Static library is missing

[Tim Rühsen]

Package: libzydiscore-dev
Severity: normal
X-Debbugs-Cc: tim.rueh...@gmx.de

Dear Maintainer,

for software development, I need to build static binaries.
Currently, I have to build my own static library.
But it would be way easier to communicate the build steps in Zydis didn't need
an extra recipe on how to build and install the static library.

Please add the static library to the package (libzydis-dev is also affected).

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_AUX
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1033398: linux-image-amd64: reproducible kernel freeze on 5.19+

[Tim Rühsen]

Package: linux-image-amd64
Version: 6.1.20-1
Severity: important
X-Debbugs-Cc: tim.rueh...@gmx.de

Dear Maintainer,

   * What led up to the situation?

We run a priviledged eBPF based tool with a communication between kernel and 
user space.
It runs without issues on kernels 4.15 to 5.18.
On kernels 5.19+, the whole system freezes after a few minutes.
It seems that with more system activities (load, forks) the freeze happens 
earlier.
The underlying hardware seems to play no role, we could reproduce this on 
different
bare metal systems as well as within a qemu based VM.

Since the running program is rather complex, it is not easily possible to carve 
out a small reproducer.
We can provide gdb backtraces from freezes inside qemu.


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
ii  linux-image-6.1.0-7-amd64  6.1.20-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LC_MONETARY = "en_DE.UTF-8",
LC_COLLATE = "en_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
(gdb) thread apply all bt full

Thread 8 (Thread 1.8 (CPU#7 [running])):
#0  arch_atomic_read (v=0x837c2b4c ) at 
arch/x86/include/asm/atomic.h:29
No locals.
#1  atomic_read (v=0x837c2b4c ) at 
include/linux/atomic/atomic-instrumented.h:28
No locals.
#2  pv_hybrid_queued_unfair_trylock (lock=0x837c2b4c ) 
at kernel/locking/qspinlock_paravirt.h:88
val = 
#3  __pv_queued_spin_lock_slowpath (lock=0x837c2b4c , 
val=) at kernel/locking/qspinlock.c:446
prev = 
next = 
node = 0x88813bdf1b40
old = 
tail = 2097152
idx = 0
queue = 
cnt = 
__PTR = 
VAL = 
_val = 
__PTR = 
VAL = 
__vpp_verify = 
_val = 
__PTR = 
VAL = 
__vpp_verify = 
pao_ID__ = 
pao_tmp__ = 
pto_val__ = 
pto_tmp__ = 
pao_ID__ = 
pao_tmp__ = 
pto_val__ = 
pto_tmp__ = 
pao_ID__ = 
pao_tmp__ = 
pto_val__ = 
pto_tmp__ = 
#4  0x81a2b6f0 in pv_queued_spin_lock_slowpath (val=7, 
lock=0x837c2b4c ) at arch/x86/include/asm/paravirt.h:591
__esi = 
__edx = 
__edi = 
__ecx = 
__eax = 
#5  queued_spin_lock_slowpath (val=7, lock=0x837c2b4c ) 
at arch/x86/include/asm/qspinlock.h:51
No locals.
#6  queued_spin_lock (lock=0x837c2b4c ) at 
include/asm-generic/qspinlock.h:114
val = 7
val = 
#7  do_raw_spin_lock (lock=0x837c2b4c ) at 
include/linux/spinlock.h:186
No locals.
#8  __raw_spin_lock (lock=0x837c2b4c ) at 
include/linux/spinlock_api_smp.h:134
No locals.
#9  _raw_spin_lock (lock=lock@entry=0x837c2b4c ) at 
kernel/locking/spinlock.c:154
No locals.
#10 0x812e1ba7 in spin_lock (lock=0x837c2b4c ) 
at include/linux/spinlock.h:350
No locals.
#11 alloc_vmap_area (size=size@entry=20480, align=align@entry=16384, 
vstart=vstart@entry=18446683600570023936, vend=vend@entry=18446718784942112767, 
node=node@entry=-1, gfp_mask=3264, gfp_mask@entry=3520) at mm/vmalloc.c:1634
va = 0x88802dbb05c0
freed = 0
addr = 
purged = 0
ret = 
retry = 
__func__ = "alloc_vmap_area"
#12 0x812e2111 in __get_vm_area_node (size=20480, size@entry=16384, 
align=align@entry=16384, shift=shift@entry=12, flags=flags@entry=34, 
start=start@entry=18446683600570023936, end=end@entry=18446718784942112767, 
node=-1, gfp_mask=3520, caller=0x8109ad0f ) at 
mm/vmalloc.c:2501
va = 
area = 0x888113d8dfc0
requested_size = 16384
#13 0x812e52c4 in __vmalloc_node_range (size=, 
size@entry=16384, align=align@entry=16384, start=, 
end=, gfp_mask=gfp_mask@entry=3520, prot=..., 
vm_flags=, node=, caller=) at 
mm/vmalloc.c:3173
area = 
ret = 
kasan_flags = 
real_size = 16384
real_align = 16384
shift = 12
again = 
#14 

Bug#1028857: libpsl: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Tim Rühsen]

On Sat, 11 Feb 2023 18:47:04 +0100 Florian Ernst  
wrote:

Of course, updating to 0.21.2 with its "273 changed files with 70,410
additions and 1,392 deletions"[0] feels rather invasive this late in the
Debian release cycle, so maybe a more targeted fix could be extracted.
These files are mostly test corpora from OSS-Fuzz. So I wouldn't be too 
bothered, as those are only used with `make check`.


Some other changes are updates of the copyright year and meson and msvc 
build files, both have no influence on the Debian build (autotools/make).


I leave it to you to decide about the few remaining changed files.

Regards, Tim


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028857: libpsl: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Tim Rühsen]

Hi Lucas,

maybe @dkg has time to update the packaging ?

Regards, Tim

On 14.01.23 23:51, Lucas Nussbaum wrote:

Hi Tim,

I can't find that new version (0.21.2) in Debian?

Lucas

On 14/01/23 at 20:19 +0100, Tim Rühsen wrote:

Hey Lucas,

could you try with the latest release v0.21.2 ?

I am working on Debian sid, and can't reproduce the issue.

But I will examine the logs and/or try to build from the debian sources (in
the next days).

Regards, Tim

On 14.01.23 13:59, Lucas Nussbaum wrote:

Source: libpsl
Version: 0.21.0-1.2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230113 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[5]: Entering directory '/<>/tests'
PASS: test-is-public-builtin
PASS: test-registrable-domain
PASS: test-is-public
PASS: test-is-cookie-domain-acceptable
FAIL: test-is-public-all
=
 libpsl 0.21.0: tests/test-suite.log
=

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-is-public-all


loaded 9458 suffixes and 8 exceptions
builtin PSL has 9458 suffixes and 8 exceptions
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
Summary: 28 out of 290640 tests failed
FAIL test-is-public-all (exit status: 1)


Testsuite summary for libpsl 0.21.0

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ER

Bug#1028857: libpsl: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Tim Rühsen]

Hey Lucas,

could you try with the latest release v0.21.2 ?

I am working on Debian sid, and can't reproduce the issue.

But I will examine the logs and/or try to build from the debian sources 
(in the next days).


Regards, Tim

On 14.01.23 13:59, Lucas Nussbaum wrote:

Source: libpsl
Version: 0.21.0-1.2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230113 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[5]: Entering directory '/<>/tests'
PASS: test-is-public-builtin
PASS: test-registrable-domain
PASS: test-is-public
PASS: test-is-cookie-domain-acceptable
FAIL: test-is-public-all
=
libpsl 0.21.0: tests/test-suite.log
=

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-is-public-all


loaded 9458 suffixes and 8 exceptions
builtin PSL has 9458 suffixes and 8 exceptions
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-2.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-northeast-3.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ap-southeast-2.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.ca-central-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_PRIVATE|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_ANY)=0 (expected 1)
psl_is_public_suffix2(webview-assets.cloud9.eu-central-1.amazonaws.com, 
PSL_TYPE_ANY|PSL_TYPE_NO_STAR_RULE)=0 (expected 1)
Summary: 28 out of 290640 tests failed
FAIL test-is-public-all (exit status: 1)


Testsuite summary for libpsl 0.21.0

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to tim.rueh...@gmx.de

make[5]: *** [Makefile:802: test-suite.log] Error 1
make[5]: Leaving 

Bug#1005865: Fixed upstream

[Tim Rühsen]

This issue has been fixed upstream (wget2 v2.0.1)

$ wget2 --content-disposition -P maps https://addons.wz2100.net/download/1
[0] Downloading 'https://addons.wz2100.net/download/1' ...
Saving 'maps/2c-Battle_hills_v2.wz'
HTTP response 200 OK [https://addons.wz2100.net/download/1]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#991540: Fixed upstream

[Tim Rühsen]

This issue has been fixed upstream (wget2 2.0.1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#974708: Fixed upstream

[Tim Rühsen]

Fixed upstream in commit c355efb7c86b4dfc9ac8d9f441101aa97aeef918 (on 
top of wget2 v2.0.1).


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990109: Fixed upstream

[Tim Rühsen]

This issue has been fixed upstream (wget2 2.0.1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows

[Tim Rühsen]

Hi Felix,

On 03.01.22 21:28, Felix Lechner wrote:

The good folks at wolfSSL cannot reproduce the error. Do you '#include
' before the others?


Thanks for the hint. Including the wolfssl/options.h solved the issue 
for me (in project GNU Wget2).


Regards, Tim


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows

[Tim Rühsen]

Hi Felix,

Thanks for taking care and sorry for my delayed answer - your reply went 
into the Spam folder and I just saw it there by "accident" :(


On 03.01.22 21:28, Felix Lechner wrote:

On Mon, Jan 3, 2022 at 9:09 AM Tim Rühsen  wrote:


Valgrind reports a buffer overflow.


The good folks at wolfSSL cannot reproduce the error. Do you '#include
' before the others?


In my bug report there is a (standalone) reproducer C code, which 
doesn't include  at all. So I am not sure why/what 
they are asking for.



Either way, will you please also attach your configuration to this
report? Thanks!


I don't understand - what configuration ? I use the Debian packages on 
Debian bookworm/sid - architecture, package version etc is all included 
in the bug report.


Could you point me to the upstream bug report ?

Regards, Tim


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows

[Tim Rühsen]

Package: libwolfssl30
Version: 5.0.0-1+b1
Severity: important

Dear Maintainer,

the unit test for WolfSSL hashing in GNU Wget2 crashes.
Valgrind reports a buffer overflow.

This can be reproduced with this little C code:
#include 
#define WOLFSSL_SHA512
#define WC_NO_HARDEN
#include 
int main(void)
{
wc_HashAlg *h = malloc(sizeof(wc_HashAlg));
wc_HashInit(h, WC_HASH_TYPE_SHA512);
return 0;
}

Compile it with 'gcc -g -O0 sha512_overflow.c -o sha512_overflow -lwolfssl'
and run it with 'valgrind ./sha512_overflow'.

Valgrind output:
==1781168== Invalid write of size 4
==1781168==at 0x48DCEB1: wc_InitSha512_ex (in 
/usr/lib/x86_64-linux-gnu/libwolfssl.so.30.0.0)
==1781168==by 0x10916F: main (sha512_overflow.c:11)
==1781168==  Address 0x4e27120 is 0 bytes after a block of size 224 alloc'd
==1781168==at 0x483F7B5: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1781168==by 0x10915A: main (sha512_overflow.c:9)
==1781168== 
==1781168== Invalid write of size 8
==1781168==at 0x48DCEB7: wc_InitSha512_ex (in 
/usr/lib/x86_64-linux-gnu/libwolfssl.so.30.0.0)
==1781168==by 0x10916F: main (sha512_overflow.c:11)
==1781168==  Address 0x4e27128 is 8 bytes after a block of size 224 alloc'd
==1781168==at 0x483F7B5: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1781168==by 0x10915A: main (sha512_overflow.c:9)
==1781168== 
==1781168== Invalid write of size 4
==1781168==at 0x48DCEE2: wc_InitSha512_ex (in 
/usr/lib/x86_64-linux-gnu/libwolfssl.so.30.0.0)
==1781168==by 0x10916F: main (sha512_overflow.c:11)
==1781168==  Address 0x4e27130 is 16 bytes after a block of size 224 alloc'd
==1781168==at 0x483F7B5: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1781168==by 0x10915A: main (sha512_overflow.c:9)

The code so far worked with WolfSSL versions < 5.0.0 (e.g. libwolfssl24).

Regards, Tim

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libwolfssl30 depends on:
ii  libc6  2.33-1

libwolfssl30 recommends no packages.

libwolfssl30 suggests no packages.

-- no debconf information

Bug#950168: pstack always fails with "crawl: Input/output error"

[Tim Rühsen]

On 01.02.20 13:44, Andreas Beckmann wrote:
> On Wed, 29 Jan 2020 19:51:22 +0100 =?utf-8?q?Tim_R=C3=BChsen?=
> The manpage (dated Feb 25 2002) says:
> 
> RESTRICTIONS
>pstack currently works only on Linux, only on an x86  machine
>running  32  bit  ELF binaries (64 bit not supported).  Also,
>for symbolic information, you need to use a GNU  compiler  to
>generate  your  program, and you can't strip symbols from the
>binaries.  For thread information to be dumped, you  have  to
>use the debug-aware version of the LinuxThreads libpthread.so
>library.  (To check, run nm(1) on your pthreads library,  and
>make   sure  that  the  symbol  "__pthread_threads_debug"  is
>defined.)  Threads are not  supported  with  the  newer  NPTL
>libpthread.so library.
> 
> So the pstack tool is probably useless on modern systems.

I believe the man page and the top comment within pstack.c are is wrong.
The source code explicitly supports 64bit ELF, you can build it for
amd64, it does some work, but fails on 'crawl...'.

The man page of ptrace() gives no obvious hint why it may fail on amd64
and not on x86 here.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#950168: pstack always fails with "crawl: Input/output error"

[Tim Rühsen]

Package: pstack
Version: 1.3.1-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I can't get pstack working as expected. Even not as root.

Example:
# pstack 2280

2280: /usr/lib/upower/upowerd
(No symbols found)
0x7fbfe723dd0f:  (55babe9e5900, 51, 0, 0, 0, 7fbfe7593f30) + 
aa46415ffdb3
crawl: Input/output error
Error tracing through process 2280
0x10008: 


I assume there something going on with ptrace(), as I see the same issue
with a ptrace example code that uses PTRACE_PEEKDATA.
PTRACE_ATTACH seems to work, but PTRACE_PEEKDATA returns error (errno is 5).

strace and gdb work well.

Web searches so far didn't help.

Any ideas / hints ?

Regards, Tim

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pstack depends on:
ii  libc6  2.29-9

pstack recommends no packages.

pstack suggests no packages.

-- no debconf information

Bug#942879: libbrotli-dev: Please add static version of libraries (.a)

[Tim Rühsen]

Package: libbrotli-dev
Version: 1.0.7-3
Severity: normal

Dear Maintainer,

I tried to build a static version of a binary (wget2).

There is no static version of the brotli libraries.

Regards, Tim


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbrotli-dev depends on:
ii  libbrotli1  1.0.7-3

libbrotli-dev recommends no packages.

libbrotli-dev suggests no packages.

-- no debconf information

Bug#924573: lcov: Update to latest version 1.14

[Tim Rühsen]

On Thu, 14 Mar 2019 13:45:50 + Marco F  wrote:
> Package: lcov
> Version: 1.13-4
> Severity: normal
> 
> Dear Maintainer,
> 
> could you please update the package to the latest version?
> It includes some bug fixes and other improvements.

Please also include support for gcc 9:
https://github.com/linux-test-project/lcov/commit/75fbae1cfc5027f818a0bb865bf6f96fab3202da

The upstream issue is at
https://github.com/linux-test-project/lcov/issues/58

Thank you !

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Tim Rühsen]

On 3/17/19 11:11 PM, Daniel Kahn Gillmor wrote:
> On Sun 2019-03-17 13:14:54 +0100, Tim Rühsen wrote:
>> Fixed it by building my own libiconv on MinGW systems. It really is
>> straight forward and possibly no extra Debian package is needed.
> 
> Thanks for the feedback, Tim.  For your fix, are you building libiconv
> itself, or win-iconv for MinGW systems?

Libiconv 1.15 itself from tarball.

If you are interested in the details, have a look at our CI Dockerfile
where we build/install the dependencies needed for testing:

https://gitlab.com/gnuwget/build-images/blob/master/docker-debian-mingw/Dockerfile

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Tim Rühsen]

Fixed it by building my own libiconv on MinGW systems. It really is
straight forward and possibly no extra Debian package is needed.

Regards, Tim

On Sat, 16 Mar 2019 21:02:26 +0100 =?UTF-8?Q?Tim_R=c3=bchsen?=
 wrote:
> Please do not remove this package, the first CI builds (MinGW cross
> builds) already break (GNU Wget / Wget2).
> 
> Well, it's already gone from buster... please add it back or provide a
> another way to convert charsets within cross-compiled Windows executables.
> 
> Regards, Tim
> 



signature.asc
Description: OpenPGP digital signature

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Tim Rühsen]

Please do not remove this package, the first CI builds (MinGW cross
builds) already break (GNU Wget / Wget2).

Well, it's already gone from buster... please add it back or provide a
another way to convert charsets within cross-compiled Windows executables.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#908478: wget -r doesn't recurse if index.html hasn't been updated

[Tim Rühsen]

On Mon, 10 Sep 2018 11:24:05 +0200 Tor Arntsen  wrote:
> Package: wget
> Version: 1.19.5-1
> Severity: important
> 
> Dear Maintainer,
> 
> wget used for maintaining a local mirror of a web site
> 
> Did: wget -r -N -np --no-host-directories $url/
> Outcome: Got 'index.html not mofified on server. Omitting dowload', followed 
> by exit
> Expected: Recursive check of $url/, download of 'modified on server' pages

Clearly a bug. Try with --no-if-modified-since. If that works for you,
put it into the .wgetrc file to make it permanent.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#875370: dependency on PSL pulls in ICU, which dwarfs wget in size

[Tim Rühsen]

On Sun, 10 Sep 2017 23:51:12 +0200 Josip Rodin
 wrote:
> Package: wget
> Severity: minor
> 
> Hi,
> 
> Resolving #766780 seems to have pulled in a pair of disproportionally large
> libraries:
> 
>   [...]
>   The following NEW packages will be installed:
> libicu52 libpsl0
>   The following packages will be upgraded:
> wget
>   [...]
>   After this operation, 28,4 MB of additional disk space will be used.

libpsl5 doesn't depend on libicu since a long time. It depends on
libidn2 which is needed by wget anyways (and which is even pulled in by
libc6).

Is there any reason why this report is still open ?

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#917279: Fixed now

[Tim Rühsen]

After the latest apt-get update (incl. systemd upgrade), Netbeans works
as expected again.

IMO, this bug can be closed.



signature.asc
Description: OpenPGP digital signature

Bug#917279: openjdk-8-jre: Netbeans 8.2 crashes at startup with 'library initialization failed...'

[Tim Rühsen]

Package: openjdk-8-jre
Version: 8u191-b12-2
Severity: important

Dear Maintainer,

since yesterday I experience a crash when starting upstream Netbeans 8.2.

$ netbeans-8.2/bin/netbeans 

library initialization failed - unable to allocate file descriptor table - out 
of memory/home/tim/netbeans-8.2/platform/lib/nbexec: Zeile 470: 11277 
Abgebrochen "/usr/lib/jvm/java-8-openjdk-amd64/bin/java" 
-Djdk.home="/usr/lib/jvm/java-8-openjdk-amd64" -classpath 
"/home/tim/netbeans-8.2/platform/lib/boot.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-modules.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-util.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-util-lookup.jar:/home/tim/netbeans-8.2/platform/lib/org-openide-util-ui.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/boot_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-modules_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-lookup_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_ja.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_pt_BR.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_ru.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util-ui_zh_CN.jar:/home/tim/netbeans-8.2/platform/lib/locale/org-openide-util_zh_CN.jar:/usr/lib/jvm/java-8-openjdk-amd64/lib/dt.jar:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar"
 -Dnetbeans.default_userdir_root="/home/tim/.netbeans" 
-Dnetbeans.running.environment=kde 
-Dnetbeans.dirs="/home/tim/netbeans-8.2/nb:/home/tim/netbeans-8.2/ergonomics:/home/tim/netbeans-8.2/ide:/home/tim/netbeans-8.2/extide:/home/tim/netbeans-8.2/java:/home/tim/netbeans-8.2/apisupport:/home/tim/netbeans-8.2/webcommon:/home/tim/netbeans-8.2/websvccommon:/home/tim/netbeans-8.2/enterprise:/home/tim/netbeans-8.2/mobility:/home/tim/netbeans-8.2/profiler:/home/tim/netbeans-8.2/python:/home/tim/netbeans-8.2/php:/home/tim/netbeans-8.2/identity:/home/tim/netbeans-8.2/harness:/home/tim/netbeans-8.2/cnd:/home/tim/netbeans-8.2/cndext:/home/tim/netbeans-8.2/dlight:/home/tim/netbeans-8.2/groovy:/home/tim/netbeans-8.2/extra:/home/tim/netbeans-8.2/javacard:/home/tim/netbeans-8.2/javafx:"
 -Dnetbeans.home="/home/tim/netbeans-8.2/platform" 
'-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade' 
'-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense' '-client' 
'-Xmx4096m' '-Xss2m' '-Xms32m' '-Dapple.laf.useScreenMenuBar=true' 
'-Dapple.awt.graphics.UseQuartz=true' '-Dsun.java2d.noddraw=true' 
'-Dsun.java2d.dpiaware=true' '-Dsun.zip.disableMemoryMapping=true' 
'-Dswing.aatext=true' '-Dawt.useSystemAAFontSettings=lcd' 
-DaddExports:java.desktop/sun.awt=ALL-UNNAMED 
-DaddExports:java.base/jdk.internal.jrtfs=ALL-UNNAMED 
-DaddExports:java.desktop/java.awt.peer=ALL-UNNAMED 
-DaddExports:java.desktop/com.sun.beans.editors=ALL-UNNAMED 
-DaddExports:java.desktop/sun.awt.im=ALL-UNNAMED 
-DaddExports:java.desktop/com.sun.java.swing.plaf.gtk=ALL-UNNAMED 
-DaddExports:java.management/sun.management=ALL-UNNAMED 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath="/home/tim/.netbeans/8.2/var/log/heapdump.hprof" 
org.netbeans.Main --cachedir "/home/tim/.cache/netbeans/8.2" --userdir 
"/home/tim/.netbeans/8.2" "--branding" "nb" "--laf" "Nimbus" 0<&0

I tried removing cache and userdir with no difference. Didn't find a 
work-around so far.

Netbeans definitely worked correctly a few days ago (I regularly upgrade my 
system).

$ dpkg -l '*openjdk*'

un  openjdk-11-demo   (keine Beschreibung 
vorhanden)
ii  openjdk-11-jdk:amd64  11.0.1+13-3  amd64OpenJDK Development 
Kit (JDK)
ii  openjdk-11-jdk-headless:amd64 11.0.1+13-3  amd64OpenJDK Development 
Kit (JDK) (headless)
ii  openjdk-11-jre:amd64  11.0.1+13-3  amd64OpenJDK Java 
runtime, using Hotspot JIT
ii  openjdk-11-jre-headless:amd64 11.0.1+13-3  amd64OpenJDK Java 
runtime, using Hotspot JIT (headless)
un  openjdk-11-source (keine Beschreibung 
vorhanden)
un  openjdk-6-jre (keine Beschreibung 
vorhanden)
un  openjdk-6-jre-headless(keine Beschreibung 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Tim Rühsen]

On 22.12.18 16:56, Aurelien Jarno wrote:
> On 2018-12-22 16:24, Tim Rühsen wrote:
>> On 22.12.18 13:37, Aurelien Jarno wrote:
>>> On 2018-12-21 12:58, Tim Rühsen wrote:
>>>> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
>>>>> On 2018-12-21 11:51, Tim Rühsen wrote:
>>>>>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>>>>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
>>>>>>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
>>>>>>>>>> Package: libc6-armhf-cross
>>>>>>>>>> Version: 2.28-2cross2
>>>>>>>>>> Severity: normal
>>>>>>>>>>
>>>>>>>>>> Dear Maintainer,
>>>>>>>>>>
>>>>>>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>>>>>>>>>
>>>>>>>>>> The expected errno value would be either EINVAL or not touching errno
>>>>>>>>>> at all.
>>>>>>>>>>
>>>>>>>>>> This behavior is relatively new and causes some CI cross builds to 
>>>>>>>>>> fail.
>>>>>>>>>> The failing test is a gnulib test (test-strerror.c).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>>>>>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>>>>>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>>>>>>>> think it's a qemu bug.
>>>>>>>>
>>>>>>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>>>>>>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>>>>>
>>>>>>> It seems to have been caused by this upstream patch:
>>>>>>>
>>>>>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>>>>>> | Author: Wilco Dijkstra 
>>>>>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>>>>>> | 
>>>>>>> | Add support for sqrt asm redirects
>>>>>>> | 
>>>>>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
>>>>>>> in GLIBC.
>>>>>>> | The goal is to enable GCC to do the inlining, and if this fails 
>>>>>>> call the
>>>>>>> | __ieee754_sqrt function.  This is done by internally declaring 
>>>>>>> sqrt with asm
>>>>>>> | redirects.  The compat symbols and sqrt wrappers need to disable 
>>>>>>> the redirect.
>>>>>>> | The redirect is also disabled if there are already redirects 
>>>>>>> defined when
>>>>>>> | using -ffinite-math-only.
>>>>>>> | 
>>>>>>> | All math functions (but not math tests, non-library code and 
>>>>>>> libnldbl) are
>>>>>>> | built with -fno-math-errno which means GCC will typically inline 
>>>>>>> sqrt as a
>>>>>>> | single instruction.  This means targets are no longer forced to 
>>>>>>> add a special
>>>>>>> | inline for sqrt.
>>>>>>> | 
>>>>>>> | * include/math.h (sqrt): Declare with asm redirect.
>>>>>>> | (sqrtf): Likewise.
>>>>>>> | (sqrtl): Likewise.
>>>>>>> | (sqrtf128): Likewise.
>>>>>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but 
>>>>>>> build testsuite,
>>>>>>> | nonlib and libnldbl with -fmath-errno.
>>>>>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>>>>>> | * math/w_sqrt_template.c: Likewise.
>>>>>>> | * math/w_sqrtf_compat.c: Likewise.
>>>>>>> | * math/w_sqrtl_compat.c: Likewise.
>>>>>>> | * sysdeps/i386/fpu/w_sqrt.c: Likew

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Tim Rühsen]

On 22.12.18 13:37, Aurelien Jarno wrote:
> On 2018-12-21 12:58, Tim Rühsen wrote:
>> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
>>> On 2018-12-21 11:51, Tim Rühsen wrote:
>>>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
>>>>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
>>>>>>>> Package: libc6-armhf-cross
>>>>>>>> Version: 2.28-2cross2
>>>>>>>> Severity: normal
>>>>>>>>
>>>>>>>> Dear Maintainer,
>>>>>>>>
>>>>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>>>>>>>
>>>>>>>> The expected errno value would be either EINVAL or not touching errno
>>>>>>>> at all.
>>>>>>>>
>>>>>>>> This behavior is relatively new and causes some CI cross builds to 
>>>>>>>> fail.
>>>>>>>> The failing test is a gnulib test (test-strerror.c).
>>>>>>>>
>>>>>>>
>>>>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>>>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>>>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>>>>>> think it's a qemu bug.
>>>>>>
>>>>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>>>>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>>>
>>>>> It seems to have been caused by this upstream patch:
>>>>>
>>>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>>>> | Author: Wilco Dijkstra 
>>>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>>>> | 
>>>>> | Add support for sqrt asm redirects
>>>>> | 
>>>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
>>>>> in GLIBC.
>>>>> | The goal is to enable GCC to do the inlining, and if this fails 
>>>>> call the
>>>>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
>>>>> with asm
>>>>> | redirects.  The compat symbols and sqrt wrappers need to disable 
>>>>> the redirect.
>>>>> | The redirect is also disabled if there are already redirects 
>>>>> defined when
>>>>> | using -ffinite-math-only.
>>>>> | 
>>>>> | All math functions (but not math tests, non-library code and 
>>>>> libnldbl) are
>>>>> | built with -fno-math-errno which means GCC will typically inline 
>>>>> sqrt as a
>>>>> | single instruction.  This means targets are no longer forced to add 
>>>>> a special
>>>>> | inline for sqrt.
>>>>> | 
>>>>> | * include/math.h (sqrt): Declare with asm redirect.
>>>>> | (sqrtf): Likewise.
>>>>> | (sqrtl): Likewise.
>>>>> | (sqrtf128): Likewise.
>>>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
>>>>> testsuite,
>>>>> | nonlib and libnldbl with -fmath-errno.
>>>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>>>> | * math/w_sqrt_template.c: Likewise.
>>>>> | * math/w_sqrtf_compat.c: Likewise.
>>>>> | * math/w_sqrtl_compat.c: Likewise.
>>>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
>>>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
>>>>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
>>>>> math.h and
>>>>> | complex.h.
>>>>>
>>>>> And more precisely by building libc with -fno-math-errno.
>>>>
>>>> Thanks for looking into it.
>>>>
>>>> How is the proceeding ? Is there enough info to fix (or report upstream)
>>>> ? If not, what has to be done ?
>>>
>>> No it's not enough to fix it or report it upstream. We still have to
>>&g

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Tim Rühsen]

On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> On 2018-12-21 11:51, Tim Rühsen wrote:
>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
>>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>>>> Hi,
>>>>>
>>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
>>>>>> Package: libc6-armhf-cross
>>>>>> Version: 2.28-2cross2
>>>>>> Severity: normal
>>>>>>
>>>>>> Dear Maintainer,
>>>>>>
>>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>>>>>
>>>>>> The expected errno value would be either EINVAL or not touching errno
>>>>>> at all.
>>>>>>
>>>>>> This behavior is relatively new and causes some CI cross builds to fail.
>>>>>> The failing test is a gnulib test (test-strerror.c).
>>>>>>
>>>>>
>>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>>>> think it's a qemu bug.
>>>>
>>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>
>>> It seems to have been caused by this upstream patch:
>>>
>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>> | Author: Wilco Dijkstra 
>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>> | 
>>> | Add support for sqrt asm redirects
>>> | 
>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
>>> GLIBC.
>>> | The goal is to enable GCC to do the inlining, and if this fails call 
>>> the
>>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
>>> with asm
>>> | redirects.  The compat symbols and sqrt wrappers need to disable the 
>>> redirect.
>>> | The redirect is also disabled if there are already redirects defined 
>>> when
>>> | using -ffinite-math-only.
>>> | 
>>> | All math functions (but not math tests, non-library code and 
>>> libnldbl) are
>>> | built with -fno-math-errno which means GCC will typically inline sqrt 
>>> as a
>>> | single instruction.  This means targets are no longer forced to add a 
>>> special
>>> | inline for sqrt.
>>> | 
>>> | * include/math.h (sqrt): Declare with asm redirect.
>>> | (sqrtf): Likewise.
>>> | (sqrtl): Likewise.
>>> | (sqrtf128): Likewise.
>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
>>> testsuite,
>>> | nonlib and libnldbl with -fmath-errno.
>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>> | * math/w_sqrt_template.c: Likewise.
>>> | * math/w_sqrtf_compat.c: Likewise.
>>> | * math/w_sqrtl_compat.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
>>> | * sysdeps/generic/math-type-macros-float128.h: Remove math.h 
>>> and
>>> | complex.h.
>>>
>>> And more precisely by building libc with -fno-math-errno.
>>
>> Thanks for looking into it.
>>
>> How is the proceeding ? Is there enough info to fix (or report upstream)
>> ? If not, what has to be done ?
> 
> No it's not enough to fix it or report it upstream. We still have to
> understand the exact issue. For me it's not yet clear if the bug is in
> QEMU or in glibc. The fact that it works fine on real hardware would
> go towards a QEMU bug, but there is no proof yet.

Looking at glibc's string/strerror.c, it calls __strerror_r() before
saving errno.

In __strerror_r(), gettext() is being called via a the #define _().

gettext() saves/restores errno only if successful, else it doesn't.
__strerror_r() doesn't check or save errno at all.

So whenever gettext() sets errno, this value stays when strerror()
returns. The gettext() code path is only travelled when errnum is < 0.

You can of course argue, if gettext() or strerror() must be fixed. But
that is clearly an upstream issue.

And if there is an underlying issue with memory allocation is a
different issue. But is doesn't affect the strerror() function in the
gnulib test as it seems.

It's out of scope for me to cross-build the glibc. But if that is
possible for you, I'd suggest a fix (Debian patch ?) in strerror() until
it is fixed upstream.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Tim Rühsen]

On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> On 2018-12-21 11:51, Tim Rühsen wrote:
>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
>>>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>>>> Hi,
>>>>>
>>>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
>>>>>> Package: libc6-armhf-cross
>>>>>> Version: 2.28-2cross2
>>>>>> Severity: normal
>>>>>>
>>>>>> Dear Maintainer,
>>>>>>
>>>>>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>>>>>
>>>>>> The expected errno value would be either EINVAL or not touching errno
>>>>>> at all.
>>>>>>
>>>>>> This behavior is relatively new and causes some CI cross builds to fail.
>>>>>> The failing test is a gnulib test (test-strerror.c).
>>>>>>
>>>>>
>>>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>>>> think it's a qemu bug.
>>>>
>>>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>>>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>
>>> It seems to have been caused by this upstream patch:
>>>
>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>> | Author: Wilco Dijkstra 
>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>> | 
>>> | Add support for sqrt asm redirects
>>> | 
>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
>>> GLIBC.
>>> | The goal is to enable GCC to do the inlining, and if this fails call 
>>> the
>>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
>>> with asm
>>> | redirects.  The compat symbols and sqrt wrappers need to disable the 
>>> redirect.
>>> | The redirect is also disabled if there are already redirects defined 
>>> when
>>> | using -ffinite-math-only.
>>> | 
>>> | All math functions (but not math tests, non-library code and 
>>> libnldbl) are
>>> | built with -fno-math-errno which means GCC will typically inline sqrt 
>>> as a
>>> | single instruction.  This means targets are no longer forced to add a 
>>> special
>>> | inline for sqrt.
>>> | 
>>> | * include/math.h (sqrt): Declare with asm redirect.
>>> | (sqrtf): Likewise.
>>> | (sqrtl): Likewise.
>>> | (sqrtf128): Likewise.
>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
>>> testsuite,
>>> | nonlib and libnldbl with -fmath-errno.
>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>> | * math/w_sqrt_template.c: Likewise.
>>> | * math/w_sqrtf_compat.c: Likewise.
>>> | * math/w_sqrtl_compat.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
>>> | * sysdeps/generic/math-type-macros-float128.h: Remove math.h 
>>> and
>>> | complex.h.
>>>
>>> And more precisely by building libc with -fno-math-errno.
>>
>> Thanks for looking into it.
>>
>> How is the proceeding ? Is there enough info to fix (or report upstream)
>> ? If not, what has to be done ?
> 
> No it's not enough to fix it or report it upstream. We still have to
> understand the exact issue. For me it's not yet clear if the bug is in
> QEMU or in glibc. The fact that it works fine on real hardware would
> go towards a QEMU bug, but there is no proof yet.

I think it's pretty clear: Under no circumstances must strerror() set
errno to ENOMEM because this is against the specs [1].

That makes it pretty likely an upstream issue. Not sure about any Debian
patches playing a role.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Tim Rühsen]

On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> On 2018-12-18 22:11, Aurelien Jarno wrote:
>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>> Hi,
>>>
>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
 Package: libc6-armhf-cross
 Version: 2.28-2cross2
 Severity: normal

 Dear Maintainer,

 currently strerror(-3) sets errno unexpectedly to ENOMEM (12).

 The expected errno value would be either EINVAL or not touching errno
 at all.

 This behavior is relatively new and causes some CI cross builds to fail.
 The failing test is a gnulib test (test-strerror.c).

>>>
>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>> think it's a qemu bug.
>>
>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> 
> It seems to have been caused by this upstream patch:
> 
> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> | Author: Wilco Dijkstra 
> | Date:   Thu Mar 15 17:57:03 2018 +
> | 
> | Add support for sqrt asm redirects
> | 
> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
> GLIBC.
> | The goal is to enable GCC to do the inlining, and if this fails call the
> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> with asm
> | redirects.  The compat symbols and sqrt wrappers need to disable the 
> redirect.
> | The redirect is also disabled if there are already redirects defined 
> when
> | using -ffinite-math-only.
> | 
> | All math functions (but not math tests, non-library code and libnldbl) 
> are
> | built with -fno-math-errno which means GCC will typically inline sqrt 
> as a
> | single instruction.  This means targets are no longer forced to add a 
> special
> | inline for sqrt.
> | 
> | * include/math.h (sqrt): Declare with asm redirect.
> | (sqrtf): Likewise.
> | (sqrtl): Likewise.
> | (sqrtf128): Likewise.
> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> testsuite,
> | nonlib and libnldbl with -fmath-errno.
> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> | * math/w_sqrt_template.c: Likewise.
> | * math/w_sqrtf_compat.c: Likewise.
> | * math/w_sqrtl_compat.c: Likewise.
> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> | * sysdeps/generic/math-type-macros-float128.h: Remove math.h and
> | complex.h.
> 
> And more precisely by building libc with -fno-math-errno.

Thanks for looking into it.

How is the proceeding ? Is there enough info to fix (or report upstream)
? If not, what has to be done ?

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#842242: Missing $LINENO support is intentional

[Tim Rühsen]

> So, keeping $LINENO support disable is *intentional* so as configure
> *does not* catch dash as the default shell, because it breaks a lot of
> packages with bashisms. The bug highlights the reason of this
> deactivation, even if “long term” solution is to fix all the bashisms.
> So, as long as we have bashisms, we must have slow configure for
> everyone…

Yeah, sounds like that.

For the interested, I wrote some hints on how to dramatically speed up
configure scripts:
https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain

A list of broken packages due to bashisms would also be very helpful to
create patches for upstream (count me in).

Another long-term solution would be a 'bash mode' for autoconf, to create a
bash-only configure script with all the possible speedups that bash offers.

(Just an idea.)

> So maybe this bug could be merged/closed?

For me it's currently a WONTFIX, so not against closing it.

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#893280: linux-image-4.15.0-1-amd64: Crash in nouveau kernel code

[Tim Rühsen]

Package: src:linux
Version: 4.15.4-1
Severity: normal

Dear Maintainer,

sometimes I see kernel crashes when alt-tab'ing between windows in KDE.

The, the either the Window renders unusable or everything is stuck (except 
mouse pointer
movement). Everything means the keyboard is also dead, no chance to ctrl-alt-fx.
The 'solution' is to switch the machine off.

Regards, Tim

-- Package-specific info:
** Version:
Linux version 4.15.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-amd64 
root=UUID=0d5e982a-cd3b-4e72-88c6-3c8b89a353c2 ro elevator=noop quiet splash

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[ 6213.855158] microcode: CPU6: patch_level=0x08001129
[ 6213.855304] CPU6 is up
[ 6213.855314] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 6213.857544] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.857580]  cache: parent cpu7 should not be sleeping
[ 6213.857661] microcode: CPU7: patch_level=0x08001129
[ 6213.857846] CPU7 is up
[ 6213.857855] smpboot: Booting Node 0 Processor 8 APIC 0x8
[ 6213.860183] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.860217]  cache: parent cpu8 should not be sleeping
[ 6213.860299] microcode: CPU8: patch_level=0x08001129
[ 6213.860529] CPU8 is up
[ 6213.860539] smpboot: Booting Node 0 Processor 9 APIC 0x9
[ 6213.862829] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.862867]  cache: parent cpu9 should not be sleeping
[ 6213.862951] microcode: CPU9: patch_level=0x08001129
[ 6213.863190] CPU9 is up
[ 6213.863202] smpboot: Booting Node 0 Processor 10 APIC 0xa
[ 6213.865514] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.865549]  cache: parent cpu10 should not be sleeping
[ 6213.865624] microcode: CPU10: patch_level=0x08001129
[ 6213.865875] CPU10 is up
[ 6213.865886] smpboot: Booting Node 0 Processor 11 APIC 0xb
[ 6213.868176] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.868210]  cache: parent cpu11 should not be sleeping
[ 6213.868291] microcode: CPU11: patch_level=0x08001129
[ 6213.868562] CPU11 is up
[ 6213.868572] smpboot: Booting Node 0 Processor 12 APIC 0xc
[ 6213.870904] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.870943]  cache: parent cpu12 should not be sleeping
[ 6213.871028] microcode: CPU12: patch_level=0x08001129
[ 6213.871305] CPU12 is up
[ 6213.871316] smpboot: Booting Node 0 Processor 13 APIC 0xd
[ 6213.873618] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.873654]  cache: parent cpu13 should not be sleeping
[ 6213.873743] microcode: CPU13: patch_level=0x08001129
[ 6213.874052] CPU13 is up
[ 6213.874064] smpboot: Booting Node 0 Processor 14 APIC 0xe
[ 6213.876386] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.876426]  cache: parent cpu14 should not be sleeping
[ 6213.876511] microcode: CPU14: patch_level=0x08001129
[ 6213.876815] CPU14 is up
[ 6213.876826] smpboot: Booting Node 0 Processor 15 APIC 0xf
[ 6213.879148] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
[ 6213.879189]  cache: parent cpu15 should not be sleeping
[ 6213.879284] microcode: CPU15: patch_level=0x08001129
[ 6213.879632] CPU15 is up
[ 6213.881088] ACPI: Waking up from system sleep state S3
[ 6213.959655] usb usb1: root hub lost power or was reset
[ 6213.959657] usb usb2: root hub lost power or was reset
[ 6213.959661] usb usb5: root hub lost power or was reset
[ 6213.959663] usb usb6: root hub lost power or was reset
[ 6213.960504] serial 00:04: activated
[ 6214.144673] r8169 :07:00.0 enp7s0: link down
[ 6214.272657] ata6: SATA link down (SStatus 0 SControl 300)
[ 6214.273002] ata2: SATA link down (SStatus 0 SControl 300)
[ 6214.273143] ata9: SATA link down (SStatus 0 SControl 300)
[ 6214.276352] ata5: SATA link down (SStatus 0 SControl 300)
[ 6214.285880] usb 3-2: reset low-speed USB device number 3 using xhci_hcd
[ 6214.313876] usb 5-1: reset high-speed USB device number 2 using xhci_hcd
[ 6214.434153] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 6214.451765] ata1.00: configured for UDMA/133
[ 6214.735878] usb 2-4: reset SuperSpeed USB device number 2 using xhci_hcd
[ 6214.762807] OOM killer enabled.
[ 6214.762808] Restarting tasks ... done.
[ 6214.764066] PM: suspend exit
[ 6214.773933] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready
[ 6214.906153] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready
[ 6214.928518] r8169 :07:00.0 enp7s0: link down
[ 6214.928621] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready
[ 6217.946688] r8169 :07:00.0 enp7s0: link up
[ 6217.946702] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
[ 9601.969200] WARNING: CPU: 9 PID: 8595 at 
/build/linux-PFKtCE/linux-4.15.4/drivers/gpu/drm/nouveau/nvif/vmm.c:71 
nvif_vmm_put+0x6a/0x80 [nouveau]
[ 9601.969202] Modules linked 

Bug#855346: been hit with same

[Tim Rühsen]

On Fri, 8 Dec 2017 14:08:13 +0100 Paolo Inaudi  wrote:
> Profile from #126 still doesn't allow to open links in Firefox:
> 
> dic 08 14:06:43 paolo-desktop audit[19990]: AVC apparmor="DENIED" 
> operation="exec" profile="thunderbird" name="/usr/lib/firefox/firefox" 
> pid=19990 comm="thunderbird" requested_mask="x" denied_mask="x" 
> fsuid=1000 ouid=0

Same problem here on latest Debian unstable.

Fix / Work-around:

Add
  /usr/lib/firefox/firefox ixr,
to
  /etc/apparmor.d/usr.bin.thunderbird
and execute
  service apparmor reload

Not sure why /usr/bin/firefox is a symlink to /usr/lib/firefox/firefox
and if it has something to do with our problem.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#882689: libidn2: [INTL:de] Initial German translation

[Tim Rühsen]

Hello Chris,

sorry for the delay.

I sent your work to coordina...@translationproject.org also with the
request to take libidn2 onto their todo list. We seem to have missed
that before.


If interested, you can contact the translation team at
https://translationproject.org/html/welcome.html.

Anyways, thanks for your initial work !

With Best Regards, Tim



On 11/25/2017 07:09 PM, Chris Leick wrote:
> Package: libidn2
> Version: 2.0.2
> Severity: wishlist
> Tags: l10n patch
> 
> 
> 
> Hi,
> 
> please find attached the German translation.
> 
> Kind regards,
> Chris
> 
> 
> 
> ___
> Help-libidn mailing list
> help-lib...@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-libidn
> 



signature.asc
Description: OpenPGP digital signature

Bug#883407: libc6: getpwnam_r() leaks memory

[Tim Rühsen]

On Tue, 5 Dec 2017 19:17:42 +0100 Aurelien Jarno 
wrote:
> It's not something I can reproduce here, but getpwnam_r can behave very
> differently depending on the nss configuration your system. A small
> reproducer and the content of /etc/nsswitch.conf would definitely help.
> 
> That said libc6 version 2.25-3 included security fixes and memory leak
> fixes for the glob function. Can you confirm the version you used, and
> if it's really 2.25-3 try with version 2.25-2 which is still in testing.
Here we have a reproducer (assuming the there is no user 'O' on system).

#include 
#include 
int main(void)
{
struct passwd *p;
char tmp[1024];
struct passwd pw;

getpwnam_r("O", , tmp, sizeof(tmp), );
return 0;
}

Build/compile/reproduce:
gcc -g x.c -o x
valgrind --leak-check=full ./x


Here is a reproducer using glob():

#include 
#include 
int main(void)
{
glob_t pglob;
if (glob("~O", GLOB_TILDE, NULL, ) == 0) {
globfree();
}
return 0;
}

Build/compile/reproduce:
gcc -g x.c -o x
valgrind --leak-check=full ./x


Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#883407: libc6: getpwnam_r() leaks memory

[Tim Rühsen]

Package: libc6
Version: 2.25-3
Severity: normal

Dear Maintainer,

valgrinding a C code shows the following:

==27943== 4,096 bytes in 1 blocks are definitely lost in loss record 3 of 3
==27943==by 0x6C27715: getpwnam_r@@GLIBC_2.2.5 (getXXbyYY_r.c:314)
==27943==by 0x4E8569F: rpl_glob (glob.c:781)

That rpl_glob() is gnulib's glob replacement. The code there looks good.
And valgrind doesn't/didn't show this leak with previous (2.24 and lower)
versions of glibc.

I can't currently provide you with a short reproducer (out of time here).

Regards, Tim

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/16 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#882581: libidn2: debian/upstream/signing-key.asc is 15M and contains unrelated public keys

[Tim Rühsen]

On 11/24/2017 09:40 AM, Simon McVittie wrote:
> Source: libidn2
> Version: 2.0.4-1.1
> Severity: normal
> 
> libidn2 contains both debian/upstream-signing-key.pgp and
> debian/upstream/signing-key.asc, which appears to have been a mistake.
> debian/upstream/signing-key.asc also appears to have unintended content.
> 
> debian/upstream-signing-key.pgp is 72K, which seems plausible for a public
> key (although the filename debian/upstream/signing-key.asc is preferred,
> and uscan(1) recommends using gpg --export --export-options export-minimal
> --armor to include only the public key, user IDs and self-signatures, and
> not signatures by other people, to reduce the size further). It has two user
> IDs:
> 
> % gpg --list-packets libidn2_2.0.4-1.1.debian/upstream-signing-key.pgp | grep 
> ':user ID packet:'
> :user ID packet: "Simon Josefsson <si...@yubico.com>"
> :user ID packet: "Simon Josefsson <si...@josefsson.org>"
> 
> and it seems entirely plausible that Simon Josefsson is the only valid
> upstream release manager for libidn2.

Simon and me (Tim Rühsen <tim.rueh...@gmx.de>) - I signed the last few
upstream releases with key 0x08302DB6A2670428.


Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#881915: libidn FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

[Tim Rühsen]

On 11/23/2017 03:37 PM, Helmut Grohne wrote:
> On Thu, Nov 23, 2017 at 11:32:06AM +, Simon McVittie wrote:
>> It looks as though plain gtkdocize replaces gtk-doc.make with a symbolic
>> link, which dh-autoreconf won't delete (bug filed), breaking the ability
>> to build twice in a row; so gtkdocize --copy (which works like I expected)
>> is probably better, at least until/unless dh-autoreconf can be taught
>> to remove files that were replaced with a symlink. I've changed flatpak
>> in git to use gtkdocize --copy.
> 
> Thank you for your attention to detail.
> 
>> Helmut: similarly, is there a reason that I'm not seeing why explicitly
>> removing gtk-doc.make before gtkdocize was necessary, or were you only
>> doing that as a way to be completely sure that the old one wasn't used, or
>> was it a workaround for gtkdocize turning the plain file into a symlink?
> 
> I was under the impression that my first attempt was just running
> gtkdocize without removing gtk-doc.make and that didn't work. I might be
> wrong here.
> 
> Call me careless, but I am a bit annoyed by libidn2 now, as it keeps
> breaking in new ways. I was in need of a patch to make bootstrap builds
> proceed, so I only looked as far as making it barely build. The bug is
> supposedly fixed upstream, so I expected it to be fixed with a new
> upstream release rather than applying my patch.


If it helps, I can make up a new upstream release.
Let me know if there is something that should be applied before.


With Best Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#870669: libidn: Make source package bootstrappable

[Tim Rühsen]

On 09/13/2017 02:19 PM, Helmut Grohne wrote:
> retitle 870669 move gcj-jdk from Build-Depends to Build-Depends-Indep
> tags 870669 + patch
> severity 870669 normal
> user helm...@debian.org
> usertags 870669 + rebootstrap
> thanks
> 
> On Thu, Aug 03, 2017 at 03:14:48PM -0700, Daniel Schepler wrote:
>> It would be nice if the Build-Depends on gcj-jdk could be moved to
>> Build-Depends-Indep.  (I did recently see notifications that gcj will
>> be going away in Debian soon.  But even if you switch over to using
>> default-jdk, that would still create a build dependency cycle since
>> openjdk-8 Build-Depends on libcups2-dev also.)
> 
> I second that. The gcj-jdk dependency also breaks cross compilation and
> moving it to Build-Depends-Indep significantly simplifies debian/rules
> as the attached patch demonstrates. In particular, it removes all those
> different(!) architecture lists.
> 
> Though I'd much rather see libidn go. Most rdeps but hesiod have moved
> on to libidn2-0.

Just FYI.

There are some packages using the stringprep functionality of libidn.
This has no replacement in libidn2. We (libidn2 upstream maintainers)
have a libprecis (for PRECIS[1] implementation) in mind. PRECIS replaces
the IDNA 2003 stringprep functionality.

[1] https://tools.ietf.org/html/rfc7564

With Best Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#873903: Wheezy update of libidn?

[Tim Rühsen]

On Freitag, 1. September 2017 16:51:18 CEST Raphael Hertzog wrote:
> Dear maintainer(s),
> 
> The Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of libidn:
> https://security-tracker.debian.org/tracker/source-package/libidn
> 
> Would you like to take care of this yourself?

Hi Raphaël,

I asked Ondřej Surý (ond...@debian.org, now in CC) yesterday to do the 
packaging for libidn and libidn2, especially with those CVEs in mind.
And he seems willing, so just coordinate to not do the work twice.

Background: the current maintainers are either hindered by private issues 
(Simon, si...@josefsson.org) or not enough into packaging any more to stem it 
(me).

Personally, I can only offer any help from upstream (things can be fastly done 
if you contact me or better if you open an issue on either libidn or libidn2).

> 
> If yes, please follow the workflow we have defined here:
> https://wiki.debian.org/LTS/Development
> 
> If that workflow is a burden to you, feel free to just prepare an
> updated source package and send it to debian-...@lists.debian.org
> (via a debdiff, or with an URL pointing to the source package,
> or even with a pointer to your packaging repository), and the members
> of the LTS team will take care of the rest. Indicate clearly whether you
> have tested the updated package or not.
> 
> If you don't want to take care of this update, it's not a problem, we
> will do our best with your package. Just let us know whether you would
> like to review and/or test the updated package before it gets released.

I appreciate any work that you do on packaging libidn/libidn2 and if it's ok 
for you, take me out of the review process (I just know too little about 
Debian packaging to review/judge anything from you experts).

Just coordinate with Ondřej.

With Best Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Bug#873903: libidn2-0: CVE-2017-14062: integer overflow in decode_digit

[Tim Rühsen]

On Fri, 01 Sep 2017 06:52:53 +0200 Salvatore Bonaccorso
 wrote:
> Source: libidn2-0
> Version: 0.10-2
> Severity: important
> Tags: upstream security patch
> 
> Hi,
> 
> the following vulnerability was published for libidn2-0.
> 
> CVE-2017-14062[0]:
> | Integer overflow in the decode_digit function in puny_decode.c in
> | Libidn2 before 2.0.4 allows remote attackers to cause a denial of
> | service or possibly have unspecified other impact.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2017-14062
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14062
> [1] 
> https://gitlab.com/libidn/libidn2/commit/3284eb342cd0ed1a18786e3fcdf0cdd7e76676bd

Just backported the fix from libidn2 into libidn upstream (commit
e9e81b8063b095b02cf104bb992fa9bf9515b9d8).

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#873715: includes -R (-rpath) in libidn2.pc file

[Tim Rühsen]

On 08/30/2017 01:55 PM, Dmitry Eremin-Solenikov wrote:
> Package: libidn2-dev
> Version: 2.0.2-3
> Severity: normal
> 
> Hi,
> 
> libidn2.pc includes -R option in Libs.private section of the file. It
> does not make sense, especially because this option points to the
> standard libaries dir (/usr/lib/x86_64-linux-gnu/ in my case). Could you
> please strip that option?
> 

I can't remember that we recently changed libidn2.pc.in.

The current libidn2.pc.in looks like:

prefix=@prefix@
exec_prefix=@exec_prefix@
includedir=@includedir@
libdir=@libdir@

Name: libidn2
Description: Library implementing IDNA2008 and TR46
Version: @PACKAGE_VERSION@
Cflags: -I${includedir}
Libs: -L${libdir} -lidn2
Libs.private: @LTLIBICONV@ @LTLIBUNISTRING@


How does the -R come into your .pc file ?

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#869561: underscores get stripped

[Tim Rühsen]

On 08/30/2017 12:00 PM, Marco d'Itri wrote:
> On Jul 24, Laurent Bigonville  wrote:
> 
>> I'm not sure when is the next planned release for libidn, but could you
>> considere fixing that in debian?
> 2.0.3 was released some weeks ago, can you package it?
> I need this fix to switch whois from 1.x as well.

In preparation for this I just made a libidn2 2.0.4 release (adding a
few bug fixes).

Simon has upload rights, so trying him to get in here...

With Best Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#870813: [bug #51666] Please hash the hostname in ~/.wget-hsts files

[Tim Rühsen]

On Freitag, 18. August 2017 14:51:12 CEST Ander Juaristi wrote:
> Follow-up Comment #2, bug #51666 (project wget):
> 
> I'm not generally against these kind of small tweaks that don't harm and
> slightly improve user's privacy.
> 
> If Firefox doesn't do it, we don't care: it's their business and they will
> end up doing it if users request that feature (maybe because they saw it in
> wget).
> 
> Private SSH keys can be protected with a password if you want to.

As long as it is optional...

It would be nice being file compatible with Firefox (at least reading Firefox 
HSTS db).
Maybe the sqlite backend that has been mentioned earlier should then work with 
the same settings (hashed/not hashed).

> We can do both, hash and still keep the readable to the user only. If the
> overhead is not much I would go for it. That is the basis of every security
> framework out there: if the benefits of having 2 security mechanisms instead
> of only 1 outweigh the drawbacks, then implement 2 instead of 1.

Absolutely, but in this special case you open up a can of worms. From a 
security standpoint, the average home directory is a nightmare. Once someone 
gets access to it (read or write)...

Regards, Tim

signature.asc
Description: This is a digitally signed message part.

Bug#866406: Fixed upstream - please update package

[Tim Rühsen]

It looks like this bug has been fixed upstream in

commit 09b6e78d1592ce10fdc975025d699ee41444aa3f
Author: Paul Eggert 
Date:   Fri Feb 5 21:06:20 2016 -0800

Fix memory leak in AC_FUNC_MMAP

* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Fix memory leak
in test case, found by configuring with gcc -fsanitize=address.

It's a trivial fix (just two calls to free()).

Please consider adding this fix to the Debian package.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves

[Tim Rühsen]

On 07/20/2017 05:09 PM, Matthias Klose wrote:
> On 20.07.2017 14:45, Tim Ruehsen wrote:
>> Package: gcc-6
>> Version: 6.4.0-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> building autotools packages with address sanitizer currently breaks with 
>> gcc-6 and gcc-7.
>> gcc-5 is not effected.
>>
>> This breaks quality checking and fuzzing with ASAN enabled.
>> Using LD_PRELOAD to load libasan first doesn't change anything.
>>
>> This doesn't help either (in case this is a ASLR problem with the kernel):
>> echo 0 >/proc/sys/kernel/randomize_va_space
>>
>>
>> $ CC=gcc-6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" 
>> ./configure   
>> checking for a BSD-compatible install... /usr/bin/install -c 
>>  
>>
>> checking whether build environment is sane... yes
>>  
>>
>> checking for a thread-safe mkdir -p... /bin/mkdir -p 
>>  
>>
>> checking for gawk... gawk
>>  
>>
>> checking whether make sets $(MAKE)... yes
>>  
>>
>> checking whether make supports nested variables... yes   
>>  
>>
>> checking for gcc... gcc-6
>>  
>>
>> checking whether the C compiler works... yes 
>>  
>>
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables... 
>> checking whether we are cross compiling... configure: error: in 
>> `/usr/oms/src/libpsl':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>>
>>
>> >From config.log:
>> configure:3459: gcc-6 -o conftest -g -fsanitize=address 
>> -fno-omit-frame-pointer   conftest.c  >&5
>> configure:3463: $? = 0
>> configure:3470: ./conftest
>> ==13782==Shadow memory range interleaves with an existing memory mapping. 
>> ASan cannot proceed correctly. ABORTING.
>> ==13782==ASan shadow was supposed to be located in the 
>> [0x7fff7000-0x10007fff7fff] range.
>> ==13782==Process memory map follows:
>> 0x005450338000-0x005450339000   /usr/oms/src/libpsl/conftest
>> 0x005450539000-0x00545053a000   /usr/oms/src/libpsl/conftest
>> ...
>> 0x7fff70943000-0x7fff70964000   [stack]
>> 0x7fff709a4000-0x7fff709a6000   [vvar]
>> 0x7fff709a6000-0x7fff709a8000   [vdso]
>> ==13782==End of process memory map.
>> configure:3474: $? = 1
>> configure:3481: error: in `/usr/oms/src/libpsl':
>> configure:3483: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
> 
> please could you attach the failing conftest?

config.log doesn't even say.
It continues with

==28018==End of process memory map.
configure:3474: $? = 1
configure:3481: error: in `/usr/oms/src/libpsl':
configure:3483: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

##  ##
## Cache variables. ##
##  ##

...

and exit.


Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves

[Tim Rühsen]

Any program:

#include 

int main(void)
{
printf("Hello\n");
}

$ gcc-6 -g -fsanitize=address -fno-omit-frame-pointer x.c -o x

$ ./x

==29033==Shadow memory range interleaves with an existing memory
mapping. ASan cannot proceed correctly. ABORTING.
==29033==ASan shadow was supposed to be located in the
[0x7fff7000-0x10007fff7fff] range.
==29033==Process memory map follows:
0x0001-0x00011000   /usr/oms/src/libpsl/x
0x00010020-0x000100201000   /usr/oms/src/libpsl/x
0x000100201000-0x000100202000   /usr/oms/src/libpsl/x
0x75889000-0x75bdb000
0x75bdb000-0x75bf1000   /lib/x86_64-linux-gnu/libgcc_s.so.1
0x75bf1000-0x75df   /lib/x86_64-linux-gnu/libgcc_s.so.1

...


With Best Regards, Tim



On 07/20/2017 05:09 PM, Matthias Klose wrote:
> On 20.07.2017 14:45, Tim Ruehsen wrote:
>> Package: gcc-6
>> Version: 6.4.0-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> building autotools packages with address sanitizer currently breaks with 
>> gcc-6 and gcc-7.
>> gcc-5 is not effected.
>>
>> This breaks quality checking and fuzzing with ASAN enabled.
>> Using LD_PRELOAD to load libasan first doesn't change anything.
>>
>> This doesn't help either (in case this is a ASLR problem with the kernel):
>> echo 0 >/proc/sys/kernel/randomize_va_space
>>
>>
>> $ CC=gcc-6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" 
>> ./configure   
>> checking for a BSD-compatible install... /usr/bin/install -c 
>>  
>>
>> checking whether build environment is sane... yes
>>  
>>
>> checking for a thread-safe mkdir -p... /bin/mkdir -p 
>>  
>>
>> checking for gawk... gawk
>>  
>>
>> checking whether make sets $(MAKE)... yes
>>  
>>
>> checking whether make supports nested variables... yes   
>>  
>>
>> checking for gcc... gcc-6
>>  
>>
>> checking whether the C compiler works... yes 
>>  
>>
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables... 
>> checking whether we are cross compiling... configure: error: in 
>> `/usr/oms/src/libpsl':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>>
>>
>> >From config.log:
>> configure:3459: gcc-6 -o conftest -g -fsanitize=address 
>> -fno-omit-frame-pointer   conftest.c  >&5
>> configure:3463: $? = 0
>> configure:3470: ./conftest
>> ==13782==Shadow memory range interleaves with an existing memory mapping. 
>> ASan cannot proceed correctly. ABORTING.
>> ==13782==ASan shadow was supposed to be located in the 
>> [0x7fff7000-0x10007fff7fff] range.
>> ==13782==Process memory map follows:
>> 0x005450338000-0x005450339000   /usr/oms/src/libpsl/conftest
>> 0x005450539000-0x00545053a000   /usr/oms/src/libpsl/conftest
>> ...
>> 0x7fff70943000-0x7fff70964000   [stack]
>> 0x7fff709a4000-0x7fff709a6000   [vvar]
>> 0x7fff709a6000-0x7fff709a8000   [vdso]
>> ==13782==End of process memory map.
>> configure:3474: $? = 1
>> configure:3481: error: in `/usr/oms/src/libpsl':
>> configure:3483: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
> 
> please could you attach the failing conftest?
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Tim Rühsen]

Here the work-around:

Use a different device driver, you likely use 'aufs'.

In /etc/default/docker change
DOCKER_OPTS="--storage-driver=aufs"
to
DOCKER_OPTS="--storage-driver=devicemapper"
(or whatever driver you like)

Then start apt-get upgrade again to configure docker.io:

apt-get --with-new-pkgs -f upgrade

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Tim Rühsen]

Just an idea... aufs too old (not matching the kernel version) ?

# uname -a
Linux blitz-lx 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64
GNU/Linux

# dpkg -l '*aufs*'
un  aufs-dev 
 (no description available)
ii  aufs-dkms   4.9+20161219-2 amd64
 DKMS files to build and install aufs
ii  aufs-tools  1:4.1+20161219-1   amd64
 Tools to manage aufs filesystems

# apt-cache policy aufs-dkms
aufs-dkms:
  Installed: 4.9+20161219-2
  Candidate: 4.9+20161219-2
  Version table:
 *** 4.9+20161219-2 500
500 https://ftp.de.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status




signature.asc
Description: OpenPGP digital signature

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Tim Rühsen]

On Mon, 26 Jun 2017 17:37:48 -0400 Antoine Beaupre
 wrote:
> Control: notfound -1 1.13.1~ds1-2
> Control: tags -1 unreproducible
> 
> Similarly: I installed 1.13.1~ds1-2 from sid on stretch and it installs
> fine.
> 
> Any more details on how to reproduce this? Which init system are you
> using? If you are using systemd, what does "systemctl status docker.io"
> say?

Have the same syptoms here (Debian SID amd64):

The fault seems to be "Error starting daemon: error initializing
graphdriver: driver not supported"

Any work-around is appreciated.

Here are the messages:


Setting up docker.io (1.13.1~ds1-2) ...
Job for docker.service failed because the control process exited with
error code.
See "systemctl  status docker.service" and "journalctl  -xe" for details.
invoke-rc.d: initscript docker, action "start" failed.
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; disabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2017-07-11 08:50:15
CEST; 9ms ago
 Docs: https://docs.docker.com
  Process: 7157 ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS
(code=exited, status=1/FAILURE)
 Main PID: 7157 (code=exited, status=1/FAILURE)
Tasks: 19
   Memory: 43.2M
  CPU: 98ms
   CGroup: /system.slice/docker.service

Jul 11 08:50:13 blitz-lx systemd[1]: Starting Docker Application
Container Engine...
Jul 11 08:50:14 blitz-lx dockerd[7157]:
time="2017-07-11T08:50:14.086356811+02:00" level=info
msg="libcontainerd: new containerd process, pid: 7165"
Jul 11 08:50:15 blitz-lx dockerd[7157]: Error starting daemon: error
initializing graphdriver: driver not supported
Jul 11 08:50:15 blitz-lx systemd[1]: docker.service: Main process
exited, code=exited, status=1/FAILURE
Jul 11 08:50:15 blitz-lx systemd[1]: Failed to start Docker Application
Container Engine.
Jul 11 08:50:15 blitz-lx systemd[1]: docker.service: Unit entered failed
state.
Jul 11 08:50:15 blitz-lx systemd[1]: docker.service: Failed with result
'exit-code'.
dpkg: error processing package docker.io (--configure):
 subprocess installed post-installation script returned error exit status 1




signature.asc
Description: OpenPGP digital signature

Bug#856951: Now hit by this issue on unstable as well

[Tim Rühsen]

Seems to hit me on unstable since today.

runc 1.0.0~rc2+git20170201.133.9df8b30-1
systemd 233-9

container_linux.go:247: starting container process caused
"process_linux.go:359: container init caused \"rootfs_linux.go:54:
mounting \\\"cgroup\\\" to rootfs
\\\"/var/lib/docker/aufs/mnt/e9be6e7ac3cda6eee560f94f99913f636081978eb4c8fccc9d53801657e77fdb\\\"
at \\\"/sys/fs/cgroup\\\" caused \\\"no subsystem for mount\\\"\""
oci runtime error: container_linux.go:247: starting container process
caused "process_linux.go:359: container init caused
\"rootfs_linux.go:54: mounting \\\"cgroup\\\" to rootfs
\\\"/var/lib/docker/aufs/mnt/e9be6e7ac3cda6eee560f94f99913f636081978eb4c8fccc9d53801657e77fdb\\\"
at \\\"/sys/fs/cgroup\\\" caused \\\"no subsystem for mount\\\"\""

This breaks software testing here and downgrading doesn't work either.

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#862335: openssl creates and accepts certificates with bad notAfter field

[Tim Rühsen]

On Thu, 11 May 2017 18:42:17 +0200 Kurt Roeckx  wrote:
> On Thu, May 11, 2017 at 02:59:20PM +0200, Harald Dunkel wrote:
>> 
>> Please note the "-enddate 20451231235959Z" and compare with RFC
>> 5280 section 4.1.2.5 (https://www.ietf.org/rfc/rfc5280.txt). The
>> GeneralizedTime format is not allowed for 2045, but apparently
>> openssl doesn't convert the string to UTCTime format.
> 
> Please note that the manual says the format is: YYMMDDHHMMSSZ
> 
> I guess it would be nice we converted it properly.

Just for the record, the latest openssl (1.1.1-dev from Github) accepts
this (seen from the code):

[SS] is optional, <+|-> = either + or - must be present

1.
YYMMDDHHMM[SS]Z YYMMDDHHMM[SS]<+|->hhmm
If valid, these date strings are written to ASN.1 into an UTCTime field.

2.
MMDDHHMM[SS]Z or MMDDHHMMSS<+|->hhmm
If valid, these date strings are written to ASN.1 into a GeneralizedTime
field.

Regarding RFC5280 in both cases (UTCTime and GeneralizedTime) the
seconds (SS) and Z (Zulu) timezone is a MUST.

See RFC5280 '4.1.2.5.1.  UTCTime' and '4.1.2.5.2.  GeneralizedTime'.

OpenSSL relies on their ASN.1 code to check for validity, which is
simply not strict enough. Other implementors do a strict check and thus
might reject certificates generated by openssl.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#857953: bash: debian/rules execute $(STRIP) even when empty

[Tim Rühsen]

On Donnerstag, 16. März 2017 17:26:23 CET Matthias Klose wrote:

> please read about bug severities.

This bugs renders the source package unusable for me.
That's what reportbug suggests 'important' for ("...major effect on the 
usability...")
And I need the source package to create a .deb with debugging symbols, for 
debugging #849517, to get gnulib's --enable-valgrind-tests working with 
several other packages.
So this bug is certainly a blocker...

> This works by default as seen by the latest binNMU.

???
This is not obvious for everybody. Just checked the bash package versions for 
unstable and experimental... no update yet.
So, what do you try to communicate here ? Is my Debian apt source  (http://
ftp.de.debian.org) somewhat behind ?

With Best Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Bug#808356: wget: bad syntax comment in .wget-hsts

[Tim Rühsen]

This is fixed in the current wget 1.18.

Tim


signature.asc
Description: This is a digitally signed message part.

Bug#849389: Remove patch 'wget-doc-CRLs.patch' from source package

[Tim Rühsen]

Package: wget
Version: 1.18-4

The patch states that wget does not suport CRLs.
Well, it does:

commit cf4991d6022d990604bb8175dc94b931e69617dc
Author: Tim Rühsen <tim.rueh...@gmx.de>
Date:   Tue Nov 11 17:56:09 2014 +0100

Added OpenSSL support for --crl-file

commit a0c30fc72b745a41836bc7aed63731e4ae32ea47
Author: Tim Rühsen <tim.rueh...@gmx.de>
Date:   Mon Nov 10 11:59:26 2014 +0100

Added new test Test--https-crl.py to check --crl-file

commit e4a8fe84e2b813b65d91aec29298eecabe4850a5
Author: Tim Rühsen <tim.rueh...@gmx.de>
Date:   Thu Nov 6 17:53:44 2014 +0100

Added --crl-file to load a Certificate Revocation List (CRL) file


Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Bug#813256: flex: C++ style comment in C output

[Tim Rühsen]

Package: flex
Version: 2.6.0-3
Severity: important

Dear Maintainer,

flex adds a C++ comment into C code which prevents compiling with gcc -
std=c89.

It has been fixed in upstream in commit 07d89829.

Please also fix it in the Debian flex package.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.4
ii  install-info   6.0.0.dfsg.1-4
ii  libc6  2.21-7
ii  libfl-dev  2.6.0-3
ii  m4 1.4.17-5

Versions of packages flex recommends:
ii  clang-3.5 [c-compiler]  1:3.5.2-3
ii  clang-3.6 [c-compiler]  1:3.6.2-3
ii  clang-3.7 [c-compiler]  1:3.7.1-1
ii  gcc [c-compiler]4:5.3.1-1
ii  gcc-4.6 [c-compiler]4.6.4-7
ii  gcc-4.7 [c-compiler]4.7.4-3
ii  gcc-4.8 [c-compiler]4.8.5-4
ii  gcc-4.9 [c-compiler]4.9.3-11
ii  gcc-5 [c-compiler]  5.3.1-7

Versions of packages flex suggests:
ii  bison2:3.0.4.dfsg-1
ii  build-essential  12.1

-- no debconf information


signature.asc
Description: This is a digitally signed message part.

Bug#801784: gitk de_DE.UTF-8: Error in startup script: bad menu entry index "Ansicht bearbeiten ..."

[Tim Rühsen]

On Wed, 14 Oct 2015 16:44:53 +0200 Christoph Berg  
wrote:
> Package: gitk
> Version: 1:2.6.1-1
> Severity: grave
> 
> Hi,
> 
> running in a German locale, gitk is broken:

Workaround:

LC_ALL=C gitk 



signature.asc
Description: This is a digitally signed message part.

Bug#800698: Kmail2 display garbled (after a while)

[Tim Rühsen]

Sorry for the noise.

I just read #800698 to the end.
And I can confirm that OpenJDK 8 solves the issue.

For Netbeans, you have to set
netbeans_jdkhome="/usr/lib/jvm/java-8-openjdk-amd64"
in
~/netbeans-8.0.2/etc/netbeans.conf

Tim

Am Montag, 12. Oktober 2015, 16:38:45 schrieb Tim Ruehsen:
> Hi Boris,
> 
> I got it again and I guess it has something to do with using Netbeans.
> 
> Huhh ? Yes, Netbeans creates many but small shared memory blocks.
> I can't find any limit here for the number of shmem blocks nor for a max
> memory usage. But somehow it seems limited to 4096 chunks.
> 
> I just experienced a garbled Kmail window (when opening a new window for a
> reply). I quick check with ipcs in a console says:
> $ ipcs -m|grep -c ^0x
> 4096
> 
> I closed Kmail and Netbeans, restarted Kmail and now:
> $ ipcs -m|grep -c ^0x
> 8
> 
> I use the original Oracle Netbeans download, Version 8.0.2.
> Well, maybe it is not Netbeans but simply Java (OpenJDK 8 here) - I can't
> say. However, there seems to be a shmem limit since a few weeks that hasn't
> been there before.
> 
> Any idea how to proceed ?
> 
> Tim
> 
> On Thursday 08 October 2015 11:42:25 Boris Pek wrote:
> > Hi Tim,
> > 
> > > since I installed kde5 I have a kmail2 issue.
> > > 
> > > After a while the kmail2 display window becomes drawn unreadable.
> > > See this screenshot:
> > > https://drive.google.com/open?id=0B_loju3MX2rTZlNOdDRxblVTWDg
> > > 
> > > Stopping and starting kmail does not help.
> > > Stopping and starting kdm helps for a while (until it suddenly happens
> > > again).
> > > 
> > > I can't see anything obvious in 'dmesg' or .xsession-errors. Well I see
> > > lot's of 'BadDrawable' messages, but these are not limited to kmail.
> > > 
> > > I am on Debian SID with latest dist-upgrade, have the problem with
> > > kernel
> > > 4.1 and 4.2 (didn't test any older kernels). Grafix is internal Intel i3
> > > (Sandy Bridge).
> > > 
> > > Any ideas how to work around that or how to pin the problem ?
> > 
> > $ ldd /usr/bin/kmail | grep QtGui
> > libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4
> > (0x7f984cbb)
> > 
> > kmail is currently built with old Qt4 based KDE libs. It looks that you
> > have faced with issue from #800698. Please try to launch kmail from
> > terminal and show the output.
> > 
> > Best regards,
> > Boris

Bug#790524: src:gmt: takes over files from several unrelated packages (was: Re: gmt: libgenome-perl in sid already provides /usr/bin/gmt)

[Tim Rühsen]

Am Freitag, 3. Juli 2015, 22:11:49 schrieb Sebastiaan Couwenberg:
  * libpsl-dev
  
[...]

Filelist libpsl-dev vs. libgmt-dev:

usr/lib/x86_64-linux-gnu/libpsl.so
 
 The libpsl  gmt packages use different a SONAME. To ensure dependencies
 on the GMT libpsl it's bundled with libgmt in the libgmt5 package.
 
 To resolve the conflict I'm considering renaming the GMT libpsl to
 libgmt-psl.
 
 I've CC'ed the libpsl maintainers, and I would like to ask your opinion
 on this conflict too.

Hi Sebastiaan.

IMO, renaming GMT libpsl to libgmt-psl seems reasonable to me. It is a step 
towards a cleaner library 'namespacing' regarding GMT.

If it comes to renaming the non-GMT file (and/or package), I won't be 
reluctant. You'll have a good reason than.

BTW, I could not CC this mail to Daniel Kahn Gillmor 
d...@40fifthhorseman.net, that's why I took him out of the recipient list.

Regards, Tim

signature.asc
Description: This is a digitally signed message part.

Bug#766780: Please add Public Suffix List cookie domain checking via libpsl

[Tim Rühsen]

Package: wget
Version: 1.15-1
Severity: wishlist


When building the next release of Wget (coming soon), please add Public Suffix 
List cookie domain checking. Not using libpsl makes using cookies much more 
vulnerable to 'supercookies'.

in debian/control
- add libpsl-dev to Build-Depends
- add libpsl0 to Depends

(Optionally add --with-libpsl to ./configure, but since this is the default, 
you won't really need this.)

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Bug#745836: CRLs where from ?

[Tim Rühsen]

Wget currently does not load CRLs.
It loads (by default) certificates from the /etc/ssl/certs/ directory.
If a cert is found here and is still valid (despite from any CRLs), the 
appropriate connection is accepted/verified.

An implementation of CRL loading from local files would be nice and easy going.

I did not find any CRLs on my Debian Sid. Where are they going / what am I 
missing ?

Tim


signature.asc
Description: This is a digitally signed message part.

Bug#733039: Exposing GnuTLS priority strings

[Tim Rühsen]

There has been a discussion about exposing GnuTLS priority strings to the Wget 
user:
http://lists.gnu.org/archive/html/bug-wget/2013-08/msg00053.html

Tim


signature.asc
Description: This is a digitally signed message part.

Bug#728735: wget: unexpected linker -Lyes/lib seen in wget --version

[Tim Rühsen]

Package: wget
Version: 1.14-4
Severity: minor

Dear Maintainer,

wget --version outputs -Lyes/lib as param to the linker.

tim@debian:~$ wget --version
GNU Wget 1.14 übersetzt unter linux-gnu.

+digest +https +ipv6 +iri +large-file +nls -ntlm +opie +ssl/gnutls 

Wgetrc: 
/etc/wgetrc (System)
Lokale: /usr/share/locale 
Übersetzt: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=/etc/wgetrc 
-DLOCALEDIR=/usr/share/locale -I. -I../lib -I../lib 
-D_FORTIFY_SOURCE=2 -Iyes/include -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security 
-DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
Gebunden: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
  -Wl,-z,relro -Lyes/lib -lgnutls -lz -lz -lidn -luuid ftp-opie.o 
gnutls.o ../lib/libgnu.a 



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc62.17-93
ii  libgnutls28  3.2.4-4
ii  libidn11 1.28-1
ii  libuuid1 2.20.1-5.5
ii  zlib1g   1:1.2.8.dfsg-1

wget recommends no packages.

wget suggests no packages.

-- no debconf information

signature.asc
Description: This is a digitally signed message part.

Bug#725522: libgnutls28: memory leak calling gnutls_global_init/gnutls_global_deinit

[Tim Rühsen]

Package: libgnutls28
Version: 3.2.4-4
Severity: normal

Dear Maintainer,

calling gnutls_global_init() followed by gnutls_global_deinit() leaves one 
memory chunk
unfreed. That's what valgrind says:

==17498== HEAP SUMMARY:
==17498== in use at exit: 32 bytes in 1 blocks
==17498==   total heap usage: 2,198 allocs, 2,197 frees, 324,240 bytes 
allocated
==17498== 
==17498== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
==17498==at 0x4C2B514: calloc (vg_replace_malloc.c:593)
==17498==by 0x620865F: _dlerror_run (dlerror.c:141)
==17498==by 0x62080C0: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==17498==by 0x5703ACA: dlopen_and_get_function_list (in /usr/lib/x86_64-
linux-gnu/libp11-kit.so.0.0.0)
==17498==by 0x5704909: _p11_kit_initialize_registered_unlocked_reentrant 
(in /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0)
==17498==by 0x5704CCC: p11_kit_initialize_registered (in /usr/lib/x86_64-
linux-gnu/libp11-kit.so.0.0.0)
==17498==by 0x4E88037: gnutls_pkcs11_init (in /usr/lib/x86_64-linux-
gnu/libgnutls.so.28.25.0)
==17498==by 0x4E719A2: gnutls_global_init (in /usr/lib/x86_64-linux-
gnu/libgnutls.so.28.25.0)
==17498==by 0x4006F5: main (in /home/tim/src/mget/tmp/x)

It may be in libp11-kit0 or even in libc6, but that is beyond of my current 
scope.

C source to reproduce the leak:
#include stdio.h
#include gnutls/gnutls.h
void main(void) {
  gnutls_global_init();
  gnutls_global_deinit();
}


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgnutls28 depends on:
ii  libc6  2.17-93
ii  libgmp10   2:5.1.2+dfsg-3
ii  libhogweed22.7.1-1
ii  libnettle4 2.7.1-1
ii  libp11-kit00.18.5-3
ii  libtasn1-6 3.3-2
ii  multiarch-support  2.17-93
ii  zlib1g 1:1.2.8.dfsg-1

libgnutls28 recommends no packages.

Versions of packages libgnutls28 suggests:
ii  gnutls-bin  3.2.4-4

-- no debconf information


signature.asc
Description: This is a digitally signed message part.

Bug#724069: libidn11:amd64: invalid read of size 4 in idna_to_ascii_8z/idna_to_ascii_4z reported by valgrind

[Tim Rühsen]

Package: libidn11
Version: 1.28-1
Severity: normal

Dear Maintainer,

compiling and running a C program using valgrind leads to 'invalid read of 
size 4' report.

The code snippet is

#include stdio.h
#include idna.h
void main(void)
{
char *host_asc = NULL;
idna_to_ascii_8z(www.exampl.com, host_asc, IDNA_USE_STD3_ASCII_RULES);
printf(-%s\n,host_asc);
}

Compiling it with gcc 4.8.1-10 and executing the executable with
  valgrind ./x

leads to
==8903== Invalid read of size 4
==8903==at 0x4E386A2: idna_to_ascii_4z (in /usr/lib/x86_64-linux-
gnu/libidn.so.11.6.11)
==8903==by 0x4E38919: idna_to_ascii_8z (in /usr/lib/x86_64-linux-
gnu/libidn.so.11.6.11)
==8903==by 0x400642: main (in /home/tim/src/mget/tmp/x)
==8903==  Address 0x54121c8 is 8 bytes inside a block of size 11 alloc'd
==8903==at 0x4C2B72E: realloc (vg_replace_malloc.c:662)
==8903==by 0x4E3870D: idna_to_ascii_4z (in /usr/lib/x86_64-linux-
gnu/libidn.so.11.6.11)
==8903==by 0x4E38919: idna_to_ascii_8z (in /usr/lib/x86_64-linux-
gnu/libidn.so.11.6.11)
==8903==by 0x400642: main (in /home/tim/src/mget/tmp/x)


Using www.example.com (or any string with one byte longer) does not trigger 
valgrind.
The printf() prints in both cases the expected result.



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libidn11:amd64 depends on:
ii  libc6  2.17-92+b1
ii  multiarch-support  2.17-92+b1

libidn11:amd64 recommends no packages.

libidn11:amd64 suggests no packages.

-- no debconf information


signature.asc
Description: This is a digitally signed message part.

Bug#707555: Solution

[Tim Rühsen]

I compiled the current wget from git on a current Debian SID.

It works together with the option secure-protocol=SSLv3 (which does not 
work on Debians 1.14-2: 'GnuTLS internal error').

I have installed:

gnutls-bin 3.1.12-2
libgnutls-openssl27:amd64 2.12.23-5
libgnutls-xssl0:amd64 3.1.12-2
libgnutls26:amd64 2.12.23-5
libgnutls26:i386 2.12.23-5
libgnutls28:amd64 3.1.12-2
libgnutls28-dbg 3.1.12-2
libgnutls28-dev 3.1.12-2
libgnutlsxx28:amd64 3.1.12-2


tim@debian:~/src/wget/trunk$ ldd src/wget
linux-vdso.so.1 (0x7fff7d7fe000)
libgnutls.so.28 = /usr/lib/x86_64-linux-gnu/libgnutls.so.28 
(0x7fd0a8336000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fd0a811e000)
libidn.so.11 = /usr/lib/x86_64-linux-gnu/libidn.so.11 
(0x7fd0a7ee9000)
libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 
(0x7fd0a7ce4000)
libpcre.so.3 = /lib/x86_64-linux-gnu/libpcre.so.3 
(0x7fd0a7aa6000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd0a76f8000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fd0a74f)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fd0a72d4000)
libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 
(0x7fd0a70c1000)
libtasn1.so.6 = /usr/lib/x86_64-linux-gnu/libtasn1.so.6 
(0x7fd0a6ead000)
libnettle.so.4 = /usr/lib/x86_64-linux-gnu/libnettle.so.4 
(0x7fd0a6c7d000)
libhogweed.so.2 = /usr/lib/x86_64-linux-gnu/libhogweed.so.2 
(0x7fd0a6a4d000)
libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7fd0a67d3000)
/lib64/ld-linux-x86-64.so.2 (0x7fd0a866d000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd0a65ce000)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675056: clang / gcc 4.7 issue

[Tim Rühsen]

There seem to be issues with clang compiled with gcc 4.7.

Either a recompilation with gcc 4.6 or [gcc 4.7 -fno-tree-pre] could help.

see also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53147

Other problems with clang and gcc 4.7 can be found on llvm's bugzilla.

Regards, Tim



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#626579: libxpcom.so: cannot open shared object file: No such file or directory

[Tim Rühsen]

Am Friday, 13. May 2011 schrieb Mike Hommey:
 On Fri, May 13, 2011 at 11:13:15AM +0200, Tim Rühsen wrote:
  Sorry, I forget to say that it causes a problem with prelink:
  prelink: /usr/lib/xulrunner-1.9.1/xulrunner-bin: Could not find one of
  
   the dependencies
  
  This just means, this libraries would not prelink. Would be nice to avoid
  such messages and have it going
 
 Just set LD_LIBRARY_PATH when you prelink.
 Prelinking is a terrible idea anyway.

Prelinking is automatically done by cron when you install the package 
'prelink'. I don't like modifying the cron script since it is provided by the 
package as is.
What I did is putting a file into /etc/ld.so.conf.d/ which contains the 
library path '/usr/lib/xulrunner-1.9.1/'. But this a short time workaround 
which will break when xulrunner-1.9.1 is removed or replaced by a new version.

A proper solution still would be if xulrunner-x.y.z (whatever version) could 
provide the mentioned file. I have enough of these little things to keep in 
mind... computers are better at houskeeping library paths.
If you fix it, there are some nice side effects:
- prelink will work
- ldd will show the correct dependencies
- any program relying on ldd or prelink will work
( i am shure this list is not complete !)

 Prelinking is a terrible idea anyway.
It is beyond of the scope of this bug report... but maybe you could be more 
precise or link me to good discussions about pros and cons (never found a 
funded con that was relevant to me).
I personally use prelink since many years and can't remember any serious 
problems. But I just use on my desktop and not on any server. Just being 
precautious, not having a real reason.

Regards, Tim



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#528217: The problem is gone for me

[Tim Rühsen]

Yesterday I could reproduce the behaviour after rebooting.

Today, I rebooted, aptitude update, aptitude upgrade, started OpenOffice 
without a Document (from the KDE menu), stopped it, started OpenOffice from 
Dolphin (clicking on the same .odt files as yesterday) - and it did not crash 
the X server !

Today I upgraded these packages:
  gstreamer0.10-alsa gstreamer0.10-plugins-base gstreamer0.10-x libcfitsio3 
libglew1.5  
  libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 liblqr-1-0 libncurses5 
libncurses5-dev 
  libncursesw5 linphone login ncurses-base ncurses-bin passwd   


But anyway, X should not crash after:
[xkb] BOGUS LENGTH in write keyboard desc, expected 7344, got 7360

Regards, Tim




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#455479: failed to mount smbfs shares: mount error 13 = Permission denied

[Tim Rühsen]

Am Mittwoch, 12. Dezember 2007 schrieb Steve Langasek:
 forcemerge 369495 455479
 thanks

 On Mon, Dec 10, 2007 at 12:09:24PM +0100, Tim Rühsen wrote:
  Am Montag, 10. Dezember 2007 schrieb Steve Langasek:
   On Mon, Dec 10, 2007 at 11:51:39AM +0100, Tim Ruehsen wrote:
mounting shares via smbfs (also tried cifs - same problem) result in:
mount error 13 = Permission denied
   
the systems to mount are different linux systems:
- current stable
- 6 years old unstable
- SuSE 7.1
   
downgrading just smbfs to 3.0.27a-1 completely removes the problem.
(dpkg -i --force-all smbfs_3.0.27a-1_i386.deb)
   
my fstab entries look all the same (for example):
//dev-3/dev/network/dev-3/dev  smbfs
credentials=/etc/credentials.oms,uid=oms,gid=users,noauto,user
   
the permissions for /network/dev-3/dev are 0777.
i could not track the problem down (strace, changing permissions on
the credential file, trying with different users incl. root, changed
options)
  
   By any chance, to you have spaces before or after the equal sign in
   your credentials file?
 
  Whow, good point. You just found the problem:
  having a space before the username produces the error.
  having a space before the password seems to be ok.

 Ok, then this becomes an instance of bug #369495; merging.

 Unfortunately, I have to say that the mount.cifs semantics are the more
 correct because whitespace (including leading whitespace) is significant in
 passwords and trimming whitespace therefore makes it impossible to
 represent some possible passwords in credentials files.  So this bug is
 wontfix as far as fully supporting the old syntax, but there is an open
 request for improved documentation.

Please read my above comment:
A leading space before the password does not matter at the moment.
But a leading whitespace in the username matters.

Either, the docs should mention this exception or (maybe better)
we need a fix in software (to make leading spaces work for passwords) together 
with a fix for #369495. It is still an issue for smbfs 3.0.28-1 - i just made 
a test.

Bug#455479: failed to mount smbfs shares: mount error 13 = Permission denied

[Tim Rühsen]

Am Montag, 10. Dezember 2007 schrieb Steve Langasek:
 On Mon, Dec 10, 2007 at 11:51:39AM +0100, Tim Ruehsen wrote:
  mounting shares via smbfs (also tried cifs - same problem) result in:
  mount error 13 = Permission denied
 
  the systems to mount are different linux systems:
  - current stable
  - 6 years old unstable
  - SuSE 7.1
 
  downgrading just smbfs to 3.0.27a-1 completely removes the problem.
  (dpkg -i --force-all smbfs_3.0.27a-1_i386.deb)
 
  my fstab entries look all the same (for example):
  //dev-3/dev/network/dev-3/dev  smbfs 
  credentials=/etc/credentials.oms,uid=oms,gid=users,noauto,user
 
  the permissions for /network/dev-3/dev are 0777.
  i could not track the problem down (strace, changing permissions on the
  credential file, trying with different users incl. root, changed options)

 By any chance, to you have spaces before or after the equal sign in your
 credentials file?

Whow, good point. You just found the problem:
having a space before the username produces the error.
having a space before the password seems to be ok.

Thanks a lot.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#454115: on pc-to-pc twinkle sends INVITE to unknown IP 81.169.145.87:5060 (registrar not configured)

[Tim Rühsen]

Package: twinkle
Version: 1:1.1-2+b1
Severity: normal

am trying to connect pc-to-pc (as described on the twinkle homepage, but 
without using name - so i just enter the destination IP 192.168.0.101 for 
example).
I just enter the desired IP an hit 'Dial' which results in '503 Service 
Unavailable'.
In the log i find that twinkle contacts the IP 81.169.145.87:5060, no matter 
what IP i selected.
UserProfile/SIPServer/Registrar is empty and 'Register at startup' is off.
'Use Outbound Proxy' is off.
NAT: 'NAT traversal not needed' is on.

Here is the extract from the log:
+++ 30-11-2007 12:40:28.187366 INFO SIP ::send_sip_udp
Send to: 81.169.145.87:5060
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP 192.1.11.218;rport;branch=z9hG4bKlztaveet
Max-Forwards: 70
To: sip:[EMAIL PROTECTED]
From: Tim Ruehsen sip:[EMAIL PROTECTED];tag=frctk
Call-ID: [EMAIL PROTECTED]
CSeq: 710 INVITE
Contact: sip:[EMAIL PROTECTED]
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 203

v=0
o=tim 1628269059 1659689211 IN IP4 192.1.11.218
s=-
c=IN IP4 192.1.11.218
t=0 0
m=audio 8002 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

---

+++ 30-11-2007 12:40:28.212792 INFO NORMAL ::listen_udp
Received ICMP from: 81.169.145.87
ICMP type: 3
ICMP code: 3
Destination of packet causing ICMP: 81.169.145.87:5060
Socket error: 111 Connection refused
---

+++ 30-11-2007 12:40:28.213057 INFO NORMAL t_tc_invite::process_icmp
ICMP error received.

Send internal:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 192.1.11.218;rport;branch=z9hG4bKlztaveet
To: sip:[EMAIL PROTECTED];tag=npooi
From: Tim Ruehsen sip:[EMAIL PROTECTED];tag=frctk
Call-ID: [EMAIL PROTECTED]
CSeq: 710 INVITE
Server: Twinkle/1.1
Content-Length: 0




That unknown IP 81.169.145.87 must somewhere being hardcoded...
I don't want Twinkle to connect an unknown IP which can't be switched off. Do 
you?

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages twinkle depends on:
ii  kdelibs4c2a 4:3.5.8.dfsg.1-4 core libraries and binaries for 
al
ii  libasound2  1.0.15-2 ALSA library
ii  libboost-regex1.34.11.34.1-2 regular expression library for 
C++
ii  libc6   2.7-2GNU C Library: Shared libraries
ii  libccrtp1-1.5-1 1.5.2-1  Common C++ class framework for 
RTP
ii  libcommoncpp2-1.5.3-0   1.5.9-1  A GNU package for creating 
portabl
ii  libgcc1 1:4.2.2-4GCC support library
ii  libgsm1 1.0.12-1 Shared libraries for GSM speech 
co
ii  libqt3-mt   3:3.3.7-9Qt GUI Library (Threaded runtime 
v
ii  libsndfile1 1.0.17-4 Library for reading/writing audio 
ii  libspeex1   1.1.12-3 The Speex Speech Codec
ii  libstdc++6  4.2.2-4  The GNU Standard C++ Library v3
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxext61:1.0.3-2X11 miscellaneous extension 
librar
ii  libxml2 2.6.30.dfsg-3GNOME XML library
ii  libzrtpcpp-0.9.2deb00.9.2-3  ccrtp extension for zrtp/Zfone 
sup
ii  zlib1g  1:1.2.3.3.dfsg-7 compression library - runtime

twinkle recommends no packages.

-- no debconf information




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#454115: on pc-to-pc twinkle sends INVITE to unknown IP 81.169.145.87:5060 (registrar not configured)

[Tim Rühsen]

Am Montag, 3. Dezember 2007 schrieb Mikael Magnusson:
 Tim Rühsen wrote:
  Package: twinkle
  Version: 1:1.1-2+b1
  Severity: normal
 
  am trying to connect pc-to-pc (as described on the twinkle homepage, but
  without using name - so i just enter the destination IP 192.168.0.101 for
  example).

 Why can't you add a name?

the snom300 phone is reachable only without a name. i can test that with e.g. 
ekiga or linphone (address is sip:192.1.11.92). a name leads to '404 not 
found' message from the phone.


  I just enter the desired IP an hit 'Dial' which results in '503 Service
  Unavailable'.
  In the log i find that twinkle contacts the IP 81.169.145.87:5060, no
  matter what IP i selected.
  UserProfile/SIPServer/Registrar is empty and 'Register at startup' is
  off. 'Use Outbound Proxy' is off.
  NAT: 'NAT traversal not needed' is on.
 
  Here is the extract from the log:
  +++ 30-11-2007 12:40:28.187366 INFO SIP ::send_sip_udp
  Send to: 81.169.145.87:5060
  INVITE sip:[EMAIL PROTECTED] SIP/2.0
  Via: SIP/2.0/UDP 192.1.11.218;rport;branch=z9hG4bKlztaveet
  Max-Forwards: 70
  To: sip:[EMAIL PROTECTED]
  From: Tim Ruehsen sip:[EMAIL PROTECTED];tag=frctk

 ...

  That unknown IP 81.169.145.87 must somewhere being hardcoded...
  I don't want Twinkle to connect an unknown IP which can't be switched
  off. Do you?

 Apparently twinkle thinks 192.168.0.101 is a telephone number, not an IP
 address, and it got translated to 1921680101 and your domain name is
 appended resulting in [EMAIL PROTECTED] When sending the
 INVITE request to [EMAIL PROTECTED], twinkle looks up the IP
 address of openmediasystem.de, which is 81.169.145.87.

sorry for that.
I didn't expect twinkle works like that. of course i tried 'host 
81.169.145.87' which lead to 'w87.rzone.de' which is absolutely unknown to me 
(it must be from my provider 'Strato').

i think, this bug can be closed.

Is there a way to dial an IP directly without name? Or should I open a 
wishlist 'bug'?


 Mikael

-- 
OMS Open Media System GmbH
Holzdamm 40
20099 Hamburg
Fon +49-40-238878-0
Fax +49-40-238878-99
Email [EMAIL PROTECTED]
Sitz und Registergericht Hamburg
HRB 57616

Bug#386609: Same with 0.9.17

[Tim Rühsen]

 /usr/lib/wine/wined3d.dll.so is found in the libwine-gl package. (The
 name does not start with lib.)

Wow, that's it! I somehow missed the new package, thanks.

I think, the bug can be closed now.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386609: same with 0.9.18-1

[Tim Rühsen]

Package: wine
Version:0.9.18-1

Same as with 0.9.16-1 and 0.9.17-1. DiabloII fails to start. It looks like 
libwined3d is completely missing. I found a /usr/lib/wine/libwined3d.def 
file, but no /usr/lib/wine/libwined3d.dll.so.

Tim


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386609: Same with 0.9.17

[Tim Rühsen]

Package: wine
Version:0.9.17-1

Same as with 0.9.16-1. DiabloII fails to start. It looks like libwined3d is 
completely missing. I found a /usr/lib/wine/libwined3d.def file, but 
no /usr/lib/wine/libwined3d.dll.so.
But i am not shure if this is the problem.

Tim


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386945: initscripts: User Mode Linux (UML) doesn't start because /dev/shm is mounted noexec

[Tim Rühsen]

Package: initscripts
Version: 2.86.ds1-20
Severity: critical
Justification: breaks UML environments

The mountdevsubfs.sh init script mounts /dev/shm with the noexec flag.
UML (/usr/bin/linux) complains about that and doesn't start.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386609: Diablo II fails to start

[Tim Rühsen]

Package: wine
Version:0.9.16-1

Everything worked fine upto 0.9.15-1.
0.9.16-1 fails with:
...
err:module:import_dll Library wined3d.dll (which is needed by 
LC:\\Windows\\System\\ddraw.dll) not found
ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file 
or directory
fixme:x11drv:X11DRV_GetDeviceCaps (0x33c): CAPS1 is unimplemented, will return 0
err:module:import_dll Library wined3d.dll (which is needed by 
LC:\\Windows\\System\\ddraw.dll) not found
fixme:x11drv:X11DRV_GetDeviceCaps (0x1b4): CAPS1 is unimplemented, will return 0
fixme:msimg32:vSetDdrawflag stub: vSetDrawFlag 1
fixme:win:EnumDisplayDevicesW ((null),0,0x7fbb7a90,0x), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x7fbb7a90,0x), stub!
err:ntdll:RtlpWaitForCriticalSection section 0x7ffdcfe4 loader.c: 
loader_section wait timed out in thread 000c, blocked by 000b, retrying (60 
sec)
err:ntdll:RtlpWaitForCriticalSection section 0x6ffa6ecc ? wait timed out in 
thread 000b, blocked by 000c, retrying (60 sec)
Wine failed with return code 1

It looks like something is wrong with finding wined3d.dll, but i'm not the 
doctor;-)

After downgrading to 0.9.15-1 Diablo II works again as always.

My system is SID/unstable.

Regards, Tim


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]