Bug#943321: libbrotli-dev: Please rename static libraries from *-static.a to *.a

[Tim Ruehsen]

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

Dear Maintainer,

thanks for adding the static libraries in this version.

But gcc linker won't find those file names automatically.
The linker expects the library names having just a .a extension (instead of 
.so).

That would be
/usr/lib/x86_64-linux-gnu/libbrotlicommon.a
/usr/lib/x86_64-linux-gnu/libbrotlidec.a
/usr/lib/x86_64-linux-gnu/libbrotlienc.a

instead of (currently)
/usr/lib/x86_64-linux-gnu/libbrotlicommon-static.a
/usr/lib/x86_64-linux-gnu/libbrotlidec-static.a
/usr/lib/x86_64-linux-gnu/libbrotlienc-static.a

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/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.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-4

libbrotli-dev recommends no packages.

libbrotli-dev suggests no packages.

-- no debconf information

Bug#929702: bash-builtins: Please add loadables 'rm' and 'cat'

[Tim Ruehsen]

Package: bash-builtins
Version: 5.0-4
Severity: wishlist

Dear Maintainer,

as developer, I make use of the 'rm' and 'cat' bash loadables to speed up 
./configure runs.

Currently, I have to build my own bash + builtins because the package 
'bash-builtins' does not
contain these two builtins.

To build them, you have to execute make target 'others' in examples/loadables,
'make -C examples/loadables others'.

With best Regards, Tim

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash-builtins depends on:
ii  bash  5.0-4

bash-builtins recommends no packages.

bash-builtins suggests no packages.

-- no debconf information

Bug#929668: bash: Valgrind reports 'definitely lost' memory in main/set_default_locale

[Tim Ruehsen]

Package: bash
Version: 5.0-4
Severity: important

Dear Maintainer,

I do lot's of software development and testing with valgrind on Debian unstable.
Several testsuites of OSS projects use bash as part of the tests.

The current bash version breaks test suite due to a 'definitely lost block'.
It doesn't matter how you invoke bash. Here is just an example.

$ valgrind --leak-check=yes bash x
==2103== Memcheck, a memory error detector
==2103== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2103== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2103== Command: bash x
==2103== 
bash: x: No such file or directory
==2103== 
==2103== HEAP SUMMARY:
==2103== in use at exit: 40,853 bytes in 631 blocks
==2103==   total heap usage: 798 allocs, 167 frees, 60,518 bytes allocated
==2103== 
==2103== 12 bytes in 1 blocks are definitely lost in loss record 80 of 220
==2103==at 0x483577F: malloc (vg_replace_malloc.c:299)
==2103==by 0x195E8D: xmalloc (in /bin/bash)
==2103==by 0x18F51A: set_default_locale (in /bin/bash)
==2103==by 0x135EE6: main (in /bin/bash)
==2103== 
==2103== LEAK SUMMARY:
==2103==definitely lost: 12 bytes in 1 blocks
==2103==indirectly lost: 0 bytes in 0 blocks
==2103==  possibly lost: 0 bytes in 0 blocks
==2103==still reachable: 40,841 bytes in 630 blocks
==2103== suppressed: 0 bytes in 0 blocks
==2103== Reachable blocks (those to which a pointer was found) are not shown.
==2103== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2103== 
==2103== For counts of detected and suppressed errors, rerun with: -v
==2103== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


Building bash 5.0 from upstream fixes this issue for me.

Regards, Tim

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   10.3
ii  debianutils  4.8.6.1
ii  libc62.28-10
ii  libtinfo66.1+20181013-2

Versions of packages bash recommends:
ii  bash-completion  1:2.8-6

Versions of packages bash suggests:
pn  bash-doc  

-- Configuration Files:
/etc/bash.bashrc changed [not included]

-- no debconf information

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

[Tim Ruehsen]

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).

The behavior is not seen on an i368 cross build, while on all our other cross 
builds,
which are arm-linux-gnueabihf, mips-linux-gnu, aarch64-linux-gnu.

Here is a small reproducer:
include 
#include 
#include 

int main(void)
{
errno=0;
char *msg=strerror(-3);
printf("errno=%d, msg=%s\n",errno,msg);

return 0;
}

Test it with:
$ arm-linux-gnueabihf-gcc -Wextra x.c -o x
$ ./x
errno=12, msg=Unknown error -3

You need the binfmt/qemu stuff set up to execute the cross-compiled binary.

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.18.0-3-amd64 (SMP w/12 CPU cores)
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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

[Tim Ruehsen]

Follow-up Comment #5, bug #51666 (project wget):

Thanks for addressing the issue.

Saving the salt together with the (salted) hash isn't of big help when we talk
about a limited set of input strings. You can get complete lists of existing
domains and brute force through them in a few seconds. Can even be optimized
by starting with the top 1m domains. I just mention this to make clear that
this way of obscuring is far from being safe. It is just slightly more effort
to reverse the domain names in comparison to unsalted hashes.

Anyways, it helps from being fly-by looked at, e.g. on the console.

I would like to ask you to not use OpenSSL for hashing. We have/use the SHA256
digest functions from gnulib anyways. So it should be straight forward.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Bug#874590: [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[Tim Ruehsen]

Follow-up Comment #14, bug #51181 (project wget):

Sorry, I forgot to mention that I used J's system() call.

> Given the special behavior of "timeout", isn't this "working as intended"?

I see wget-log being created with J's C code though --output-file was given
(-o dump.html):

#include 
int main (void) {
int result = system("timeout 25 src/wget -o dump.html
http://google.com/;);
return result;
}

$ gcc x.c -o x
$ ./x

Redirecting output to ‘wget-log.1’.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Bug#874590: [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[Tim Ruehsen]

Update of bug #51181 (project wget):

  Status:   Fixed => Confirmed  
 Open/Closed:  Closed => Open   
 Release:  1.19.1 => 1.19.5 
 Planned Release:  1.19.3 => 1.19.6 

___

Follow-up Comment #11:

The 'timeout' command puts wget into background.

If you either leave it away or use --foreground with 'timeout', you won't see
wget-log. You can use --timeout=25 for wget if you need a timeout.

But that's a work-around. The issue is that wget behaves contrary to the
manual which says "--background: If no output file is specified via the -o,
output is redirected to wget-log".

I re-open the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Bug#888691: [bug #53020] wget -b produces empty wget-log file

[Tim Ruehsen]

Additional Item Attachment, bug #53020 (project wget):

File name: 0001-Fix-logging-in-background-mode.patch Size:2 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#888691: [bug #53020] wget -b produces empty wget-log file

[Tim Ruehsen]

Follow-up Comment #2, bug #53020 (project wget):

Added a patch - please review. If OK it goes into master.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#887384: [bug #53021] Ability to provide password per-instance

[Tim Ruehsen]

Follow-up Comment #1, bug #53021 (project wget):

Having an option for a different .netrc file is a good request and I wonder
why nobody ever asked for it before.

We already have it in wget2 (--netrc-file=). Latest sources from git at
https://git.savannah.gnu.org/git/wget/wget2.git, collaboration at
https://gitlab.com/gnuwget/wget2.

And that's where we add new features. Wget 1.x is still maintained - that mean
we fix bugs and accept contributions. But that's it.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#832528: Latest akonadi packages do not kick out old package baloo-utils

[Tim Ruehsen]

Am Samstag, den 20.01.2018, 19:28 +0100 schrieb Sandro Knauß:
> Control: reassign -1 baloo-utils
> Control: found -1 4:4.14.3-3
> Control: affects -1 akonadi-server
> 
> Hey,
> 
> With kdepim with 16.08+ baloo package was split into baloo (file
> indexer) and 
> akonadisearch the kdepim indexer. I can't tell you why at your system
> baloo-
> utils are not removed by default. Maybe you need to run apt
> autoremove. There 
> should normally no dependency stopping you from removing that cruft
> package. 
> Additionally baloo-utils are part of baloo4 aka based on Qt4. So only
> the 
> remaining Qt4 applications creating this unfortunate situation.

> Please try to find out, what application stops the autoremoval of
> baloo-utils. 

Hi, this bug is too old to investigate (mid 2016).
I wouldn't mind if you close it.

Regards, Tim

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

Bug#887590: libhttp-daemon-perl: Please patch HTTP::Daemon to IPv6

[Tim Ruehsen]

Package: libhttp-daemon-perl
Version: 6.01-1
Severity: normal

Dear Maintainer,

the Wget test suite fails because of HTTP::Daemon being IPv4 only.

This comes out when 'localhost' resolves to IPv6 ::1.
In this case tests/Test-https-* fail with
HTTP request sent, awaiting response... Bad arg length for Socket::inet_ntoa, 
length is 16, should be 4 at /usr/share/perl5/HTTP/Daemon.pm line 51.

Switching off IPv6 and the tests pass (echo 1 > 
/proc/sys/net/ipv6/conf/all/disable_ipv6).

At least Arch Linux ships a patched version of HTTP::Daemon (so all tests 
survive).
The patch can be found at
https://metacpan.org/pod/HTTP::Daemon::Patch::IPv6

Patching should also fix issue #667738.

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-3-amd64 (SMP w/4 CPU cores)
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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libhttp-daemon-perl depends on:
ii  libhttp-date-perl   6.02-1
ii  libhttp-message-perl6.14-1
ii  liblwp-mediatypes-perl  6.02-1
ii  perl5.26.1-4

libhttp-daemon-perl recommends no packages.

libhttp-daemon-perl suggests no packages.

-- no debconf information

Bug#874590: [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[Tim Ruehsen]

Update of bug #51181 (project wget):

  Status:   Confirmed => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.19.3 

___

Follow-up Comment #5:

Thanks, applied.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#883407: libc6: getpwnam_r() leaks memory

[Tim Ruehsen]

Am Dienstag, den 05.12.2017, 19:17 +0100 schrieb Aurelien Jarno:
> On 2017-12-03 17:34, Tim Rühsen wrote:
> > 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).
> 
> 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.
> 
I'll try to make up a reproducer the next days. Here is more info that
I have to far.

### nsswitch.conf ###
passwd: compat systemd
group:  compat systemd
shadow: compat

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis


> 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.
> 

The glob issues have been found by me when fuzzing GNU Wget2. Reported
via gnulib mailing list :-)

Just updated my stretch VM to testing... I can reproduce the issue with
2.25-2 (testing) and with 2.25-3 (unstable).

Regards, Tim

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

Bug#813158: [bug #52349] Seg fault with wget -O - smxi.org/sm/sm-versions

[Tim Ruehsen]

Update of bug #52349 (project wget):

 Release:  1.19.1 => 1.19.2 
 Planned Release:None => 1.19.3 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#874590: [bug #51181] Unexpected "Redirecting output to 'wget-log'."

[Tim Ruehsen]

Update of bug #51181 (project wget):

  Status:None => Confirmed  

___

Follow-up Comment #3:

>From the mailing list (21./22.5.2017):

If you use an explicit logfile (-o / --output-file), that code for
creating 'wget-log' isn't triggered.

It is a documented behavior, see 'man wget':
"   -b
   --background
   Go to background immediately after startup.  If no output
file is specified via the -o, output is redirected to wget-log.
"

Maybe the implementation was buggy and didn't match the docs - and since 1.19
it has been fixed ?

Anyways, we want to keep backward compatibility and if that change breaks
existing scripts, we should revert the change and change the docs (I am sure
people dislike that as well ;-)).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[Tim Ruehsen]

Follow-up Comment #1, bug #51666 (project wget):

The files are read/write only to the user (in case you didn't protect your
home directory appropriately).

If you are still concerned, what about
~/.mozilla/firefox/*.default/SiteSecurityServiceState.txt and likely hundreds
or thousands of other files containing potential private information ?

Not thinking of your private keys lying around in .ssh/.

And even file dates and sizes are potential private data leaks.

While we could hash anything, it would be way safer for you to protect your
complete home directory.

We could think about an option, just in case you want to keep your HSTS cache
in a public space, e.g. /var. But we already think of using SQLite for storing
and maybe sharing with Firefox.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[Tim Ruehsen]

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


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.11.0-2-amd64 (SMP w/4 CPU cores)
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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-6 depends on:
ii  binutils  2.28-6
ii  cpp-6 6.4.0-1
ii  gcc-6-base6.4.0-1
ii  libc6 2.24-12
ii  libcc1-0  7.1.0-9
ii  libgcc-6-dev  6.4.0-1
ii  libgcc1   1:7.1.0-9
ii  libgmp10  2:6.1.2+dfsg-1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-1+b2
ii  libmpfr4  3.1.5-1
ii  libstdc++67.1.0-9
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-12

Versions of packages gcc-6 suggests:
ii  gcc-6-doc 6.3.0-1
pn  gcc-6-locales 
pn  gcc-6-multilib
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#866406: autoconf: mmap() detection doesn't work with leak and/or address sanitizer

[Tim Ruehsen]

Package: autoconf
Version: 2.69-10
Severity: normal

Dear Maintainer,

the mmap() detection code in /usr/share/autoconf/autoconf/functions.m4 doesn't
free() the allocated memory. Consequently a ./configure run fails when leak
or address sanitizers are enabled.

>From config.log (the relevant compiler flag is -fsanitize=address):

##
configure:49549: checking for working mmap
configure:49696: clang-5.0 -o conftest -I/usr/local/include 
-I/usr/include/p11-kit-1 -DNDEBUG -O1 -fno-omit-frame-pointer 
-gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION 
-fsanitize=address -fsanitize-address-use-after-scope 
-fsanitize-coverage=trace-pc-guard,trace-cmp   conftest.c -lunistring -lidn2 
-L/usr/local/lib -lbrotlidec -llzma -lz -lbz2 -lnghttp2 -lpsl -lgnutls  >&5
configure:49696: $? = 0
configure:49696: ./conftest

=
==23695==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x4d5498 in malloc (/usr/oms/src/wget2/conftest+0x4d5498)
#1 0x50b85c in main /usr/oms/src/wget2/conftest.c:829:20
#2 0x7fe0be4ac2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: 4096 byte(s) leaked in 1 allocation(s).
configure:49696: $? = 1
configure: program exited with status 1
#

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.9.0-3-amd64 (SMP w/4 CPU cores)
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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autoconf depends on:
ii  debianutils  4.8.1.1
ii  m4   1.4.18-1
ii  perl 5.24.1-4

Versions of packages autoconf recommends:
ii  automake [automaken]  1:1.15.1-1
ii  automake1.10 [automaken]  1:1.10.3-3.1
ii  automake1.6 [automaken]   1.6.3-12
ii  automake1.9 [automaken]   1.9.6+nogfdl-4

Versions of packages autoconf suggests:
ii  autoconf-archive  20160916-1
pn  autoconf-doc  
ii  gettext   0.19.8.1-2
ii  gnu-standards 2010.03.11-1
ii  libtool   2.4.6-2

-- no debconf information

Bug#843620: [bug #50579] wget --continue: Download fails when server does not support HEAD request

[Tim Ruehsen]

Update of bug #50579 (project wget):

  Status:Needs Discussion => Wont Fix   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#858248: Sorry, bad coincidence

[Tim Ruehsen]

Please close this issue.

Somehow a configuration file with host / port information has been clobbered 
here.
Still, the ':0' in the first part of the error message comes from the Java 
Socket Class (no matter what I provide to new Socket() as hostname).
That misguided me completely.

Regards, Tim


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

Bug#858248: openjdk-8-jre: Starting java GUI app from Konsole: java.net.NoRouteToHostException (Host unreachable)

[Tim Ruehsen]

Package: openjdk-8-jre
Version: 8u121-b13-4
Severity: normal

Dear Maintainer,

after updating openjdk-8-* today, starting a GUI java app from the KDE Konsole
doesn't work any more (it did for several years without problems).

$ DISPLAY=:0 java -jar //DBClient.jar

results in a Java error message window saying
"Can't connect to :0" (roughly translated from german)
"java.net.NoRouteToHostException: No route to host (Host unreachable)"

Other (non-java) applications start without problems (e.g. xterm).

I tried several different DISPLAY settings without success.

Regards, Tim


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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-8-jre depends on:
ii  libasound21.1.3-5
ii  libatk-wrapper-java-jni   0.33.3-13
ii  libc6 2.24-9
ii  libgif7   5.1.4-0.4
ii  libgl1-mesa-glx [libgl1]  13.0.5-1
ii  libglib2.0-0  2.50.3-2
ii  libgtk2.0-0   2.24.31-2
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpng16-16   1.6.28-1
ii  libpulse0 10.0-1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  openjdk-8-jre-headless8u121-b13-4
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages openjdk-8-jre recommends:
ii  fonts-dejavu-extra  2.37-1

Versions of packages openjdk-8-jre suggests:
ii  icedtea-8-plugin  1.6.2-3.1

-- no debconf information

Bug#843620: [bug #50579] wget --continue: Download fails when server does not support HEAD request

[Tim Ruehsen]

Update of bug #50579 (project wget):

Category:   Program Logic => Feature Request
  Status:None => Needs Discussion   
 Summary: wget --continue: URL with trailing slash '/' (but
Content-Disposition) => wget --continue: Download fails when server does not
support HEAD request

___

Follow-up Comment #1:

As you already stated, the server should have answered the HEAD request
properly. If a server refuses to do so, --continue currently doesn't work.

Especially with --content-disposition, Wget doesn't know about the filename to
look/save at, so it simply gives up here.

If now Wget tries to be 'clever' and (silently) falls back to the filename
derived from the URL, it could be that the wrong file becomes saved,
clobbered, destroyed (depending on additional options).

So IMO, we better leave it up to the user to *exactly* say what (s)he wants.

The title is misleading, the problem is the same wether with or without
trailing slash.

I leave this bug open for discussion and mark it feature request.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#849961: [bug #50577] URL in wget.texi changed

[Tim Ruehsen]

Update of bug #50577 (project wget):

  Status:None => Fixed  
 Assigned to:None => rockdaboot 
   Fixed Release:None => trunk  
 Planned Release:None => 1.19.2 

___

Follow-up Comment #1:

Thanks !

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#849961: [bug #50577] URL in wget.texi changed

[Tim Ruehsen]

Update of bug #50577 (project wget):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[Tim Ruehsen]

Package: bash
Version: 4.4-4+b1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

in debian/rules the $(STRIP) command is tried to be executed even when empty.

The code is
ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
  ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
STRIP = $(DEB_HOST_GNU_TYPE)-strip
  else
STRIP = strip
  endif
endif
...
$(STRIP) -R .comment -R .note debian/bash.preinst

This sets me into a R shell :-)

Reproducer:
$ apt-get source bash
$ cd bash-4.4
$ DEB_BUILD_OPTIONS="" debuild -b -uc -us

$(DEB_BUILD_OPTIONS) is empty by default here.

Regards, Tim

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   9.8
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1
ii  libc62.24-9
ii  libtinfo56.0+20161126-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi
if [ -x /usr/lib/command-not-found -o -x 
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
   /usr/lib/command-not-found -- "$1"
   return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
   /usr/share/command-not-found/command-not-found -- "$1"
   return $?
else
   printf "%s: command not found\n" "$1" >&2
   return 127
fi
}
fi


-- no debconf information

Bug#849517: bash: invalid free() - address in brk data segment

[Tim Ruehsen]

Dear maintainer,

this bug is still open, on Debian Sid (bash 4.4-4+b1).

And it breaks building software that relies on gnulib's Valgrind checking (m4/
valgrind-tests.m4, ./configure --enable-valgrind-tests).

A supposed valgrind 'make check' run won't detect any failures and returns 
with success due to valgrind testing being silently disabled.

This comes since the ./configure check expects
"valgrind -q --error-exitcode=1 --leak-check=full /bin/bash -c 'exit 0'"
to return with $? being 0.

But with the current bash version it returns $? being 1.
Thus, the valgrind checking is (silently) skipped.

IMO, this bug should be raised to IMPORTANT since building/testing of many 
packages is affected.

BTW, Debian building bash (debuild ) is broken (I will open another bug). I 
end up in a R shell:

$ debuild -b -uc -us
...
R .comment -R .note debian/bash.preinst
ARGUMENT '.comment' __ignored__

WARNING: unknown option '-R'

ARGUMENT '.note' __ignored__

ARGUMENT 'debian/bash.preinst' __ignored__


R version 3.3.3 (2017-03-06) -- "Another Canoe"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


Best Regards, Tim


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

Bug#857675: libidn2-0 FTCBFS: runs host arch code during build (gentr46map, help2man)

[Tim Ruehsen]

Hi Helmut,

On Tuesday, March 14, 2017 12:44:59 PM CET Helmut Grohne wrote:
> On Tue, Mar 14, 2017 at 11:30:48AM +0100, Tim Ruehsen wrote:
> > Just removing 'include ' from gentr46map.c doesn't work out
> > here.
> > _GL_ATTRIBUTE_CONST and _GL_ATTRIBUTE_PURE are then not defined (used in
> > gentr46map.c and tr46map.h) and the compiler errors.
> 
> These weren't in use in the Debian version of libidn2, so it compiled
> there. Given that gnulib has very little clue about cross compilation
> and given that both attributes are an optimization mechanism, I suggest
> to simply drop them (for these two files only). The code is only
> executed during build, so optimizing seems unnecessary to me.
> Alternatively, have the CC_FOR_BUILD invocation define them as empty
> macros. In any case, using config.h in a file compiled for the build
> architecture is an error, because its values are specific to the host
> architecture. It must not be included here.

Thanks for the good explanation, pushed upstream.

> > Also, using -lunistring directly doesn't work out on systems without
> > libunistring. I guess it needs libtool and $(LTLIBUNISTRING) +
> > ../gl/libgnu.la to do it portable. I can't test that for the Debian
> > environment and know too less about cross-compiling to test that myself.
> 
> I tried using $(LTLIBUNISTRING), but that doesn't work for two reasons:
> * It contains libtool parameter such as -R, which are not understood by
>   gcc.
> * It contains parameters specific to the host architecture, but we need
>   the libunitstring for the build architecture. Given that autoconf has
>   no means to check for a build architecture library, I figured that we
>   should skip checking it and link it directly.
> 
> Do you have any other ideas on how to fix this properly for everyone?

Not yet. I'll have a deeper look into libtool. If you are right and libtool 
has no means for the build architecture, well then we have to use libunistring 
directly :-(

> The only other way I see here (and I don't like that) is to implement
> this twice, once portably for native builds and once less portably for
> cross compilation.

Using 'if !cross_compiling' makes the normal standard build more portable and 
let's cross-compilation for Debian still succeed. I think about it.

> Something (a README) should maybe note that libunistring is required
> for both the build and host architecture.

New issue opened upstream.

> > Added the changes for configure.ac and help2man into upstream.
> 
> Nice. I'd slightly favour not using help2man at all, because it is
> something that breaks cross compilation by design and the utility of
> manual pages produced by help2man tends to be limited. What do you
> think?

Right, also added a new issue upstream.

BTW, 'upstream' now is https://gitlab.com/libidn/libidn2.

Thanks for all your feedback !

Regards, Tim


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

Bug#857675: libidn2-0 FTCBFS: runs host arch code during build (gentr46map, help2man)

[Tim Ruehsen]

On Monday, March 13, 2017 9:30:29 PM CET Helmut Grohne wrote:
> Source: libidn2-0
> Version: 0.16-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> cross building libidn2-0 is required for bootstrapping new architectures
> as curl added it to its Build-Depends a while ago. Unfortunately, cross
> building libidn2-0 currently fails. The immediate reason is failure to
> execute gentr46map during build. It is not installed into any package
> and should thus be compiled with the build architecture compiler, but
> the build system opts for the host architecture compiler. After fixing
> that, help2man fails running idn2. Fixing help2man calls doesn't have a
> straight forward solution. One can choose among:
> 1. Stop using help2man and write proper documentation.
> 2. Skip rebuilding manual pages during cross builds.
> 3. Add a idn2:native  to Build-Depends and run that.
> 4. Build libidn2-0 twice. Once native, then cross.
> In the attached patch, I opted for option 2. Please consider applying
> it.

Thanks for your patch(es), Helmut.

Just removing 'include ' from gentr46map.c doesn't work out here.
_GL_ATTRIBUTE_CONST and _GL_ATTRIBUTE_PURE are then not defined (used in 
gentr46map.c and tr46map.h) and the compiler errors.

Also, using -lunistring directly doesn't work out on systems without 
libunistring. I guess it needs libtool and $(LTLIBUNISTRING) + ../gl/libgnu.la 
to do it portable. I can't test that for the Debian environment and know too 
less about cross-compiling to test that myself.

Added the changes for configure.ac and help2man into upstream.

Regards, Tim


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

Bug#855699: publicsuffix: Libpsl loads wrong file due to file dates

[Tim Ruehsen]

On Tuesday, February 21, 2017 9:51:06 AM CET Daniel Kahn Gillmor wrote:
> On Tue 2017-02-21 06:31:57 -0500, Tim Ruehsen wrote:
> > both, /usr/share/publicsuffix/public_suffix_list.dafsa and
> > /usr/share/publicsuffix/public_suffix_list.dat have the same file date
> > (mtime).
> > 
> > Together with a small glitch in libpsl/psl_latest() this leads to .dat
> > being loaded which causes lot's of parse/conversion/malloc overhead.
> 
> whoops, thanks for catching this!
> 
> > There are two possible solutions:
> > 1. The .dafsa file should be older than the .dat file by at least 1s.
> > This makes sense since the .dafsa file is generated from .dat and thus
> > should be older.
> 
> as you said in your followup, the .dafsa should be *newer* than the
> .dat.  I'm trying to decide how to package this change most cleanly.
> 
> The timestamps for the installed files are "clamped" to the timestamp in
> the debian/changelog entry.  This is a relatively new change, in debian,
> the result of the reproducible-builds policy, which is the right one.
> 
> Since the build daemons are all going to do the build *after* the
> debian/changelog entry timestamp, just including a "sleep 1" before
> invoking psl-make-dafsa won't provide a fix.
> 
> > Also the .dat file should have the original timestamp from upstream.
> 
> What timestamp do you mean by this?  I don't think that the upstream
> development includes a specific timestamp aside from those found in the
> git commit history.  Do you mean that the .dat should have timestamp
> based on the git commit timestamp?  if so, which timestamp -- the author
> timestamp or the committer timestamp?  Given that i'm naming the
> upstream package version number based on the committer timestamp, that
> might be a reasonable way to choose the timestamp for the .dat file.
> 
> if we do that, then should we let the .dafsa receive the clamped timestamp
> of the debian/changelog?  or should we explicitly set the .dafsa to the
> .dat + 1 second?

Technically it doesn't matter as long as the .dafsa is at least 1s newer than 
the .dat. The timestamp of the latest commit/change would be fine, though.

Maybe this can be used by 'date' and/or 'touch' ?
git log -n 1 --pretty=format:%cd --date=iso public_suffix_list.dat


> > 2. Apply a 1-line patch to libpsl (already in upstream git repo) which
> > prefers the distribution (.dafsa) file.
> 
> I think this is worth applying anyway, since it's the right thing to
> do.  thanks!  I've cloned this bug report and reassigned the clone to
> libpsl to track that.



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

Bug#855699: Typo

[Tim Ruehsen]

...thus should be newer...



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

Bug#855699: publicsuffix: Libpsl loads wrong file due to file dates

[Tim Ruehsen]

Package: publicsuffix
Version: 20170202-1
Severity: normal

Dear Maintainer,

both, /usr/share/publicsuffix/public_suffix_list.dafsa and
/usr/share/publicsuffix/public_suffix_list.dat have the same file date (mtime).

Together with a small glitch in libpsl/psl_latest() this leads to .dat
being loaded which causes lot's of parse/conversion/malloc overhead.

There are two possible solutions:
1. The .dafsa file should be older than the .dat file by at least 1s.
This makes sense since the .dafsa file is generated from .dat and thus should
be older. Also the .dat file should have the original timestamp from upstream.

2. Apply a 1-line patch to libpsl (already in upstream git repo) which prefers
the distribution (.dafsa) file.

Regards, Tim Rühsen


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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#347573: [bug #20417] 503 respose is not retryable but should be

[Tim Ruehsen]

Update of bug #20417 (project wget):

  Status: Invalid => Fixed  
   Fixed Release:None => 1.19.1 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#852418: libpsl5 (runtime library) depends against -dev package

[Tim Ruehsen]

I am the package maintainer, but can't upload.
Does creating a new version (on collab-maint/libpsl) help, or should we wait 
until Daniel (uploader) is awake (maybe ~3-4 hours from now, but no promise).

Sorry, but I am somewhat inexperienced regarding this situation.

Regards, Tim

On Tuesday, January 24, 2017 11:14:47 AM CET Laurent Bigonville wrote:
> Package: libpsl5
> Version: 0.17.0-2
> Severity: serious
> 
> Hi,
> 
> Are there any reasons for the libpsl5 library package to depend against
> libidn2-0-dev and the libpsl-dev for not doing so?
> 
> This seems backward to me, the libidn2-0-dev dependency must be moved to
> the libpsl-dev package.
> 
> Regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)



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

Bug#851675: flex: Please update homepage in package description

[Tim Ruehsen]

Package: flex
Version: 2.6.1-1.3
Severity: normal

Dear Maintainer,

pleased update the upstream homepage in the package description.

The new homepage seems to be https://github.com/westes/flex.

Regards, Tim

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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.59
ii  dpkg   1.18.18
ii  install-info   6.3.0.dfsg.1-1+b1
ii  libc6  2.24-9
ii  m4 1.4.18-1

Versions of packages flex recommends:
ii  clang-3.6 [c-compiler]  1:3.6.2-4
ii  clang-3.7 [c-compiler]  1:3.7.1-3
ii  clang-3.8 [c-compiler]  1:3.8.1-17
ii  clang-3.9 [c-compiler]  1:3.9.1-3
ii  gcc [c-compiler]4:6.2.1-1
ii  gcc-4.4 [c-compiler]4.4.7-8
ii  gcc-4.5 [c-compiler]4.5.4-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.4-2
ii  gcc-5 [c-compiler]  5.4.1-4
ii  gcc-6 [c-compiler]  6.3.0-2
ii  libfl-dev   2.6.1-1.3
ii  tcc [c-compiler]0.9.27~git20161217.cd9514ab-3

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

-- debconf information excluded

Bug#839936: wget segfaults when ~/.wget-hsts is not writable

[Tim Ruehsen]

This has been fixed upstream by commit 40870e1271c977d9b80734690a5691a68bf05473

Regards, Tim


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

Bug#778277: wget memory leak

[Tim Ruehsen]

I can't reproduce this problem on current Debian unstable with wget 1.18-4.

BTW, since 1.13.4 we fixed several memory leaks in wget.

Regards, Tim


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

Bug#847958: curl: Please add PSL support in debian/control

[Tim Ruehsen]

Package: curl
Version: 7.51.0-1
Severity: wishlist

Dear Maintainer,

please add libpsl-dev to the appropriate 'build-depends' in debian/control.

That enables checking libcurl/curl against cross domain cookies.
Curl's build environment detects and enables the appropriate code
path if it finds libpsl being installed during configure time.

Regards, Tim

-- 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.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages curl depends on:
ii  libc62.24-8
ii  libcurl3-gnutls  7.51.0-1
ii  zlib1g   1:1.2.8.dfsg-4

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#846199: libunistring0: Please update to libunistring2, libunistring0 has bugs

[Tim Ruehsen]

Package: libunistring0
Version: 0.9.6+really0.9.3-0.1
Severity: important

Dear Maintainer,

please update to libunistring2.

1. There is no API for Unicode joining types in libunistring0, but in 
libunistring2.
   This API is needed for IDNA2008 processing done by libidn2.
   Currently, libidn2 carries it's own copy of gnulib's unicode code with all
   the disadvantages this has.

2. libunistring0 reports codepoint 0x1a66 as BIDI category 'L' which isn't 
correct.
   Libunistring2 correctly reports it as 'NSM'.
   This bug breaks the test suite of libidn2 when linking with libunistring.
   
Small C code to demonstrate 2.:
/* Info: http://www.fileformat.info/info/unicode/char/1a66/index.htm */
#include 
#include 
int main(void)
{
uint32_t cp = 0x1a66; /* TAI THAM VOWEL SIGN II */
int bc = uc_bidi_category (cp);
printf("0x%4X bidi category: %s\n", cp, uc_bidi_category_name(bc));
return 0;
}

