Re: debian hurd -- a little help?
> 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.
> 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?
For hurd, the current CVS version is fine. I will make a snapshot tar file
later tonight that you can use.
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.
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.
> 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.
> 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).
> 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.
Thanks,
Roland
Reply to: