NetBSD 5 package status

[Greg Troxel]

Manuel's bulk reports for 2014Q1 show the following packages with lots
of consequences (plus math/blas on amd64):

x11/gtk3 406 pkgsrc-***@NetBSD.org
devel/boost-libs 325 pkgsrc-***@NetBSD.org
audio/pulseaudio 302 pkgsrc-***@NetBSD.org

Has anyone looked into these or fixed them since Q1?

[OBATA Akio]

Post by Greg Troxel
Manuel's bulk reports for 2014Q1 show the following packages with lots

Builtin X11 is too old for gtk3.
Conversely, builtin X11 is sufficient unless using gtk3.
Unclear point is
* inputproto>=2.0 is required to build
* libXi is also required (no version specified, buitin one is sufficient)
* libXi require inputproto to build, and also in buildlink3.mk.
For such case, buitin libXi should be used or pkgsrc one?
(currently, pkgsrc one will be selected)
Builtin GCC is too old?
We can also find some packages that GCC_REQD is set higher than NetBSD 5
builtin gcc.
USE_PKGSRC_GCC should be set for NetBSD 5?
x11 option is enabled by default, but it require x11-xcb,
but it is not in NetBSD 5 builtin X11.

Same as gtk3, libX11 from pkgsrc must be used, i.e. almost of
builtin X11 will not be used.
gtk3 and pulseaudio will be mixed used with other package depending on X11.
So if gtk3 and pulseaudio are built with libX11 from pkgsrc,
other package (gtk2, and so on) also must be built with libX11 from pkgsrc.

In desktop related packages (x11, gnome, and so on), we can find that
many BUILDLINK_API_DEPENDS are defined individually.

Should we bump BUILDLINK_API_DEPENDS.pkg defined in pkg/buildlink3.mk?

Is it realistic approach to still support pre-modular monolithic old X?

Should we allow partial packages with builtin X11, or should we set
required version (BUILDLINK_API_DEPENDS) consistently for whole
pkgsrc tree?

[Greg Troxel]

Post by OBATA Akio
Builtin X11 is too old for gtk3.
Builtin GCC is too old?

(Thanks John also for the confirming comments.)

So it seems like we have two separate problems.

1) netbsd-5 x11 is crufty

Builtin x11 on netbsd-5 is too old for a number of things, We don't
really have enough cycles to keep this working; until I raised the
issue about freetype2 last time it had been broken a long time.

Not really germane to pkgsrc, but if NetBSD 7 had been released we
would ignore netbsd-5. NetBSD 5 was released over 5 years ago.

Post by OBATA Akio
Should we allow partial packages with builtin X11, or should we set
required version (BUILDLINK_API_DEPENDS) consistently for whole
pkgsrc tree?

My guess is that mixing builtin x11 and xorg is tricky and in general
can't really work. At best each module has to be flipped to xorg
globally for pkgsrc if any package needs it, which is what I think you
are suggesting.

Switching netbsd-5 to modular is a low-churn approach for all
platforms except netbsd-5. Like John, I use modular on netbsd-5, and
things work pretty well.

Trying to fix pkgsrc so that things will build on nebtsd-5/native has
a risk of destabilitzing pkgsrc on other platforms, and we're about to
enter the Q2 freeze. With Q1, there were a lot of problems with
freetype2, but I realize that was partly a security fix being needed
at an inopportune time. I would really like to avoid this happening
again.

I don't see much downside to swtiching netbsd-5 to modular. The real
question is what choice better serves a pkgsrc user on netbsd-5. So I
think we should switch, and I don't really want to put effort (myself)
into making netbsd-5/native work.

2) boost-libs needs newer gcc

So we should set GCC_REQD for boost-libs, or perhaps force higher gcc
for everything (which seems like overkill)..

Possibly, programs that include boost-libs need higher gcc too,
because of the complexity in .h files. Perhaps we can put that in the
buildlink3.mk.

This situation worries me less, because someone with a netbsd-5 system
can experiment with the compiler issues and build things more easily
than flipping to modular, which invalidates using most binary packages
and requires a big rebuild.

[John D. Baker]

Post by Greg Troxel
Manuel's bulk reports for 2014Q1 show the following packages with lots

Not long (enough) ago, I gave up on netbsd-5 in-tree Xorg and use only
modular/pkgsrc Xorg on the systems I still have running netbsd-5 (three
i386 systems). (I would like to use netbsd-6 or -current, but something
broke the X server between -5 and -6 on some i810e-based machines, see
PR/48344).

Anyway, with modular/pkgsrc Xorg, x11/gtk3 builds and operates just fine
on netbsd-5/i386.
This apparently can't be compiled with native gcc 4.1.3 in netbsd-5.
It built successfully with gcc 4.6.4 (needed for www/firefox anyway)
but none of the packages that depend on boost-libs (that I tried--
multimedia/gnash, cad/kicad, misc/libreoffice4) would build. I had
other alternatives and tasks so have not investigated it further.
I disable pulseaudio in PKG_DEFAULT_OPTIONS so no, I have not tried it.

[John D. Baker]

Post by John D. Baker
It built successfully with gcc 4.6.4 (needed for www/firefox anyway)
but none of the packages that depend on boost-libs (that I tried--
multimedia/gnash, cad/kicad, misc/libreoffice4) would build. I had
2) boost-libs needs newer gcc
Possibly, programs that include boost-libs need higher gcc too,
because of the complexity in .h files. Perhaps we can put that in
the buildlink3.mk.

I returned to trying to build cad/kicad (with GCC 4.6), but that fails
as well, although not as many warnings as with native gcc 4.1.3. The
failure indicates missing prototypes/declarations for floating-point
functions. The build of "kicad" stopped due to missing declaration of
"fabsl()". IIRC, the other boost-libs-dependent packages failed in
similar fashion.

[ 51%] Building CXX object common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o
/d0/build/pkgsrc/cad/kicad/work/kicad-stable-20140214/pcbnew/legacy_plugin.cpp: In member function 'int LEGACY_PLUGIN::biuSprintf(char*, LEGACY_PLUGIN::BIU) const':
/d0/build/pkgsrc/cad/kicad/work/kicad-stable-20140214/pcbnew/legacy_plugin.cpp:2659:44: error: 'fabsl' was not declared in this scope
*** Error code 1