Miscellaneous notes

[Brian M. Carlson]

On Saturday 19 November 2005 09:41, Robert Millan wrote:
> On Sat, Nov 19, 2005 at 05:20:23AM +0000, Brian M. Carlson wrote:
> > I have kFreeBSD 6.0 packages working.
>
> Very nice!  Btw, did you need to fix anything in trunk/kfreebsd-6 ?  When I
> committed it it wasn't yet tested.

I had to do some serious overhaul. ;-)  However, it seems that with the proper 
patches it works, except for the ssh problem.  Some patches for 
freebsd6-buildutils were necessary also.  I think kldutils only needed 
adjustments on the current patches.

The code is already sitting in my public_html directory on my server; it's 
just waiting for apache2 to work.

> > However, there is a need for updated
> > glibc packages, as this would fix the ssh/sftp problem[0].
> > [...]
> > [0] http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/grantpt.c
>
> I don't quite understand the problem with openpty(), but Glibc 2.3 is now
> buildable.  Does that help?

The problems Robert Edmonds reported with ssh are not yet fixed in glibc.  But 
for some reason the devname call is necessary to get it to work on 6.0 (see 
the diff between 1.3 and 1.4).  As a consequence, it should be patched to use 
devname (at least) if we're using 6.0.  I don't know if 5.4 has it.  This is 
the problem with openpty.

I think the underlying problem is that FreeBSD's devfs (in 6.0 at least) has 
dynamic major/minor numbers, and so devname is essential to get it to find 
the right name.

Does that explain it better?

> > Can we please not reboot the system if remount at reboot fails?  I think
> > it would be fine to wait on the disk for several seconds (up to 60) to
> > become not busy.  This just cost me /etc/motd due to a filesystem and
> > softupdates inconsistency, and fsck runs at every boot.  Thank you.
>
> Sounds good.  I'd also add a "sync" before calling mount.

Sounds like a great idea.

Other notes:

FreeBSD's HEAD contains support for POSIX realtime signals.  I don't know if 
they're going to MFC (merge from -current) into 6.1, but I sure hope so.

gcc-4.1 is building now, and I expect it will work (I will report back).  The 
problem is for some reason it is build-depending on libc0.1 (>= 2.3.5-5), 
which obviously doesn't exist, so I had to force it.  However, I don't expect 
this to cause the build to fail, and if it succeeds, I will file a bug asking 
to relax the build-deps at least for us.

Also, when trying to build gcc-4.1, it seems that fastjar fails because it 
can't find DIR, from dirent.h.  It turns out this is because the following 
test program fails:

-------
/* confdefs.h.  */

#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
/* end confdefs.h.  */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif
-------

If you run gcc -E on it, you will find a bug in glibc's handling of limits.h 
and dirent.h.  That's because we don't handle the _LIBC_LIMITS_H_ [sic] and 
_SYS_CDEFS_H [sic] properly.  Instead of erroring out, I'd just #include 
<sys/cdefs.h> in sys/syslimits.h, which is what I did to my local copy.  If 
you can find a better solution, by all means implement it.

I am working on glibc 2.3.5-8, but it may take awhile to figure out how 
everything works and get it bootstrapped.  Here in the U.S., our Thanksgiving 
holiday is Wednesday to Friday of next week (Nov. 23-25, this year), so I 
will probably not have time to work on it then, since I will be with family 
and my laptop is powerpc.  However, I will still read my mail.

-- 
Brian M. Carlson <sandals at crustytoothpaste.ath.cx>
Running on GNU/kFreeBSD
Support alternative kernels in Debian!