Re: [gccsdk] Unable to autpbuild libpng12-0

Hi,

Thanks for that, guys.

I did a bit of digging after my email, and it did appear as thought it was the transition from Wheezy to Stretch that caused the problem for other people on standard Linux, but I didn't know how to get older versions used (now I've got a good pointer once I know where they can be located :) ).

It's now built with the AB_URL fix above (although libsdl2 isn't building - problem with Khronos - although I'm still looking at that)...

On Mon, 2 Oct 2017 at 16:38 Theo Markettos <theo@markettos.org.uk> wrote:

On Mon, Oct 02, 2017 at 04:15:12PM +0100, Lee Noar wrote:
> No, something has changed; I can't build it either. It was okay in June
> when I last built it. As a work around for this package, you can add:
>
> AB_URL=http://http.debian.net/debian/pool/main/libp/libpng/libpng_1.2.50.orig.tar.xz
>
> to the top of its setvars file until we figure out what's going on.
>
> If it turns out to be more widespread, ie, others packages are the
> same, then perhaps they've changed the server's name or structure
> and we need to catch up.

I think this is the result of Debian releasing version 9 'stretch' in July.

Since we mostly pick up sources from the 'stable' and/or 'testing' Debian
repos, a new Debian release means they advance their sources according to
their release schedule (so now stable='stretch' and testing='buster',
eventually to be v10).  That may break RISC OS packaging scripts that look
for or depend on specific package names from a previous release.  Libraries
with the version number in the package name are particularly vulnerable.

In stretch the package is libpng-dev (for the header files) and libpng16-16
(for the library binaries) so it would be worth renaming to libpng16-16 and
see if it's possible to build that.  If so, it's probably worth changing the
'depends' files of packages that depend on libpng12 to libpng16-16.  It may
be we need to retain the libpng12 package because some programs won't work
with libpng 1.6, in which case pinning it to the source tarball as Lee
indicates above is probably going to be necessary.  But we should move as
much as possible to 1.6.

A rename is simply renaming the folder inside the autobuilder/ tree, and
possibly changing the setvars script inside it as well.  The autobuilder
scripts should pick that up and find the right sources.

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK