Hello Stefan,
Le Thu, 09 Aug 2012 22:22:06 +0300,
Stefan Fröberg <stefan.froberg@petroprogram.com> a écrit :
> Signed-off-by: Stefan Froberg <stefan.froberg@petroprogram.com>> ---
Thanks for this patch. A few comments:
(1) Your patch has been line-wrapped by your e-mail client. Try to use
git send-email instead, which will guarantee that your patch
remains intact and can be applied properly.
(2) As far as I know, the bump from libpng 1.4 to libpng 1.5 changes
the API, and is therefore causing build failures in other
packages. Have you tested things like DirectFB and other packages
that rely on libpng?
(3) Is this apng feature something that is being integrated in the
upstream version of libpng? In Buildroot, we don't like carrying
patches that add features to packages. Imagine we later want to
bump libpng to version 1.5.10 or 1.5.11, we'd have to refresh the
patch, which becomes complicated if we accumulate many large
patches.
Best regards,
Thomas

Good morning Thomas
10.8.2012 10:02, Thomas Petazzoni kirjoitti:
> Hello Stefan,>> Le Thu, 09 Aug 2012 22:22:06 +0300,> Stefan Fröberg <stefan.froberg@petroprogram.com> a écrit :>>> Signed-off-by: Stefan Froberg <stefan.froberg@petroprogram.com>>> ---> Thanks for this patch. A few comments:>> (1) Your patch has been line-wrapped by your e-mail client. Try to use> git send-email instead, which will guarantee that your patch> remains intact and can be applied properly.
Ok, I try to get used to using git for sending these patches.
Im still git newbie :-)
> (2) As far as I know, the bump from libpng 1.4 to libpng 1.5 changes> the API, and is therefore causing build failures in other> packages. Have you tested things like DirectFB and other packages> that rely on libpng?
Well, firefox is working nicely.
And the only DirectFB depending package I have here is the graphical
version of links browser from buildroot.
Links start's okay too but freezes after exiting. But it had done it
before too, so I know it's not the issue of libpng
in this specific case.
But will I check what applications I have currently linked against that
1.5 version and test them all.
> (3) Is this apng feature something that is being integrated in the> upstream version of libpng? In Buildroot, we don't like carrying> patches that add features to packages. Imagine we later want to> bump libpng to version 1.5.10 or 1.5.11, we'd have to refresh the> patch, which becomes complicated if we accumulate many large> patches.
That's a good guestion.
I had to check from http://en.wikipedia.org/wiki/APNG
and it says the following:
"The PNG group officially rejected APNG as an official extension on
April 20, 2007.[3]
There have been several subsequent proposals for a simple animated
graphics format based on PNG using several different approaches.[4]
Mozilla Firefox added support for APNG in version 3 trunk builds on
March 23, 2007.[5]
However, because libpng is the PNG Group's reference implementation of
the official specification,
APNG support can never be supported in the main libpng distribution so
long as it remains
unratified by the Group. Iceweasel 3 now supports APNG by using
Mozilla's unofficial variant of libpng."
So it seems that even tought APNG support is needed for libpng by
Firefox the PNG group will never add it :(
However, there is a solution:
Firefox tarball contains it's own private copy of libpng with apng
support included.
Ofcourse that's some extra disk space wasted for having two versions of
libpng (private and system-wide)
included in the final rootfs and that's why I originally wanted to use
as much buildroot made system libs as possible.
But it's a simple matter to drop the "--with-system-png" from firefox
mozconfig and trash that apng patch.
By the way Thomas, how should I split my patches if they become too large ?
I have currently eight files for my firefox build and the total number
of lines is...well...large.
So, should I chunk it to separately patches with git ([PATCH 1/8],
[PATCH 2/8] etc ....) ,
with each patch containing just one file or how ?
Stefan
> Best regards,>> Thomas

Hello Stefan,
Le Fri, 10 Aug 2012 12:47:33 +0300,
Stefan Fröberg <stefan.froberg@petroprogram.com> a écrit :
> > (1) Your patch has been line-wrapped by your e-mail client. Try to use> > git send-email instead, which will guarantee that your patch> > remains intact and can be applied properly.> Ok, I try to get used to using git for sending these patches.> Im still git newbie :-)
No problem :)
> > (2) As far as I know, the bump from libpng 1.4 to libpng 1.5 changes> > the API, and is therefore causing build failures in other> > packages. Have you tested things like DirectFB and other packages> > that rely on libpng?> Well, firefox is working nicely.> > And the only DirectFB depending package I have here is the graphical> version of links browser from buildroot.> Links start's okay too but freezes after exiting. But it had done it> before too, so I know it's not the issue of libpng> in this specific case.> > But will I check what applications I have currently linked against that> 1.5 version and test them all.
I was more talking about all the other packages that we have in
Buildroot and that rely on libpng:
$ git grep "select BR2_PACKAGE_LIBPNG"
cairo/Config.in: select BR2_PACKAGE_LIBPNG
collectd/Config.in: select BR2_PACKAGE_LIBPNG
directfb/Config.in: select BR2_PACKAGE_LIBPNG
efl/libevas/Config.in: select BR2_PACKAGE_LIBPNG
fbgrab/Config.in: select BR2_PACKAGE_LIBPNG
fbv/Config.in: select BR2_PACKAGE_LIBPNG
imlib2/Config.in: select BR2_PACKAGE_LIBPNG
links/Config.in: select BR2_PACKAGE_LIBPNG
multimedia/gst-plugins-good/Config.in: select BR2_PACKAGE_LIBPNG
opencv/Config.in: select BR2_PACKAGE_LIBPNG
qt/Config.in: select BR2_PACKAGE_LIBPNG
rrdtool/Config.in: select BR2_PACKAGE_LIBPNG
sdl_image/Config.in: select BR2_PACKAGE_LIBPNG
x11r7/Config.in: select BR2_PACKAGE_LIBPNG
x11r7/xapp_xcursorgen/Config.in: select BR2_PACKAGE_LIBPNG
> That's a good guestion.> > I had to check from http://en.wikipedia.org/wiki/APNG> and it says the following:> > "The PNG group officially rejected APNG as an official extension on> April 20, 2007.[3]> There have been several subsequent proposals for a simple animated> graphics format based on PNG using several different approaches.[4]> > Mozilla Firefox added support for APNG in version 3 trunk builds on> March 23, 2007.[5]> However, because libpng is the PNG Group's reference implementation of> the official specification,> APNG support can never be supported in the main libpng distribution so> long as it remains> unratified by the Group. Iceweasel 3 now supports APNG by using> Mozilla's unofficial variant of libpng."> > So it seems that even tought APNG support is needed for libpng by> Firefox the PNG group will never add it :(
Argh, so it sounds a bit nasty to include this apng patch.
> However, there is a solution:> Firefox tarball contains it's own private copy of libpng with apng> support included.> > Ofcourse that's some extra disk space wasted for having two versions of> libpng (private and system-wide)> included in the final rootfs and that's why I originally wanted to use> as much buildroot made system libs as possible.> But it's a simple matter to drop the "--with-system-png" from firefox> mozconfig and trash that apng patch.
Yes, we usually don't like this solution either, but for now, it looks
like the easiest option.
> By the way Thomas, how should I split my patches if they become too large ?> I have currently eight files for my firefox build and the total number> of lines is...well...large.> > So, should I chunk it to separately patches with git ([PATCH 1/8],> [PATCH 2/8] etc ....) ,> with each patch containing just one file or how ?
You can send all the files related to a particular package as a single
patch, even if it is large. However, we might be a bit reluctant to add
a package that requires such a number of big patches. We'll wait your
posting to see what those patches do, and whether they are acceptable
inside Buildroot.
Best regards,
Thomas

>> By the way Thomas, how should I split my patches if they become too large ?>> I have currently eight files for my firefox build and the total number>> of lines is...well...large.>>>> So, should I chunk it to separately patches with git ([PATCH 1/8],>> [PATCH 2/8] etc ....) ,>> with each patch containing just one file or how ?> You can send all the files related to a particular package as a single> patch, even if it is large. However, we might be a bit reluctant to add> a package that requires such a number of big patches. We'll wait your> posting to see what those patches do, and whether they are acceptable> inside Buildroot.
Not to worry, the patches are actually very small and I was surprised
how little I had to change code.
But the actual build process was very ... messy ... and i had spend most
of the last four months of (and lot's of hair tearing)
finding just the right combination of build switches to make the damn
thing compile and actually run.
Firefox extensions work now and It even plays YouTube videos with gnash
plugin. Yay! :-)
So the biggest files are firefox.mk, which I have commented extensively
so that nobody has to go for this trouble again, and mozconfig file.
I also have added optional feature that when enabled will try to make
Firefox as privacy enhanced as possible
(using NoScript and AdblockPlus extension plus my own about:config
settings)
If the yasm package patch and that little cairo option addition patch
are both okay for you I will then send one final patch (few little
changes needed to sqlite.mk)
and then im ready to send the actual firefox.
Stefan
> Best regards,>> Thomas

Hello,
Le Sat, 11 Aug 2012 02:22:33 +0300,
Stefan Fröberg <stefan.froberg@petroprogram.com> a écrit :
> Not to worry, the patches are actually very small and I was surprised> how little I had to change code.
Great!
> But the actual build process was very ... messy ... and i had spend most> of the last four months of (and lot's of hair tearing)> finding just the right combination of build switches to make the damn> thing compile and actually run.
Yeah, I believe you that building Firefox is certainly not a piece of
cake. Congrats to you for working on this!
> Firefox extensions work now and It even plays YouTube videos with gnash> plugin. Yay! :-)
Woh! I presume it only works under X.org, right?
> So the biggest files are firefox.mk, which I have commented extensively> so that nobody has to go for this trouble again, and mozconfig file.
How complicated do you feel the Firefox version bumps will be,
considering the work you had to do for a specific version?
> I also have added optional feature that when enabled will try to make> Firefox as privacy enhanced as possible> (using NoScript and AdblockPlus extension plus my own about:config> settings)> > If the yasm package patch and that little cairo option addition patch> are both okay for you I will then send one final patch (few little> changes needed to sqlite.mk)> and then im ready to send the actual firefox.
I will try to catch up a bit on my Buildroot backlog today, hoping that
the 3G connection will be more cooperative than the other days.
Best regards,
Thomas

Hello Thomas
11.8.2012 9:50, Thomas Petazzoni kirjoitti:
> Hello,>> Le Sat, 11 Aug 2012 02:22:33 +0300,> Stefan Fröberg <stefan.froberg@petroprogram.com> a écrit :>>> Not to worry, the patches are actually very small and I was surprised>> how little I had to change code.> Great!>>> But the actual build process was very ... messy ... and i had spend most>> of the last four months of (and lot's of hair tearing)>> finding just the right combination of build switches to make the damn>> thing compile and actually run.> Yeah, I believe you that building Firefox is certainly not a piece of> cake. Congrats to you for working on this!>>> Firefox extensions work now and It even plays YouTube videos with gnash>> plugin. Yay! :-)> Woh! I presume it only works under X.org, right?
Yes but there is also an configure option
"--enable-default-toolkit=cairo-gtk2-dfb" for directfb and
whitch I have not tested at all and I remember that I have seen
somewhere in the net a way to
build firefox to use just DirectFB + Gtk2 and no Xorg at all.
There is also "--enable-mobile-optimize" configure switch whitch I
suspect will only affect building for Android phone
(at least theres are lot's of #ifdef ANDROID stuff in the code)
So that switch combined with directfb could make a really small firefox
binary, at least for phones.
>> So the biggest files are firefox.mk, which I have commented extensively>> so that nobody has to go for this trouble again, and mozconfig file.> How complicated do you feel the Firefox version bumps will be,> considering the work you had to do for a specific version?>>> I also have added optional feature that when enabled will try to make>> Firefox as privacy enhanced as possible>> (using NoScript and AdblockPlus extension plus my own about:config>> settings)>>>> If the yasm package patch and that little cairo option addition patch>> are both okay for you I will then send one final patch (few little>> changes needed to sqlite.mk)>> and then im ready to send the actual firefox.> I will try to catch up a bit on my Buildroot backlog today, hoping that> the 3G connection will be more cooperative than the other days.
Great!
Stefan
> Best regards,>> Thomas

11.8.2012 9:50, Thomas Petazzoni kirjoitti:
> So the biggest files are firefox.mk, which I have commented extensively> so that nobody has to go for this trouble again, and mozconfig file.> How complicated do you feel the Firefox version bumps will be,> considering the work you had to do for a specific version?
I think the bumps will be trivial.
The firefox.mk is more or less in stable state now and
simply changing FIREFOX_VERSION should be enough.
Ofcourse adding more optional configure options like DBus support,
libnotify etc.,
can be added later but right now it will build a very minimal binary and
im satisfied with that.
The mozconfig file which is Mozilla way of feeding all the configure
switches to build process
is pretty much stable and static now and will unlikely change for very
long time.
And the only changes I had to make to actual code was to replace finite()
with more standard isinf() and handle glibc specific malloc_usable_size and
execinfo.h stuff.
When I started the version number was 11.0 and now they have released
14.0 so those things might be
even fixed by now. :-)
If not, then I will try to contact upstream for including those minor
fixes and if failing that Im
more than willing to keep those lil patches updated.
Stefan
>> I also have added optional feature that when enabled will try to make>> Firefox as privacy enhanced as possible>> (using NoScript and AdblockPlus extension plus my own about:config>> settings)>>>> If the yasm package patch and that little cairo option addition patch>> are both okay for you I will then send one final patch (few little>> changes needed to sqlite.mk)>> and then im ready to send the actual firefox.> I will try to catch up a bit on my Buildroot backlog today, hoping that> the 3G connection will be more cooperative than the other days.>> Best regards,>> Thomas

On 08/10/12 11:47, Stefan Fröberg wrote:
> Good morning Thomas>> 10.8.2012 10:02, Thomas Petazzoni kirjoitti:
[snip]
>> (3) Is this apng feature something that is being integrated in the>> upstream version of libpng? In Buildroot, we don't like carrying>> patches that add features to packages. Imagine we later want to>> bump libpng to version 1.5.10 or 1.5.11, we'd have to refresh the>> patch, which becomes complicated if we accumulate many large>> patches.>> That's a good guestion.>> I had to check from http://en.wikipedia.org/wiki/APNG> and it says the following:>> "The PNG group officially rejected APNG as an official extension on> April 20, 2007.[3]> There have been several subsequent proposals for a simple animated> graphics format based on PNG using several different approaches.[4]>> Mozilla Firefox added support for APNG in version 3 trunk builds on> March 23, 2007.[5]> However, because libpng is the PNG Group's reference implementation of> the official specification,> APNG support can never be supported in the main libpng distribution so> long as it remains> unratified by the Group. Iceweasel 3 now supports APNG by using> Mozilla's unofficial variant of libpng."
The most logical solution for me seems to be to add a libapng package
that uses the Mozilla code base. Of course, that introduces the same
variants mess we have for expat/libxml2 and lua/luajit.
Regards,
Arnout

22.8.2012 0:30, Arnout Vandecappelle kirjoitti:
> On 08/10/12 11:47, Stefan Fröberg wrote:>> Good morning Thomas>>>> 10.8.2012 10:02, Thomas Petazzoni kirjoitti:>> [snip]>>> (3) Is this apng feature something that is being integrated in the>>> upstream version of libpng? In Buildroot, we don't like carrying>>> patches that add features to packages. Imagine we later want to>>> bump libpng to version 1.5.10 or 1.5.11, we'd have to refresh the>>> patch, which becomes complicated if we accumulate many large>>> patches.>>>> That's a good guestion.>>>> I had to check from http://en.wikipedia.org/wiki/APNG>> and it says the following:>>>> "The PNG group officially rejected APNG as an official extension on>> April 20, 2007.[3]>> There have been several subsequent proposals for a simple animated>> graphics format based on PNG using several different approaches.[4]>>>> Mozilla Firefox added support for APNG in version 3 trunk builds on>> March 23, 2007.[5]>> However, because libpng is the PNG Group's reference implementation of>> the official specification,>> APNG support can never be supported in the main libpng distribution so>> long as it remains>> unratified by the Group. Iceweasel 3 now supports APNG by using>> Mozilla's unofficial variant of libpng.">> The most logical solution for me seems to be to add a libapng package> that uses the Mozilla code base. Of course, that introduces the same> variants mess we have for expat/libxml2 and lua/luajit.>
Yes and it would still duplicate libpng code in the target (having
system-wide libpng and libapng package with private Mozilla libpng +
apng stuff).
I forgotted to mention Thomas that that APNG patch is steadily updated
in http://sourceforge.net/projects/libpng-apng/
So keeping it updated between libpng versions is really not an issue.
It is even less issue if that patch can be made optional.
What I have now in mind is something like this:
################################
ifeq ($(BR2_PACKAGE_LIBPNG_APNG_SUPPORT),y)
define LIBPNG_ADD_APNG
cp package/libpng/patches/libpng-apng.patch package/libpng/
endif
LIBPNG_PRE_PATCH_HOOKS += LIBPNG_ADD_APNG
else
if [ -f package/libpng/libpng-apng.patch ]; then
rm package/libpng/libpng-apng.patch
fi
endif
################################
That way apng patch could be switched on and off
and the duplicate code bloat of having two copies of libpng could be
avoided.
Im not even sure if there is a PRE_PATCH_HOOKS.
At least http://buildroot.org/downloads/buildroot.html#add_packages does
not mention it
But I think I saw it somewhere.
Stefan
> Regards,> Arnout

On 08/22/12 00:01, Stefan Fröberg wrote:
> I forgotted to mention Thomas that that APNG patch is steadily updated> inhttp://sourceforge.net/projects/libpng-apng/>> So keeping it updated between libpng versions is really not an issue.
Even better! Then you can make something like
ifeq ($(BR2_PACKAGE_LIBPNG_APNG_SUPPORT),y)
LIBPNG_PATCH = sf://libpng-apng/files/libpng15/$(LIBPNG_VERSION)/libpng-$(LIBPNG_VERSION)-apng.patch.gz
endif
(where sf:// is Yann's soon-to-be-interoduced abbreviation of the sourceforge
URLs). As far as I know (but never tried it), the above should download and
apply the patch.
Regards,
Arnout