headers
Greg Troxel | 1 Dec 2009 01:43
Picon

libwnck fails due to libxcb


I added x11/libxcb bl3 to libwnck's Makefile, but then got this - I have
X11_TYPE=modular, so I wonder if there is something wrong in mk/
somewhere about xcb?  Can anyone else build libwnck?  With
X11_TYPE=modular?

===> Patching for libwnck-2.28.0
===> Creating toolchain wrappers for libwnck-2.28.0
ERROR: xcb-util>=0.3.3 is not installed; can't buildlink files.
*** Error code 1

Stop.
make: stopped in /usr/ANONCVS/pkgsrc/devel/libwnck
*** Error code 1

Stop.
make: stopped in /usr/ANONCVS/pkgsrc/devel/libwnck

It's true that xcb-util is not installed.  But I don't see what requires
that, and why it's failing.
Permalink | Reply | 3 comments |
headers
OBATA Akio | 1 Dec 2009 03:06
Picon

Re: libwnck fails due to libxcb

On Tue, 01 Dec 2009 09:43:52 +0900, Greg Troxel <gdt <at> ir.bbn.com> wrote:

> I added x11/libxcb bl3 to libwnck's Makefile, but then got this - I have
> X11_TYPE=modular, so I wonder if there is something wrong in mk/
> somewhere about xcb?  Can anyone else build libwnck?  With
> X11_TYPE=modular?
>
>
> ===> Patching for libwnck-2.28.0
> ===> Creating toolchain wrappers for libwnck-2.28.0
> ERROR: xcb-util>=0.3.3 is not installed; can't buildlink files.
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ANONCVS/pkgsrc/devel/libwnck
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ANONCVS/pkgsrc/devel/libwnck
>
>
> It's true that xcb-util is not installed.  But I don't see what requires
> that, and why it's failing.

I see... it probably came from update of x11/startup-notification to 0.10,
and you have startup-notification<0.10.

  From commit log:
   Changes since 0.9:
    - Add XCB backend
(Continue reading)

Permalink | Reply | 1 comment |
headers
David H. Gutteridge | 1 Dec 2009 04:26
Picon
Favicon

Re: libwnck fails due to libxcb

On Tue, 01 Dec 2009 11:06:54 +0900, OBATA Akio wrote:
>On Tue, 01 Dec 2009 09:43:52 +0900, Greg Troxel <gdt <at> ir.bbn.com> wrote:
>> I added x11/libxcb bl3 to libwnck's Makefile, but then got this - I
>> have X11_TYPE=modular, so I wonder if there is something wrong in
>> mk/somewhere about xcb?  Can anyone else build libwnck?  With
>> X11_TYPE=modular?
>>
>>
>> ===> Patching for libwnck-2.28.0
>> ===> Creating toolchain wrappers for libwnck-2.28.0
>> ERROR: xcb-util>=0.3.3 is not installed; can't buildlink files.
>> *** Error code 1
>> Stop.
>> make: stopped in /usr/ANONCVS/pkgsrc/devel/libwnck
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/ANONCVS/pkgsrc/devel/libwnck
>>
>>
>> It's true that xcb-util is not installed.  But I don't see what requires
>> that, and why it's failing.
>
> I see... it probably came from update of x11/startup-notification to
> 0.10, and you have startup-notification<0.10.
>
> From commit log:
>  Changes since 0.9:
>   - Add XCB backend
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Norton Allen | 1 Dec 2009 15:21
Picon

Re: Too much metadata?

Joerg Sonnenberger wrote:
> On Mon, Nov 30, 2009 at 12:49:51PM -0500, Norton Allen wrote:
>   
>> I'm interested in building a handful of packages which are supplied
>> through pkgsrc. Is it true that I have to download metadata for every
>> package every conceived before I can build the package I want?
>>     
>
> You have to get the full pkgsrc tree, there is no support for having
> only a subset. This is different for binary packages though.
>   
Has the possibility of eliminating that requirement been discussed?
Offhand, it doesn't seem like it would be that hard to work
around--which I say having admittedly not even begun to look into it. If
it's obvious why this can't work, forgive me for wasting bandwidth.

I ask because I have wasted more than a day trying to get started with
pkgsrc in order to build a single package. I was originally thwarted by
the size of the distribution (i.e. it would be helpful if there was some
notice somewhere of how much disk space is required.) then my filesystem
ran out of inodes due to tons of small files. Now the host that I'm
downloading from seems to be bandwidth limiting, and only allows my
about 30 seconds of download before stopping.

None of this is pkgsrc's problem, so pardon my whining, but it does
represent an unnecessary barrier to entry. Presumably you would like
maintainers of single packages to work with pkgsrc, but if getting into
the game requires dedicating gigabytes of storage and gigabytes of
network transfer regardless of how small a package you maintain, there
will be folks who just can't afford it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 1 Dec 2009 15:40
Picon

Re: Too much metadata?

On Tue, Dec 01, 2009 at 09:21:22AM -0500, Norton Allen wrote:
> > You have to get the full pkgsrc tree, there is no support for having
> > only a subset. This is different for binary packages though.
> >   
> Has the possibility of eliminating that requirement been discussed?

In the past. Basically, it was not considered worth the trouble. There a
lot of dependencies in the tree and for many 

> I ask because I have wasted more than a day trying to get started with
> pkgsrc in order to build a single package. I was originally thwarted by
> the size of the distribution (i.e. it would be helpful if there was some
> notice somewhere of how much disk space is required.) then my filesystem
> ran out of inodes due to tons of small files. Now the host that I'm
> downloading from seems to be bandwidth limiting, and only allows my
> about 30 seconds of download before stopping.

You can kick start the process by getting the pkgsrc.tar.gz or whatever
it is called from ftp.netbsd.org. I forgot if the numbers where ever
included in the guide or not.

Overall size of the main tree is in the area of 420MB with 15k inodes
used, YMMV.

Joerg
Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 1 Dec 2009 16:01

Re: Too much metadata?

I recall a script or other method was made available at least a couple 
times to just check out parts of pkgsrc.  I can't find it now, but I 
thought I heard about one this year. Basically it needs all the 
pkgsrc/mk and then fetches all the ".include" as used by the desired 
package. Good luck.
Permalink | Reply | 0 comments |
headers
Cem Kayali / E Ticaret ve Bilisim Teknolojileri | 1 Dec 2009 16:02
Picon
Gravatar

gnash requires boost version 1.6 because...


Hello!

Is there a specific reason to exclude *mt-d* libraries from 
devel/boost-libs?

Gnash plugin fails because of missing library:
----------------------------------------------------------------------------
Shared object "libboost_thread-mt-d.so" not found
Player request channel hang up

I had working version of Gnash with FF3 using September 15th pkgsrc, and 
now it refuses to work.

Regards,
Cem
Permalink | Reply | 8 comments |
headers
Greg Troxel | 1 Dec 2009 16:16
Picon

Re: libwnck fails due to libxcb


  > I added x11/libxcb bl3 to libwnck's Makefile, but then got this - I have
  > X11_TYPE=modular, so I wonder if there is something wrong in mk/
  > somewhere about xcb?  Can anyone else build libwnck?  With
  > X11_TYPE=modular?

  I see... it probably came from update of x11/startup-notification to 0.10,
  and you have startup-notification<0.10.

   From commit log:
    Changes since 0.9:
     - Add XCB backend

  But the changes at the commit are not sufficient.

  1. need to bump BUILDLINK_ABI_DEPENDS.startup-notification in buildlink3.mk to 0.10.
  2. need to recursive revision bump for related packages.

Sorry, when I said "added" I meant locally, to figure this out.  I have
committed nothing.

I was using pkg_rr, so I don't know why startup-notification wouldn't
have been updated, assuming libwnck depends on it.
Permalink | Reply | 0 comments |
headers
Louis Guillaume | 1 Dec 2009 20:18

pam failure with netatalk

Hi,

I've been using netatalk on NetBSD successfully for years now; using the 
GSSAPI authentication module. Today I tried authenticating using the 
dhx_pam user authentication module instead and it did not work. Here is 
the session transcript from /var/log/messages:

Dec  1 13:31:47 maat afpd[7266]: Registering CNID module [last]
Dec  1 13:31:47 maat afpd[7266]: Registering CNID module [cdb]
Dec  1 13:31:47 maat afpd[7266]: Registering CNID module [dbd]
Dec  1 13:31:47 maat afpd[7266]: ASIP started on 192.168.1.110:548(5) 
(2.0.4)
Dec  1 13:31:47 maat afpd[7266]: uam: uams_gss.so loaded
Dec  1 13:31:47 maat afpd[7266]: uam: uams_dhx.so loaded
Dec  1 13:31:47 maat afpd[7266]: uam: "DHCAST128" available
Dec  1 13:31:47 maat afpd[7266]: uam: "Client Krb v2" available
Dec  1 13:31:54 maat afpd[7591]: ASIP session:548(5) from 
192.168.1.214:50866(7)
Dec  1 13:31:54 maat afpd[7266]: server_child[1] 7516 exited 1
Dec  1 13:31:54 maat afpd[7266]: server_child[1] 7591 done
Dec  1 13:31:55 maat afpd[2280]: ASIP session:548(5) from 
192.168.1.214:50867(7)
Dec  1 13:31:55 maat afpd[2280]: dhx login: louis
Dec  1 13:31:55 maat afpd[2280]: in openpam_load_module(): no 
pam_unix.so found
Dec  1 13:31:55 maat afpd[2280]: uams_dhx_pam.c :PAM: PAM_Error: system 
error
Dec  1 13:31:55 maat afpd[7266]: server_child[1] 2280 killed by signal 11

... In /etc/pam.d/netatalk I have:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave B | 1 Dec 2009 20:42

Re: Too much metadata?

On Mon, Nov 30, 2009 at 12:49:51PM -0500, Norton Allen wrote:
> 
> I'm interested in building a handful of packages which are supplied
> through pkgsrc. Is it true that I have to download metadata for every
> package every conceived before I can build the package I want? Clearly
> that is not necessary, but I haven't found a roadmap for starting with a
> smaller set. It seems as though the pkgtools that understand
...

  I did something like this at some point.

  Just as a pointer for your exploration (since, as has been
pointed out, it's not officially supported) I believe I started by
checking out

    pkgsrc/mk
    pkgsrc/pkgtools
    pkgsrc/_myCategory_/_myPackage_

and then iteratively checked out other packages upon which my in-
progress package builds depended one-by-one--or maybe few-by-few--
as I discovered them (in the build attempts' errors).

  Of course, this amounts to paying for reduced disk-space and
bandwidth with increased initial investment of time and cumbersome-
ness; but actually, for your scenario, it sounds like it may be
worthwhile in the longer term (at least if the dependencies of the
package you want to maintain rarely change).

Cheers,  --Dave B
(Continue reading)

Permalink | Reply | 0 comments |

Gmane