FS#49624 - [zlib,minizip] can zlib include minizip

Attached to Project: Arch Linux
Opened by Florian Bruhin (The-Compiler) - Wednesday, 08 June 2016, 15:48 GMT
Last edited by Pierre Schmitz (Pierre) - Saturday, 03 December 2016, 08:53 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

It seems Arch switched from the upstream minizip to some GitHub fork with epoch 1:
https://git.archlinux.org/svntogit/community.git/commit/trunk/PKGBUILD?h=packages/minizip&id=d95c6b6488e0a6f27165902fe48c1e4ba1ddfa55

However, that is incompatible with the upstream minizip:
https://github.com/nmoinvaz/minizip/commit/50665d2d596ab2f0ac132c99f01354112a63e837
https://github.com/nmoinvaz/minizip/blob/master/ChangeLog

The "Clean up & changed unzLocateFile to support custom comparison function" change changed the signature of unzLocateFile:

-extern int ZEXPORT unzLocateFile OF((unzFile file,
- const char *szFileName,
- int iCaseSensitivity));
+extern int ZEXPORT unzLocateFile OF((unzFile file, const char *filename, unzFileNameComparer filename_compare_func));

This means packages which depend on minizip, such as qt5-webengine, no longer build successfully:
https://bugreports.qt.io/browse/QTBUG-53933

I think this package should be reverted to the upstream one, and perhaps the fork packaged as a separate thing. Not sure what else broke in that monster "cleanup" commit either...
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Saturday, 03 December 2016, 08:53 GMT
Reason for closing:  Implemented
Comment by Alexander F. Rødseth (xyproto) - Saturday, 11 June 2016, 18:05 GMT
The latest version of Minizip from that page is 12 years old. I can't remember the exact reason I switched to the version that is on GitHub, but I can imagine that it was because of the combination of it not building together with the sources not being maintained. Will take another look at the old sources.
Comment by Alexander F. Rødseth (xyproto) - Saturday, 11 June 2016, 18:38 GMT
Replied to the bug report at https://bugreports.qt.io/browse/QTBUG-53933.
Comment by Alexander F. Rødseth (xyproto) - Saturday, 11 June 2016, 18:45 GMT
Seems like there might be (at least) two different minizip projects.

Pierre, could minizip from the zlib tarball be included in the zlib package, so that this minizip package can be moved to AUR instead (or be removed)?
Comment by Florian Bruhin (The-Compiler) - Saturday, 11 June 2016, 18:48 GMT
FWIW it seems like Arch's QtWebEngine is going to use the bundled minizip:

2016-06-09 09:14:07 <arojas> The-Compiler: i switched to internal minizip for 5.7
Comment by Antonio Rojas (arojas) - Saturday, 11 June 2016, 19:09 GMT
@Florian that's just a workaround until this is sorted out. I agree that minizip should be built from the zlib sources, as Fedora and Gentoo do. Since it's only 85kB and doesn't add any extra dependency, it can even be shipped in the zlib package itself.
Comment by Alexander F. Rødseth (xyproto) - Thursday, 07 July 2016, 16:36 GMT
Assigning to zlib package maintainer.
Comment by Antonio Rojas (arojas) - Friday, 11 November 2016, 20:39 GMT
ping Pierre, any decision about this? This is preventing building qt against system zlib, which is not good. If you don't want to include this in the zlib package let us know so we can package it separately
Comment by Pierre Schmitz (Pierre) - Sunday, 20 November 2016, 10:38 GMT
I have build a minizip split package which is currently in [testing]. minizip from [community] has to be remove once this package hits [core].
Comment by Doug Newgard (Scimmia) - Tuesday, 22 November 2016, 05:21 GMT
Package in Community has an epoch, this one will need it added.

Loading...