In article <[EMAIL PROTECTED]> you wrote:

: This means that we should, now, use "standard" Debian policy when
: uploading our Debian packages?

Yes.  The hamm tree has been seeded with the current state of the Sparc port,
and there are enough Alpha files in the hamm tree to really frustrate anyone
who tries to use them.  Michael Dorman and I are making good progress on the
Alpha port, though, and we're working now on the pieces necessary to build a 
new set of base disks.

: Have we completed Stage1?

Good question!  :-)  

: I'm the mantainer of SILO package, which is already at -2 version:
: should I mail to new-maintainer?

It looks like you already have a login on master.debian.org, Davide, so you
can just upload the SILO package and the right things will happen.  Anyone else
who is going to help with the Sparc or Alpha ports who isn't registered as a
maintainer should contact [EMAIL PROTECTED] to identify yourself and
acquire the needed maintainer credentials.

Here are my hints for building and uploading an architecture-specific .deb for
an existing package (you would, of course, do a full package upload for SILO 
and any other Sparc-only packages, as we will for MILO in the Alpha world):

        - install dpkg-dev and dupload.  I also use sudo to manage root privs
          during package builds.  Make sure to edit the dupload config file
          in /etc.

        - *READ* the Debian policy manual and programmers manual, which can be
          found under /usr/doc/dpkg.

        - build the architecture-specific parts of your package with
          dpkg-buildpackage like this (using your own contact information,
          of course!):

          dpkg-buildpackage -uc -rsudo '-mBdale Garbee <[EMAIL PROTECTED]>' -b 
-B

          This says to leave the changes file unsigned (drop the -uc when you
          get PGP working on Sparc), use sudo to acquire root privs when
          needed, set the maintainer for this upload to yourself so that you
          get the acknowledgement from the package installer on master, don't
          build the source packages, and don't build any architecture-
          independent .deb files.
         
          When you're done, you'll have a .deb file and a .changes file.

        - if you need to apply any architecture-specific patches, do so, 
          updating the debian/changelog file to indicate a new version number
          with a suffix to indicate a non-maintainer upload, as documented in
          section 5.1 of the policy manual.  

        - upload the package using dupload to master.debian.org, or one of the
          other sites that provide drop points for uploads to master.

        - if you made any architecture-specific patches, submit a bug report
          against the package providing the diffs, again as indicated in 
          section 5.1 of the policy manual.

That's it!  If anyone has any procedural questions, just ask and I'll do my
best to help.

: If this is true, we are going to have a Debian Sparc distribution!!! :)

It's way too late for bo, which is already in code-freeze, but I see no reason
that we can't have full/reasonable support for Sparc and Alpha in the next
release, code-named "hamm".

Bdale

Reply via email to