Bug#847774: RFS: lbzip2/2.5-2 [RC]

[Mikołaj Izdebski]

Hi Andrey,

On 12/12/16, Andrey Rahmatullin  wrote:
> You've replaced orig.tar.bz2 with orig.tar.gz. Is this intended? If yes,
> why? If no, please fix this.

No, that was not intended, thanks for catching this.
It should be fixed now.

--
Mikolaj Izdebski

Bug#847774: RFS: lbzip2/2.5-2 [RC]

[Mikołaj Izdebski]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "lbzip2"

* Package name: lbzip2
  Version : 2.5-2
  Upstream Author : Mikolaj Izdebski 
* URL : http://lbzip2.org/
* License : GPL-3+
  Section : utils

It builds those binary packages:

  lbzip2 - fast, multi-threaded bzip2 utility

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/lbzip2

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/l/lbzip2/lbzip2_2.5-2.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

   * debian/rules: Switch to default dpkg-deb compression
 format, closes: #833252
   * debian/control: Bump Standards-Version to 3.9.8.

Regards,
Mikolaj Izdebski

Bug#804814: ITP: xmvn -- Local Extensions for Apache Maven

[Mikołaj Izdebski]

Package: wnpp
Version: N/A; reported 2015-11-12
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
X-Debbugs-CC: debian-j...@lists.debian.org

* Package name : xmvn
Version : 2.5.0
Upstream Author : Mikolaj Izdebski 
* URL : https://mizdebsk.fedorapeople.org/xmvn/
* License : Apache License Version 2.0
Description : Local Extensions for Apache Maven

XMvn was developed by Red Hat and it's used in Fedora and RHEL as
primary Java packaging automation tool.  Its adoption in Debian aims
at improving Java packaging techniques.

XMvn is a set of extensions for Apache Maven that can be used to
manage system artifact repository and use it to resolve Maven
artifacts in offline mode.  It also provides Maven plugins to help
with creating packages containing Maven artifacts.

XMvn integrates with the most popular Java build systems, including:
* Apache Maven,
* Gradle,
* Apache Ivy,
* Aether Ant Tasks,
* Eclipse Tycho (through external plugin),
* Scala SBT (througt Ivy).

Bug#801025: stapler servlet31 patch

[Mikołaj Izdebski]

tags 801025 patch
quit

Patch is available at
http://pkgs.fedoraproject.org/cgit/stapler.git/plain/servlet31.patch?id=e45a628b31c85668895359d41b542602edbe7e34

Bug#733095: 733095

[Mikołaj Izdebski]

tags 733095 patch
quit

Patch is available at
http://pkgs.fedoraproject.org/cgit/freemind.git/plain/0004-Update-to-groovy-2.4.patch?id=7dbf8e0b96c2223a7f1466ed3833895b6e2e9f0c

Bug#801018: groovy servlet

[Mikołaj Izdebski]

tags 801018 patch
quit

Patch is available at
http://pkgs.fedoraproject.org/cgit/groovy.git/plain/0001-Port-to-Servlet-API-3.1.patch?id=25f3de886ae02397509879efdb5b75fb061ca175

Bug#743038: RFS: lbzip2/2.5-1

[Mikołaj Izdebski]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package lbzip2

Package name: lbzip2
Version : 2.5-1
Upstream Author : Mikolaj Izdebski zurg...@gmail.com
URL : http://lbzip2.org/
License : GPL-3+
Section : utils

It builds those binary packages:

  lbzip2 - fast, multi-threaded bzip2 utility

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/lbzip2

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/l/lbzip2/lbzip2_2.5-1.dsc

More information about lbzip2 can be obtained from http://lbzip2.org/.

Changes since the last upload:

  * New upstream release:
- new sequential mode of operation,
- fixed several major and minor bugs.
  * debian/patches/automake-1.14: Remove patch, upstream has switched
to Automake 1.14.
  * debian/control: Bump Standards-Version to 3.9.5.
  * debian/copyright: Update copyright to new upstream release.

Regards,
Mikolaj Izdebski


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

Bug#725516: lbzip2: FTBFS: problems running testsuite

[Mikołaj Izdebski]

On Tue, Oct 15, 2013 at 9:21 PM, Steven Chamberlain ste...@pyro.eu.org wrote:
 On 13/10/13 21:21, Mikołaj Izdebski wrote:
 Upstream lbzip2 uses automake 1.11 and it is not compatible
 with automake = 1.13.  Attached patch to use automake 1.11.
 The patch will be included in the next lbzip2 upload.

 Thanks a lot for this.  The test suite now runs, but I see consistent
 fail results on kfreebsd-amd64:

[...]

 If I invoke ./Tester or ../src/lbzip2 directly from the shell, it works
 fine for all the valid test cases, and produces the same output as
 minbzcat.  It only fails when invoked by 'make check' (using only -j1).

This can be (yet another) problem with Automake.  Could you try new upstream
version?  The package is not yet in unstable, but you can download it with:

  dget -x http://mentors.debian.net/debian/pool/main/l/lbzip2/lbzip2_2.3-1.dsc

This package also uses newer Automake (1.14) which may solve the issue.


 + ./timeout ./minbzcat
 + rc1=0
 + ./timeout ../src/lbzip2 -dcqn4
 lbzip2: unable to create a POSIX thread: Resource temporarily unavailable
 + rc2=1

 (To see that. I added +x to the shell invocation of ./Tester and removed
 2/dev/null from the decompressor command lines).

 From ktrace/dump:

  92870 lbzip2   CALL
 mmap(0,0x20001000,0x3PROT_READ|PROT_WRITE,0x1002MAP_ANON|MAP_TYPE|MAP_PRIVATE,0x,0)
  92870 lbzip2   RET   mmap -1 errno 12 Cannot allocate memory
  92870 lbzip2   CALL  write(0x2,0x61e820,0x4a)
  92870 lbzip2   GIO   fd 2 wrote 74 bytes
lbzip2: unable to create a POSIX thread: Resource temporarily
 unavailable


This doesn't seem right. It looks like pthread_create() tries to allocate 500 MB
of memory, which is much more than it should ever need.  (lbzip2 itself never
allocates more than 5MB in one chunk.)


 It is interesting that only some of the .bz2 test cases trigger the
 problem, while minbzcat has no problem with them.  I tried changing the
 1GB ulimit -v in ./Tester to 2GB or 256MB which made no difference.
 The system had approx. 5GB free memory anyway.

In the cases that succeed lbzip2 is supposed to fail (and it does, but
with memory
allocation problem).  I suspect that in all cases the mmap() problem occurs.

Thank you for for analysis.  If new package doesn't solve this then I will
have a closer look myself.


 Regards,
 --
 Steven Chamberlain
 ste...@pyro.eu.org


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

Bug#725516: lbzip2: FTBFS: problems running testsuite

[Mikołaj Izdebski]

Upstream lbzip2 uses automake 1.11 and it is not compatible
with automake = 1.13.  Attached patch to use automake 1.11.
The patch will be included in the next lbzip2 upload.


debian-bug-725516.patch
Description: Binary data

Bug#726261: RFS: lbzip2/2.3-1 [RC]

[Mikołaj Izdebski]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package lbzip2

* Package name: lbzip2
  Version : 2.3-1
  Upstream Author : Mikolaj Izdebski zurg...@gmail.com
* URL : http://lbzip2.org/
* License : GPL-3+
  Section : utils

It builds those binary packages:

  lbzip2 - fast, multi-threaded bzip2 utility

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/lbzip2

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/l/lbzip2/lbzip2_2.3-1.dsc

More information about lbzip2 can be obtained from http://lbzip2.org/.

Changes since the last upload:

  * New upstream release:
- fixed bug which prevented symbolic links to be opened in some
  situations, closes: #700680,
- fixed several other minor bugs.
  * debian/patches/automake-1.14: Add patch fixing compatibility with
GNU Automake 1.14; closes: #725516.
  * debian/control:
- bump Standards-Version to 3.9.4,
- bump automake build-dependency version to 1.14,
- bump gnulib build-dependency version to prevent FTBFS,
- add link to new upstream home site.
  * debian/rules: Enable verbose make output to silence the
compiler-flags-hidden warning.
  * debian/watch: Update to reflect upstream website changes.
  * debian/copyright: Update copyright to new upstream release.


Regards,
Mikolaj Izdebski


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

Bug#725516: lbzip2: FTBFS: problems running testsuite

[Mikołaj Izdebski]

Hello,

Thank you for the report.

On Sun, Oct 6, 2013 at 8:42 PM, Steven Chamberlain ste...@pyro.eu.org wrote:
 There seem to be some problems running the testsuite during build, which
 I don't think are specific to my architecture (kfreebsd-amd64) :

 make  check-TESTS
 make[2]: Entering directory `/home/steven/lbzip2-2.2/tests'
 make[3]: Entering directory `/home/steven/lbzip2-2.2/tests'
 ./Tester: line 27: tmp./bin/bash.1.21252: No such file or directory
 ./Tester: line 28: tmp./bin/bash.2.21252: No such file or directory
 ./Tester: line 27: tmp./bin/bash.1.21266: No such file or directory
 ./Tester: line 28: tmp./bin/bash.2.21266: No such file or directory
 ./Tester: line 27: tmp./bin/bash.1.21280: No such file or directory

 Tester tries to use '$1' to uniquely identify the test that is running,
 but the invocation seems to be:
 /bin/bash ./Tester /bin/bash ../build-aux/test-driver --test-name $f

 Even if I omit using the $bn part, it still fails for another
 unexplained reason:

 make[4]: Leaving directory `/home/steven/lbzip2-2.2/tests'
 fatal: making test-suite.log: failed to create 32767.bz2.trs
 fatal: making test-suite.log: failed to create 32767.bz2.log
 fatal: making test-suite.log: failed to create ch255.bz2.trs
 fatal: making test-suite.log: failed to create ch255.bz2.log
 fatal: making test-suite.log: failed to create concat.bz2.trs

This is probably a problem with Autotools.
Not reproducible in testing on GNU/Linux.
I will try to reproduce this in unstable on GNU/kFreeBSD


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

Bug#714125: lbzip2: use alternatives mechanism if possible

[Mikołaj Izdebski]

Hello Christoph,

Thank you for the report.  Making lbzip2 as a bzip2 alternative in
Debian was and still is desired. I will try to make it happen in some
future. Previous lbzip2 maintainer conducted a survey [1] about that,
but it failed to get any attention.

lbzip2 should be fully compatible with bzip2.  Incompatibilities, if
any, are treated as bugs and will be fixed upstream.

I consider the additional tools you mentioned (bzexe, bzdiff etc.) as
obsolete.  Zutils project [2] is already included in Debian [3]. It
provides better-quality tools that can be used to process several
kinds of compressed files.  It makes little sense for each package
(lbzip2, bzip2, gzip, lzip, xz, ...) to provide separate set of these
tools as shell scripts.

[1] http://lists.debian.org/debian-user/2009/11/msg01182.html
[2] http://www.nongnu.org/zutils/zutils.html
[3] http://packages.debian.org/sid/zutils


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

Bug#700680: related gentoo bug 309683

[Mikołaj Izdebski]

Hi,

 this upstream fix (commit 7d85774) could also allow gentoo to drop a patch
 that I wasn't willing to merge when I was still maintainer.

 https://bugs.gentoo.org/show_bug.cgi?id=309683

My primary motivation for making this change is consistency with gzip, bzip2
and xz. I didn't test it yet, but as far as I remember it should make
it more consistent.
It shouldn't break any valid lbzip2 usage because I am relaxing
requirements only,
but it should increase compatibility with bzip2 and ease migration to lbzip2.

If I remember correctly the Gentoo patch was doing something different
and I am not
going to adopt Gentoo behavior because it's neither symetric in terms
of compression/
decompression nor consistent with other utilities of this kind (i.e.
gzip, bzip2 and xz).
Your table from the Gentoo bug, extended with -t column:

(I may be wrong somewhere here because now I am writing enterily from what
I remember, without verifying anything.)

bzip2
 -z   -zc  -zf  -zcf  -d  -dc -df  -dcf -t  -tf
regular file 1111 1   1   111   1
symlink to regular file   111 1   111   1
device111 1   111   1
symlink to device 111 1   111   1

lbzip2 released (incl. Debian sid)
 -z   -zc  -zf  -zcf  -d  -dc -df  -dcf -t  -tf
regular file 1111 1   1   111   1
symlink to regular file11 111
device 11 111
symlink to device  11 111

lbzip2 development (git master)
 -z   -zc  -zf  -zcf  -d  -dc -df  -dcf -t  -tf
regular file 1111 1   1   111   1
symlink to regular file   M11 M   11M   1
deviceM11 M   11M   1
symlink to device M11 M   11M   1

Gentoo lbzip2
 -z   -zc  -zf  -zcf  -d  -dc -df  -dcf -t  -tf
regular file 1111 1   1   111   1
symlink to regular file11 G   G   11G   1
device 11 G   G   11G   1
symlink to device  11 G   G   11G   1

--
Mikolaj


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

Bug#700680: lbzip2 can't compress symlinks when output to stdout

[Mikołaj Izdebski]

tags 700680 fixed-upstream
--

Thank you for the report.

The bug was fixed upstream: https://github.com/kjn/lbzip2/commit/7d85774

--
Mikolaj Izdebski


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

Bug#685484: unblock: lbzip2/2.2-2

[Mikołaj Izdebski]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lbzip2

This package fixes 2 RC and 2 normal bugs, as well as several other
upstream bugs not reported in Debian BTS.

#685418 [grave] - this is just a packaging bug, it could be fixed in
wheezy without updating to new upstream version

#645999 [serious] - this bug cannot be fixed without updating to new
upstream version, this bug makes lbzip2 unusable in several use cases,
there is no way to workaround it.

#582476, #673378 - normal bugs fixed by updating to newer upstream version

Version 2.2-2 has no API/ABI changes or other incompatible changes.
All known bugs were fixed (including those not reported to Debian
BTS). I would also like to highlight that no package depends on
lbzip2, recommend or even suggest it, and lbzip2 has no depends except
libc, so chances of breaking wheezy bu unblocking bzip2_2.2-2 are (in
my opinion) minimal.


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

Bug#685418: lbzip2: build-arch target in debian/rules doesn't work

[Mikołaj Izdebski]

Hi,

 Thanks for fixing the issue in unstable!
 But I fear you will have to fix it in testing too, as I do not think RT
 will allow 2.2-2 in testing at this point of the freeze.

I submited an ublokck request (#685484). If freeze exception for new
upstream version if not granted, I will prepare a fix only for this
bug in wheezy.

Mikolaj


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

Bug#685418: lbzip2: build-arch target in debian/rules doesn't work

[Mikołaj Izdebski]

Package: lbzip2
Version: 2.1-1
Severity: grave
Justification: renders package unusable

build-arch of debian/rules doesn't work properly. The package can be
built using build target, but buildd builds packages using build-arch
and build-indep (if they are present). As a result packages built by
buildd have no content except for documentation. Such packages are
obviously completely unusable, hence the grave severity.


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

Bug#645999: lbzip2: uses excessive amounts of memory when decompressing highly compressible data

[Mikołaj Izdebski]

This bug can cause lbzip2 to allocate huge amounts of memory (more then hundreds
of gigabytes per thread). This case is not so rare, decompressing an average
hard disk image will likely trigger it as there will probably be long runs of
zeros (unallocated sectors). Even in average case memory allocation is way too
high. This in my opinion makes lbzip2 unsuitable for a stable release.

This bug was recently fixed in upstream version 2.2 and the fix should really
make into Wheezy. I am rising severity to serious.


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

Bug#643576: antlr-doc: Examples have non-commercial clause

[Mikołaj Izdebski]

The 2 files in question are DFSG-free. The copyright holder
(Oracle) relicensed them under a free software license. See:

http://docs.oracle.com/javase/tutorial/i18n/text/examples/ShowString.java
http://docs.oracle.com/javase/tutorial/i18n/text/examples/StreamConverter.java

See also: https://bugzilla.redhat.com/show_bug.cgi?id=848662


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

Bug#684585: RFS: lbzip2/2.2-1 - fast, multi-threaded bzip2 utility

[Mikołaj Izdebski]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package lbzip2

 * Package name: lbzip2
   Version : 2.2-1
   Upstream Author : Mikolaj Izdebski zurg...@gmail.com
 * URL : https://github.com/kjn/lbzip2
 * License : GPL-3+
   Section : utils

It builds those binary packages:

  lbzip2 - fast, multi-threaded bzip2 utility

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/lbzip2

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/l/lbzip2/lbzip2_2.2-1.dsc

More information about lbzip2 can be obtained from https://github.com/kjn/lbzip2

Changes since the last upload:

  * New upstream release:
- limited memory allocation, closes: #645999,
- improved bzip2 compatibility, closes: #582476,
- fixed several other minor bugs, closes: #673378.
  * debian/control:
- drop version requirements on autotools,
- bump Standards-Version to 3.9.3.
  * debian/copyright:
- remove comment about maintainers involved in creation of the package,
- update to reflect new upstream version.
  * debian/rules: execute Bourne shell scripts with sh instead of perl.
  * debian/compat: Bump to 9.


Regards,
Mikolaj Izdebski


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

Bug#673378: lbzip2: fails unpacking files with result grather then 4 GB

[Mikołaj Izdebski]

tags = confirmed upstream
quit

Hello Andreas,

thank you for reporting the bug.

I confirm this assertion failure. This is a known implementation bug
introduced in upstream lbzip2 2.0. It has already been resolved and
it's going to be fixed in a future upstream release.

I'm removing lfs tag as this bug has nothing to do with large file
support. On Debian GNU/Linux and GNU/kFreeBSD lbzip2 supports large
files up to kernel internal limits (often dependent on file system
type).

Mikolaj Izdebski



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

Bug#671786: transmission: segfaults after download is canceled

[Mikołaj Izdebski]

Package: transmission-gtk
Version: 2.51-1
Severity: normal


Steps to reproduce:
1. Run transmission-gtk 'magnet:?xt=urn:btih:This+Is+A+Dummy+Torrent+InfoHash'
2. As soon as the dialog window pops up, press Cancel button
3. Close the main window

I can reproduce the bug only if I close the dialog quickly enough.
Not reproducible under valgrind.


GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/transmission-gtk...Reading symbols from
/usr/lib/debug/usr/bin/transmission-gtk...done.
done.
(gdb) r magnet:?xt=urn:btih:This+Is+A+Dummy+Torrent+InfoHash
Starting program: /usr/bin/transmission-gtk
magnet:?xt=urn:btih:This+Is+A+Dummy+Torrent+InfoHash
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x7fffeae8a700 (LWP 18031)]
[New Thread 0x7fffea689700 (LWP 18032)]
[New Thread 0x7fffe9e88700 (LWP 18033)]
[New Thread 0x7fffe9687700 (LWP 18034)]
[New Thread 0x7fffe8e86700 (LWP 18035)]
[Thread 0x7fffe8e86700 (LWP 18035) exited]
[New Thread 0x7fffe8e86700 (LWP 18037)]
[New Thread 0x7fffdeeaf700 (LWP 18038)]
[New Thread 0x7fffde6ae700 (LWP 18039)]
[New Thread 0x7fffddead700 (LWP 18040)]
[New Thread 0x7fffdd6ac700 (LWP 18041)]
[Thread 0x7fffddead700 (LWP 18040) exited]
[Thread 0x7fffeae8a700 (LWP 18031) exited]
[Thread 0x7fffde6ae700 (LWP 18039) exited]
[Thread 0x7fffe8e86700 (LWP 18037) exited]
[New Thread 0x7fffe8e86700 (LWP 18042)]
[Thread 0x7fffdd6ac700 (LWP 18041) exited]
[New Thread 0x7fffdd6ac700 (LWP 18043)]
[New Thread 0x7fffde6ae700 (LWP 18044)]
[Thread 0x7fffde6ae700 (LWP 18044) exited]
[New Thread 0x7fffde6ae700 (LWP 18045)]
[Thread 0x7fffde6ae700 (LWP 18045) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9e88700 (LWP 18033)]
tr_sessionLock (session=0x) at session.c:1043
1043session.c: No such file or directory.
(gdb) bt full
#0  tr_sessionLock (session=0x) at session.c:1043
No locals.
#1  0x0045be70 in tr_torrentLock (tor=optimized out) at torrent.h:305
No locals.
#2  tr_torrentRecheckCompleteness (tor=0xae6300) at torrent.c:2028
completeness = optimized out
#3  0x0045d409 in torrentRecheckDoneImpl (vtor=optimized out)
at torrent.c:1698
tor = 0xae6300
#4  0x004628e6 in readFromPipe (fd=13, eventType=optimized out,
veh=0x7fffe400c910) at trevent.c:192
data = {func = 0x45d400 torrentRecheckDoneImpl, user_data = 0xae6300}
nwant = 16
ngot = optimized out
ch = 114 'r'
ret = optimized out
eh = 0x7fffe400c910
#5  0x74b8ea4c in event_base_loop () from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#6  0x004627a0 in libeventThreadFunc (veh=0x7fffe400c910)
at trevent.c:248
base = 0x803cf0
eh = 0x7fffe400c910
---Type return to continue, or q return to quit---
#7  0x0044ec4a in ThreadFunc (_t=0x7fffe400b240) at platform.c:118
t = 0x7fffe400b240
#8  0x73c52b50 in start_thread (arg=optimized out)
at pthread_create.c:304
__res = optimized out
pd = 0x7fffe9e88700
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737117718272,
7762726597842260300, 140737283215776, 140737117718976,
140737354125376, 3, -7762678094867115700,
-7762700267951140532}, mask_was_saved = 0}}, priv = {pad = {
  0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
  canceltype = 0}}}
not_first_call = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#9  0x7399d90d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#10 0x in ?? ()
No symbol table info available.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages transmission depends on:
ii  transmission-cli 2.51-1
ii  transmission-common  2.51-1
ii  transmission-gtk 2.51-1
ii  transmission-qt  2.51-1

transmission recommends no packages.

transmission 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#641019: pristine-tar does not work with tar files made by openSUSE

[Mikołaj Izdebski]

 From theoretical point of view, for every plain (uncompressed) file
 there exist *infinite* number of bz2 compressed files that correctly
 decompress to the plain file.

 pristine-tar consists of a bet that, while this is certianly the
 theoretical case, the number of actual implementations of a compressor
 for a given file format will be manageable, and that moreover
 implementations will deterministically produce the same result for a
 given set of inputs.

 There are two reasons to think this is the case. First, the 80/20 rule
 applies; most people who want to compress a file with bzip2 are going
 to do it using one of a few commonly available implementations, using
 more or less the default parameters.

Do you consider alternative bzip2 implementations available in Debian
(lbzip2, pbzip2, p7zip-full, libcommons-compress-java) as commonly
available implementations? They all produce different compressed
files for the same input file. Moreover, lbzip2-0.23 from stable
produces different files than lbzip2-2.1 from unstable.

Should any incompatibility with all those compressors be reported as
separate, independent pristine-tar bugs? If yes, I'd be happy to do
so.

 Secondly, pristine-gz is known to reproduce nearly every gzip file used in a
 source package in Debian, which were created across a wide span of time,
 on a diverse set of operating systems.

I believe that pristine-tar generates binary diffs for gzip files it
fails to reproduce, but doesn't do the same for bzip2 files. Maybe
implementing such feature for bzip2 files is the solution?

 Of course an implementation of an unstable sorting algorithm could use
 some value that varies between runs (ie, something based on the current
 time or memory layout) to break ties in its comparison function, but at
 least for gzip (and compress) implementations, that does not seem to
 have ever been the case.

My point was that block size isn't the only factor the resulting file
depends on. There is also a work factor, as described in bzip2
documentation. Even the same version of bzip2, with the same block
size given, for the same input can produce different outputs, given
that work factors are different. A proof of concept is available in
lbzip2 git repo:

   https://raw.github.com/kjn/lbzip2/master/tests/incomp

Mikołaj



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

Bug#641019: pristine-tar does not work with tar files made by openSUSE

[Mikołaj Izdebski]

 Do you consider alternative bzip2 implementations available in Debian
 (lbzip2, pbzip2, p7zip-full, libcommons-compress-java) as commonly
 available implementations? They all produce different compressed
 files for the same input file. Moreover, lbzip2-0.23 from stable
 produces different files than lbzip2-2.1 from unstable.

 I have not seen files produced by these yet afaik, but it's sure nice to
 have a list to try when someone comes with a weird file; I did not know
 about some of those!

It's a vicious circle. People refrain from using alternative bzip2
implementations partly because pristine-tar doesn't support them. And
pristine-tar doesn't support them because they're not used widely
enough. For example I didn't compress my Debian lbzip2 package with
lbzip2 itself only because of problems with pristine-tar!

 Even bzip2 changed its output after 0.9.5d -- I have a program that uses
 the compressor from the old version since some files needed it.

Not the first and not the last time. The last change I'm aware of was
in Oct 2004 (version 1.0.3). This means that with default parameters
bzip2 1.0.2 and 1.0.3 can produce different files.

 I believe that pristine-tar generates binary diffs for gzip files it
 fails to reproduce, but doesn't do the same for bzip2 files. Maybe
 implementing such feature for bzip2 files is the solution?

 I'll add it if I see a bz2 file that can nearly exactly be reproduced
 and only needs the delta to get the rest of the way. Haven't yet.

Does an artificially crafted bz2 file count? If so, I can easily create one.



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

Bug#646331: flex: Scanners with -F or -f crashes

[Mikołaj Izdebski]

Hi,

For me it looks like you are running flex in 7-bit mode, which is
default. If your input file contains bytes above 127 you should be
invoking flex with -8 (generate 8-bit scanner).

Can you reproduce this bug with -8 given?

Mikołaj Izdebski



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

Bug#641019: pristine-tar does not work with tar files made by openSUSE

[Mikołaj Izdebski]

Hello,

This bug is much more generic.

From theoretical point of view, for every plain (uncompressed) file
there exist *infinite* number of bz2 compressed files that correctly
decompress to the plain file.

In practice there exists number of different compressors that can
create different compressed files. Those include lbzip2 and pbzip2,
which may become even more popular as number of CPU cores increases
rapidly.

Even the newest version of unmodified upstream (or Debian) bzip2 can
produce different compressed files with the same block size. Basically
it's because bzip2 internally uses shellsort and quicksort, which
aren't stable sorting algorithms. Block-sorting can therefore produce
different results under different circumstances. If anyone cares I can
provide a proof-of-concept and/or explain why that happens.

The same thinking applies to gzip-compressed files.

IMO this bug should be merged with #563651, renamed to something like
does not support tarballs compressed with alternative compressors
and tagged wontfix (unless there is a sane solution, which I can't
think about now).

Mikołaj

PS. I know the internals of bzip2 *really* well. I am open for
discussion about any possible solutions.



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

Bug#645999: (lbzip2: uses excessive amounts of memory when decompressing highly compressible data)

[Mikołaj Izdebski]

 If anyone is interested I can prepare an appropriate patch. Just let me know.

 Mikołaj,

 I am interested in a patch.

I am about to implement this solution in a newer version of lbzip2. I
may be able to backport the patch to 0.23.

 I looked over lbzip2 code enough to realize I couldn't think of a simple
 patch for this issue.  I was thinking it would be simple to limit the
 number of memory buffers between worker and muxer.  Then looking at how
 blocks are split into input for the workers, started to worry that
 this would get into trouble with deadlocks on blocks which are split
 between two input blocks.  So I filed a bug with no patch.  ;)

 My guess of the easiest way to fix this is to change the behavior
 of the splitter.  Instead of sending random blocks of input to the
 worker threads for them to split, the splitter actually reads and scans
 for the block markers at the same time and passes along single blocks into
 a queue of worker threads.  Then a worker who is picking up a new block
 to decompress can check if he is too far ahead of the muxer and then
 block/wait for the muxer to catch up.

I don't think this would scale well. The scanner implemented in lbzip2
0.23 is naive and slow. As Laszlo said, splitter would be the
bottleneck.

I am currently working on lbzip2 2.0, which is going to include some
new features, among which there is a command-line option for limiting
max memory usage during decompression. I hope lbzip2 2.0 can be
released within a month.

 On Thu, 20 Oct 2011 20:23:05 +0200 (CEST) Ersek, Laszlo 
 la...@caesar.elte.hu wrote:
 I'll tell you this: you might want to check out pbzip2; I believe
 pbzip2 should have a working memory throttle staring with v1.1.2.

 Laszlo,

 Yes, thanks for the suggestion.  I do fallback on pbzip2 when lbzip2 fails.

 I used to use pbzip2, back then decompression required it to read the
 input file twice, first pass was single threaded and scanned for block
 markers, the second read was feed to worker threads to decompress... for
 large input streams (anything larger than fit in ram) that implementation
 sucked as it was input I/O bound for many minutes before generating
 any output.  This double read also prevented it from decompressing pipes.

 At that time, I think due to the double I/O, lbzip2 was wall clock faster
 for any given input stream.  I see now that the pbzip2 I/O layer has
 changed and it appears to support pipes and scans input only once.

 I should re-compare them.

The problem with pbzip2 splitter is that (AFAIK) it recognizes stream
boundaries only (bz2 files consist of streams, streams consist of
blocks). That's no problem if you decompress files created by lbzip2
= 0.23 or pbzip2.

Again, you should probably wait for lbzip2-2.0. Wall clock times are
usually much better compared to 0.23 (or pbzip2), for example on my 4
core amd64 desktop:

$ time lbzip2-2.0 -dkf linux-3.0.4.tar.bz2
real 9.03
user 29.78
sys 1.61
$ time lbzip2-0.23 -dkf linux-3.0.4.tar.bz2
real 16.29
user 53.90
sys 1.92



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

Bug#645999: lbzip2: uses excessive amounts of memory when decompressing highly compressible data

[Mikołaj Izdebski]

There is a simple way of solving this issue. Changes that need to be made:

1) Make workers return slots directly to the splitter, not to the muxer.

2) Introduce a new kind of slots, passed between the muxer and
workers. One slot grants the right to allocate a 1MB block for output
buffer. Whenever a worker is about to allocate memory for output
blocks, it needs to acquire a slot from the muxer. If there are no
free slots, the worter must wait. However, to avoid possible
deadlocks, the muxer will always grant slots to the worker that is
processing the block the muxer is expecting to receive next
(reord_needed).

This algorithm is simple, but works. Of course there are better, more
sophisticated algorithms for managing memory. One of them is to be
implemented in lbzip2-2.0, which is under development.

If anyone is interested I can prepare an appropriate patch. Just let me know.



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