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

Re: gdb available

In article <199704091633.SAA13778@chiara.dei.unipd.it> 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 new-maintainer@debian.org 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 <bdale@gag.com>' -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".


Reply to: