2015-08-12 4:34 GMT+03:00 Matthias Klose <email@example.com>:
> we don't ship cd images anymore, we are not limited to CD sizes, and as long as
> we don't hit some 2GB limit, we shouldn't optimize for size. This "optimizer"
> adds for some packages 100% build time, in rare occasions up to 2000%. This is
> not worth the savings. If we want to optimize for size, this should be done by
> test rebuilds and individual patches, not consuming scare buildd resources.
I'd support this, as the PNG repacking is hugely time consuming on
especially armhf Qt builds. If I recall correctly it's pretty near
that 100% in eg qtdeclarative, making it 2h instead of 1h, and very
slow also with for example qtbase amd64. And whenever doing a big
amount of no-change rebuilds, the build times add up.
In test builds I try to remember to use export NO_PNG_PKG_MANGLE := 1
It's not that the feature itself is bad, but optipng is just slow for
the gain it brings on average. Just being able to run it utilizing all
CPU:s would probably help, or maybe different parameters.
There are alternative tools in archives like pngquant, but that one is
lossy (funny for a PNG). Some are faster and do better compression,
but are not free software.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel