Re: build of etch release-notes from svn, conflicts with sgml vs po: ro, pt, ru
On Mon, Jan 12, 2009 at 01:01:22PM +0100, Jens Seidel wrote:
> On Mon, Jan 12, 2009 at 11:44:10AM +0100, Simon Paillard wrote:
[..]
> > During the build of etch release notes, it appears that some of your
> > translations are performered in the po files, some other in the SGML.
> >
> > Please see below what you should perform to update the po file before
> > the SGML can be safely removed.
>
> In the past it was not possible to remove the (generated SGML) files because
> of errors in the old build infrastructure. The Makefile still contains my
> comment:
> # TODO: Once #477458 is fixed in stable remove all committed sgml files
> # which are generated from a PO file (was a workaround for old po4a).
We can see from build logs on www-master that the PO file is correctly
generated. (see attached the part specific to ro, ru, pt).
What do I miss ? (maybe backported po4a on www-master ?)
> > As spotted by Rhonda, some sgml files are stored in the (etch) SVN
> > together with their po source, as a consequence :
> > $ svn status | grep -v ^?
> > M ro/release-notes.ro.sgml
> > M pt/release-notes.pt.sgml
> > M ru/release-notes.ru.sgml
>
> That's the status in your local working copy, not on the build host where only
> a very restricted set of people has access to, right?
That is the one of www-master (discussed with Rhonda who has access to
it).
> > Unfortunately, they cannot be removed straight away from the SVN,
> > because the translations are not consistent in PO and SGML :
>
> Later removal of files with local modifications should also cause a svn (tree)
> conflict.
If the SGML are removed from the SVN, there would be no risk of
conflict.
> > The right place to change the po is :
> > svn://svn.debian.org/ddp/manuals/tags/release-notes/etch
>
> This remembers me that it would be a good idea to verify that no one works
> any longer on the files in CVS ...
No commit since 11 months. I've asked DSA whether the repository is set read-only or not.
--
Simon Paillard
Reply to: