[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#364385: marked as done (localechooser almost tripled in size...)

Your message dated Fri, 28 Apr 2006 23:30:16 +0200
with message-id <[🔎] 200604282330.17492.aragorn@tiscali.nl>
and subject line Bug#364385: localechooser almost tripled in size...
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: localechooser
Version: 1.12
Severity: important

On IRC someone mentioned that the PPC root floppy image was too large.

A check against an older image shows that the main culprit is 
localechooser:
   108758 B - 136 blocks - 10 files from localechooser.udeb (version 1.06)
   344544 B - 360 blocks - 10 files from localechooser.udeb (version 1.12)

Is it possible to bring that down again a bit please?

Attachment: pgpx27RGybUvB.pgp
Description: PGP signature


--- End Message ---
--- Begin Message --- 
On Sunday 23 April 2006 08:18, Christian Perrier wrote:
> In 1.06, I introduced a bug when I removed the crafted intltool-merge
> which allowed partial translations for country names.

Ah, that explains a lot.

As the ppc root floppy is now normal size again, I'm closing this bug.
The real cause probably was the temporary size increase of the udev udeb 
because it was incorrectly linked against two extra libraries.

That said, having the language list in the templates file 4 times (though 
with a different number of languages) is not really memory friendly. We 
really should try to find a different solution for that, maybe by 
building the list dynamically at runtime from a masterlist that has the 4 
levels (ascii, latin, fb, all).
As the list is not translated anyway, that should not be a major problem. 
The same variable translation that is currently done at build time, could 
also be done at runtime.

Attachment: pgp8VVHKGnEvp.pgp
Description: PGP signature


--- End Message ---
Reply to: