headers
NetBSD source update | 1 Mar 2012 02:07
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/archivers/mousetar/Makefile
P pkgsrc/archivers/mousetar/distinfo
P pkgsrc/archivers/mousetar/patches/patch-aa
P pkgsrc/archivers/xbin/distinfo
P pkgsrc/archivers/xbin/patches/patch-aa
P pkgsrc/audio/alsa-plugins-oss/Makefile
P pkgsrc/audio/audacity/Makefile
P pkgsrc/audio/bmpx/Makefile
P pkgsrc/audio/ifp-line/Makefile
P pkgsrc/audio/mp3diags/Makefile
P pkgsrc/cad/librecad/Makefile
P pkgsrc/cad/openscad/Makefile
P pkgsrc/chat/konversation/Makefile
P pkgsrc/databases/libcassandra/Makefile
P pkgsrc/devel/boost-build/buildlink3.mk
P pkgsrc/devel/boost-headers/Makefile
P pkgsrc/devel/boost-headers/PLIST
P pkgsrc/devel/boost-headers/buildlink3.mk
P pkgsrc/devel/boost-jam/buildlink3.mk
P pkgsrc/devel/boost-libs/Makefile
P pkgsrc/devel/boost-libs/buildlink3.mk
P pkgsrc/devel/boost-python/buildlink3.mk
P pkgsrc/devel/exempi/Makefile
P pkgsrc/devel/kdesdk4/Makefile
P pkgsrc/devel/libthrift/Makefile
(Continue reading)

Permalink | Reply | 0 comments |
headers
MFL Commissioner | 1 Mar 2012 07:20
Favicon

Re: Maybe it's time to adopt extra testing for certain packages with high number of dependencies

On 2/27/2012 10:44, Ryo ONODERA wrote:
> Hi,
>
> From: John Marino<marino <at> netbsd.org>, Date: Mon, 27 Feb 2012 08:02:00 +0100
>
>> Unfortunately devel/gobject-inspection breaks on the glib module after
>> building glib2 using the patch.  I am not sure if the error lies in
>> glib2 or gobject-introspection which was also recently updated to a
>> new version.  JustinS said gobject-introspection built for him, but
>> it's not clear if his machine was building the latest version.
>>
>>[snip] *** Error code 1
>> ===============================================
>
> On DragonFly/i386 3.0.1, devel/gobject-introspection builds.
>

Ryo ONODERA,

I successfully built glib2 and gobject-introspection and every other 
updated dependency of firefox 10 inside the clean environment of 
tinderbox-dragonfly.  It's jail is post 3.0.1-RELEASE but it's not at 
the latest either.

Let's go ahead and assume the problem with gobject-introspection is 
specific to my work machine.

the glib2 patch seems okay.  Please commit it.

Thanks!
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Marino | 1 Mar 2012 08:58
Favicon

Re: FireFox 10.0.1 pkg for testing

On 2/27/2012 23:21, Ryo ONODERA wrote:
> Hi,
>
> From: Martin Husemann<martin <at> duskware.de>, Date: Sat, 25 Feb 2012 14:04:05 +0100
>>> But in link stage, the following error generated.
>>> I cannot understand why it fails.
>>> I have added some OS_LIBS += $(call EXPAND_LIBNAME,kvm) to makefiles,
>>> no effects. Attached patch-* does not include this attempt.
>>
>> Hmm, that is what I would have tried as well - DragonFly folks, any ideas?
>
> DragonFly 3.0.1 have shipped with gcc 4.4.7 and 4.1.2 and gcc 4.4.7 is default.
> With gcc 4.4.7, hidden symbol error generated even when -lkvm is added.
> With gcc 4.1.2, hidden symbol error does not generated when -lkvm is added.
>
> There is gcc 4.4.7 related problem probably.
>
> Thank you.
>

I was able to recreate this error on tinderbox-dragonfly.
Would linking libkvm statically solve this?
John
Permalink | Reply | 4 comments |
headers
Martin Husemann | 1 Mar 2012 10:02
Picon

Re: FireFox 10.0.1 pkg for testing

On Thu, Mar 01, 2012 at 08:58:52AM +0100, John Marino wrote:
> I was able to recreate this error on tinderbox-dragonfly.
> Would linking libkvm statically solve this?

Could someone describe the problem again, please?
Last error messages I saw had:

> process_util_bsd.cc:(.text+0x859): undefined reference to `kvm_open'
> process_util_bsd.cc:(.text+0x885): undefined reference to `kvm_getprocs' 
> process_util_bsd.cc:(.text+0x9b2): undefined reference to `kvm_close'  

are these gone with libkinfo/libkvm or whatever?

/usr/libexec/binutils221/elf/ld: libxul.so: hidden symbol `kvm_getprocs' isn't defined

This might be a missing include or something, please check how kvm_getprocs
is defined when used in process_util_bsd.cc. It could be a wrong extern
declaration, which (due to default visibility hidden) needs an explicit
visibility attribute. An example for this happening is the extern declaration
of "environ" in the same source file:

#ifdef HAVE_POSIX_SPAWN
#include <spawn.h>
extern "C" char **environ __dso_public;
#endif

without the __dso_public, which is defined as:

	 __attribute__((__visibility__("default")))
(Continue reading)

Permalink | Reply | 3 comments |
headers
Havard Eidnes | 1 Mar 2012 11:51
Picon

Re: the pixman problem

