On 06/23/14 17:00, Jeffrey Johnson wrote:
On Jun 23, 2014, at 10:54 AM, Jacek Konieczny jaj...@jajcus.net wrote:
The deeper question is
Why is the localedb arch dependent?
Fix the localedb implementation and you won’t have to worry
about package replacement.
I was not sure if the
Hi,
most images these days are 8-bit/component, most IM use cases covers
simple one-pass actions like converting formats or resizing, so while
defaulting to Q16 is the right way to go as suggested by IM docs itself,
we should also provide Q8 version, especially for wide range of
server-side
On Tue, Jun 24, 2014 at 12:57:32 +0200, Jacek Konieczny wrote:
I think I can even move the data to /usr/share and make
glibc-localedb-all a noarch package.
No endianness issue here?
--
Tomasz Pala go...@pld-linux.org
___
pld-devel-en mailing list
On 06/24/14 13:11, Tomasz Pala wrote:
On Tue, Jun 24, 2014 at 12:57:32 +0200, Jacek Konieczny wrote:
I think I can even move the data to /usr/share and make
glibc-localedb-all a noarch package.
No endianness issue here?
I don't know. And we currently support x86 only. But I will leave it
On Jun 24, 2014, at 6:57 AM, Jacek Konieczny jaj...@jajcus.net wrote:
I think I can even move the data to /usr/share and make
glibc-localedb-all a noarch package.
Using /usr/share sounds like a great idea if endianness
can be handled.
On the other hand… I am still curious why some
