headers
NetBSD source update | 1 Apr 2012 03:05
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
? pkgsrc/net/wget/work
P pkgsrc/chat/eggdrop/Makefile
P pkgsrc/chat/eggdrop/PLIST
P pkgsrc/chat/eggdrop/distinfo
P pkgsrc/chat/eggdrop/patches/patch-aa
P pkgsrc/chat/eggdrop/patches/patch-ab
P pkgsrc/chat/eggdrop/patches/patch-ad
P pkgsrc/chat/eggdrop/patches/patch-ag
P pkgsrc/databases/phppgadmin/DESCR
P pkgsrc/databases/phppgadmin/MESSAGE
P pkgsrc/doc/CHANGES-2012
P pkgsrc/doc/TODO
P pkgsrc/emulators/suse121_libpng/Makefile
U pkgsrc/emulators/suse121_libpng/distinfo
P pkgsrc/filesystems/glusterfs/Makefile
P pkgsrc/graphics/kipi-plugins/buildlink3.mk
P pkgsrc/graphics/kipi-plugins-kde3/buildlink3.mk
P pkgsrc/graphics/libkdcraw-kde3/buildlink3.mk
P pkgsrc/graphics/libkexiv2-kde3/buildlink3.mk
P pkgsrc/graphics/libkipi-kde3/buildlink3.mk
P pkgsrc/lang/python24/Makefile
P pkgsrc/lang/python25/Makefile
P pkgsrc/lang/tcl/distinfo
P pkgsrc/lang/tcl/patches/patch-ab
P pkgsrc/mail/akonadi/Makefile
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Holland | 1 Apr 2012 04:35
Picon

2012Q1 failing packages (on netbsd-current)

This is somewhat behind schedule relative to the freeze, but better
late than never.

   ------

Note: this list does not include kde4 stuff, which seems to still be
fully borked. As usual it also doesn't include the usual variety of
doomed/unfixable packages either.

audio/xine-arts		plugin removed upstream, see pkgsrc-users
archivers/mousetar	struct direct misuse
cad/tnt-mmtl		failure in automake
chat/centericq		severe C++ issues
chat/licq-core		locales don't get built
comms/asterisk10	(**) extra codec getting built (same as asterisk18)
comms/asterisk18	extra codec getting built (same as asterisk10)
comms/hylafax		dislikes tiff 4.x
comms/mgetty+sendfax	needs -lutil
converters/p5-MARC-Charset	(**) victim of PR 44985 (p5-gdbm borked)
databases/cstore	(**) throws exception during build
databases/gramps	broken by py25-gobject; see editors/zim
databases/gramps2	broken by py25-gobject; see editors/zim
databases/myodbc	doesn't like new iodbc
databases/odbc-postgresql	missing -R flags linking configure tests with -liodbc
databases/ruby-odbc	failed in ruby gem handling (?)
databases/sqlsharpgtk	mono linking issues (cf. f-spot, dcsharp)
devel/ArX		scons
devel/clisp-syscalls	bad lisp code
devel/electric-fence	(*) SIGSEGV during build
devel/g-wrap		(*) generic build failure
(Continue reading)

Permalink | Reply | 61 comments |
headers
John Marino | 1 Apr 2012 12:58
Favicon

DragonFly KDE4.8: issue with QT4-tools or KDE-workspace4?

I'm having trouble getting kde-workspace4 to build on DragonFly.  Due to 
my unfamiliarity with both KDE and QT4, I don't know if the problem lies 
with qt4-tools or with kde-workspace4.

The error is:
/work/x11/kde-workspace4/work/kde-workspace-4.8.0/kcontrol/fonts/fonts.cpp:18:27: 
error: qplatformdefs.h: No such file or directory

What I believe the cause of the error is:
In file

work/kde-workspace-4.8.0/_KDE_build/systemsettings/CMakefiles/CMakeDirectoryInformation.cmake, 
one of the directories in CMAKE_C_INCLUDE_PATH is 
"/usr/pkg/qt4/mkspecs/default".  For DragonFly, I suspect this should 
actually be "/usr/pkg/qt4/mkspecs/freebsd-g++" after looking over the 
qt4-tools PLIST.

Should QT4-tools be changed to either create a dragonfly mkspecs 
directory?  Or for DragonFly only, copy mkspecs/freebsd-g++ files to the 
mkspecs/default directory which is empty?

Or is there someplace in kde-workspace4 that a patch should be applied?

Like I said, I'm wondering if the kde-workspace4 breakage is a symptom 
of a problem with qt4-tools.  Can somebody with familiar with either 
KDE4 or QT4 please provide insight into the best approach to fix this?

John
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Davies | 1 Apr 2012 13:19
Picon
Picon

Re: DragonFly KDE4.8: issue with QT4-tools or KDE-workspace4?

On Sunday 01 April 2012 22:58:55 John Marino wrote:
> I'm having trouble getting kde-workspace4 to build on DragonFly.  Due 
to
> my unfamiliarity with both KDE and QT4, I don't know if the problem 
lies
> with qt4-tools or with kde-workspace4.
> 
> The error is:
> /work/x11/kde-workspace4/work/kde-
workspace-4.8.0/kcontrol/fonts/fonts.c
> pp:18:27: error: qplatformdefs.h: No such file or directory
     [...]
> Or is there someplace in kde-workspace4 that a patch should be 
applied?
> 
> Like I said, I'm wondering if the kde-workspace4 breakage is a 
symptom
> of a problem with qt4-tools.  Can somebody with familiar with either
> KDE4 or QT4 please provide insight into the best approach to fix 
this?

There is a problem that buildlink does not create the default symlink 
in mkspecs when building the buildlink tree.

In sysutils/k3b/Makefile you can see a work around for this:

pre-configure:
        # buildlink loses this symlink
        ln -s ${BUILDLINK_PREFIX.qt4-libs}/qt4/mkspecs/default 
${BUILDLINK_DIR}/qt4/mkspecs/default
(Continue reading)

Permalink | Reply | 4 comments |
headers
Thomas Klausner | 1 Apr 2012 13:21
Picon

Re: 2012Q1 failing packages (on netbsd-current)

On Sun, Apr 01, 2012 at 02:35:50AM +0000, David Holland wrote:
> Note: this list does not include kde4 stuff, which seems to still be
> fully borked. As usual it also doesn't include the usual variety of
> doomed/unfixable packages either.

I remember many of these packages from previous lists of yours. Could
you please make a list of packages that have been broken for a year
now, with the aim of removing them if noone speaks up for them
(promising to fix them)?
 Thomas
Permalink | Reply | 34 comments |
headers
Mark Davies | 1 Apr 2012 13:30
Picon
Picon

Re: DragonFly KDE4.8: issue with QT4-tools or KDE-workspace4?

On Sunday 01 April 2012 23:19:17 I wrote:
> There is then the question why it would strike DragonFly and not NetBSD
> (or other systems).

And the answer is because kde-workspace4/hacks.mk has an older version of 
the workaround in it.

What happens if you replace the last line of hacks.mk with
	ln -s ${BUILDLINK_PREFIX.qt4-libs}/qt4/mkspecs/default 
${BUILDLINK_DIR}/qt4/mkspecs/default

cheers
mark
Permalink | Reply | 3 comments |
headers
Aleksej Saushev | 1 Apr 2012 15:21
Picon

Re: 2012Q1 failing packages (on netbsd-current)

David Holland <dholland-pkgtech <at> netbsd.org> writes:

> This is somewhat behind schedule relative to the freeze, but better
> late than never.
>
>    ------
>
> Note: this list does not include kde4 stuff, which seems to still be
> fully borked. As usual it also doesn't include the usual variety of
> doomed/unfixable packages either.

First thing to note is that this list is based only on amd64 builds.

> devel/clisp-syscalls	bad lisp code

Bad C code or even just system most likely.

> lang/mercury		generic build failure, may also/then crash during build

amd64 problem, works fine here.

> lang/pfe		PLIST divergence

I'll look at it when I have time.

> lang/polyml		"ld: bad value" (not MAKE_JOBS)
> lang/racket		SIGABRT during build
> lang/racket-textual	SIGABRT during build

amd64 problem, work fine here.
(Continue reading)

Permalink | Reply | 7 comments |
headers
John Marino | 1 Apr 2012 17:09
Favicon

Re: DragonFly KDE4.8: issue with QT4-tools or KDE-workspace4?

On 4/1/2012 13:30, Mark Davies wrote:
> On Sunday 01 April 2012 23:19:17 I wrote:
>> There is then the question why it would strike DragonFly and not NetBSD
>> (or other systems).
>
> And the answer is because kde-workspace4/hacks.mk has an older version of
> the workaround in it.
>
> What happens if you replace the last line of hacks.mk with
> 	ln -s ${BUILDLINK_PREFIX.qt4-libs}/qt4/mkspecs/default
> ${BUILDLINK_DIR}/qt4/mkspecs/default
>
> cheers
> mark

Hi Mark,
The package fails with the same error with that line.
That doesn't really surprise me because according to the PLIST of 
qt4-tools, there is no qplatformdefs.h file in the qt4/mkspecs/default 
directory unless you build qt4-tools on SunOS.

But I suspect you are on the right track here.

Thanks,
John
Permalink | Reply | 2 comments |
headers
MFL Commissioner | 1 Apr 2012 17:51
Favicon

Re: DragonFly KDE4.8: issue with QT4-tools or KDE-workspace4?

On 4/1/2012 17:09, John Marino wrote:
> On 4/1/2012 13:30, Mark Davies wrote:
>> On Sunday 01 April 2012 23:19:17 I wrote:
>>> There is then the question why it would strike DragonFly and not NetBSD
>>> (or other systems).
>>
>> And the answer is because kde-workspace4/hacks.mk has an older version of
>> the workaround in it.
>>
>> What happens if you replace the last line of hacks.mk with
>> ln -s ${BUILDLINK_PREFIX.qt4-libs}/qt4/mkspecs/default
>> ${BUILDLINK_DIR}/qt4/mkspecs/default
>>
>> cheers
>> mark
>
> Hi Mark,
> The package fails with the same error with that line.
> That doesn't really surprise me because according to the PLIST of
> qt4-tools, there is no qplatformdefs.h file in the qt4/mkspecs/default
> directory unless you build qt4-tools on SunOS.
>
> But I suspect you are on the right track here.
>
> Thanks,
> John

I think this might actually be the problem:
bmake: "/usr/pkgsrc/x11/kde-workspace4/hacks.mk" line 19: warning: 
duplicate script for target "post-wrapper" ignored
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Marino | 1 Apr 2012 18:37
Favicon

Re: DragonFly KDE4.8: issue with QT4-tools or KDE-workspace4?

On 4/1/2012 17:09, John Marino wrote:
> On 4/1/2012 13:30, Mark Davies wrote:
>> On Sunday 01 April 2012 23:19:17 I wrote:
>>> There is then the question why it would strike DragonFly and not NetBSD
>>> (or other systems).
>>
>> And the answer is because kde-workspace4/hacks.mk has an older version of
>> the workaround in it.
>>
>> What happens if you replace the last line of hacks.mk with
>> ln -s ${BUILDLINK_PREFIX.qt4-libs}/qt4/mkspecs/default
>> ${BUILDLINK_DIR}/qt4/mkspecs/default
>>
>> cheers
>> mark
>
> Hi Mark,
> The package fails with the same error with that line.
> That doesn't really surprise me because according to the PLIST of
> qt4-tools, there is no qplatformdefs.h file in the qt4/mkspecs/default
> directory unless you build qt4-tools on SunOS.
>
> But I suspect you are on the right track here.
>
> Thanks,
> John

(The following was already sent but didn't make to the mailing list due 
to the wrong "From:" address
===============
(Continue reading)

Permalink | Reply | 0 comments |

Gmane