headers
NetBSD source update | 1 Nov 2007 02:13
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/archivers/stuffit/Makefile
P pkgsrc/archivers/unace-bin/Makefile
P pkgsrc/archivers/xbin/Makefile
P pkgsrc/databases/rrdtool/Makefile
P pkgsrc/devel/GConf/Makefile
P pkgsrc/devel/GConf/Makefile.common
P pkgsrc/devel/GConf/PLIST
P pkgsrc/devel/GConf/distinfo
P pkgsrc/devel/GConf-ui/Makefile
P pkgsrc/devel/at-spi/Makefile
P pkgsrc/devel/at-spi/PLIST
U pkgsrc/devel/at-spi/distinfo
U pkgsrc/devel/at-spi/patches/patch-aa
P pkgsrc/devel/gail/Makefile
P pkgsrc/devel/gail/distinfo
P pkgsrc/devel/gmp/Makefile
P pkgsrc/devel/gmp/distinfo
P pkgsrc/devel/kdevelop-base/Makefile
P pkgsrc/devel/kdevelop-base/distinfo
U pkgsrc/devel/kdevelop-base/patches/patch-aj
P pkgsrc/devel/libbonobo/Makefile
P pkgsrc/devel/libbonobo/PLIST
P pkgsrc/devel/libbonobo/distinfo
P pkgsrc/devel/libbonoboui/Makefile
P pkgsrc/devel/libbonoboui/PLIST
(Continue reading)

Permalink | Reply | 0 comments |
headers
Min Sik Kim | 1 Nov 2007 04:11
Picon

Re: Some pullup-requests

On 10/31/07, Joerg Sonnenberger <joerg <at> britannica.bec.de> wrote:
> On Wed, Oct 31, 2007 at 01:55:18PM +0100, Dennis den Brok wrote:
> > databases/shared-mime-info , which recently received a build fix
> > for NetBSD {2,3}.*
>
> I said it in the ticket -- I strongly object that and I will just back
> out the change if noone bothers enough to help to fix the real issue.

As I said in the PR, please do not revert the change until
shared-mime-info builds without it.

The package in pkgsrc-2007Q3 has never built on NetBSD-3, preventing
stable branch users from building gnome packages.  It really hurts our
reputation in both NetBSD and pkgsrc.  If no one comes up with a
better fix soon, I think we should pull up the change.

Regards,
Min
Permalink | Reply | 0 comments |
headers
David Brownlee | 1 Nov 2007 10:05
Picon

Re: Some pullup-requests

On Wed, 31 Oct 2007, Joerg Sonnenberger wrote:

> On Wed, Oct 31, 2007 at 01:55:18PM +0100, Dennis den Brok wrote:
>> databases/shared-mime-info , which recently received a build fix
>> for NetBSD {2,3}.*
>
> I said it in the ticket -- I strongly object that and I will just back
> out the change if noone bothers enough to help to fix the real issue.

 	So what are the options?

 	a) INCOMPAT_GETTEXT+= NetBSD-[123].*
 	   Builds and runs, but the same binary could end up pulling
 	   in system and pkgsrc gettext, with associated issues
 	b) We declare INCOMPAT_GETTEXT for everything on NetBSD-[123].*
 	   Clean & quick, but something of a sledgehammer
 	c) Some logic to fixup the files so the other gettext can handle
 	   them
 	   The best solution, but the most work
--

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --
Permalink | Reply | 2 comments |
headers
Joerg Sonnenberger | 1 Nov 2007 14:07
Picon

Re: Some pullup-requests

On Thu, Nov 01, 2007 at 09:05:28AM +0000, David Brownlee wrote:
> 	b) We declare INCOMPAT_GETTEXT for everything on NetBSD-[123].*
> 	   Clean & quick, but something of a sledgehammer

Doesn't work either as NetBSD doesn't support the argument reordering
and the macros create some interesting issues e.g. for mplayer and other
applications that build stuff with libintl.h but without linking with
-lintl.

> 	c) Some logic to fixup the files so the other gettext can handle
> 	   them
> 	   The best solution, but the most work

Noone has provided the data point that those files *don't* work. It used
to work fine with older versions of intltool, so I am quite happy to put
the blame on that.

Joerg
Permalink | Reply | 1 comment |
headers
Johnny C. Lam | 1 Nov 2007 15:05

Re: RFC: Fix for IMAKE_MANINSTALL handling

Roland Illig wrote:
> Johnny C. Lam wrote:
>> I'd prefer to keep all the hard stuff in mk/plist if possible, and 
>> leave PLISTs and simple to read and understand as possible.
>>
>> In the above scenario, where you have a custom native X11 
>> installation, you say that both man pages and catman pages are 
>> installed.  In your oneko example, why don't we do something like:
>>
>>     bin/oneko
>>     man/man1/oneko.1
> 
> As long as the "1" is unambiguous here, I'm fine with it.

Judging from what I see in mk/platform/*.mk, I believe it is 
unambiguous.  That means we can map the "man/man1/oneko.1" consistently 
to something else for another X11 installation, e.g. "man/man1/oneko.1x" 
on Solaris.

>> In the case where a package installs manpages through imake, we do 
>> something like:
>>
>>     PKGMANDIR=    ${IMAKE_MANDIR}
>>
>> where IMAKE_MANDIR varies based on the X11 installation.  This would 
>> inform the plist module that the "man" subdirectory could be something 
>> else, e.g. "catman/u_man" on IRIX.  We teach the plist module a new 
>> variable, PKGMANSUBDIR which is a special directory inside the normal 
>> man page directory where the man pages are stored, e.g. "X11" on IRIX 
>> but normally empty for most platforms.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Klos | 2 Nov 2007 00:36

lang/php5 problem om m68k

NetBSD 4 from 22-Oct-2007, pkgsrc from two days ago, on a mac68k system:

/bin/sh /usr/pkgsrc/lang/php5/work/php-5.2.4/libtool --silent 
--preserve-dup-deps --mode=compile cc  -Iext/standard/ 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4/ext/standard/ -DPHP_ATOM_INC 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4/include 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4/main 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4 -I/usr/local/include/libxml2 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4/ext/date/lib 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4/TSRM 
-I/usr/pkgsrc/lang/php5/work/php-5.2.4/Zend  -I/usr/local/include 
-I/usr/include  -O2 -O2 -m68040 -I/usr/local/include -I/usr/include  -c 
/usr/pkgsrc/lang/php5/work/php-5.2.4/ext/standard/filters.c -o 
ext/standard/filters.lo
/var/tmp//ccAJpMGN.s: Assembler messages:
/var/tmp//ccAJpMGN.s:234: Error: value out of range
/var/tmp//ccAJpMGN.s:234: Error: value of -286 too large for field of 1 
bytes at 535
/var/tmp//ccAJpMGN.s:277: Error: value out of range
/var/tmp//ccAJpMGN.s:277: Error: value of -286 too large for field of 1 
bytes at 627
/var/tmp//ccAJpMGN.s:355: Error: value out of range
/var/tmp//ccAJpMGN.s:355: Error: value of -286 too large for field of 1 
bytes at 833
gmake: *** [ext/standard/filters.lo] Error 1
*** Error code 2

Stop.
make: stopped in /usr/pkgsrc/lang/php5
*** Error code 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 2 Nov 2007 01:27

should package renames mean dependency bumps?

A few days ago in my "ERROR: libglade is not installed; can't buildlink 
files." email I asked about this.

I have same problem again (third time lately).

Building inkscape fails with:

	ERROR: libsigcpp is not installed; can't buildlink files.

inkscape includes x11/gtkmm/buildlink3.mk which includes 
devel/glibmm/buildlink3.mk which includes devel/libsigc++/buildlink3.mk.

I have good enough gtkmm and glibmm installed so pkgsrc doesn't know to 
install devel/libsigc++.

I have libsigc++2-2.0.17nb1 installed.

libsigc++2 was renamed to libsigc++ on 2007/09/21.

What can we do to make pkgsrc work?

One solution is to bump the required versions for the packages that depend 
on a renamed package. So I have installed:

glibmm-2.12.10

And at the time of the libsigc++ rename, it was 2.12.10.

Something like this should fix my problem:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeremy C. Reed | 2 Nov 2007 01:43

Re: should package renames mean dependency bumps?

Just updating glibmm's buildlink3.mk is not good enough. That causes a new 
error for me:

	ERROR: glibmm is not installed; can't buildlink files.

It is installed.

Bumping the BUILDLINK_ABI_DEPENDS.libsigcpp also does not help.

Bumping BUILDLINK_API_DEPENDS.gtkmm should do it in addition to the 
BUILDLINK_API_DEPENDS.glibmm, but that means I have to reinstall three new 
packages (for no real API reason) just because one was renamed.

Any advice?

A third idea is to get the new buildlink3.mk file for libsigc++ to know 
about the previous PKGNAME and maybe use it?

  Jeremy C. Reed
Permalink | Reply | 0 comments |
headers
NetBSD source update | 2 Nov 2007 02:24
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/audio/bmpx/Makefile
P pkgsrc/audio/bmpx/distinfo
U pkgsrc/audio/bmpx/patches/patch-aa
P pkgsrc/bootstrap/bootstrap
P pkgsrc/databases/gramps2/Makefile
P pkgsrc/databases/gramps2/PLIST
P pkgsrc/databases/gramps2/distinfo
P pkgsrc/devel/Makefile
P pkgsrc/doc/CHANGES-2007
P pkgsrc/doc/TODO
U pkgsrc/editors/emacs/PLIST.carbon
P pkgsrc/editors/emacs/options.mk
P pkgsrc/editors/vim-share/Makefile.common
P pkgsrc/editors/vim-share/distinfo
P pkgsrc/editors/vim-share/version.mk
P pkgsrc/fonts/t1lib/Makefile
U pkgsrc/fonts/t1lib/options.mk
P pkgsrc/graphics/Makefile
P pkgsrc/graphics/gimp/Makefile
P pkgsrc/graphics/gimp/distinfo
P pkgsrc/graphics/gimp/patches/patch-ab
cvs update: pkgsrc/graphics/gimp24/DESCR is no longer in the repository
cvs update: pkgsrc/graphics/gimp24/Makefile is no longer in the repository
cvs update: pkgsrc/graphics/gimp24/PLIST is no longer in the repository
cvs update: pkgsrc/graphics/gimp24/buildlink3.mk is no longer in the repository
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ulrich Habel | 2 Nov 2007 10:30

Re: pkgsrc-2007Q3 SunOS 5.9/sparc bulk build results 20071027.2253

On Fri, 2 Nov 2007, Ulrich Habel wrote:

>        Build started:                  Sat Oct 27 21:16:25 2007 UTC
>        Build ended:                    Fri Nov 02 06:47:49 2007 UTC
>
>        Successfully packaged:          3827
>        Packages really broken:         1213
>        Pkgs broken due to them:        1830
>        Total broken:                   3043
>        Not packaged:                   11
>        Not available:                  486
>        Total:                          3054
>

There are still some problems around. I built this bulk build with my fix 
for PR 37200.

I am still sorting out other problems like the non-building atk. It will 
build if I set a LD_LIBRARY_PATH explictly to:

LD_LIBRARY_PATH=/usr/pkg/lib:$LD_LIBRARY_PATH

as it find the one which is included in Solaris first and the build will 
crash due to version mismatch.

Regards
Uli
Permalink | Reply | 0 comments |

Gmane