Bugzilla Bug 171847

Ghostscript 8.56 has been released.  I've haven't tried a local bump, sorry.

This description seems out of date now that leading edge development is done
under the GPL:
DESCRIPTION="GPL Ghostscript - the most current Ghostscript, AFPL, relicensed"

How about:

DESCRIPTION="GPL Ghostscript - an interpreter for the PostScript language"
or:
DESCRIPTION="an interpreter for the PostScript language"

although the latter is not consistent with the other ghostscript-* ebuilds...

Can you please try it out? I am using gs-esp

Created an attachment (id=115707) [details]
ghostscript-gpl-8.56.ebuild.diff

- only build djvu support w/ USE="-bindist" (see
http://djvu.sourceforge.net/gsdjvu/COPYING for reasons), adjust LICENSE
accordingly, adjust IUSE accordingly
- Fix SRC_URI and S for new tarball name
- add loads of quoting all over the place

This is a work in progress, I fixed ghostscript-afpl-8.54-cups-lib.patch
(attached below), the other patches need work as well.

Created an attachment (id=115709) [details]
ghostscript-afpl-8.56-cups-lib.patch

Updated ghostscript-afpl-8.54-cups-lib.patch (dropped one hunk that would only
add comments now).

ghostscript-afpl-8.54-big-cmap-post.patch fails as well (5/9 hunks, see below,
the others will pretty likely need work as well). I don't have time for this
now.

Created an attachment (id=115836) [details]
app-text/ghostscript-gpl/ghostscript-gpl-8.56.ebuild

ebuild with jakub's patch applied and everything that fails commented out.

I was trying to replace ghostscript-afpl-8.54-destdir.diff with some sed magic.

#       epatch "${FILESDIR}"/ghostscript-afpl-8.54-destdir.diff
        sed -i -e 's:\$(BINDIR):\$(DESTDIR)\$(BINDIR):' \
                   -e 's:\$(GS_SHARE):\$(DESTDIR)\$(GS_SHARE):' \
                   -e 's:\$(prefix):\$(DESTDIR)\$(prefix):' \
                   -e 's:\$(datadir):\$(DESTDIR)\$(datadir):' \
                   -e 's:\$(gsdir):\$(DESTDIR)\$(gsdir):' \
                   -e 's:\$(gsdatadir):\$(DESTDIR)\$(gsdatadir):' \
                   -e 's:\$(bindir):\$(DESTDIR)\$(bindir):' \
                   -e 's:\$(libdir):\$(DESTDIR)\$(libdir):' \
                   -e 's:\$(scriptdir):\$(DESTDIR)\$(scriptdir):' \
                   -e 's:\$(docdir):\$(DESTDIR)\$(docdir):' \
                   -e 's:\$(mandir):\$(DESTDIR)\$(mandir):' \
                   -e 's:\$(exdir):\$(DESTDIR)\$(exdir):' src/*.mak

unfortunately this wasn't exactly right, cause now emake install failed.

app-text/ghostscript-gpl-8.57 has been released.

Marijn's 8.56 ebuild worked for me, but I changed following:

DESCRIPTION="Ghostscript, an interpreter for the PostScript language and for
PDF."
HOMEPAGE="http://ghostscript.com/"
MY_P=ghostscript-${PV}

MY_P is obviously not needed. I was using the gs-gnu ebuild accidentialy,
because BugZilla sent me to the next bug in the list.

Created an attachment (id=121811) [details]
ghostscript-gpl-8.57.ebuild

Marijn's 8.56 ebuild altered for 8.57, additional info:

fixed upstream:
ghostscript-afpl-8.54-ps2epsi-afpl.diff - fixed in 8.57
ghostscript-afpl-8.54-destdir.diff - fixed in 8.57
ghostscript-afpl-8.54-segfault.patch - fixed in 8.57
ghostscript-afpl-8.54-gtk2.patch - seems to be fixed in 8.57

updated/still needed patches:
ghostscript-afpl-8.56-cups-lib.patch - updated patch
ghostscript-afpl-8.54-rinkj.patch - not fixed, still needed

still needed "addon" patches
ghostscript-afpl-8.54-cups-destdir.diff - still needed
gdevcups.patch - still needed
djvu-gs-gpl.patch - still needed

failing/commented out patches:
ghostscript-afpl-8.54-big-cmap-post.patch - does not apply, couldn't find any
references on http://bugs.ghostscript.com/ about what this patch is good for

Created an attachment (id=121813) [details]
ghostscript-afpl-8.57-cups-lib.patch

renamed Jakub's patch for 8.57, just for convenience.

thank you. I committed this.

btw, I am really looking forward to the new release which includes gs-esp :)

Hi all,
I noticed that the package does not produce libgs.so anymore (it is needed by
gsview and maybe other tools)
I think adding a make so and make soinstall in the ebuild could be useful, and
we could use an use flag to do it or not..

-- 
cJ