[Glibc-bsd-devel] GNU/kFreeBSD and package report

[Brian M. Carlson]

=2D----BEGIN PGP SIGNED MESSAGE-----

On Thursday 01 July 2004 22:49, Robert Millan wrote:
> Hi Brian!

Greetings.

> On Thu, Jul 01, 2004 at 10:05:15PM +0000, Brian M. Carlson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > I installed GNU/kFreeBSD using livecd2; it works well except for a
> > few things. ssh is broken: it doesn't prompt for passwords or
> > passphrases, and so the only thing that can be done is to use a key
> > without a passphrase. This is obviously not the most secure thing
> > to do. This may have something to do with /dev/tty not appearing in
> > the 'ls /dev' output (it does appear in the 'ls /dev/tty' output).
>
> This is related to the terminal definition. IIRC Guillem knows more
> about this.
>
> Btw, you can work around it by using screen.

OK, that's what I'll do then.

> > I've compiled a list of successful and unsuccessful packages that I
> > have attempted to build. Those marked builds built successfully,
> > those marked needs-update need some sort of autotools or dependency
> > update, needs-dependencies indicates a need for dependencies that
> > are lacking, and failed indicates a refusal to build, usually
> > because they depend on Linux semantics, instead of BSD.
>
> Generaly, packages depend on Glibc semantics and are not really
> dependant on kernel interfaces (Linux, kFreeBSD, etc).
>
> All packages in Debian support Glibc. However, some check for Glibc
> in the wrong way. For example they check if you are running Linux
> before using code for Glibc, etc. This is the most common source of
> breakness.
>
> > lcms (config.*)
>
> We generaly don't care much about these (since they are fixed
> eventualy with no effort). However, if you want to send a note to the
> debian maintainer or upstream it doesn't hurt ;).

OK.

> > neon (autoreconf; ./autogen.sh)
>
> This is probably libtool-related. But anyway, if that suffices to get
> it working it's all fine. Could you send a bug report for this?

I have filed a bug.

> > krb4 (builds with db4.2; currently uses db4.1, which is not in
> > archive)
>
> db4.1 should work. Perhaps it needs a libtool/autotools update (which
> is non trivial in its weird build system) but that should be all.

db4.1 requires java to build, and we don't have java. So either=20
debian/control needs to be modified or we need to get java (which=20
requires libffi2).

> > gcc-3.3 (needs !kfreebsd-i386 wherever !freebsd-i386 is, plus
> > libc0.1-dev, build not tested)
>
> gcc-3.2 or gcc-3.3 both need heavy patching in order to work. I did
> it for the debian gcc-3.4 package but I don't find it worth to
> backport the fixes to 3.2 or 3.3. We currently have hacked binaries
> for gcc-3.2 and gcc-3.3 in the archive though.
>
> If you like, you can backport the changes in gcc-3.4 (by differing
> from the gcccvs SVN repository) to gcc-3.2 and gcc-3.3, but I find
> more useful to spend effort getting gcc-3.4 in shape rather than
> this.

Should we modify gcc-defaults to make it the default on kfreebsd-gnu?

> Currently gcc-3.4 (in experimental) still won't build but it's mostly
> fixed. There was a problem with our selection of conditional patches
> not being compatible. Would you like to give it a try?

I'll see what I can do. I won't have access this weekend (July 4 is the=20
US Independence Day which I am spending with family) but if not this=20
weekend, then next week probably. I'd like to get subversion working=20
first, so I can pull patches directly into the system.

> > apache2 (tarball uses out of date autotools that do not know about
> > GNU/kFreeBSD)
>
> Ah, I see. Same as in neon.

The difference here is that the upstream tarball contains the broken=20
autotools and the .orig.tar.gz just contains the upstream tarball,=20
which is unpacked during the build process, so it's much harder to fix.=20
Bug filed.

> > needs-dependencies
> > - ------------------
> > openldap2 B-D: libsasl2-dev (cyrus-sasl2)
> > cyrus-sasl2 B-D: libldap2-dev (openldap2)
>
> Yeah, chicken and egg.
>
> Last time I checked, one of them can be built without the other, but
> at that time there were other build-deps I couldn't resolve. Is it
> like this yet?

I'll work on it. gnutls10 is holding the entire thing up right now.

> > vim B-D: libgpmg1 (gpm)
>
> We don't have gpm (it's Linux-specific). When packages build-depend
> on it they should conditionalise it with type-handling. E.g:
>
> Build-Depends: ..., vim | not+linux-gnu, ...

ITYM, libgpmg1 | not+linux-gnu. A bug has been filed.

> Could you try disabling it and see if it builds/works?

Yes, it does. I had to disable building python because python-dev broke=20
the build process, but it basically took just hacking=20
debian/{control,rules}. 6.3 works with lesstif, and gtk. I'll send a=20
patch soon.

> > gcc-3.3 B-D-I: doxygen (doxygen)
>
> Always use -B for building. Then you don't need to care about
> Build-Depends-Indep.

Yeah, I eventually did. I first tried -b, but that didn't seem to work.

> > fails
> > - -----
> > esound (doesn't copy libesd.la to directory because of typo)
>
> Probably also needs a libtool update. Are you sending a bug report?

I have done so. Actually, I figured out that it's not a typo, but that=20
it doesn't copy into debian/tmp everything that should be there. Maybe=20
it's a debhelper problem that I just can't see.

> > gpm (FreeBSD semantics differ from Linux, duh)
>
> Yeah. This is totaly unportable. We'll just port the utilities
> FreeBSD provides for this functionality to GNU/kFreeBSD. That's way
> easier.

Actually, it isn't that far off with the constants, but the struct=20
vt_stat scared me.

> > mp3blaster (compiler syntax error on apparently valid code)
>
> If you paste the error and offending code in this list, maybe we can
> help.

I will get back to you on this. I did manage to build madplay, so OSS=20
does work.

> > krb5 (can't find res_search in -lresolv)
>
> Ah, the mithical res_search thing. Guillem fixed some of these bugs
> IIRC.

OK. There is a __res_search, though.

> > postgresql (no template for kfreebsd-i386)
>
> What do you mean here?

The postgresql build system uses autotools to select some template that=20
it then uses for building somehow. There is no template for=20
i386-unknown-kfreebsd5.2.1-gnu or i386-pc-kfreebsd-gnu.

> > In order to support sablevm, gcc-3.3 should probably be configured
> > to build libffi2. Then java support will be much easier.
>
> libffi is not supported in gcc. When porting gcc pre3.5 (in
> upstream), I gave it an attempt but gave up soon as I didn't care
> much. If you are going to fix it, I suggest you do it in upstream
> CVS, so that 3.5 release fully supports GNU/kFreeBSD. Then we can
> backport your patch to older releases in Debian.

Okay. I don't know much about gcc, but I'll try. I do know that sablevm,=20
at least, uses libffi2 a great deal for portability ;-).

> > Also, some
> > packages use autotools but the versions they use don't support
> > shared libraries on this platform. What is the workaround for that?
>
> Yes. This is because of outdated libtool. You just need to libtoolize
> that package (and regenerate aclocal.m4, configure.ac, etc) and it'll
> work.
>
> See bug #242950 for details.

Thanks, I'll do that.

I'd also like to point out that we are now more popular (according to=20
popcon) than both s390 and hurd-i386.

In addition, imlib+png2 builds with libpng12-dev (which is the old=20
libpng3) and also it fails linking looking for XFreePixmap (and a host=20
of other X* functions). I'll post a build log soon.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQOWaNuWR/8lWBVPnAQFTjgf7Bm0MUtaT87WiHOPJiJWL+u23fJZGVdaH
WE/5skHTVLrpCa/RJs2G2zeRojo9nk1NhBg1+NwJk6I9SshyJgi5YXX8kpg3Zaxx
mttOTaFGqzjI0g8Co1eDXAI9QpgvcAq6/Ndbv//AaawRIbLa6J6oV2dQIaZ1DEs0
QYc9L5sjcGJ+YwrpVieNadcsbRj0+Y5BiBGlHBU6/g8HbXp1+Dw4wD+6iyVHVeFh
xPm3JyPbOh7D+ogIKm9lrN+5kzAkABqydm4YdQUfc/hpvKqtizy8COVF7YWQmgCQ
dDqZKDehJ6bCkR/RY/TCzbH6QWnJ/kvbljRch6cm8ZLID3FhIJnTLw=3D=3D
=3DTQN4
=2D----END PGP SIGNATURE-----