> People using -5 have become all too familiar with this:
>
> .../work/.x11-buildlink/lib/libcairo.so: undefined reference to `pixman_image_set_destroy_function'
> .../work/.x11-buildlink/lib/libcairo.so: undefined reference to `pixman_image_composite32'
> .../work/.x11-buildlink/lib/libcairo.so: undefined reference to `pixman_image_fill_boxes'
> *** Error 1

Indeed.  The graphics/gnuplot package is just one example, which
was the first one I stumbled over.

> (1) Something in the victim package's config logic adds
> -L/usr/X11R7/lib -R/usr/X11R7/lib to LDFLAGS or LIBS.

In the case of gnuplot, it appears that AC_PATH_XTRA used in
configure.in is responsible for adding the -R/usr/X11R7/lib part,
via X_LIBS which configure.in converts into LIBRARIES_FOR_X.  At
that point I stopped trying to fix the package, since AC_PATH_XTRA
comes from autoconf and not from the package itself.

> (2) This gets added *before* the -Wl,-R/usr/pkg/lib -Wl,-R/usr/X11R7/lib
> that comes from pkg-config.

Correct, this is apparently something gcc does -- it reorders any
-R args to come first in the ld invocation, which messes up the
search order relative to any other -Wl,-R specifications.

> (3) The wrappers remove -L/usr/X11R7/lib but leave the
> -R/usr/X11R7/lib alone and print:
>    WARNING: [transform-gcc] passing unknown option -R/usr/X11R7/lib
(Continue reading)

Permalink | Reply | 3 comments |
headers
OBATA Akio | 1 Mar 2012 14:00
Picon

TOOLS_PLATFORM.xxx, TOOLS_PATH.xxx and ${TOOLS_VARNAME.xxx}

On system:
TOOLS_PLATFORM.wish=/usr/bin/wish

With condition:
_TOOLS_USE_PKGSRC.with=yes

In pkg's Makefile:
USE_TOOLS+= wish

Then
% make show-vars VARNAMES="TOOLS_PLATFORM.wish TOOLS_PATH.wish WISH"
/usr/bin/wish
/usr/pkg/bin/wish
/usr/bin/wish

Is it expected behavior?
If so,
  * `TOOLS_PATH.wish' (or `TOOLS_CMDLINE.wish') should be used for the case
    `wish' is effect to installed package contents.
  * `WISH' should be used for packaging work (pkgsrc framework, make targets, or so on).

I it correct?

--

-- 
OBATA Akio / obache <at> NetBSD.org
Permalink | Reply | 2 comments |
headers
Benny Siegert | 1 Mar 2012 14:53
Picon
Gravatar

Re: TOOLS_PLATFORM.xxx, TOOLS_PATH.xxx and ${TOOLS_VARNAME.xxx}

On Thu, Mar 1, 2012 at 14:00, OBATA Akio <obache <at> netbsd.org> wrote:
> _TOOLS_USE_PKGSRC.with=yes

This one is misspelled, maybe this is the reason?

--Benny.
Permalink | Reply | 1 comment |
headers
Greg Troxel | 1 Mar 2012 20:12
Picon

pkg_install breakage


On a NetBSD/i386 machine with recent netbsd-5 (this January) and
-current pkgsrc, trying to build pkgsrc/pkgtools/pkg_install fails.  I
get the same failure on another netbsd-5 i386 machine.

Are others seeing this?

===> Building for pkg_install-20120221
--- all ---
make:
"/n0/gdt/NetBSD-current/pkgsrc/pkgtools/pkg_install/work/pkg_install-20120221/lib/Makefile"
line 65: Malformed conditional (!empty(MANINSTALL:Mcatinstall))
make: Fatal errors encountered -- cannot continue

make: stopped in /n0/gdt/NetBSD-current/pkgsrc/pkgtools/pkg_install/work/pkg_install-20120221/lib
*** [all] Error code 1
1 error

make: stopped in /n0/gdt/NetBSD-current/pkgsrc/pkgtools/pkg_install/work/pkg_install-20120221
*** Error code 2

Stop.
make: stopped in /n0/gdt/NetBSD-current/pkgsrc/pkgtools/pkg_install
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/pkgtools/pkg_install
Permalink | Reply | 2 comments |
headers
Robert Elz | 1 Mar 2012 21:16
Picon

Re: pkg_install breakage

    Date:        Thu, 01 Mar 2012 14:12:49 -0500
    From:        Greg Troxel <gdt <at> ir.bbn.com>
    Message-ID:  <rmi62eodtji.fsf <at> fnord.ir.bbn.com>

  | Are others seeing this?

I built pkg_install-20120221 on NetBSD 5.0/i386 a week or so ago (Feb 24)
without any problems.   It was built in a fairly empty pkg_comp sandbox
(with USE_DESTDIR=no in case that makes a difference.)

kre
Permalink | Reply | 1 comment |
headers
Greg Troxel | 1 Mar 2012 21:53
Picon

Re: pkg_install breakage [FIXED!]


Robert Elz <kre <at> munnari.OZ.AU> writes:

>     Date:        Thu, 01 Mar 2012 14:12:49 -0500
>     From:        Greg Troxel <gdt <at> ir.bbn.com>
>     Message-ID:  <rmi62eodtji.fsf <at> fnord.ir.bbn.com>
>
>   | Are others seeing this?
>
> I built pkg_install-20120221 on NetBSD 5.0/i386 a week or so ago (Feb 24)
> without any problems.   It was built in a fairly empty pkg_comp sandbox
> (with USE_DESTDIR=no in case that makes a difference.)

The problem was introduced on 2/28 (about not installing man pages if
MANINSTALL says not to), and jklos just fixed it (to work if MANINSTALL
was not defined).
Permalink | Reply | 0 comments |

Gmane