Re: Packaging progress, packaging problems
On Thu, Jan 24, 2002 at 01:53:55AM -0500, Jimmy Kaplowitz wrote:
> I was able to build gettext with no problems, and the same with sudo and
> libtool. Sudo required an /etc/hosts file containing the current computer,
> as well as the unsetting of the original BSD $SHELL value (from within the
> chroot), to work correctly, but it works fully, with no errors, once all
> that is done. Fakeroot seems to be linking with -ldl, which neither
> exists nor is necessary with NetBSD's libc. How can I get it to avoid
> linking with -ldl? Except for that I think I have fakeroot compiling
> OK. Sharutils had an undefined symbol error on _nl_default_dirname, but
> worked when I disabled nls. What might be wrong with the nls support?
1) Gettext - good, I was worried for a moment.
2) Sudo - cool. That should be fixed by getting base-files and kin in place,
I expect. (Well, that, and maybe purging the environment enough to look
like you logged into the machine, rather than chrooting)
3) Fakeroot and -ldl - I've noticed some packages for the use of -ldl, in
fairly broken ways. I generally patch it and submit a bug, at this point,
if I find that. If not... check the autoconf or script that sets up
everything, it's usually the next culprit (or, the lack of it, and the
assumption of -ldl in a Makefile, but this is rare anymore).
4) Sharutils - uhm, I'd check whether it needed to link to -lintl (which is
often missed, because GNU libc has this in the libc itself).
> The /etc/ld.so.conf file needs to be mode 644 and not mode 600, because
> with the more restrictive modes, processes running as non-root (yes I
> have gotten that to work) can't see any of the libs in /lib, such as
> ncurses. It's an easy change to make.
Quite true; I'm just working as root for now, myself. I should quit that
at some point.
> Also, /dev/null needs to be mode 666 and /tmp/ needs to be mode 1777.
> Various things break otherwise as non-root with Permission denied
> errors.
I suspect we'll find more of these. And this is really what base-files is
about. Uhm. Has anyone *looked* at base-files? Is there a reason it can't
be built right now? I had thought there was, but...
> Next, while compiling vim (without perl/python/tcl/gtk support), I noticed
> that mkdir foo/ gives a No such directory error, while mkdir foo works fine
> (note the absence of a slash). This is because the version of GNU fileutils
> that is included is from 1999 rather than 2001 (version 4.0l rather than
> 4.1). Apparently fileutils Build-Depends on groff, which needs debconf,
> which needs dialog. All of those are good things to have, so I'm gonna
> do them all.
A new fileutils is up in my APT archive. As is a working groff and
groff-base (but not groff-x11); see the recent comments by Mr. Colin.
Oh,a nd debconf/dialog are up, too.
> I am soon going to make a list of everything in the tarball that is not
> yet packaged, and I'll make a "filler" package with all that stuff. That
> way, the thing I describe in the next paragraph can work. Plus, it'll
> make it very easy to list exactly what we need to package (dpkg -L
> yet-to-package, for example), and we can steadily remove things from
> increasing revisions of this package. It'll be like checking things off
> a list! :-) We'll just have to coordinate who does what, which shouldn't
> be hard if we all use this list.
I *strongly* urge you to look at the APT archive first; I'm adding things
on a daily basis, focusing on the Required and Important priority packages.
Most of what isn't in there is either waiting on an official bugfix (since
I'm not putting up hacked versions if I have a bug open), or require more
work or analysis than I've managed to invest as of yet (and nobody else has
spoken up about it :)
GCC and friends (some 14 packages in the tarball) are all out of date, and
waiting only on the GCC patch appearing in public for a recompile.
> Also, I'm going to set up debootstrap along with a package mirror
> (aptable of course) so that we can have people set up their systems "the
> debian way". (I may even put it in my home directory on an official Debian
> server.) It basically gets the base .debs, extracts them, and sets up a
> chrootable environment, all without dpkg or apt. It does any debconf
> stuff that's required, too (using the noninteractive frontend).
Now this, I haven't worked with yet, though someone mentioned that they
were looking at it. And it's definitely a nice thing, especially for those
of us who have spare debian systems to build the chroot on (can debootstrap
do a cross-architecture build? IE, can I use my 'i386' Debian machine
to read the netbsd-i386 archive and build one from that?)
> And yes I do mean .debs - the binary kind. Do we have any aptable source
> for those yet?
deb http://debian-bsd.lightbearer.com/debian-bsd unstable main contrib non-free
deb-src http://debian-bsd.lightbearer.com/debian-bsd unstable main contrib non-free
> That's more enough for my first substantive email to this list - but see
> below the sig for a bit more ;-)
>
> - Jimmy Kaplowitz
> jimmy@debian.org
>
> P. S. - Sorry if I've overstepped any bounds for someone new to the
> debian-bsd project. I do think I will be able to help out in these
> important ways, and hopefully do my part to help jumpstart things. If
> someone else wants to do any of these things instead, just speak up. Or,
> if you are already working on any of these things, of course speak up
> and I'll try to be helpful to you if I can be.
It's fine, and we always welcome help - but see the above commentary. I've
been playing 'human autobuilder' for the past week, since the actual auto
stuff requires quinn-diff (which needs libglib1.2, which nominally needs
the XFree86 stuff), and the main software blows up in the first file on
wanting a sysinfo() call. I haven't had time to invest in fixing this, yet,
either :)
Oh, and just for the record - if anyone has packages they *want* to see
in the archive, email me. I've just about exhausted the Required packages
that don't require serious fixing, and for that matter, many of those in
the first tarball (since it's my primary list to work from).
If I have some time, I still might look at what compiling X actually *needs*
for a bare-minimal (mostly library/dev packages) compile, since so fragging
many things depend on libxaw, xlibs-dev, libdps, libfreetype6, etc. Or on
tetex-bin, which requires those (or a workaround).
tetex-base and tetex-extra are done, though. Just not installable without
tetex-bin :)
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Reply to: