Report error received from zip_close

[Dirk Hohndel]

On Mon, Oct 26, 2015 at 01:22:25PM +0200, Lubomir I. Ivanov wrote:
> On 26 October 2015 at 09:54, Rick Walsh <rickmwalsh at gmail.com> wrote:
> > On 26 October 2015 at 18:42, Dirk Hohndel <dirk at hohndel.org> wrote:
> >>
> >> That's what I get for assuming that libzip has a stable API. Silly, of
> >> course. I'll need to check the specific commit that Lubomir has tested as
> >> known good and see which API is apropriate for this one (and I should
> >> check if there is a way to check at compile time which API is available).
> >>
> 
> no, one of the libzip maintainers pointed out that they are making a
> major API rework before 1.0 is released.
> 
> >
> > For what it's worth, I have the version in the F22 repository,
> > 0.11.2-5.fc22.  It appears that libzip v1.0 was released in May this year
> > (first release since 0.11.2 in December 2013), so hopefully that means the
> > API will be more stable from now on, once all the distros catch up.
> >
> 
> months or years could pass before the distros catch up, so instead
> it's probably better to maintain a local repository, the same way we
> do with Marble and such.
> basically, the newer libzip is only needed for Windows to work with
> spacial paths (UTF-16), older libzip works fine on Linux and OSX
> (UTF-8) paths but if we use new API calls from 1.0, the distro builds
> will break.
> 
> a local repository is the way to go.

Actually - you and I are the only two people to build Windows binaries.

So what we really need to do is

a) go back to only use 0.11.2 APIs (I will do that tonight)
b) figure out why the F@(k the libzip I build doesn't work $#^(&$@

/D