Re: lenny release-notes built and available, questions
On Wed, Jan 14, 2009 at 02:19:49PM +0100, Simon Paillard wrote:
> On Wed, Jan 14, 2009 at 01:25:31PM +0100, Jens Seidel wrote:
> > On Wed, Jan 14, 2009 at 10:48:18AM +0100, W. Martin Borgert wrote:
> > > locales-all is *not* installed, neither in etch nor lenny, but I
> > > have en_GB.UTF-8 as LANG. Without an UTF-8 locale txt output
> > > will be broken!
> >
> > It *is* broken on the build host! See for example
> > http://www.debian.org/releases/lenny/i386/release-notes.de.txt
> > which contains "?" instead of 8bit umlauts.
> >
> > How to fix this, using LANG=en_GB.UTF-8 in Makefile (is this a supported)
> > locale on the build host)? Maybe it is better to change the system locale on
> > www-master?
>
> It's less intrusive (and with no possible side effect on other
> applications on www-master) to specify the locale in the makefile.
What locale should we use? Even if en_GB.UTF-8 is supported on the build
host is it supported on your/my box?
Maybe it's better to locally adapt the single affected txt rule (xsltproc or w3m?)
instead of all rules. Maybe there is a specific option to enable UTF-8 output
(or will something as LC_CTYPE=UTF-8 work?).
> > PS: I tried my best to optimize the build system. It does at the moment no longer
> > create useless builds and is that's why much faster. If there are further problems
> > please report.
>
> I experienced something strange: after a change on a po file, updatepo
> tells "make: Nothing to be done for `updatepo'."
That's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509759 and I had already
a fix but delayed to commit it. Problem: The timestamps are evaluated (remember
it's a makefile :-)) so I'm sure a touch en/*.dbk; make updatepo will work for
you, right?
Nevertheless I think a PO file should never be updated without user intervention
(it would also be useless, as po4a-updatepo will not add translations but just
ensure that the source references are up-to-date which is unimportant for the
built document). Also the initial Subversion checkout could ensure that the PO file
is older that XML (slow checkout) which would update the PO file during build and
could create a local modification in the working copy which is unwanted on the
build host.
But this attempt will force me to introduce a ugly for-loop and could spend too much
time if called manually. Mmh, still investigating ...
PS: What's the status of removal of generated XML files? It should be save to
do so *now*, right?
Jens
Reply to: