On Tue, 20 Jan 2009 23:10:13 +0100
Jakub Wilk wrote:
> * Neil Williams , 2009-01-20, 20:59:
> >> > Perhaps we could have a tool converting .mo files from one endianess to
> >> > the other and ship the two versions in epiphany-browser-data,
> >>
> >> Well, either msgfmt should be able to produc
Hello,
> > I see two main issues:
> > - the endianess of files in the archive is actually random
> > - I would expect the most common endianess to be the little endian one
> >since maintainers mostly upload packages for amd64/i386; this means
> >that the slow big endian arches usually g
* Neil Williams , 2009-01-20, 20:59:
> Perhaps we could have a tool converting .mo files from one endianess to
> the other and ship the two versions in epiphany-browser-data,
Well, either msgfmt should be able to produce both or a special tool is
required. The later would be easier as this too
On Tue, Jan 20, 2009, Mike Hommey wrote:
> How much performance loss are we looking at ? If it's a few %, is it
> that important? There are already various things that are little-endian
> even on big-endian architectures, beginning with the ext3 filesystem.
I'd love to hear about the speed benefi
On Tue, Jan 20, 2009 at 11:02:46AM +0100, Loïc Minier wrote:
> (moving to -devel with a reply-to)
>
> On Tue, Jan 20, 2009, Fabian Greffrath wrote:
> > Running the 'file' command on
> > '/usr/share/locale/de/LC_MESSAGES/epiphany.mo' reveals a "GNU message
> > catalog (little endian), revision 0
On Tue, 20 Jan 2009 21:00:25 +0100
Loïc Minier wrote:
Adding a CC for debian-i18n
(context for debian-i18n)
> n Tue, Jan 20, 2009, Fabian Greffrath wrote:
> > Running the 'file' command on
> > '/usr/share/locale/de/LC_MESSAGES/epiphany.mo' reveals a "GNU message
> > catalog (little endian), re
On Tue, 20 Jan 2009 21:43:35 +0100
Bastian Blank wrote:
> On Tue, Jan 20, 2009 at 11:02:46AM +0100, Loïc Minier wrote:
> > Perhaps we could have a tool converting .mo files from one endianess to
> > the other and ship the two versions in epiphany-browser-data,
>
> Well, either msgfmt should be
On Tue, Jan 20, 2009 at 11:02:46AM +0100, Loïc Minier wrote:
> Perhaps we could have a tool converting .mo files from one endianess to
> the other and ship the two versions in epiphany-browser-data,
Well, either msgfmt should be able to produce both or a special tool is
required. The later would
Loïc Minier (20/01/2009):
> On Tue, Jan 20, 2009, Neil Williams wrote:
> > Changing the endianness of a .mo normally requires the original .po
> > and the msgfmt binary which means a runtime dependency on gettext
> > *AND* the need for the original source.
Tatata.
> I understand you're replying
On Tue, Jan 20, 2009, Neil Williams wrote:
> Is there any actual evidence of a problem with the current situation?
I see two main issues:
- the endianess of files in the archive is actually random
- I would expect the most common endianess to be the little endian one
since maintainers mostly
On Tue, 20 Jan 2009 14:43:12 +0100
Loïc Minier wrote:
> On Tue, Jan 20, 2009, Дмитрий Ледков wrote:
> > My understanding was that checksums are provided for
> > original tarball, diff, and deb. Not the individual files in the
> > package, hence my logic was that no checksums
On Tue, Jan 20, 2009, Дмитрий Ледков wrote:
> My understanding was that checksums are provided for
> original tarball, diff, and deb. Not the individual files in the
> package, hence my logic was that no checksums will be lost.
I meant the /var/lib/dpkg/info/*.md5sums to use
Loïc Minier wrote:
> On Tue, Jan 20, 2009, Дмитрий Ледков wrote:
>> Maybe a work around like python/emacssen could work here? To
>> (re-)/generate correct endianess at install time?
>
> Sure, this sounds possible, albeit it seems slightly more fragile to
> me; you also lose distro-provided md5su
On Tue, Jan 20, 2009, Дмитрий Ледков wrote:
> Maybe a work around like python/emacssen could work here? To
> (re-)/generate correct endianess at install time?
Sure, this sounds possible, albeit it seems slightly more fragile to
me; you also lose distro-provided md5sums for the generated data.
-
Loïc Minier wrote:
> On Tue, Jan 20, 2009, Fabian Greffrath wrote:
>> May I conclude that it is common practice to ship little-endian locale
>> files in arch-indep data packages that are also referenced by
>> big-endian arch packages? While not being perfect, it is convenient
>> and (most import
Hi Loic, thanks for your answer!
Loïc Minier schrieb:
The files will work on both little endian and big endian systems, but
there's a performance hit when the endianess differ (as the file can't
be used directly when it's mmap-ed).
It's a bug, but it's not clear to me how we could fix this
On Tue, Jan 20, 2009, Fabian Greffrath wrote:
> May I conclude that it is common practice to ship little-endian locale
> files in arch-indep data packages that are also referenced by
> big-endian arch packages? While not being perfect, it is convenient
> and (most importantly) it actually works
On Tue, 20 Jan 2009 11:02:46 +0100
Loïc Minier wrote:
> On Tue, Jan 20, 2009, Fabian Greffrath wrote:
> > Running the 'file' command on
> > '/usr/share/locale/de/LC_MESSAGES/epiphany.mo' reveals a "GNU message
> > catalog (little endian), revision 0, 920 messages".
This is a "feature" of gette
(moving to -devel with a reply-to)
On Tue, Jan 20, 2009, Fabian Greffrath wrote:
> Running the 'file' command on
> '/usr/share/locale/de/LC_MESSAGES/epiphany.mo' reveals a "GNU message
> catalog (little endian), revision 0, 920 messages".
>
> The 'little endian' part is fine, since this is an
19 matches
Mail list logo