Compile it with libunistring0 (from unstable)
  gcc x.c -o x -lunistring

Compile it with libunistring2 (from experimental)
  gcc x.c -o x /usr/lib/x86_64-linux-gnu/libunistring.so.2

Regards, Tim

-- 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.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libunistring0 depends on:
ii  libc6  2.24-7

libunistring0 recommends no packages.

libunistring0 suggests no packages.

-- no debconf information

Bug#842242: $LINENO needed for POSIX compliancy

[Tim Ruehsen]

I didn't check POSIX specs myself, but people say that $LINENO is needed for 
POSIX compliancy.

https://wiki.ubuntu.com/DashAsBinSh
says
"$LINENO

POSIX requires that conforming shells expand the special parameter $LINENO to 
the current line number in a script or function; dash does not yet support 
this feature. "

The last sentence holds not true (any more ?) - at least Debian switches 
$LINENO off by (unknown) purpose.


I built and installed dash from the 0.5.8-2.3 sources without --disable-
lineno. It doesn't like ':' as a do-nothing operator - this looks like a bug, 
but I couldn't find anything about it when searching the web.
I try to communicate with upstream to find out and report back.


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

Bug#842242: dash: Missing $LINENO support avoids using dash for autotools ./configure scripts

[Tim Ruehsen]

Package: dash
Version: 0.5.8-2.3
Severity: normal

Dear Maintainer,

autotools configure scripts always fall back to bash due to switched-off $LINENO
support. This makes running ./configure scripts much slower in comparison to
using dash.

I am aware of #766048, but the provided link is no longer available and thus it
is not possible to see why the build failed.
Maybe these 'several packages' needs to be fixed.

As developer who uses ./configure all day long, I am suffering from not being 
able to
use dash. AFAIK, other distros do not use --disable-lineno for packaging.

Regards, Tim

-- 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.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii  debianutils  4.8
ii  dpkg 1.18.10
ii  libc62.24-5

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#281201: [bug #45790] wget prints it's progress even when background

[Tim Ruehsen]

Update of bug #45790 (project wget):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#827452: dolphin Mouse wheel scrolling speed is now painfully slow

[Tim Ruehsen]

There are many upstream bug reports describing the same (yes, I have been 
struck as well).

People in https://bugs.kde.org/show_bug.cgi?id=355410
suggest to remove the x11 libinput driver and instead install the x11 evdev 
driver.

Here (Debian Sid), both packages were installed (xserver-xorg-input-libinput 
and xserver-xorg-input-evdev).

Removing the first and restarting KDE solved the problem for me.

$ sudo apt-get remove xserver-xorg-input-libinput

That also removes two or three other packages, so be careful.

The KDE people say, it's likely a QT5 bug... just a hint for the maintainer.


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

Bug#832528: Acknowledgement (akonadi-server: Latest akonadi packages do not kick out old package baloo-utils)

[Tim Ruehsen]

I just want to add that the KDE Crash Handler pops up with backtraces like 
these:

Application:  (akonadi_baloo_indexer), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f9e61e701c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#7  0x7f9e61e7164a in __GI_abort () at abort.c:89
#8  0x7f9e65a7ef15 in qt_message_output(QtMsgType, char const*) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x7f9e645a8267 in ?? () from /usr/lib/libakonadi-kde.so.4
#10 0x7f9e645a772a in ?? () from /usr/lib/libakonadi-kde.so.4
#11 0x7f9e65bb3d61 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#12 0x7f9e630b590c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x7f9e630bc846 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x7f9e63e363ba in KApplication::notify(QObject*, QEvent*) () from 
/usr/lib/libkdeui.so.5
#15 0x7f9e65b998fd in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x7f9e65b9d3b6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x7f9e65bca0a3 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#18 0x7f9e6153a1a7 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x7f9e6153a400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x7f9e6153a4ac in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x7f9e65bca1f4 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#22 0x7f9e6315f9d6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#23 0x7f9e65b9817f in 
QEventLoop::processEvents(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x7f9e65b984e5 in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#25 0x7f9e65b9e4a9 in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#26 0x7f9e645a49dd in Akonadi::AgentBase::init(Akonadi::AgentBase*) () from 
/usr/lib/libakonadi-kde.so.4
#27 0x0041137e in _start ()


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

Bug#832528: akonadi-server: Latest akonadi packages do not kick out old package baloo-utils

[Tim Ruehsen]

Package: akonadi-server
Version: 4:16.04.3-1
Severity: important

Dear Maintainer,

after installing the new 16.04 akonadi + kdepim stuff, I somehow
still had baloo-utils 4.14 installed which caused me (and others) some
headaches. Kmail indexing seems to be broken due to this - but I am still
investigating.

Relevant packages currently installed:

$ dpkg -l |egrep 'akonadi|baloo|kdepim'
ii  akonadi-backend-mysql 4:16.04.3-1   
all  MySQL storage backend for Akonadi
ii  akonadi-server4:16.04.3-1   
amd64Akonadi PIM storage service
ii  akonadiconsole4:16.04.3-1   
amd64management and debugging console for akonadi
ii  baloo 4:5.23.0-1
all  transitional package for baloo
ii  baloo-kf5 5.23.0-1  
amd64framework for searching and managing metadata
ii  baloo-utils   4:4.14.2-2
amd64utilities for Baloo
ii  kde-config-baloo-advanced 1.00.00-1 
amd64advanced configuration module for KDE Baloo Desktop Search
ii  kdepim4:16.04.3-1   
all  Personal Information Management apps from the official KDE 
release
ii  kdepim-addons 16.04.2-2 
amd64Addons for KDE PIM applications
ii  kdepim-doc4:16.04.3-1   
all  KDE Personal Information Management library documentation
ii  kdepim-runtime4:16.04.2-2   
amd64runtime components for Akonadi KDE
ii  kdepim-themeeditors   4:16.04.3-1   
amd64Theme Editors for KDE PIM applications
ii  kdepimlibs-data   4:16.04.2-2   
all  kdepimlibs - data files
ii  kdepimlibs-kio-plugins4:4.14.10-5   
amd64kio slaves used by KDE PIM applications
ii  kf5-kdepim-apps-libs-data 4:16.04.2-2   
all  KDE PIM mail related libraries, data files
ii  kf5-kdepimlibs-kio-plugins4:16.04.2-2   
amd64kio slaves used by KDE PIM applications
ii  libakonadi-contact4   4:4.14.10-5   
amd64Akonadi contacts access library
ii  libakonadi-kde4   4:4.14.10-5   
amd64library for using the Akonadi PIM data server
ii  libakonadi-kmime4 4:4.14.10-5   
amd64Akonadi MIME handling library
ii  libakonadiprotocolinternals1  1.13.0-10 
amd64libraries for the Akonadi PIM storage service
ii  libbaloocore4 4:4.14.2-2
amd64core functionality for Baloo
ii  libbaloofiles44:4.14.2-2
amd64files functionality for Baloo
ii  libbalooxapian4   4:4.14.2-2
amd64Xapian functionality for Baloo
ii  libkf5akonadiagentbase5:amd64 4:16.04.3-1   
amd64Akonadi agent base library
ii  libkf5akonadicalendar5:amd64  16.04.2-2 
amd64library providing calendar helpers for Akonadi items
ii  libkf5akonadicontact5:amd64   4:16.04.2-2   
amd64Akonadi contacts access library  
ii  libkf5akonadicore-bin 4:16.04.3-1   
amd64Tools for Akonadi core library   
ii  libkf5akonadicore5:amd64  4:16.04.3-1   
amd64Akonadi core library 
ii  libkf5akonadimime5:amd64  4:16.04.2-2   
amd64Akonadi MIME handling library
ii  libkf5akonadinotes5:amd64 4:16.04.2-2   
amd64Akonadi notes access library
ii  libkf5akonadiprivate5 4:16.04.3-1   
amd64libraries for the Akonadi PIM storage service
ii  libkf5akonadisearch-bin   16.04.2-2 
amd64Akonadi search library - runtime binaries
ii  libkf5akonadisearch-data  16.04.2-2   

Bug#830119: akonadi-server: Akonadi fails to start after upgrade

[Tim Ruehsen]

Package: akonadi-server
Version: 4:16.04.2-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading this morning, Kmail shows an empty window while being busy with 
something.

$ akonadictl restart
...
ProcessControl: Application '/usr/bin/akonadi_agent_launcher' returned with 
exit code 1 (Unknown error)
...
"/usr/bin/akonadi_agent_launcher" crashed too often and will not be restarted!

Since Kmail is my main application for communication, this bug renders my 
machine
unusable (resp. unproductive).

Here comes a bit more from akonadictl output:
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
akonadiprivate_log: search paths:  ("/usr/oms/util", "/usr/oms/bin", 
"/usr/oms/node_modules/.bin", "/usr/oms/util", "/usr/oms/util", "/usr/oms/bin", 
"/usr/oms/node_modules/.bin", "/usr/local/bin", "/usr/bin", "/bin", 
"/usr/local/games", "/usr/games", "/usr/sbin", "/usr/local/sbin", 
"/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", 
"/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
Found mysql_install_db:  "/usr/bin/mysql_install_db"
Found mysqlcheck:  "/usr/bin/mysqlcheck"
Using mysqld: "/usr/sbin/mysqld"
mysqld reports version 5.6.30 (Oracle MySQL)
Executing: "/usr/sbin/mysqld" 
"--defaults-file=/usr/oms/.local/share/akonadi/mysql.conf 
--datadir=/usr/oms/.local/share/akonadi/db_data/ 
--socket=/tmp/akonadi-oms.aOT7Wn/mysql.socket"
Executing:  "/usr/bin/mysqlcheck" 
"--defaults-file=/usr/oms/.local/share/akonadi/mysql.conf --check-upgrade 
--auto-repair --socket=/tmp/akonadi-oms.aOT7Wn/mysql.socket akonadi"
akonadi.collectionattributetable   OK
akonadi.collectionmimetyperelation OK
akonadi.collectionpimitemrelation  OK
akonadi.collectiontableOK
akonadi.flagtable  OK
akonadi.mimetypetable  OK
akonadi.parttable  OK
akonadi.parttypetable  OK
akonadi.pimitemflagrelationOK
akonadi.pimitemtable   OK
akonadi.pimitemtagrelation OK
akonadi.relationtable  OK
akonadi.relationtypetable  OK
akonadi.resourcetable  OK
akonadi.schemaversiontable OK
akonadi.tagattributetable  OK
akonadi.tagremoteidresourcerelationtable   OK
akonadi.tagtable   OK
akonadi.tagtypetable   OK
MySQL version OK (required "5.1" , available "5.6" )
Database "akonadi" opened using driver "QMYSQL"
DbInitializer::run()
checking table  "SchemaVersionTable"
checking table  "ResourceTable"
checking table  "CollectionTable"
checking table  "MimeTypeTable"
checking table  "PimItemTable"
checking table  "FlagTable"
checking table  "PartTypeTable"
checking table  "PartTable"
checking table  "CollectionAttributeTable"
checking table  "TagTypeTable"
checking table  "TagTable"
checking table  "TagAttributeTable"
checking table  "TagRemoteIdResourceRelationTable"
checking table  "RelationTypeTable"
checking table  "RelationTable"
checking table  "PimItemFlagRelation"
checking table  "PimItemTagRelation"
checking table  "CollectionMimeTypeRelation"
checking table  "CollectionPimItemRelation"
DbInitializer::run() done
skipping update 2
skipping update 3
skipping update 4
skipping update 8
skipping update 10
skipping update 12
skipping update 13
skipping update 14
skipping update 15
skipping update 16
skipping update 17
skipping update 18
skipping update 19
skipping update 20
skipping update 21
skipping update 22
skipping update 23
skipping update 24
skipping update 25
skipping update 26
skipping update 28
skipping update 30
skipping update 31
Indexes successfully created
akonadiprivate_log: search paths:  ("lib/x86_64-linux-gnu", 
"lib/x86_64-linux-gnu/qt5/plugins/", "lib/x86_64-linux-gnu/kf5/", 
"lib/x86_64-linux-gnu/kf5/plugins/", "/usr/lib/qt5/plugins/", 
"/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin")
SEARCH MANAGER: searching in  "lib/x86_64-linux-gnu/akonadi" : ()
SEARCH MANAGER: searching in  "lib/x86_64-linux-gnu/qt5/plugins//akonadi" : ()
SEARCH MANAGER: searching in  "lib/x86_64-linux-gnu/kf5//akonadi" : ()
SEARCH MANAGER: searching in  "lib/x86_64-linux-gnu/kf5/plugins//akonadi" : ()
SEARCH MANAGER: searching in  "/usr/lib/qt5/plugins//akonadi" : ()
SEARCH MANAGER: searching in  "/usr/lib/x86_64-linux-gnu/qt5/plugins/akonadi" : 
()
SEARCH MANAGER: searching in  "/usr/bin/akonadi" : ()
Search loop is waiting, will wake again in -1 ms
Database "akonadi" opened using driver "QMYSQL"
Database "akonadi" opened using driver "QMYSQL"
DataStore::unhideAllPimItems()
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
PLUGINS:  "/usr/share/akonadi/agents"

Bug#800588: Problem solved for me

[Tim Ruehsen]

There was a file /etc/mysql/my.cnf.migrated containing this text:

# This file has been automatically moved from your previous
# /etc/mysql/my.cnf, with just this comment added at the top, to maintain 
MySQL
# operation using your previously customised configuration.

# To switch to the new packaging configuration for automated management of
# /etc/mysql/my.cnf across multiple variants:
#
# 1. Move your customisations from this file to /etc/mysql/conf.d/ and
#to /etc/mysql/.conf.d/ as appropriate.
# 2. Run "update-alternatives --remove my.cnf /etc/mysql/my.cnf.migrated"
# 3. Remove the file /etc/mysql/my.cnf.migrated


After
/etc/mysql# update-alternatives --remove my.cnf /etc/mysql/my.cnf.migrated

starting and stopping now works within seconds.

Please excuse my verbosity in the previous mails.

Best Regards

Tim Rühsen


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

Bug#800588: Failure due to aged mysql installation ?

[Tim Ruehsen]

After looking closer to the journalctl output, I saw
Jun 07 10:48:41 blitz-lx mysqld_safe[1877]: Could not open required defaults 
file: /etc/mysql/debian.cnf
Jun 07 10:48:41 blitz-lx mysqld_safe[1877]: Fatal error in defaults handling. 
Program aborted

# l /etc/mysql/debian.cnf
-rw--- 1 root root 317 May 11  2006 /etc/mysql/debian.cnf

Since this file has been automatically generated, I assume that at some time 
the required permissions changed !? But on a pretty fresh Debian stable, the 
file has the same perms. Maybe groups involved or capabilities missing 
somewhere ?

Best Regards

Tim Rühsen

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

Bug#800588: Same problem here since a long time...

[Tim Ruehsen]

I have the same problem on Debian SID (amd64) - daily updated - since a long 
time. It only came up here on Reboot / Powerdown, but I wasn't aware it was 
'mysqld'. Until the last systemd update... now it shows what it is waiting 
for: (10min timeout on mysqld).

I just did a
# /etc/init.d/mysqld restart
[] Restarting mysql (via systemctl): mysql.service
(Now waiting since a few minutes)

On a second console:
# systemctl status mysql.service
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: 
enabled)
   Active: deactivating (stop-sigterm) since Tue 2016-06-07 10:48:41 CEST; 16s 
ago
  Process: 1880 ExecStartPost=/usr/share/mysql/mysql-systemd-start post 
(code=exited, status=0/SUCCESS)
  Process: 1823 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre 
(code=exited, status=0/SUCCESS)
 Main PID: 1877 (mysqld_safe)
   CGroup: /system.slice/mysql.service
   ├─1877 /bin/sh /usr/bin/mysqld_safe
   ├─5176 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --
plugin-dir=/usr/lib/mysql/plugin --pid-file=/var/run/mysqld/mysqld.p
   └─5177 logger -t mysqld -p daemon error

Jun 07 10:48:42 blitz-lx mysqld[5177]: InnoDB: Last MySQL binlog file position 
0 11039, file name /var/log/mysql/mysql-bin.000539
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] InnoDB: 
128 rollback segment(s) are active.
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] InnoDB: 
Waiting for purge to start
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] InnoDB: 
5.6.30 started; log sequence number 5885519596
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] Server 
hostname (bind-address): '127.0.0.1'; port: 3306
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note]   - 
'127.0.0.1' resolves to '127.0.0.1';
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] Server 
socket created on IP: '127.0.0.1'.
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] Event 
Scheduler: Loaded 0 events
Jun 07 10:48:42 blitz-lx mysqld[5177]: 2016-06-07 10:48:42 5176 [Note] 
/usr/sbin/mysqld: ready for connections.
Jun 07 10:48:42 blitz-lx mysqld[5177]: Version: '5.6.30-1'  socket: 
'/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)


# journalctl -u mysql.service
-- Logs begin at Tue 2016-06-07 10:41:14 CEST, end at Tue 2016-06-07 10:48:42 
CEST. --
Jun 07 10:41:19 blitz-lx systemd[1]: Starting MySQL Community Server...
Jun 07 10:41:19 blitz-lx mysqld_safe[1877]: 160607 10:41:19 mysqld_safe 
Logging to syslog.
Jun 07 10:41:20 blitz-lx mysqld_safe[1877]: 160607 10:41:20 mysqld_safe 
Starting mysqld daemon with databases from /var/lib/mysql
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 0 [Warning] The 
syntax 'pre-4.1 password hash' is deprecated and will be removed in a 
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 0 [Warning] Using 
unique option prefix key_buffer instead of key_buffer_size is deprec
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 0 [Warning] options 
--log-slow-admin-statements, --log-queries-not-using-indexes and -
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 0 [Warning] 
TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 0 [Note] 
/usr/sbin/mysqld (mysqld 5.6.30-1) starting as process 2439 ...
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Warning] 
Buffered warning: Changed limits: max_open_files: 1024 (requested 5000)
Jun 07 10:41:20 blitz-lx mysqld[2440]: 
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Warning] 
Buffered warning: Changed limits: table_open_cache: 431 (requested 2000
Jun 07 10:41:20 blitz-lx mysqld[2440]: 
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Warning] 
Using unique option prefix myisam-recover instead of myisam-recover-opt
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Note] Plugin 
'FEDERATED' is disabled.
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [ERROR] 
Function 'innodb' already exists
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Warning] 
Couldn't load plugin named 'innodb' with soname 'ha_innodb.so'.
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [ERROR] 
Function 'federated' already exists
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Warning] 
Couldn't load plugin named 'federated' with soname 'ha_federated.so'.
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [ERROR] 
Function 'blackhole' already exists
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [Warning] 
Couldn't load plugin named 'blackhole' with soname 'ha_blackhole.so'.
Jun 07 10:41:20 blitz-lx mysqld[2440]: 2016-06-07 10:41:20 2439 [ERROR] 
Function 'archive' already exists
Jun 07 10:41:20 

Bug#824743: hfsplus: Lower/Uppercase issue, remembering casing after removal

[Tim Ruehsen]

Package: hfsplus
Version: 1.0.4-13
Severity: normal

Dear Maintainer,

in freshly created directory on a HFS+ mount, I experience the following:

$ mkdir xxx && cd xxx
$ touch DUMMY.TXT
$ ls
DUMMY.TXT
$ rm DUMMY.TXT
$ touch dummy.txt
$ ls
DUMMY.TXT

This should be dummy.txt, looks like HFS+ 'remembers' old casing.
Now the other way round:

$ cd ..
$ rm -rf xxx
$ mkdir xxx && cd xxx
$ touch dummy.txt
$ ls
dummy.txt
$ rm dummy.txt
$ touch DUMMY.TXT
$ ls
dummy.txt

This issue disturbs a test suite here (Wget2 development, testing 
uppercase/lowercase stuff).
I could work around it by re-creating a new temp directory for each test, but
I find this HFS+ behaviour somewhat unexpected.

How I created my HFS+ mount:
$ sudo apt-get install hfsprogs
$ dd if=/dev/zero of=hfsimage bs=512 count=500k
$ sudo losetup /dev/loop0 hfsimage
$ sudo mkfs -t hfsplus /dev/loop0
$ sudo mount -t hfsplus /dev/loop0 /mnt
$ cd /mnt
$ sudo mkdir test
$ sudo chown tim:users test
$ cd test

(amend 'tim:users' to your environment)

Regards, Tim

-- 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.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hfsplus depends on:
ii  libc6 2.22-9
ii  libhfsp0  1.0.4-13

hfsplus recommends no packages.

hfsplus suggests no packages.

-- no debconf information

Bug#803212: qt5x11extras at fault

[Tim Ruehsen]

On Wed, 23 Mar 2016 15:28:24 +0100 Tim Ruehsen <tim.rueh...@gmx.de> wrote:
> How did you do that ?
> 
> 5.4.2-2+b1 seems not to be available on 
> ftp://ftp.debian.org/debian/pool/main/q/qtx11extras-opensource-src/
> 
> Even 5.5.3-1 is from 28.10.2015... so 5.4.2 has been removed from 
> /var/cache/apt/archives/ for a long time now.
> 
> I am a bit clueless right now. And I badly want Kate.

Sorry, forget it. Wrong bug.
Have to open a new one...

Tim


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

Bug#803212: qt5x11extras at fault

[Tim Ruehsen]

On Wed, 28 Oct 2015 19:02:31 -0700 Kyanos  wrote:
> On Wed, Oct 28, 2015 at 10:03 AM, Gregor Riepl  wrote:
> > It looks like downgrading qt5x11extras as described in #802811 fixed the 
crash
> > for all affected KDE applications in my case.
> >
> > If Kyanos confirms, I think this bug can be closed.
> >
> > --
> > To unsubscribe, send mail to 803212-unsubscr...@bugs.debian.org.
> 
> Yes, I can confirm: Downgrading libqt5x11extras5 to 5.4.2-2+b1 fixes the 
issue.

How did you do that ?

5.4.2-2+b1 seems not to be available on 
ftp://ftp.debian.org/debian/pool/main/q/qtx11extras-opensource-src/

Even 5.5.3-1 is from 28.10.2015... so 5.4.2 has been removed from 
/var/cache/apt/archives/ for a long time now.

I am a bit clueless right now. And I badly want Kate.

Regards, Tim


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

Bug#818178: libc6: getaddrinfo/freeadrinfo memory leak

[Tim Ruehsen]

Package: libc6
Severity: important

Dear Maintainer,

getaddrinfo/freeaddrinfo seems to have a memory leak.

Testcode:
#include 
#include 
#include 
#include 
#include 

int main(void)
{
struct addrinfo *addrinfo, hints;

memset(, 0 ,sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_NUMERICSERV | AI_ADDRCONFIG;

int rc;
if ((rc = getaddrinfo("localhost", "80", , )) == 0) {
freeaddrinfo(addrinfo);
}
printf("rc=%d\n", rc);

return 0;
}

Valgrind throws out:
==10088== HEAP SUMMARY:
==10088== in use at exit: 28 bytes in 1 blocks
==10088==   total heap usage: 45 allocs, 44 frees, 7,337 bytes allocated
==10088== 
==10088== 28 bytes in 1 blocks are still reachable in loss record 1 of 1
==10088==at 0x4C29C0F: malloc (vg_replace_malloc.c:299)
==10088==by 0x4F3BA64: __res_vinit (in /lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x4F3D17C: __res_maybe_init (in 
/lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x4F09A26: gaih_inet (in /lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x4F0BD0D: getaddrinfo (in /lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x400625: main (in /usr/oms/src/wget2/examples/x)
==10088== 
==10088== LEAK SUMMARY:
==10088==definitely lost: 0 bytes in 0 blocks
==10088==indirectly lost: 0 bytes in 0 blocks
==10088==  possibly lost: 0 bytes in 0 blocks
==10088==still reachable: 28 bytes in 1 blocks
==10088== suppressed: 0 bytes in 0 blocks

Currently a test suite here fails due to this leak.
When setting 'addrinfo' to NULL after freeaddrinfo(), valgrind reports the leak 
as
'definitely lost' and returns with non-zero, thus the breakage of the test 
suite.

Regards, Tim


-- 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.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#387745: [bug #45778] wget and unicode

[Tim Ruehsen]

Update of bug #45778 (project wget):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
 Release:None => trunk  

___

Follow-up Comment #1:

Meanwhile this has been fixed.
I think it is commit c190677cab59c51f575f661b065db0fe14ab129d.

$ src/wget -nv "http://zh.wikipedia.org/wiki/$f;
2016-02-04 20:56:30 URL:http://zh.wikipedia.org/wiki/%E9%A6%96%E9%A1%B5
[38361] -> "首页" [1]


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#660932: [bug #45791] Double quote in (some) wget's international output for downloaded filename

[Tim Ruehsen]

Follow-up Comment #1, bug #45791 (project wget):

Works mostly correct here with de_DE.utf8.

2016-02-04 21:09:34 (233 KB/s) - »index.html.5« gespeichert [181451]

But at least this translation is still not fixed:

Wird in »»index.html.5«« gespeichert.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#757327: systemtap-common: Installing systemtap-common emits an error (but does not fail)

[Tim Ruehsen]

Package: systemtap-common
Version: 2.9-3
Followup-For: Bug #757327

Dear Maintainer,

this annoying error message still exists.


-- 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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

systemtap-common depends on no packages.

Versions of packages systemtap-common recommends:
ii  systemtap  2.9-3

systemtap-common suggests no packages.

-- no debconf information

Bug#763028: Some more tests

[Tim Ruehsen]

Just a few tests that I made:

1. Since I read about problems regarding remote filesystems, I commented all 
these in /etc/fstab. It made not difference (after restarting the machine) 
regarding the described issue.

2. I could 'init 1' from a text console (ctrl-alt-f1). But after entering root 
pw and # reboot I got the same problem as before.

3. From a text console (ctrl-alt-f1), I tried to stop kdm (/etc/init.d/kdm 
stop)... huh !? Same problem (not sure how/why 'init 1' worked in 2.).

4. Now I changed to sddm... Heyho, 'Shutdown' from the menu works. But 
'Reboot' still has the old problem (black screen, blinking cursor in top left 
corner).

BTW, I have a i915 gfx driver running.

Meanwhile it seems to be more than one problem here.

I want to state that my biggest concern is that systemd stops working without 
a timeout. I could see no evidence of a kernel crash (which would be an excuse 
for systemd to stop working).


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

Bug#763028: systemd-sysv shutdown and reboot hang system

[Tim Ruehsen]

Hi,

just want to state that I am struck by this bug for a while now.
Just started today searching for a solution.

On Wed, 1 Apr 2015 11:10:21 +0200 Martin Pitt  wrote:
> Yesterday we found quite a fundamental flaw related to how D-Bus is
> stopped during shutdown [1]. It might be worth a try to edit
> /lib/systemd/system/dbus.service and append these two lines to the
> [Service] section:
> 
>   ExecStop=/bin/true
>   KillMode=none
> 
> Then run "systemctl daemon-reload" as root. Does this improve shutdown
> for any of you?

No change in behavior at all.

> Note that this is certainly not a magic bullet for all kinds of
> shutdown problems, especially since the reports/data here is vague
> enough that these might very well be different reasons. But it would
> be interesting to see if it makes a difference for any of you. The
> Ubuntu bug https://launchpad.net/bugs/1427672 was linked to this
> Debian one and found to be fixed with the above D-Bus change.

Hmm, from my reading they say (in the end) "Don't do that !".
But however, it didn't solve anything here, so I removed the two lines.

I waited for a timeout a complete night, nothing happened. I have to tip the 
reset (hardware) button or press the poweroff knob for 5s.

What works is ALT + PrintScreen + REISUB.

But still my filesystems (several VMs running) are broken from time to time 
(e.g. one of the ReiserFS VMs needs a fsck.reiserfs --rebuild-tree, else it 
denies booting).

I have Samba installed (but can't uninstall it for testing), no squid 
installed.

I am on Debian SID amd64 (up-to-date packages).

What exactly can I do to help fixing this bug ?


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

Bug#744170: [bug #45792] wget: Read error in TLS connection with openssl s_server -www server

[Tim Ruehsen]

Update of bug #45792 (project wget):

  Status:None => Invalid
 Open/Closed:Open => Closed 
 Reproducibility:None => Every Time 

___

Follow-up Comment #1:

Reproducable with (from wget source directory):
$ cd tests/certs
$ openssl s_server -CAfile x509-ca-cert.pem -key x509-server-key.pem -cert
x509-server-cert.pem -www

>From another console:
$ wget --ca-certificate tests/certs/x509-ca-cert.pem -O out.html
https://localhost:4433
...
Read error at byte 6701 (The TLS connection was non-properly terminated.)
...

BTW, out.html is complete

Looking at the debug output reveals that the server response does not send a
Content-Length header line. So the client does not know that the data is
complete and leaves the connection open, waiting for more data to come or for
the server to close the connection. Here we see the server closing the
connection improperly which is interpreted as an error by Wget. And thus the
retries.

Curl has the same problem, saying "The TLS connection was non-properly
terminated" and returning with $? 56. Regarding the curl man page this is
"Failure in receiving network data.".

This bug either has to be fixed in 'openssl s_server' (or in GnuTLS if and
only if this is a misinterpretation of TLS standards by GnuTLS).


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#479589: [bug #33824] support file:/// URLs

[Tim Ruehsen]

Update of bug #33824 (project wget):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#805284: gnome-color-manager: Should not depend on GnuTLS

[Tim Ruehsen]

Package: gnome-color-manager
Version: 3.18.0
Severity: minor

Dear Maintainer,

this package depends on libgnutls-deb0-28 (>= 3.3.0), but I can't see any
hint in the sources why it should.

-- 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.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

[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#800698: Kmail2 display garbled (after a while)

[Tim Ruehsen]

Hi Boris,

I didn't have that issue any more since a few days.

Kmail is pretty much in use each day and when I had this issue, I had it 
several times a day (reboot, kdm stop/start, kmail stop/start didn't help 
much).

As soon as the problem pops up again, I'll come back here.

Thanks for having a look !

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#798924: /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.6.0.0: SIGSEGV on Netbeans startup

[Tim Ruehsen]

> Alexandre Pereira Nunes, le Wed 07 Oct 2015 15:04:36 -0300, a écrit :
> > I'm attaching an additional patch that complements the old netbeans one.
> > With this, I can now open netbeans.
> 
> Thanks!  I have uploaded it in 0.33.3-2.  Tim, Michael, could you try
> it?

I uncommented the Atk lines in /etc/java-7-openjdk/accessibility.properties 
and /etc/java-8-openjdk/accessibility.properties and restarted Netbeans.

Just a quick test but problems so far.

ii  libatk-wrapper-java 0.33.3-3 all  
ATK implementation for Java using JNI
ii  libatk-wrapper-java-jni:amd64   0.33.3-3 amd64
ATK implementation for Java using JNI (JNI bindings)

Thanks for fixing.

Tim

Bug#797057: [PATCH] [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Tim Ruehsen]

On Monday 28 September 2015 16:05:39 Giuseppe Scrivano wrote:
> Tim Ruehsen <tim.rueh...@gmx.de> writes:
> > wgnutls_write is called without timeout. So, what can we do here ?
> > 
> > But maybe we don't have to check for GNUTLS_E_REHANDSHAKE at this point at
> > all. Regarding
> > http://www.gnutls.org/manual/html_node/Re_002dauthentication.html, only
> > gnutls_record_recv() returns GNUTLS_E_REHANDSHAKE.
> > 
> > If you don't mind, I'll remove the rehandshake code from wgnutls_write().
> 
> yes, if it cannot return that error code, please drop the code that
> checks for it.

At least it is not explicitly documented. I removed the code from 
wgnutls_write() and pushed the patch.

Regards, Tim

Bug#797057: [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Tim Ruehsen]

Update of bug #46061 (project wget):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#797057: [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Tim Ruehsen]

Follow-up Comment #4, bug #46061 (project wget):

Sorry, my patch didn't make it to the bug tracker nor to the mailing list nor
to you !? Interesting, I saw it pop up on the Debian bug tracker (and I got an
automatic reply from there).
I attach it here for comparison with your patch.


(file #35003)
___

Additional Item Attachment:

File name: 0001-Handle-TLS-rehandshakes-in-GnuTLS-code.patch Size:6 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#797057: [PATCH] [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Tim Ruehsen]

Please review / test this patch.

BTW, I am not sure if contributors.debian.org is configured correctly.
The rehandshake occurs right after the HTTP request and it has a pretty heavy  
impact on download duration.

Regards, Tim

On Sunday 27 September 2015 20:03:54 Tim Ruehsen wrote:
> Follow-up Comment #2, bug #46061 (project wget):
> 
> Wget is not reacting on GNUTLS_E_REHANDSHAKE. Should be straight forward...
> 
> 
> ___
> 
> Reply to this item at:
> 
>   <http://savannah.gnu.org/bugs/?46061>
> 
> ___
>   Nachricht gesendet von/durch Savannah
>   http://savannah.gnu.org/
>From cbec5b0c780f9d1fc343fabf22e8ee7c7cb3222d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim=20R=C3=BChsen?= <tim.rueh...@gmx.de>
Date: Mon, 28 Sep 2015 12:00:33 +0200
Subject: [PATCH] Handle TLS rehandshakes in GnuTLS code

* src/gnutls.c: New static function _do_handshake()
* src/gnutls.c (wgnutls_read_timeout): Handle rehandshake
* src/gnutls.c (wgnutls_write): Handle rehandshake
* src/gnutls.c (ssl_connect_wget): Move handshake code into _do_handshake()

Fixes #46061
---
 src/gnutls.c | 179 ++-
 1 file changed, 102 insertions(+), 77 deletions(-)

diff --git a/src/gnutls.c b/src/gnutls.c
index a38301a..2f53592 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -57,6 +57,9 @@ as that of the covered work.  */
 #include "host.h"
 
 static int
+_do_handshake(gnutls_session_t session, int fd, double timeout);
+
+static int
 key_type_to_gnutls_type (enum keyfile_type type)
 {
   switch (type)
@@ -277,6 +280,12 @@ wgnutls_read_timeout (int fd, char *buf, int bufsize, void *arg, double timeout)
 {
   ret = gnutls_record_recv (ctx->session, buf, bufsize);
   timed_out = timeout && ptimer_measure (timer) >= timeout;
+  if (!timed_out && ret == GNUTLS_E_REHANDSHAKE)
+{
+  DEBUGP (("GnuTLS: *** REHANDSHAKE while reading\n"));
+  if ((ret = _do_handshake(ctx->session, fd, timeout)) == 0)
+ret = GNUTLS_E_AGAIN; /* restart reading */
+}
 }
 }
   while (ret == GNUTLS_E_INTERRUPTED || (ret == GNUTLS_E_AGAIN && !timed_out));
@@ -332,7 +341,15 @@ wgnutls_write (int fd _GL_UNUSED, char *buf, int bufsize, void *arg)
   int ret;
   struct wgnutls_transport_context *ctx = arg;
   do
-ret = gnutls_record_send (ctx->session, buf, bufsize);
+{
+  ret = gnutls_record_send (ctx->session, buf, bufsize);
+  if (ret == GNUTLS_E_REHANDSHAKE)
+{
+  DEBUGP (("GnuTLS: *** REHANDSHAKE while writing\n"));
+  if ((ret = _do_handshake(ctx->session, fd, 0)) == 0)
+ret = GNUTLS_E_AGAIN; /* restart writing */
+}
+}
   while (ret == GNUTLS_E_INTERRUPTED || ret == GNUTLS_E_AGAIN);
   if (ret < 0)
 ctx->last_error = ret;
@@ -425,16 +442,96 @@ static struct transport_implementation wgnutls_transport =
   wgnutls_peek, wgnutls_errstr, wgnutls_close
 };
 
-bool
-ssl_connect_wget (int fd, const char *hostname, int *continue_session)
+static int
+_do_handshake(gnutls_session_t session, int fd, double timeout)
 {
 #ifdef F_GETFL
   int flags = 0;
 #endif
+  int err;
+
+  if (timeout)
+{
+#ifdef F_GETFL
+  flags = fcntl (fd, F_GETFL, 0);
+  if (flags < 0)
+return flags;
+  if (fcntl (fd, F_SETFL, flags | O_NONBLOCK))
+return -1;
+#else
+  /* XXX: Assume it was blocking before.  */
+  const int one = 1;
+  if (ioctl (fd, FIONBIO, ) < 0)
+return -1;
+#endif
+}
+
+  /* We don't stop the handshake process for non-fatal errors */
+  do
+{
+  err = gnutls_handshake (session);
+
+  if (timeout && err == GNUTLS_E_AGAIN)
+{
+  if (gnutls_record_get_direction (session))
+{
+  /* wait for writeability */
+  err = select_fd (fd, timeout, WAIT_FOR_WRITE);
+}
+  else
+{
+  /* wait for readability */
+  err = select_fd (fd, timeout, WAIT_FOR_READ);
+}
+
+  if (err <= 0)
+{
+  if (err == 0)
+{
+  errno = ETIMEDOUT;
+  err = -1;
+}
+  break;
+}
+
+   err = GNUTLS_E_AGAIN;
+}
+  else if (err < 0)
+{
+  logprintf (LOG_NOTQUIET, "GnuTLS: %s\n", gnutls_strerror (err));
+  if (err == GNUTLS_E_WARNING_ALERT_RECEIVED ||
+  err == GNUTLS_E_FATAL_ALERT_RECEIVED)
+{
+  gnutls_alert_description_t alert = gnutls_alert_get (session);
+  const char *str = gnutls_alert_get_name (alert);
+  logprintf (LOG_NOTQUIET, "G

Bug#797057: [PATCH] [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Tim Ruehsen]

On Monday 28 September 2015 15:30:33 Giuseppe Scrivano wrote:
> Tim Ruehsen <tim.rueh...@gmx.de> writes:
> > Please review / test this patch.
> > 
> > BTW, I am not sure if contributors.debian.org is configured correctly.
> > The rehandshake occurs right after the HTTP request and it has a pretty
> > heavy impact on download duration.
> > 
> > Regards, Tim
> > 
> > On Sunday 27 September 2015 20:03:54 Tim Ruehsen wrote:
> >> Follow-up Comment #2, bug #46061 (project wget):
> >> 
> >> Wget is not reacting on GNUTLS_E_REHANDSHAKE. Should be straight
> >> forward...
> >> 
> >> ___
> >> 
> >> Reply to this item at:
> >>   <http://savannah.gnu.org/bugs/?46061>
> >> 
> >> ___
> >> 
> >>   Nachricht gesendet von/durch Savannah
> >>   http://savannah.gnu.org/
> > 
> > From cbec5b0c780f9d1fc343fabf22e8ee7c7cb3222d Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Tim=20R=C3=BChsen?= <tim.rueh...@gmx.de>
> > Date: Mon, 28 Sep 2015 12:00:33 +0200
> > Subject: [PATCH] Handle TLS rehandshakes in GnuTLS code
> > 
> > * src/gnutls.c: New static function _do_handshake()
> > * src/gnutls.c (wgnutls_read_timeout): Handle rehandshake
> > * src/gnutls.c (wgnutls_write): Handle rehandshake
> > * src/gnutls.c (ssl_connect_wget): Move handshake code into
> > _do_handshake()
> > 
> > Fixes #46061
> > ---
> > 
> >  src/gnutls.c | 179
> >  ++- 1 file
> >  changed, 102 insertions(+), 77 deletions(-)
> > 
> > diff --git a/src/gnutls.c b/src/gnutls.c
> > index a38301a..2f53592 100644
> > --- a/src/gnutls.c
> > +++ b/src/gnutls.c
> > @@ -57,6 +57,9 @@ as that of the covered work.  */
> > 
> >  #include "host.h"
> >  
> >  static int
> > 
> > +_do_handshake(gnutls_session_t session, int fd, double timeout);
> > +
> > +static int
> > 
> >  key_type_to_gnutls_type (enum keyfile_type type)
> >  {
> >  
> >switch (type)
> > 
> > @@ -277,6 +280,12 @@ wgnutls_read_timeout (int fd, char *buf, int bufsize,
> > void *arg, double timeout)> 
> >  {
> >  
> >ret = gnutls_record_recv (ctx->session, buf, bufsize);
> >timed_out = timeout && ptimer_measure (timer) >= timeout;
> > 
> > +  if (!timed_out && ret == GNUTLS_E_REHANDSHAKE)
> > +{
> > +  DEBUGP (("GnuTLS: *** REHANDSHAKE while reading\n"));
> > +  if ((ret = _do_handshake(ctx->session, fd, timeout)) == 0)
> > +ret = GNUTLS_E_AGAIN; /* restart reading */
> > +}
> > 
> >  }
> >  
> >  }
> >
> >while (ret == GNUTLS_E_INTERRUPTED || (ret == GNUTLS_E_AGAIN &&
> >!timed_out));> 
> > @@ -332,7 +341,15 @@ wgnutls_write (int fd _GL_UNUSED, char *buf, int
> > bufsize, void *arg)> 
> >int ret;
> >struct wgnutls_transport_context *ctx = arg;
> >do
> > 
> > -ret = gnutls_record_send (ctx->session, buf, bufsize);
> > +{
> > +  ret = gnutls_record_send (ctx->session, buf, bufsize);
> > +  if (ret == GNUTLS_E_REHANDSHAKE)
> > +{
> > +  DEBUGP (("GnuTLS: *** REHANDSHAKE while writing\n"));
> > +  if ((ret = _do_handshake(ctx->session, fd, 0)) == 0)
> 
> one thing: timeout here should be the remaining time instead of 0?

wgnutls_write is called without timeout. So, what can we do here ?

But maybe we don't have to check for GNUTLS_E_REHANDSHAKE at this point at 
all. Regarding 
http://www.gnutls.org/manual/html_node/Re_002dauthentication.html, only 
gnutls_record_recv() returns GNUTLS_E_REHANDSHAKE.

If you don't mind, I'll remove the rehandshake code from wgnutls_write().

Tim

Bug#797057: [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Tim Ruehsen]

Follow-up Comment #2, bug #46061 (project wget):

Wget is not reacting on GNUTLS_E_REHANDSHAKE. Should be straight forward...


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

Bug#798924: /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.6.0.0: SIGSEGV on Netbeans startup

[Tim Ruehsen]

On Monday 14 September 2015 11:11:39 Samuel Thibault wrote:
> Hello,
> 
> Tim Ruehsen, le Mon 14 Sep 2015 10:03:57 +0200, a écrit :
> > the latest version makes Netbeans (8.0.2 and 8.1beta) SIGSEGV on startup.
> > Tested with Debian OpenJDK 7 and 8.
> 
> I'm not getting a crash on my box.  Are you perhaps using e.g. a
> different look than the default?

I am on SID (unstable) and do a daily 'apt-get --with-new-pkgs upgrade'.

I tested it on another SID box and have the same problem.

For testing, I downgraded libatk-wrapper-java and libatk-wrapper-java-jni to 
0.33.0-5 and could start Netbeans 8.1beta. I disabled all plugins, stopped it, 
upgraded the two packages back to 0.33.3-1 ... and now I can start Netbeans.
But as soon as I open a Java Project and edit a java file, it crashes with the 
same error at libatk-wrapper.so.6.0.0+0x6f87.
What I did right before crash was: move the cursor behind a class name end 
enter dot ('.') to get the list of methods/attributes. Immediate crash.

I guess the crash on startup comes when having either the C/C++ plugin 
activated and/or having lots of open projects (mixed C++ and Java).

Maybe something related:
When I downgrade the above mentioned atk packages to 0.33.0-5, I also get a 
crash when typing the dot after a class name + moving the cursor in the 
appearing popup list. But it comes with this message:
# C  [libglib-2.0.so.0+0x38808]  g_hash_table_iter_next+0xb8

I experience these crashes with both combinations Netbeans8.1beta+OpenJDK8 and  
Netbeans8.0.2+OpenJDK7.

This is really a no-go. I can't use the IDE any more. Neither in the office 
nor at home.
If anyone knows of a work-around, please let me know.
If I can do anything to help fixing the issue, let me know.

Tim

Bug#798924: /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.6.0.0: SIGSEGV on Netbeans startup

[Tim Ruehsen]

On Wednesday 16 September 2015 11:37:53 Samuel Thibault wrote:
> Tim Ruehsen, le Wed 16 Sep 2015 11:30:15 +0200, a écrit :
> > This is really a no-go. I can't use the IDE any more. Neither in the
> > office
> > nor at home.
> > If anyone knows of a work-around, please let me know.
> 
> Comment the line in /etc/java-7-openjdk/accessibility.properties

Samuel, many thanks, you saved my day !!!

The libglib crash also does not happen any more after commenting that line.

Tim

Bug#798924: /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.6.0.0: SIGSEGV on Netbeans startup

[Tim Ruehsen]

Package: libatk-wrapper-java-jni
Version: 0.33.3-1
Severity: normal
File: /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.6.0.0

Dear Maintainer,

the latest version makes Netbeans (8.0.2 and 8.1beta) SIGSEGV on startup.
Tested with Debian OpenJDK 7 and 8.

Downgrading libatk-wrapper-java and libatk-wrapper-java-jni to version 0.33.0-5 
resolves the issue.

Best regards, Tim

-- 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.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libatk-wrapper-java-jni:amd64 depends on:
ii  libatk-bridge2.0-0   2.16.0-2
ii  libatk-wrapper-java  0.33.3-1
ii  libatk1.0-0  2.16.0-2
ii  libatspi2.0-02.16.0-1
ii  libc62.19-20
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libdbus-1-3  1.10.0-2
ii  libgdk-pixbuf2.0-0   2.31.5-1
ii  libglib2.0-0 2.44.1-1.1
ii  libgtk-3-0   3.16.6-1
ii  libgtk2.0-0  2.24.28-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3

libatk-wrapper-java-jni:amd64 recommends no packages.

libatk-wrapper-java-jni:amd64 suggests no packages.

-- no debconf information

Bug#798924: /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.6.0.0: SIGSEGV on Netbeans startup

[Tim Ruehsen]

On Monday 14 September 2015 11:11:39 Samuel Thibault wrote:
> Hello,
> 
> Tim Ruehsen, le Mon 14 Sep 2015 10:03:57 +0200, a écrit :
> > the latest version makes Netbeans (8.0.2 and 8.1beta) SIGSEGV on startup.
> > Tested with Debian OpenJDK 7 and 8.
> 
> I'm not getting a crash on my box.  Are you perhaps using e.g. a
> different look than the default?

Not that I know of. Netbeans 8.1beta is a fresh install (but took the settings 
from 8.0.2).

$ cat /etc/java-7-openjdk/swing.properties
# uncomment to set the default look and feel to GTK
#swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel

$ cat /etc/java-8-openjdk/swing.properties
# uncomment to set the default look and feel to GTK
#swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel

Maybe there are some private settings regarding L ?

If it helps, the crash also shows
/usr/oms/netbeans-8.1beta/platform/lib/nbexec: line 474:  9249 Aborted  
   
"/usr/lib/jvm/java-8-openjdk-amd64/bin/java" -Djdk.home="/usr/lib/jvm/java-8-
openjdk-amd64" -classpath 
"/usr/oms/netbeans-8.1beta/platform/lib/boot.jar:/usr/oms/netbeans-8.1beta/platform/lib/org-
openide-modules.jar:/usr/oms/netbeans-8.1beta/platform/lib/org-openide-
util.jar:/usr/oms/netbeans-8.1beta/platform/lib/org-openide-util-
lookup.jar:/usr/oms/netbeans-8.1beta/platform/lib/org-openide-util-
ui.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/boot_ja.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/boot_pt_BR.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/boot_ru.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/boot_zh_CN.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-modules_ja.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-modules_pt_BR.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-modules_ru.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-modules_zh_CN.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-util_ja.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-openide-
util-lookup_ja.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-openide-
util-lookup_pt_BR.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-util-lookup_ru.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-
openide-util-
lookup_zh_CN.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-openide-
util_pt_BR.jar:/usr/oms/netbeans-8.1beta/platform/lib/locale/org-openide-
util_ru.jar:/usr/oms/netbeans-8.1beta/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="/usr/oms/.netbeans" -
Dnetbeans.running.environment=kde -
Dnetbeans.dirs="/usr/oms/netbeans-8.1beta/nb:/usr/oms/netbeans-8.1beta/ergonomics:/usr/oms/netbeans-8.1beta/ide:/usr/oms/netbeans-8.1beta/extide:/usr/oms/netbeans-8.1beta/java:/usr/oms/netbeans-8.1beta/apisupport:/usr/oms/netbeans-8.1beta/webcommon:/usr/oms/netbeans-8.1beta/websvccommon:/usr/oms/netbeans-8.1beta/enterprise:/usr/oms/netbeans-8.1beta/mobility:/usr/oms/netbeans-8.1beta/profiler:/usr/oms/netbeans-8.1beta/python:/usr/oms/netbeans-8.1beta/php:/usr/oms/netbeans-8.1beta/identity:/usr/oms/netbeans-8.1beta/harness:/usr/oms/netbeans-8.1beta/cnd:/usr/oms/netbeans-8.1beta/cndext:/usr/oms/netbeans-8.1beta/dlight:/usr/oms/netbeans-8.1beta/groovy:/usr/oms/netbeans-8.1beta/extra:/usr/oms/netbeans-8.1beta/javacard:/usr/oms/netbeans-8.1beta/javafx:"
 
-Dnetbeans.home="/usr/oms/netbeans-8.1beta/platform" '-
Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade' '-
Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense' '-Xmx1024m' 
'-client' '-Xss2m' '-Xms32m' '-Dnetbeans.logger.console=true' '-ea' '-
Dapple.laf.useScreenMenuBar=true' '-Dapple.awt.graphics.UseQuartz=true' '-
Dsun.java2d.noddraw=true' '-Dsun.java2d.dpiaware=true' '-
Dsun.zip.disableMemoryMapping=true' '-
Dnetbeans.extbrowser.manual_chrome_plugin_install=yes' -XX:
+HeapDumpOnOutOfMemoryError -
XX:HeapDumpPath="/usr/oms/.netbeans/8.1beta/var/log/heapdump.hprof" 
org.netbeans.Main --cachedir "/usr/oms/.cache/netbeans/8.1beta" --userdir 
"/usr/oms/.netbeans/8.1beta" "--branding" "nb" 0<&0


Tim

Bug#798924: Netbeans output

[Tim Ruehsen]

I forgot the Netbeans output:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f4091803ee9, pid=9249, tid=139914781116160
#
# JRE version: OpenJDK Runtime Environment (8.0_66-b01) (build 1.8.0_66-
internal-b01)
# Java VM: OpenJDK 64-Bit Server VM (25.66-b01 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# C  [libatk-wrapper.so.6.0.0+0x4ee9]

Bug#633703: [bug #45800] --convert-links messages could be clearer

[Tim Ruehsen]

Update of bug #45800 (project wget):

  Status:None = Fixed  
 Open/Closed:Open = Closed 
 Release:None = trunk  


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?45800

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

Bug#387745: [bug #45778] wget and unicode

[Tim Ruehsen]

There is a current patch in discussion.

tim@blitz-lx:~/src/wget$ src/wget -nv 
http://zh.wikipedia.org/wiki/%E9%A6%96%E9%A1%B5
2015-08-17 14:47:52 URL:http://zh.wikipedia.org/wiki/%E9%A6%96%E9%A1%B5 
[36245] - 首页 [1]

Tim


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

Bug#790523: [bug #45443] http_proxy variable should also work for capitalized HTTP_PROXY

[Tim Ruehsen]

Update of bug #45443 (project wget):

  Status:None = Wont Fix   
 Assigned to:None = rockdaboot 

___

Follow-up Comment #1:

I cite Daniel Stenberg (curl maintainer/developer) from the mailing list
bug-w...@gnu.org, Tue, 30 Jun 2015 11:20:28 +0200 (CEST):

The reason some tools don't accept HTTP_PROXY and only http_proxy is that
the CGI interface from back in the old days provide headers from the incoming
request to the CGI program prefixed with HTTP_.

Thus, running a CGI script from a server, an incoming Proxy: header (which
normally doesn't do anything) would be sent to the program as HTTP_PROXY,
leading to confusions or in the worst case some sort of attack.

The CGI interface is an ancient thing, probably boardering to extinction.
Still it is out there and some such CGIs probably use wget.

Incidently, curl also only accepts the lower case version of this environment
variable and I believe it goes for some other related tools as well.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?45443

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#203716: [bug #33838] want a way to turn off verbosity but still have a progress bar

[Tim Ruehsen]

Update of bug #33838 (project wget):

  Status:None = Fixed  
 Open/Closed:Open = Closed 
 Release:1.12 = 1.16   


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33838

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#787807: libc6: mq_open unexpectedly fails with errno 24

[Tim Ruehsen]

On Mon, 15 Jun 2015 11:55:47 +0200 Aurelien Jarno aurel...@aurel32.net 
wrote:
 Nothing has changed in the libc6 package for sometimes. When does the
 breakage started? I see you are using a 4.0 kernel, could it be due to
 that?

I made some tests on Debian VMs, that I have flying around.

Debian SID with 4.0 (amd64): problem as described above
Debian SID with 3.16 (amd64): same problem
Debian Wheezy with 3.2.0 (amd64): same problem
Debian Wheezy with 3.2.0 (i386): Works as expected (up to maxmsg=1000, with 
maxmsg=1001 I get errno=22 (Invalid argument) - that's fine for me, but is not 
what the man page says for this case. BTW the man page for mq_open is broken - 
double entries below ERRORS).

Looks like amd64 architecture has the problem since a while.

Tim


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

Bug#787807: libc6: mq_open unexpectedly fails with errno 24

[Tim Ruehsen]

On Monday 15 June 2015 15:21:52 Aurelien Jarno wrote:
   I made some tests on Debian VMs, that I have flying around.
   
   Debian SID with 4.0 (amd64): problem as described above
   Debian SID with 3.16 (amd64): same problem
   Debian Wheezy with 3.2.0 (amd64): same problem
   Debian Wheezy with 3.2.0 (i386): Works as expected (up to maxmsg=1000,
   with
   maxmsg=1001 I get errno=22 (Invalid argument) - that's fine for me, but
   is not what the man page says for this case.

Ok, forget about the man pages. I was just puzzled by multiple entries per 
error number.

   Looks like amd64 architecture has the problem since a while.
  
  I don't really know what is the problem, but a strace shows that the
  glibc just returns the errno from the kernel.
 
 What does ulimit -q returns on your system? It seems to be 819200 by
 default, which is why the kernel refuses to create the message queue.

Yes, it is 819200 on i386 (Wheezy) and on amd64 (SID) here. 

 Here increasing the value allows the msg queue to be created
 successfully. The way to compute the limit is described in the
 getrlimit(2) manpage. Note that the value includes size of structures,
 which are likely to be different on i386 and amd64, and has changed
 starting with kernel 3.5. It's therefore likely that by using an
 amd64 machine and a recent kernel, you crossed the 819200 limit.

Woooh, thanks for that hint ! Wouldn't have thought about this for a while...

BTW, using /etc/security/limits.conf to increase that value (tried hard, soft, 
- for * and for the user) does not increase the users ulimit value (nor 
permits him to increase it via ulimit). But that is another story... did not 
test a reboot yet.

Many thanks for your help. I guess you can close this bug.

Best Regards
Tim

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

Bug#787807: libc6: mq_open unexpectedly fails with errno 24

[Tim Ruehsen]

Package: libc6
Severity: normal

Dear Maintainer,

I have an application that uses Posix message queues since a while.
Today I realized that mq_open fails with errno 24 where it worked before.
(errno 24: Too many open files)

Here is a short C file to reproduce the problem.
Before you start it, you have to increase msg_max system default:
sysctl -w fs.mqueue.msg_max=1000

Now (as normal user) execute the following code:
#include stdio.h
#include mqueue.h
#include errno.h

void main(void) {
  struct mq_attr attr={.mq_maxmsg=900,.mq_msgsize=1020};
  int rc=mq_open(/xxx,O_CREAT | O_RDONLY, 0600, attr);
  printf(rc=%d errno=%d\n,rc,errno);
}

It returns errno 24. Using a value of 800 for .mq_maxmsg returns success.
Compile with gcc x.c -o x -lrt.

The system settings should allow the above values without problem:
$ ls /proc/sys/fs/mqueue/|more
msg_default
msg_max
msgsize_default
msgsize_max
queues_max

$ cat /proc/sys/fs/mqueue/*
10
1000
8192
8192
256

Regards, Tim


-- 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.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


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

Bug#784348: [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

[Tim Ruehsen]

Hi Darshit,

your patch doesn't work as expected.

$ cat abc xxx
$ ln -s xxx foo
$ ln -s /etc/passwd README
$ ../src/wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README
...

$ ls -la
lrwxrwxrwx 1 oms users   11 May  7 09:28 README - /etc/passwd
-rw-r--r-- 1 oms users 1495 May  7 09:30 xxx

'foo' doesn't exist and 'xxx' has been overwritten !!!

Regards, Tim


On Thursday 07 May 2015 10:06:55 Darshit Shah wrote:
 joey@darkstar:~/tmp/yln -s /etc/passwd README
 joey@darkstar:~/tmp/yls
 README@
 joey@darkstar:~/tmp/ywget -O foo
 ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README
 --2015-05-05 13:17:22--  ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README
 
= ‘foo’
 
 Resolving ftp.funet.fi (ftp.funet.fi)... 193.166.3.2, 2001:708:10:9::20:2
 Connecting to ftp.funet.fi (ftp.funet.fi)|193.166.3.2|:21... connected.
 Logging in as anonymous ... Logged in!
 == SYST ... done.== PWD ... done.
 == TYPE I ... done.  == CWD (1) /pub/Linux/mirrors/debian ... done.
 == SIZE README ... 1495
 == PASV ... done.== RETR README ... done.
 Length: 1495 (1.5K) (unauthoritative)
 
 README  100%[=]   1.46K  5.45KB/s   in
 0.3s
 
 
 2015-05-05 13:17:28 (5.45 KB/s) - ‘foo’ saved [1495]
 
 joey@darkstar:~/tmp/yls
 foo
 
 Doesn't happen if README is a file rather than a symlink, doesn't happen
 when using http. The ftp downloader apparently has a bug..
 
 This definitely is a bug. I've attached a small fix for this particular
 issue. If no one has any issues with it, I'll push it in a day.
 
 Although, I think we should also look into the issue Giuseppe found, and
 also the point that Angel raised about compatibility with shell like
 redirection.


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

Bug#784348: [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

[Tim Ruehsen]

Follow-up Comment #2, bug #45037 (project wget):

Use -d to get
Unlinking README (symlink).

In ftp.c you will find those lines:
  /* Remove it if it's a link.  */
  remove_link (con-target);

This is done by purpose (I just can guess why: not to overwrite the content
the link points to).

The question is: is it a bug or a feature ? Should we just document this
behaviour (maybe it already is).


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?45037

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


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

Bug#144076: [Bug-wget] [PATCH] wget -nv doesn't show enough errors

[Tim Ruehsen]

On Saturday 10 January 2015 11:18:58 Giuseppe Scrivano wrote:
 Tim Ruehsen tim.rueh...@gmx.de writes:
  On Friday 09 January 2015 14:51:00 Darshit Shah wrote:
  I don't see any issue with this patch. No-verbose does need to print a
  little bit more information I think.
  
  However, @giuseppe, @Tim, do you'll see any issues with scripts
  parsing Wget's --nv output if we apply this patch?
  
  For me, it is fine. You never know about how good or bad scripts are
  grepping Wget's output. I would say, if this patch breaks a script, the
  script should be fixed.
 
 I am fine with it too, as anyway scripts should not depend from the wget
 output.

Pushed.

Tim

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

Bug#144076: (no subject)

[Tim Ruehsen]

tag 144076 fixed-upstream
thanks


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

Bug#144076: [Bug-wget] [PATCH] wget -nv doesn't show enough errors

[Tim Ruehsen]

On Friday 09 January 2015 14:51:00 Darshit Shah wrote:
 I don't see any issue with this patch. No-verbose does need to print a
 little bit more information I think.
 
 However, @giuseppe, @Tim, do you'll see any issues with scripts
 parsing Wget's --nv output if we apply this patch?

For me, it is fine. You never know about how good or bad scripts are grepping 
Wget's output. I would say, if this patch breaks a script, the script should 
be fixed.

 
 On Thu, Jan 8, 2015 at 7:03 PM, Mathieu Parent math.par...@gmail.com 
wrote:
  Hello,
  
  Here is the patch for this long-standing bug.
  
  
  See also:
  https://bugs.debian.org/144076
  
  Regards
  
  --
  Mathieu Parent


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

Bug#736427: [bug #41331] spurious errors if some files in the cert directory are not certificates

[Tim Ruehsen]

Update of bug #41331 (project wget):

  Status:Needs Discussion = Fixed  
 Open/Closed:Open = Closed 
 Planned Release:None = 1.16.1 

___

Follow-up Comment #8:

To not create regressions, only 'c' has been done.
IMHO, 'f' is not a good idea.

Fixed with commit f518d6cea167cac0f66d6e5fbc5cdb30096db50e


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?41331

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

Bug#743477: grub2: grub fails with error: 'grub_term_highlight_color' not found

[Tim Ruehsen]

Package: grub2
Version: 2.02~beta2-8
Severity: normal

Dear Maintainer,

grub2 fails to boot.

It says error: symbol 'grub_term_highlight_color' not found and enters
grub rescue

I have this problem since 2.02~beta2-7. 2.02~beta2-8 doesn't change it.

My solution right now is to boot from a rescue cd and install
grub2_2.00-22_amd64.deb
grub2-common_2.00-22_amd64.deb
grub-common_2.00-22_amd64.deb
grub-pc_2.00-22_amd64.deb
grub-pc-bin_2.00-22_amd64.deb

The detailed procedure is
- booting from a rescue cd
- mount /dev/sdb1 /mnt
- mount proc /mnt/proc -t proc
- mount sysfs /mnt/sys -t sysfs
- mount --bind /dev /mnt/dev
- chroot /mnt /bin/bash
- dpkg -i ... above mentioned grub .deb files ...

Regards, Tim


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/disk/by-uuid/dbffd07e-f453-4102-84d0-fe041d9ef5c0 / ext4 
rw,noatime,discard,data=ordered 0 0
/dev/sda3 /cave ext4 rw,relatime,dioread_nolock,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
#(hd0)  /dev/disk/by-id/ata-SAMSUNG_HD321KJ_S0ZEJ1MPC20499
(hd0) /dev/sdb1
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ ${next_entry} ] ; then
   set default=${next_entry}
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default=0
fi

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
dbffd07e-f453-4102-84d0-fe041d9ef5c0
else
  search --no-floppy --fs-uuid --set=root dbffd07e-f453-4102-84d0-fe041d9ef5c0
fi
font=/usr/share/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=1280x1024
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
dbffd07e-f453-4102-84d0-fe041d9ef5c0
else
  search --no-floppy --fs-uuid --set=root dbffd07e-f453-4102-84d0-fe041d9ef5c0
fi
insmod png
if background_image /usr/share/images/desktop-base/joy-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-dbffd07e-f453-4102-84d0-fe041d9ef5c0' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
dbffd07e-f453-4102-84d0-fe041d9ef5c0
else
  search --no-floppy --fs-uuid --set=root 
dbffd07e-f453-4102-84d0-fe041d9ef5c0
fi
echo'Loading Linux 3.13-1-amd64 ...'
linux   /boot/vmlinuz-3.13-1-amd64 
root=UUID=dbffd07e-f453-4102-84d0-fe041d9ef5c0 ro  quiet splash
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-3.13-1-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-dbffd07e-f453-4102-84d0-fe041d9ef5c0' {
menuentry 

Bug#736427: [bug #41331] spurious errors if some files in the cert directory are not certificates

[Tim Ruehsen]

Follow-up Comment #5, bug #41331 (project wget):



Before I create a patch, I would like to know what you suggest. At least such
a suggestion should satisfy the widest possible range of users.

Some options could be (single or combination)
a. Output WARNING instead of ERROR
b. Output ERROR only with --debug enabled
c. Output WARNING only with --debug enabled
d. Suppress any output
e. Ignore executables (i guess your scripts have the X flag set)
f. Just read *.pem and *.crt files

I personally tend to c.

To get rid of the messages, you could also create a subdirectory for your
scripts.

(I also would like to change the code to ignore .* files, but that might be
another patch.)

Maybe some more people could post their opinions !?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?41331

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


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

Bug#736427: [bug #41331] spurious errors if some files in the cert directory are not certificates

[Tim Ruehsen]

Follow-up Comment #3, bug #41331 (project wget):

At least, we should change the string 'ERROR' into 'WARNING'.

I personally would like to see if there is something unexpected or broken in
my certificate directory. So removing the check resp. the warning completely
is not an option to me. 

What do you think ?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?41331

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


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

Bug#730662: [bug #40746] wget: fails to parse time from 'Last-Modified: Wed, 27 Nov 2013 07:06:38 UTC'

[Tim Ruehsen]

Follow-up Comment #1, bug #40746 (project wget):

Just to mention it. The server is broken and does not behave RFC 2616
compliant.

from RFC 2616, 3.3.1 Full Date

...
This is indicated in the first two formats by the inclusion of GMT as the
three-letter abbreviation for time zone, and MUST be assumed when reading the
asctime format.
...
   HTTP-date= rfc1123-date | rfc850-date | asctime-date
   rfc1123-date = wkday , SP date1 SP time SP GMT
   rfc850-date  = weekday , SP date2 SP time SP GMT
   asctime-date = wkday SP date3 SP time SP 4DIGIT

Therefore Wget should just ignore the timezone in rfc1123-date and rfc850-date
and always assume GMT/UTC.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?40746

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

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

[Tim Ruehsen]

On Friday 08 November 2013 12:13:14 Noël Köthe wrote:
Hi Noël,

 My local buildlog:
 ...
 CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall
 CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro ./configure \
 --prefix=/usr \
 --mandir=\${prefix}/share/man \
 --infodir=\${prefix}/share/info \
 --sysconfdir=/etc \
 --enable-ipv6 \
 --with-ssl \
 --with-libidn --build x86_64-linux-gnu
 configure: configuring for GNU Wget 1.14.96-38327
 ...
 configure: Summary of build options:
 
   Version:   1.14.96-38327
   Host OS:   linux-gnu
   Install prefix:/usr
   Compiler:  gcc
   CFlags:-g -O2 -fstack-protector --param=ssp-buffer-size=4
 -Wformat -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall
 -D_FORTIFY_SOURCE=2 -Iyes/include LDFlags:   -Wl,-z,relro -Lyes/lib
   Libs:  -lnettle -lgnutls -lz  -lidn -luuid
   SSL:   gnutls
   Zlib:  yes
   Digest:yes
   NTLM:  yes
   OPIE:  yes
   Debugging: yes
 
 
 It is also on the buildservers.
 https://buildd.debian.org/status/fetch.php?pkg=wgetarch=i386ver=1.14.96.38
 327-1stamp=1383905584
 
 I'm trying to find out...

I just reproduced it here (using your ./configure options).
It is the --with-libidn option !

From ./configure --help:
  --with-libidn=DIR   Support IDN/IRIs (needs GNU Libidn)

You don't specify DIR and configure.ac is not prepared for that.

Tim


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

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

[Tim Ruehsen]

On Sunday 06 October 2013 22:47:28 Daniel Kahn Gillmor wrote:
 On 10/06/2013 03:30 PM, Tim Rühsen wrote:
  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:

 This looks to me like it might be quite similar to
 http://bugs.debian.org/700899 -- what version of valgrind are you running?
 
 see also
 http://lists.freedesktop.org/archives/p11-glue/2013-February/000263.html

Yes, it looks like the same bug.
My valgrind is 3.8.1-5.

BTW, bug #700899 is not solved here.
Your dlopentest.c still behaves as you described in the original bug report 
though the valgrind suppression is there in/usr/lib/valgrind/debian.supp:

{
  dlopen() with -lpthread bug#700899
  Memcheck:Leak
  fun:calloc
  fun:_dlerror_run
  fun:dlopen@@GLIBC_2.2.5
}

Valgrind still says:
==18794== in use at exit: 32 bytes in 1 blocks
==18794==   total heap usage: 6 allocs, 5 frees, 1,518 bytes allocated
==18794== 
==18794== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
==18794==at 0x4C2B514: calloc (vg_replace_malloc.c:593)
==18794==by 0x505065F: _dlerror_run (dlerror.c:141)
==18794==by 0x50500C0: dlopen@@GLIBC_2.2.5 (dlopen.c:87)

Out of curiosity, I copied the suppression from debian.supp to debian-libc6-
dbg.supp. And voila, that works !

Looks like valgrind is not reading debian.supp correctly !?

Tim


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

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

[Tim Ruehsen]

  Out of curiosity, I copied the suppression from debian.supp to
  debian-libc6- dbg.supp. And voila, that works !
  
  Looks like valgrind is not reading debian.supp correctly !?
 
 Did you tell valgrind to load it? It doesn't load any suppression file by
 default and never has (except debian-libc6-dbg.supp, but that's useless
 anyway and will be removed in the future).

Sorry, I thought it loads any *.supp files in /usr/lib/valgrind/.

 Maybe a note in valgrind's README.Debian would help clearing the confusion?

Yes, definitely. That would be helpful.

Please excuse my confusion...

Tim


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

Bug#725332: clang-3.4: Use of uninitialized value $HtmlDir in ccc-analyzer

[Tim Ruehsen]

Package: clang-3.4
Version: 1:3.4~svn190846-1
Severity: normal

Dear Maintainer,

scan-build make
aborted with an error (seems to be another clang bug, since 3.3 works fine),

And then, scan-build reports the following error(s):
Use of uninitialized value $HtmlDir in concatenation (.) or string at 
/usr/share/clang/scan-build/ccc-analyzer line 96.
mkdir /failures: Permission denied at /usr/share/clang/scan-build/ccc-analyzer 
line 97.

A static analyzer for perl should have recognized this... :-)

Regards

-- 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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages clang-3.4 depends on:
ii  libc62.17-93
ii  libclang-common-3.4-dev  1:3.4~svn190846-1
ii  libclang1-3.41:3.4~svn190846-1
ii  libffi6  3.0.13-4
ii  libgcc-4.8-dev   4.8.1-10
ii  libgcc1  1:4.8.1-10
ii  libllvm3.4   1:3.4~svn190846-1
ii  libobjc-4.8-dev  4.8.1-10
ii  libstdc++-4.8-dev4.8.1-10
ii  libstdc++6   4.8.1-10
ii  libtinfo55.9+20130608-1

Versions of packages clang-3.4 recommends:
ii  llvm-3.4-dev  1:3.4~svn190846-1
ii  python2.7.5-5

clang-3.4 suggests no packages.

-- no debconf information


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

Bug#513638: wget: --follow-tags not following

[Tim Ruehsen]

For a conversion to local URLs you will definitely need --span-hosts since 
www.cnn.com refers to images on other hosts.

Also, you do not need curl to fetch the index.html (you named it test.htm).


This will work for you (at least here with wget 1.14-2):

wget --span-hosts --no-clobber --convert-links --no-directories --page-
requisites --follow-tags=img http://www.cnn.com


If you are going to parse a local HTML file you use e.g.
--force-html -i test.htm
Of course, this works only for absolute URLs found in test.htm.
If you want to download relative URLs as well, add the --base option.


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#158642: wget: -q suppresses permanent fatal proxy errors

[Tim Ruehsen]

I guess, this bug can be closed.
I you don't think so, it should go upstream for further discussion on the wget 
mailing list.

The documentation is clear with -q:
   -q
   --quiet
   Turn off Wget's output.

What the reporter seems to want is -nv:
   -nv
   --no-verbose
   Turn off verbose without being completely quiet (use -q for that), 
which means that error messages and basic information still get printed.


Regards,

  Tim Rühsen


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

Bug#701775: wget: Not reproducible in Debian unstable

[Tim Ruehsen]

Package: wget
Followup-For: Bug #701775

Dear Maintainer,

I just made some tests.
The original bug is not reproducible on current unstable neither on current 
Wheezy.

The same goes for msg#31 - the server seems to have a problem since the
HTTP header looks fine for me (and of course works with an Apache test 
environment).
I also tested all examples of msg#31, all work fine.

It also works on the current Wheezy (i386 kvm virtual machine):
ii  wget1.13.4-3
ii  libc6:i386  2.13-38
ii  libgcrypt11:i3861.5.0-5
ii  libgnutls26:i3862.12.20-7
ii  libgpg-error0:i386  1.10-3.1
ii  libidn11:i386   1.25-2
ii  libuuid1:i386   2.20.1-5.3
ii  zlib1g:i386 1:1.2.7.dfsg-13



-- 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.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc6  2.17-5
ii  libgcrypt111.5.2-2
ii  libgnutls262.12.23-5
ii  libgpg-error0  1.10-3.1
ii  libidn11   1.25-2
ii  libuuid1   2.20.1-5.4
ii  zlib1g 1:1.2.8.dfsg-1

wget recommends no packages.

wget suggests no packages.

-- no debconf information


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

Bug#652480: wget: Fails to verify SSL server certificate

[Tim Ruehsen]

Package: wget
Version: 1.14-2
Followup-For: Bug #652480

Dear Maintainer,

while the problem still exists in Debian Sid, a self-compiled wget
(linking to gnutls 3.1) works well.


wget https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip
--2013-06-10 10:08:37--  
https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip
Resolving developer.pidgin.im (developer.pidgin.im)... 67.202.116.116, 
2607:f128:40:2400::16
Connecting to developer.pidgin.im (developer.pidgin.im)|67.202.116.116|:443... 
connected.
ERROR: The certificate of 'developer.pidgin.im' is not trusted.
ERROR: The certificate of 'developer.pidgin.im' hasn't got a known issuer.


../src/wget https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip 
--2013-06-10 10:10:20--  
https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip
Resolving developer.pidgin.im (developer.pidgin.im)... 67.202.116.116, 
2607:f128:40:2400::16
Connecting to developer.pidgin.im (developer.pidgin.im)|67.202.116.116|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 795294 (777K) [application/zip]
Saving to: 'cyrus-sasl-2.1.22.zip.2'

100%[===]
 795,294  586KB/s   in 1.3s   

2013-06-10 10:10:22 (586 KB/s) - 'cyrus-sasl-2.1.22.zip.2' saved [795294/795294]


[patchwork.sugarlabs.org can't be resolved any more.]



-- 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.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc6  2.17-5
ii  libgcrypt111.5.2-2
ii  libgnutls262.12.23-5
ii  libgpg-error0  1.10-3.1
ii  libidn11   1.25-2
ii  libuuid1   2.20.1-5.4
ii  zlib1g 1:1.2.8.dfsg-1

wget recommends no packages.

wget suggests no packages.

-- no debconf information


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