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

Re: status of DDTP and ftp mirror synchronization?

Hash: SHA1

On 11-12-2007 07:18, Anthony Towns wrote:
> So I'd say:
>  - prepare a byhand upload
>  - targetted at unstable (ie Distribution: unstable)
>  - with a byhand file called ddtp-translations_2007.12.12-1_all.tar.gz
>    or similar (different package name or version, eg)
>  - section should be "raw-translations"
>  - that tarball should contains:
>       main/i18n/Translation-xx_XX
>       contrib/i18n/Translation-xx_XX
>       non-free/i18n/Translation-xx_XX
>     ie, translations for all components and languages, uncompressed
> Workable?
> If you can upload all that somewhere I can have a look at it and make
> sure it's workable, rather than directly to the archive, that'd seem
> like a good next step.

	I finished working on the scripts that will generate the
files, we add some tests during the "package" build to reduce the
checks on the "archive side". The package, .dsc and byhand-ddtp
are here: http://people.debian.org/~faw/ddtp/

> Any suggestions/scripts for validating the uploaded file would be
> good too.

	Some doubts appear in the process, while writing the byhand
I realize that you (or other ftpmaster) probably would need to adjust
the necessary bits like paths and make sure that 'rm -rf' do not
erase the entire archive. We tried to check the consistence of the
tarball and also the names, we plan to add other checks, and I hope
it would be not too hard to update it in the future. We decide to
take care of the enconding on our side, before the upload.

	So, a few doubts/questions:

 * When we upload a new file "removing" a translation, how would we
   remove that from the archive? byhand-ddtp should take care of that?

 * We were concern about the version format system, but I think the
   package is not going to appear on the archive, so we decided to
   use YYYYMMDD as you suggested, without the dots, and with a Debian
   revision, even knowing it is a Debian native package, it has some
   relation to how we will manage the debian/changelog. If we need to
   do a second "upstream" release on the same date, we will just push
   a new "dedian revision".

 * Can we close bugs using debian/changelog like on a normal package?
   Because we could close #431891 when this upload happens. :)

	I also tried to implement the check of allowed uploads, but
it seems that it needs to be done on archive side, I don't have the
necessary understanding of projectb to implement that, but we would
like to restrict who can upload the new translations.

	So, this should be the first step, so we can get ready for
the next one.

Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply to: