headers
Petr Janda | 1 Oct 2007 01:25

Re: Request for import of SQLGrey

Hi,
Any progress on this yet?

Thanks,

Petr

On Tue, 18 Sep 2007 04:30:13 pm Geert Hendrickx wrote:
> On Tue, Sep 18, 2007 at 11:37:43AM +1000, Petr Janda wrote:
> > A couple of comments. 1) Is it possible for you to modify the package to
> > create sqlgrey user and group during the install?
>
> Yes, I'll do that.
>
> > 2) The script update_sqlgrey_config need's Bash. Can it be added to tje
> > dependency list of this package? The script itself also needs a patch:
> > #!/bin/bash should be #!/usr/pkg/bin/bash
>
> Can you try it with #!/bin/sh ?  Many linux scripts use #!/bin/bash while
> they work fine with POSIX sh.
>
> On Tue, Sep 18, 2007 at 12:32:29PM +1000, Petr Janda wrote:
> > Also there seems to be no rc script.
>
> I'll add that, too.
>
> 	Geert
Permalink | Reply | 9 comments |
headers
Geert Hendrickx | 1 Oct 2007 06:13
Picon
Favicon

Re: Request for import of SQLGrey

On Mon, Oct 01, 2007 at 09:25:10AM +1000, Petr Janda wrote:
> Hi,
> Any progress on this yet?

There's a pkgsrc freeze going on at this moment (preparing to branch
2007Q3).  We'll take this up again after the branch.

	Geert
Permalink | Reply | 8 comments |
headers
Aleksey Cheusov | 1 Oct 2007 21:33
Picon
Favicon

Re: pkgsrc-current Linux 2.6.18-5-vserver-686/i686 2007-09-28 12:43


 >>>    ERROR: /usr/pkg/bin/xlock: 	libSM.so.6 => not found
 >>>    ERROR: 	libICE.so.6 => not found
 >>>    ERROR: 	libX11.so.6 => not found
 >>>    ERROR: 	libXext.so.6 => not found
 >>>    ERROR: *** The programs/libs shown above will not find the listed
 >>>    ERROR:     shared libraries at runtime.
 >>>    ERROR: Please fix the package (add -Wl,-R.../lib in the right
 >>>    places)!

 >>> 
 >>> X11_TYPE=modular

 >> Does your system have a native X and/or imake and xmkmf not from
 >> pkgsrc?

> Neither X libs/header nor imake/xmkmf are installed.

> X libraries, header and imake was installed previously (that time I played
> with X11_TYPE=native) but all X packages was removed since then
> and therefore rebuilt. What packages can lead to this problem?

I removed ALL packages and rebuild them all. The problem repeated.
So, now I'm absolutely sure that neither imake nor xmkmf is installed.
Both they are from pkgsrc.

--

-- 
Best regards, Aleksey Cheusov.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian de Alwis | 1 Oct 2007 21:58
Picon
Picon
Favicon

patch to chat/libpurple/buildlink3.mk for dbus support

chat/libpurple's buildlink3.mk should pull in the dbus buildlink3.mk's
when its options includes dbus.  Patch below.  This could be
compacted to only include dbus-glib/buildlink3.mk as it pulls in
dbus/buildlink3.mk, but I'm not sure which is considered more
desirable.

I'm not sure if the other package options should cause their
corresponding buildlink3.mk's to be included too?  gnutls seems
safe (the libpurple*.so don't reference any gnutls libraries).

(libpurple's maintainer is set to pkgsrc-users.)

diff -w -b -u -r1.3 buildlink3.mk
--- buildlink3.mk       13 Aug 2007 12:42:06 -0000      1.3
+++ buildlink3.mk       1 Oct 2007 19:06:23 -0000
 <at>  <at>  -16,4 +16,9  <at>  <at> 
 BUILDLINK_PKGSRCDIR.libpurple?=        ../../chat/libpurple
 .endif # LIBPURPLE_BUILDLINK3_MK

+.if !empty(PKG_OPTIONS.libpurple:Mdbus)
+.  include "../../sysutils/dbus/buildlink3.mk"
+.  include "../../sysutils/dbus-glib/buildlink3.mk"
+.endif
+
 BUILDLINK_DEPTH:=              ${BUILDLINK_DEPTH:S/+$//}

--

-- 
  Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
      "Amusement to an observing mind is study." - Benjamin Disraeli
(Continue reading)

Permalink | Reply | 4 comments |
headers
Roland Illig | 1 Oct 2007 22:59
Picon

Re: patch to chat/libpurple/buildlink3.mk for dbus support

Brian de Alwis wrote:
> chat/libpurple's buildlink3.mk should pull in the dbus buildlink3.mk's
> when its options includes dbus.  Patch below.  This could be
> compacted to only include dbus-glib/buildlink3.mk as it pulls in
> dbus/buildlink3.mk, but I'm not sure which is considered more
> desirable.
> 
> I'm not sure if the other package options should cause their
> corresponding buildlink3.mk's to be included too?  gnutls seems
> safe (the libpurple*.so don't reference any gnutls libraries).
> 
> (libpurple's maintainer is set to pkgsrc-users.)
> 
> diff -w -b -u -r1.3 buildlink3.mk
> --- buildlink3.mk       13 Aug 2007 12:42:06 -0000      1.3
> +++ buildlink3.mk       1 Oct 2007 19:06:23 -0000
>  <at>  <at>  -16,4 +16,9  <at>  <at> 
>  BUILDLINK_PKGSRCDIR.libpurple?=        ../../chat/libpurple
>  .endif # LIBPURPLE_BUILDLINK3_MK
>  
> +.if !empty(PKG_OPTIONS.libpurple:Mdbus)
> +.  include "../../sysutils/dbus/buildlink3.mk"
> +.  include "../../sysutils/dbus-glib/buildlink3.mk"
> +.endif
> +

This code is not correct. It would only query the PKG_OPTIONS.libpurple 
variable, but the user may also set these options in 
PKG_DEFAULT_OPTIONS. The correct way to do this is:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tobias Nygren | 2 Oct 2007 11:07
Picon

Re: patch to chat/libpurple/buildlink3.mk for dbus support

On Mon, 01 Oct 2007 22:59:24 +0200
Roland Illig <rillig <at> NetBSD.org> wrote:

> Brian de Alwis wrote:
> > chat/libpurple's buildlink3.mk should pull in the dbus buildlink3.mk's
> > when its options includes dbus.  Patch below.  This could be
> > compacted to only include dbus-glib/buildlink3.mk as it pulls in
> > dbus/buildlink3.mk, but I'm not sure which is considered more
> > desirable.
> > 
> > I'm not sure if the other package options should cause their
> > corresponding buildlink3.mk's to be included too?  gnutls seems
> > safe (the libpurple*.so don't reference any gnutls libraries).
> > 
> > (libpurple's maintainer is set to pkgsrc-users.)
> > 
> > diff -w -b -u -r1.3 buildlink3.mk
> > --- buildlink3.mk       13 Aug 2007 12:42:06 -0000      1.3
> > +++ buildlink3.mk       1 Oct 2007 19:06:23 -0000
> >  <at>  <at>  -16,4 +16,9  <at>  <at> 
> >  BUILDLINK_PKGSRCDIR.libpurple?=        ../../chat/libpurple
> >  .endif # LIBPURPLE_BUILDLINK3_MK
> >  
> > +.if !empty(PKG_OPTIONS.libpurple:Mdbus)
> > +.  include "../../sysutils/dbus/buildlink3.mk"
> > +.  include "../../sysutils/dbus-glib/buildlink3.mk"
> > +.endif
> > +
> 
> This code is not correct. It would only query the PKG_OPTIONS.libpurple
(Continue reading)

Permalink | Reply | 2 comments |
headers
Klaus Heinz | 2 Oct 2007 22:53
Picon

Re: Linux: fix for wm/uwm

OBATA Akio wrote:

> "yes" is not a tool.

It is not a tool in the pkgsrc sense, but it is part of
sysutils/coreutils.

ciao
     Klaus
Permalink | Reply | 0 comments |
headers
Matthias Drochner | 2 Oct 2007 23:18
Picon
Picon
Favicon

gnome-2.20


Hi -
I've accumulated a lot of patches for gnome pkgs within the
last weeks, and since I'll be unavailable for some weeks
when the current freeze ends I'll make them available
here to encourage review and testing.
That's not completely polished, and some parts are missing
(eg accessibility, system monitoring, C#) but generally it
"works for me" well enough.

There are four files for ftp on
zelof1.zel.kfa-juelich.de:~ftp/pub/NetBSD/pkgsrc-gnome-2.20
which should be applied in about that order.

first.tar.gz: Some updates which should be done early because
 other pkgs depend on them. rarian/scrollkeeper needs to
 be done early because everything installing documentation
 depends on it. gnome-keyring is needed by gnome-platform
 but not listed there which looks like an inconsistency in
 gnome's distribution system. poppler will be needed by evince,
 but old evince doesn't build against new poppler and vice-versa.

diff.platform: Updates for the gnome-platform part which were not
 done before the freeze. I don't expect major compatibility problems.

diff.python: Updates for the Python bindings. Should not cause
 problems too.

desktop.tar.gz: Updates for the higher levels of the desktop.
 That's of varying quality. (gdm being the worst imo)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aleksej Saushev | 2 Oct 2007 21:45
Picon

Re: Linux: fix for wm/uwm

"OBATA Akio" <obache <at> netbsd.org> writes:

> On Sat, 29 Sep 2007 19:32:05 +0900, Aleksey Cheusov <cheusov <at> tut.by> wrote:
>
>> wm/uwm also needs
>>
>> USE_TOOLS+=     yes
>>
>> Please fix it
>
> "yes" is not a tool.

Why not?
Permalink | Reply | 2 comments |
headers
Joerg Sonnenberger | 3 Oct 2007 00:15
Picon

Re: Linux: fix for wm/uwm

On Tue, Oct 02, 2007 at 11:45:53PM +0400, Aleksej Saushev wrote:
> > "yes" is not a tool.
> 
> Why not?

You don't seriously have a platform with a broken yes?

Joerg
Permalink | Reply | 1 comment |

Gmane