Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#18285 - [zlib] Latest zlib causes bug in jzip (zork game interpreter)

Attached to Project: Arch Linux
Opened by David Rosenstrauch (darose) - Thursday, 11 February 2010, 04:59 GMT
Last edited by Pierre Schmitz (Pierre) - Saturday, 06 March 2010, 01:23 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Bug was introduced somewhere between zlib 1.2.3.4 and 1.2.3.7 which causes the jzip game interpreter to fail to properly interpret z compressed game files.

Additional info:
* package version(s)

zlib 1.2.3.4-4 is last known working version

* config and/or log files etc.

none

Steps to reproduce:

* Downgrade to zlib 1.2.3.4-4 (PKGBUILD tarball available at: http://www.darose.net/zlib-1.2.3.4-PKGBUILD.tar.gz)
* build & install jzip package in AUR
* build & install zork1 package in AUR
* "zork1" runs correctly
* Upgrade to current zlib (1.2.3.7-2)
* "zork1" fails; jzip is unable to read the compressed file correctly
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Saturday, 06 March 2010, 01:23 GMT
Reason for closing:  Upstream
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 13 February 2010, 17:38 GMT
  • Field changed: Status (Unconfirmed → Waiting on Response)
  • Field changed: Category (Packages: Core → Upstream Bugs)
  • Task assigned to Pierre Schmitz (Pierre)
Can be a bug in zlib or in these package of AUR. Please report to the games developers. I guess this can be closed as "invalid" and request reopen if from upstream says that is a bug in zlib.
Comment by Pierre Schmitz (Pierre) - Sunday, 14 February 2010, 19:08 GMT
This project looks quite dead with its last release 10 years ago.
Comment by David Rosenstrauch (darose) - Tuesday, 16 February 2010, 03:37 GMT
Jzip is not the issue. (Which is why I filed this as a zlib bug.)

I'm the package maintainer for jzip. It's been working for ages, and has not changed in a long time - hence jzip is not the source of the bug.

Plus I tried to run the game using a different z-code interpreter (frotz I think?) with the same result.

So again, jzip is not the issue here. There's a bug in zlib which causing it to incorrectly unzip z-code games.

This can be easily seen - and easily recreated - since switching between zlib 1.2.3.4 and 1.2.3.7 makes the bug appear. You should be able to easily recreate and confirm this behavior yourself.

Seems to me a clear case of a bug in zlib ...
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 16 February 2010, 04:04 GMT
* maybe new zlib is buggy.
* maybe new zlib is more strict with standard then, badly implemented programs does not work.

What I would do in his case is investigated. First start to compile intermediate releases. After detecting the wrong version, try to see changes between them. Which would have any possible relationship and would remove it, compile again zlib, and see the effects. I would contact zlib developers indicating what the problem and request assistance.
Comment by Pierre Schmitz (Pierre) - Tuesday, 16 February 2010, 09:56 GMT
Just because X breaks when you update Y does not mean that there is a problem in Y. E.g. libxml2 breaks, too and it was clearly a libxml2 bug. So, you have at frist to look at jzip and pin down which zlib calls don't work anymore as expected.
Comment by David Rosenstrauch (darose) - Tuesday, 16 February 2010, 18:16 GMT
Contacted upstream author. Will report back.
Comment by David Rosenstrauch (darose) - Tuesday, 16 February 2010, 19:34 GMT
He and I have been discussing, and we're both a bit puzzled:

What's the deal with zlib v1.2.3.7? The latest official release at sf.net/zlib.net seems to be v1.2.3 (released in 2005). The source for v1.2.3.7 seems to be hosted by Arch. (ftp://ftp.archlinux.org/other/zlib/zlib-1.2.3.7.tar.gz)

Is Arch maintaining its own fork of zlib? And if so, why?
Comment by Pierre Schmitz (Pierre) - Tuesday, 16 February 2010, 20:29 GMT
That's no fork. We are just mirroring the sources. These are prereleases. And it looks like as version 1.2.3.8 (currently in [testing]) will be released as 1.2.4 with only minimal changes. And I guess that one will be advertised on their homepage as well. The release cycles for the "stable" versions are just a little long, so we switched to those prereleases some time ago. (afaik there were some bugs fixxed in those versions; cannot recall which one exactly but you'll find a chagnelog in the tar) Debian does the same btw: http://packages.qa.debian.org/z/zlib.html
Comment by David Rosenstrauch (darose) - Friday, 26 February 2010, 16:24 GMT
From the jzip author:

"[There's] a patch that works, but should not be necessary. [You need] to do a full gzrewind() on the file before the gzseek() to get the page, instead of seeking straight to the page. This [resolves] the issue, even though it shouldn't be required."

Going to try to find out more info from the zlib people whether it's a zlib bug or not.
Comment by Pierre Schmitz (Pierre) - Saturday, 06 March 2010, 01:23 GMT
I suggest to request re-open this if it's really a zlib issue in the end.

Loading...