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

Re: debian hurd -- a little help?



On Thu, Dec 03, 1998 at 06:34:19PM -0500, Roland McGrath wrote:
> > Well, in case you haven't noticed yet, Santiago, Gordon and me were busy
> > building Debian packages for the Hurd. There already are packaged binary
> > versions of libc (2.0.4 though), gnumach and hurd (and several other gnu
> > software, too). Below are two pointers for you to look at.
> 
> Yes, I'm aware.  I was talking about getting those packages updated for the
> current sources.

This happens "automatically" as soon as the maintainer becomes aware of the
update and finds the time to do it. I always tried to get the latest snap
shot running, which happened to be the case for gnumach but not with hurd.

The current versions in Debian are gnumach-19981025 and hurd_19980716.

> > a) You should upload a snapshot or version numbered source tar file for the
> >    packages you want to have released. We have CVS access, so it is probably
> >    enough to tag the repository and let us know what tag to use.
> >    Nevertheless, a tar file is better, because we have to provide one anyway.
> 
> Upload to where?  For glibc, the current test release (2.0.105) or the
> current CVS state is the right source.  It's my expectation that the new
> debian-hurd glibc package will be more like debian linux package for
> glibc-2.1 than like the hurd glibc-2.0.4 package.  I am hoping that a
> single source package for glibc can be used to build for either linux or
> hurd.  Is this possible?

Sure, but this is not as easy as it may sound. The current libc6 maintainer
is overworked, and someone has to change the Debian building scripts and
remove linux specific things like architecture. So it will be faster to use
"our" version of glibc for now. Other ports are building from 2.1 pre
versions, this has to be investigated, too.

> For hurd, the current CVS version is fine.  I will make a snapshot tar file
> later tonight that you can use.

Ok.
 
> It has been my hope to get the debian packages going based on prereleases
> or snapshots so that we can get people building packages and work out some
> kinks before doing the hurd 0.3 release.

Sure.
 
> For gnumach, I would like to see a debian package based on OKUJI Yoshinori
> <okuji@kmc.kyoto-u.ac.jp>'s version of gnumach, which is available in
> ftp://alpha.gnu.org/hurd/contrib/okuji/mach/ (as well as his original site,
> ftp://duff.kuicr.kyoto-u.ac.jp/pub/mach/).  This version has updated all
> block and net device drivers from linux-2.0.36.  We will be merging his
> changes into gnumach and making a new release sometime soon, but it would
> be great to have a debian package now for people to start testing with.

Ok. I hope I can do the packages this week.

> >    The Debian packaging files will be applied by me (or the developer
> >    doing the package) and we cross compile the software and upload the
> >    package.  (we can include the debian directory to CVS, too, if you
> >    want to experiment with it. Usually it is just added by the maintainer
> >    and saved in a diff against the upstream source)
> 
> Eventually we may want to include them in our sources (for libc, you'll
> have to ask Ulrich), but for the time being we know little enough about
> debian that we'd rather leave the debian additions to you.

Sure.
 
> > b) We need to refine the packaging scripts. You already gave great
> >    explanations about how translators work. This has to be implemented in the
> >    Debian scripts and refined.
> > 
> > c) We need a boot strap mechanism, preferably some sort of boot disk or tar
> >    file that can be unpacked on an empty partition. Currently no one (?) is
> >    working on it.
> 
> Indeed, these are important things ultimately.  But for the time being I am
> most concerned about getting the core packages together so hackers can
> install them easily from linux (or a linux boot floppy).

Yep.
 
> > d) We still need to port a lot of software. Some require some tricks, some
> >    should be relativley easy. We collected a lot of knowledge about cross
> >    compiling the last weeks/months. However, we should compile the software
> >    with the new libc, gnumach and hurd.
> > 
> >    We have patches for ncurses and gcc, so they will compile fast. We have
> >    already cross compiled some packages, they will also be no problem. We
> >    need perl (dpkg uses it extensively). Me personally will care about dpkg
> >    and friends.
> 
> I suspect that the new libc package will make this easier than it has been.
> The majority of packages that build against glibc 2.1 on linux should build
> ok on the new glibc for hurd too.

We'll see. I encountered little libc6 problems during cross compilation, but
a lot of make file problems (due to cross compilation). If we can change to
native configuration, we have won a lot.

To answer your question, you've done your part. Now it is time for us to
catch up with your work. I am currently updating my CVS repositories and go
from there.

Thank you,
Marcus

-- 
"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Reply to: