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

Please review and maybe comment on this text


I would like to get some native speakers to proofread the text I just
wrote for my applicants in the Debian NM process. Be careful, its
english written by me (which is the reason why I sent it to
-l10n-english too :) ).

I want to give my applicants a way to learn how to upload packages into
the Debian Archive, without any risk to break something with their
packages or the Debian archive itself. This is not intended as another 
check for the applicant to make their life hard. Its intended to get
them used to the way the archive/the upload tools are working. This will
leave an approved applicant with more knowledge what tools are there and
how he can use them. IMO.
For this I have a full blown archive system running, the same thing our
ftp-master has.

For other AMs: If you want it I can enable your applicants to use this
system too. Im pondering on how to do it in the best way. One thing is
that you sent me the Keyid of the applicant, and I enable this key to
upload stuff (noone sane would use my archive in a sources.list, except
maybe for deb-src entries, so it should not do any harm).
What to do with all the control mails, should I setup a mailinglist for
them, so you other AMs can see what your NMs are doing?

And now, the text I want to sent to my NMs. If there is enough demand
for it that can be added to the assigned mail, but for now I plan to use
it as a seperate file.
I have changed my ways to check packages from my Applicants a bit.
I now require every applicant to upload his package(s) to my own
personal archive.
This archive is running the same software that the Debian Archive is
using. This way you can now play with the tools and learn, without a
risk to damage something on the official archive.
For now it means a bit more work, but in the end you are
not left without any knowledge how to upload packages after you got

You need either dupload or dput, whatever you like more. The following
are the config snippets you need to put in your configuration for the
tool you use to upload the package. Of course they are already setup in a
way that you can upload to Debian later without any configuration

For dput use:
fqdn = ganneff.de
method = ftp
incoming = ./
allow_unsigned_uploads = 0
run_dinstall = 0
login = dak

For dupload use:
$cfg{ganneff_app} = {
        fqdn => "ganneff.de",
        incoming => "./",
		login => "dak",
        dinstall_runs => 1,

You are asked for a password while uploading, its dak.

Now you can upload with
dput ganneff_app changesfile
dupload -t ganneff_app changesfile

It works exactly as the Debian Archive, with all its checks,
limitations and stuff, but it IS NOT the Debian Archive.

That means:
- Your first upload needs to include the original source, even
  if it is not a -1 revision. See man dpkg-buildpackage for the -sa option
  for example.
- You can't overwrite or replace any existing file. Your next upload
  needs to have a higher version. Yes, even for a simple one-line change.
- Your uploads are taking the same way as in Debian:
  The unchecked queue (your upload place) is checked every ~15 minutes.
  - If the package is unknown in the archive (your first upload), it goes
    into the NEW queue.
  - If it is already known it is installed into the pool.

  - If it was NEW and it gets accepted it gets installed into the pool.

- You get mails from the archive system, telling you what is going on
  with the package. Read them and maybe correct your actions, or ask for
  help if you are lost.

You can play with the system and test it with different uploads. You can
even add http://ganneff.de/dak/ to your sources.list if you are insane
enough. Play with it, learn, its ok.

For my package checks I will take the latest version thats in the
archive after we successfully finished the part with your answers to my
P&P and T&S questions. So you can take the whole time that needs to play with
your uploads and to polish your package.

bye Joerg
2.5 million B.C.: OOG the Open Source Caveman develops the axe and
releases it under the GPL. The axe quickly gains popularity as a means
of crushing moderators heads.

Attachment: pgp57sSlPFB3I.pgp
Description: PGP signature

Reply to: