[Slackbuilds-users] Advice needed: no libpng14.la

[Andreas Guldstrand]

webkitgtk 2.4.11 is as far as I'm aware webkit 1, while webkit2gtk
2.6.16, which is already on SBo, is webkit 2. There's more of a
difference between them than simply a version change.

On 21 August 2017 at 19:07, Didier Spaier <didier at slint.fr> wrote:
> Le 21/08/2017 à 16:24, Rich Shepard a écrit :
>>   libpng-1.6.27-i586-1_slack14.2 is installed; locate returns
>> /usr/lib/libpng14.so.14
>> /usr/lib/libpng14.so.14.18.0
>>
>>   However, gnucash-2.6.17 wants a static library, not a shared one:
>>
>> /usr/bin/sed: can't read /usr/lib/libpng14.la: No such file or directory
>> libtool: link: `/usr/lib/libpng14.la' is not a valid libtool archive
>> Makefile:639: recipe for target 'libgncmod-html.la' failed
>>
>>   This is a new issue and I need advice on how to proceed to resolve the
>> issue.
>
> I don't have the answer, but will take this opportunity for a warning to
> users of packages depending on webkitgtk2, directly or indirectly.
>
> Having read this blog post:
> https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
>
> I assume that all software that depend on a version at risk according
> to the most recent security advisory published on
> https://webkitgtk.org/security.html
> are also at risk.
>
> Today that would mean that version 2.16.6 should be used instead
> of 2.4.11 (the default in SBo).
>
> Admittedly the risk level is not the same for all software that depend
> on webkitgtk2, as explained by  Michael Catanzaro, and maybe one should
> not worry too much about gnucash (although I really don't know) but for
> instance there is a big risk for midori users, as stated by Michael.
>
> I am sorry to just bring an issue without a good solution to propose,
> as obviously not all SBo users will be happy to recompile their
> software that depend on wekitgtk2 8 times a year or so.
>
> But maybe a mention of the issue in the README of the leaf packages
> that depend on it could be added, at least in the ones that the admins
> consider the more at risk?
>
> Then it would be the responsibility of SBo users to track the security
> advisories and rebuild their packages if they think they should.
>
> Best regards,
> Didier
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>