Bug#963151: version mismatch - this is what happened

2023-09-13 Thread Nicolai Lissner
I've looked a bit deeper and this is what happened: the package tor-0.4.7.13 has been built 2023-01-12 at this point bookworm still was testing and in January bookworm/testing had libzstd-1.5.2 but then libzstd-1.5.4 entered bookworm/testing 2023-02-23 so tor would have needed a rebuild as there

Bug#963151: rebuild helps

2023-08-20 Thread Nicolai Lissner
This bug comes from the system wherever the package is built it must have some stale older version of libztd or something. When built on a CLEAN debian-stable, the result is a binary that used the header of the libzstd version actually available in debian-stable → it doesn't have this problem.

Bug#904699: patch with solution

2018-08-04 Thread Nicolai Lissner
Meanwhile, I've tested this and it works fine for me. patch attached. --- src/parser_rfc822.c~ 2013-07-13 10:10:25.0 + +++ src/parser_rfc822.c 2018-08-05 00:15:58.034730797 + @@ -35,7 +35,7 @@ #include #include -#define READSIZE 16384 +#define READSIZE 65536 int

Bug#904699: (no subject)

2018-08-02 Thread Nicolai Lissner
Found the reason for this bug. On July 8th a package called librust-winapi-dev was accepted in sid It comes with a complete common-sense breaking "Provides:" line of more than 57kB length, as it provides 1336 packages. IMHO this is insane. However, cdebootstrap uses libdebian-installer-0.116

Bug#904699: W: parser_rfc822: Iek! Don't find end of value! when using sid or testing

2018-07-26 Thread Nicolai Lissner
Package: cdebootstrap Version: 0.7.7+b1 Severity: important Dear Maintainer, when I try to use cdebootstrap with current sid or testing repository it just fails with W: parser_rfc822: Iek! Don't find end of value! it still works fine with stable though. Didn't do anything special, just #

Bug#704743: scid: upstream released new version 4.4

2013-04-05 Thread Nicolai Lissner
Package: scid Version: 1:4.3.0.cvs20120311-1 Severity: wishlist Dear Maintainer, There's a new version of scid available, it would be nice to see this version in debian. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?

Bug#599834: dash: read doesn't honour -r

2010-10-11 Thread Nicolai Lissner
Package: dash Version: 0.5.5.1-6 Severity: important read -r variable is supposed to prevent escaping chars by using backslash but actually it still allows to do that. Testcase: # read -r input (input: foo\nbar) # echo $input foo bar instead it should not translate \n to newline and therefore

Bug#599834: bug report invalid

2010-10-11 Thread Nicolai Lissner
Sorry for the noise, after discussing this with someone on IRC, I see read -r works fine, it was just my wrong assumptions about POSIX echo, I didn't know it is supposed to parse \n, and the bash echo -e is just how POSIX echo is supposed to work. So the bug report is invalid. But at least I've