reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60256] Crash when building Zip/Unzip after macOS upgrade


From: Mohammad Akhlaghi
Subject: [bug #60256] Crash when building Zip/Unzip after macOS upgrade
Date: Fri, 16 Jul 2021 19:00:58 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Follow-up Comment #2, bug #60256 (project reproduce):

Thanks for the great review of the problem Boud. It was very clear and full of
good points (to learn from).

> With our current definition of gbuild in build-rules.mk, there are no
options for modifying the configure file after unpacking the tarball and
before configuring
We actually have a hack for this in some packages, like CFITSIO
<http://git.maneage.org/project.git/tree/reproduce/software/make/high-level.mk#n405>
(where we unpack the main source, fix the configure script, package it again
and give the modified package to 'gbuild'.

But I agree, that having this done directly within 'gbuild' as an extra option
would be very useful/clean. Generally, both 'gbuild' and 'cbuild' should be
changed into scripts to allow easier editing. I just defined task #16017 for
this.

> ... after upgrading macOS to Big Sur 11.2.3, it crashes at the installation
of Zip/Unzip
I just had a look at the build instructions of Zip/Unzip in Homebrew
<https://formulae.brew.sh/formula/zip>, I see that it builds on Big Sur.

When I look into the Homebrew instructions for Zip
<https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/zip.rb>, I see
that they also say that "Upstream is unmaintained", so they use Debian's
tarball, and apply 10 patches! The patches are available on Debian
<https://sources.debian.org/patches/zip/3.0-12/>. Probably its easier if we
apply those patches, build a tarball from the patched source, and put that
tarball on our own copy of software Zenodo. 

But in any case, a fast look at the names of the patches, doesn't hint at them
being related to 'memset' unfortunately.

It is very sad to see that no-one has taken the role of maintaining such a
commonly used package! The same thing happened to Bzip2 when we started
building software in Maneage (its core developer stopped developing it and it
was only available from Debian). However, after looking again while writing
this, I was happy to see Bzip2 development is now active again
<https://sourceware.org/bzip2/downloads.html>. 

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?60256>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]