01:09 mi 

Upgrade from 1.3.1-4 to 1.3.1-10 (security fixes).

Resolve errors triggered on -current by the use of C++17

PR:		225299

 

16:57 mi 

Upgrade from 1.3.1-3 to 1.3.1-4. The only real change (outside of the auto*
nonsense) is the
restoration of the padding at the end of CDirEntry.

Clang++ used to flag it as unused private field, which lead to its removal
(incorrectly) -- and
this new release from upstream restores the padding. It is still flagged by
clang++ so a new patch
attempts to suppress that.

 

22:46 mi 

Update from 1.3.1-2, which is no longer available for download, to
1.3.1-3 -- which contains all of our patches reported to date.

Add a patch by stefanf@, which allows the port to build on 10.x
Though I'll try to submit the patch upstream as before, I'll try
to persuade them to not remove the 1.3.1-3 again after the apply
it and "release" 1.3.1-4

PR:		182009, 182005, 181779
Obtained from:	stefanf

 

05:22 mi 

Update to upstream's 1.3.1-2. Fix up the warnings raised by clang (3.2) and
gcc (4.8).

PR:	181302
Submitted by:	delphij@
Tested by:	ImageMagick's self-test suit

 

04:14 mi 

Upgrade from 1.2.x to 1.3.1-1 now that the upstream finally contains new
code (rather than simply updates to auto- configuration glue):

Notified by:	Steve Wills

via

PR:	ports/171812

The changes are minor, thus shared-library bump.

Fix several of the warnings, which GNU compiler missed, but clang uncovered
(which broke the build because of -Werror):

Notified by:	Andreas Nilsson, Thomas Zander

 

14:12 ohauer 

-remove MD5

12:42 mi 

Add a mega-patch, which makes the library usable. It barely worked on
even i386 before, and does not anymore, as its numerous original bugs
were exposed by the evolving compiler. It never worked on a 64-bit
platform, as the original authors assumed sizeof(long) to be 4.

With this patch it compiles cleanly (WARNS=3) on both i386 and amd64
and should have no problems on other 64-bit systems.

A corrupt input-file may still result in a crash, but, at least, it
works correctly with correct input files. Tested on camera-generated
originals kindly provided by the originator of the PR below.

Bump PORTREVISION.

Approved by:    portmgr (pav, after some deliberations)

Portmgr advised against bumping the SHLIB_MAJOR. They did not /insist/
so I chose to bump it -- the old version is too broken to have been
usable to anybody for years, and the dependant ports (such as Graphics
and ImageMagicks) need an easy way to insist on the new version (via
LIB_DEPENDS).

Was required to fix:    67815

12:35 edwin 

SHA256ify

Approved by: krion@

17:43 mi 

Bump from 1.2.0.11 to 1.2.0.12

Apparently, ImageMagick, realized, that their earlier rip-off "release"
(1.2.0.11) of GraphicsMagick's tar-ball (1.2.0.10) had "GraphicsMagick"
in several $Header$ fields.

So they cut another "release", which brings a slightly updated
libtool/autoconf soup, and GraphicsMagick duly replaced by ImageMagick
in all of those pesky $Header$ lines.

There are no functional differences WHATSOEVER in the source files, but
the earlier 1.2.0.11 is no longer available.

Notified by:    all recent builders of ImageMagick

20:59 mi 

This package has a controversial history. It was originally "given" to
the ImageMagick team, where Bob Friesenhahn made it work with IM.

Since then, Bob and other developers forked GraphicsMagick. libfpx
remained unchanged until January 2005, when ImageMagick released an
updated tar-ball with a patch applied. The release was botched (missing
a subdirectory) and I changed the port to use the old tar-ball on
GraphicsMagick's site and apply the same patch.

Since then, GraphicsMagick replaced the old 1.2.0.9 tarball with the new
1.2.0.10, where the patch is applied. On the same date, ImageMagick,
not to be outdone, "released" 1.2.0.11, WHICH IS NO DIFFERENT from
GraphicsMagick's version, except for libtool/configure soup.

I'm now switching the port to ImageMagick's mirrors again, simply
because they seem to have better bandwidth.

I must add, for the record, that ImageMagick team's behavior appears
rather dubious and unscrupulous in this incident. There was no need to
"release" their own tarball, especially considering, that some sources
are marked as "GraphicsMagick" (an embarassing oversight). I also
found, that those of my postings on ImageMagick's support forum, which
mentioned GraphicsMagick, were misteriously removed from the board
shortly after posting...

This update is made neccessary by there being no MASTER_SITES for the
original 1.2.0.9 tarball left. While at it, however, I also remove the
jpeg-dependency -- libfpx does not, actually, use it.

Prompted by: pointyhat  (kris)

23:19 mi 

There is a new tarball out there called 1.2.0.9-1, which is incomplete
and does not build.

Use GraphicsMagick's copy for the time being, but apply the only fix
mentioned in the new tarball's ChangeLog.

Bump PORTREVISION. Clean up a little while I am here -- no need for
REINPLACE any more.

Notified by: Michael Metzger (via pav@)

03:12 trevor 

SIZEify (maintainer timeout)

03:46 mi 

Upgrade to 1.2.0.9. All our patches are in now...

PR:             53595
Submitted by:   Melvyn Sopacua

15:16 mi 

Upgrade to 1.2.0.8, which contains some of our patches. Add two more,
which should solve some crashes and allow to compile with a non-GCC
compiler (Re: zero-sized arrays).

Unfortunately, this still crashes on some images, but the vendor has
already pulled the 1.2.0.7 from the mirrors, so this upgrade will, at
least, keep things downloadable.

23:30 mi 

Upgrade from 1.2.0.4 to 1.2.0.7 released on April 12th. May need
careful testing on other architectures, though...

Compelled by: Chris P.

06:30 mi 

The ImageMagick crew took this library over and released the 1.2.0.4.   The
changes:    

08:52 mi 

Upgrade to 1.2.0-3. Minor improvements. One of our patches got   incorporated. 
Hey!    

20:35 will 

Add libfpx 1.2.0, library routines for working with Flashpix images.