The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: archive maintainance

On Tue, 14 May 1996, Juergen Menden wrote:
> On Mon, 13 May 1996, Bruce Perens wrote:
> > From: Guy Maor <maor@ece.utexas.edu>
> > 
> > > finish support for dchanges format 1.5, which fixes some important
> > > shortcomings of 1.4.  I don't think I'll support 1.4.
> > 
> > You may demand that everyone use dchanges 1.5 when uploading packages,
> > that's fine with me.
> 
> well, but in this case we need someone to look at the 8 weeks backlog
> in the m68k incomming area (home/Debian/ftp/private/m68k/Incoming)
> we havn't got dchanges-1.5 right now, but it might be linked from 
> binary-i386.

It's trivial for me to make the script parse both format 1.4 and 1.5.
Format 1.5 is produced by dchanges-3.3 (unnecessary confusion).

> Guy, does your script handles the binary architecture, or even
> multiarchitecture? can we merge the incomming areas when your
> script is installed?

Yes, the script looks at the Architecture field of dchanges.  If it
sees more than one architecture, it requires the filenames to have the
architecture encoded in them.  It handles the "all" architecture in a
special way by installing it in i386 and making symlinks from the other
architectures.

The script can already handle a single Incoming directory, but the
developers have to be sure to not override each others' files.  The
easiest way to do this is to always encode the architecture in the
filename AND the changes files.  I don't really care how you encode the
arch in the changes file as the script is just run as "dinstall
*.changes".

After I finish the script tomorrow, I'll write a "How to Upload"
document.  Basically the rules will be this:

1. Run dpkg-name on your .deb files to rename them correctly.

2. Run dchanges to create a changes file.  Be sure the changes file is
   unique.  Encode your name in it if you want.

3. Upload the whole mess into .../Incoming

4. Move the .changes file into .../Incoming/Queue.  (This prevents
   dinstall from processing the changes file before you've finished
   uploading.)

5. You'll get email from dinstall in a day or so telling you that the
   files were installed or rejected.  If they were rejected, dinstall
   will move them to ...Incoming/Reject.  For safety, a changes file
   won't be partially installed; if any files are bad, everything is
   rejected.

6. dinstall creates a human readable report of the packages installed
   which will be mailed to debian-changes.  I'll mail it to
   debian-devel for now until everything is smooth.

Some other points - 
dchanges(5) - some of the fields are required by dinstall.  I'll
specify which ones in this document, and Andy can add that to the
dchanges(5) man pages.  This is just to get the impemention seperate
from the definition.

section in the file line - You're encouraged to specify the right
section to reduce maintainer fatigue. :)  dinstall will first try to
get the section from the overrides file, then it will try the section
field here.  I guess I can parse the Packages file for one last try.
Otherwise it gives up, and doesn't parse the package.  Perhaps I should
just reject the package.

Actually I think it's a good idea to just make dinstall very strict so
as to not have to handle special cases.  If the rules are listed in the
"How to Upload" file, maintainers can't complain if their packages are
rejected for not following them.


Guy