Nabble - tech-pkg

Re: Support for Max OS X 10.3 (was: cpp in OS X, information needed)

2009-12-20T14:40:10Z

Am 20.12.2009 um 21:10 schrieb Edgar Fuß:

>> 10.3: very old, probably no reason to be running it
> My G3 iBook is broken now, but does 10.4 run on G3 hardware?

it depends on the precise model.

>
>> So I would drop support for 10.3 and lower if it hurts at all.
> Depending on whether that locks out G3 Macs.
>

it would lock out some G3 Macs.

--
Georg Schwarz http://home.pages.de/~schwarz/
georg.schwarz@... +49 151 11559652

Re: Support for Max OS X 10.3

2009-12-20T12:36:59Z

Edgar Fuß wrote:
>> So I would drop support for 10.3 and lower if it hurts at all.
> Depending on whether that locks out G3 Macs.

According to http://support.apple.com/kb/HT1514 Tiger runs on some, but not all
G3 Macs.

Cheers,
Lloyd

Support for Max OS X 10.3 (was: cpp in OS X, information needed)

2009-12-20T12:10:06Z

> 10.3: very old, probably no reason to be running it
My G3 iBook is broken now, but does 10.4 run on G3 hardware?

> So I would drop support for 10.3 and lower if it hurts at all.
Depending on whether that locks out G3 Macs.

Re: cpp in OS X, information needed

2009-12-20T09:44:26Z

On Sun, Dec 20, 2009 at 5:28 PM, Joerg Sonnenberger
<joerg@...> wrote:

> On Sun, Dec 20, 2009 at 01:28:28PM +0000, Julio Merino wrote:
>> Well, yes and no. If we change the default conditionally, we add
>> complexity for no real gain (unless someone steps up and tests that
>> things still work in ancient versions). Plus, if we are going to use
>> this change to fix libtool (instead of my workaround in f2c), we'd be
>> leaving out old OS X versions broken anyway, thus only fixing part of
>> the problem.
>
> Indepent of everything else, f2c should call the preprocessor in a way
> that works. I think using "gcc -x c -E" is preferable for GCC...

Hm, I think adding "-x c" to our current default should be enough and
would work.

--
Julio Merino

Re: cpp in OS X, information needed

2009-12-20T09:28:44Z

On Sun, Dec 20, 2009 at 01:28:28PM +0000, Julio Merino wrote:
> Well, yes and no. If we change the default conditionally, we add
> complexity for no real gain (unless someone steps up and tests that
> things still work in ancient versions). Plus, if we are going to use
> this change to fix libtool (instead of my workaround in f2c), we'd be
> leaving out old OS X versions broken anyway, thus only fixing part of
> the problem.

Indepent of everything else, f2c should call the preprocessor in a way
that works. I think using "gcc -x c -E" is preferable for GCC...

Joerg

Re: cpp in OS X, information needed

2009-12-20T07:47:27Z

On Sun, Dec 20, 2009 at 3:45 PM, Greg Troxel <gdt@...> wrote:
> For macs, I think the OS situation is:
>
> 10.2: ancient, irrelevant
> 10.3: very old, probably no reason to be running it
> 10.4: old, but works on ppc macs
> 10.5: normal
> 10.6: somewhere between bleeding edge and new
>
> So I would drop support for 10.3 and lower if it hurts at all.

Yes, that's exactly what I was thinking after Obata confirmed that
Tiger has a pretty recent toolchain.

--
Julio Merino

Re: cpp in OS X, information needed

2009-12-20T07:45:41Z

Also, the question is: what versions of OS X do we care about? Are we
really interested in supporting the ancient toolchain that may be in,
e.g. OS X 10.2?

A good question, and I think it's a different answer from how we feel
about hardware. For hardware, we've now given up in 80386, but not
80486, and we still try to support sun3 and vax.

For old operating systems, I feel differently, and the question is how
many people are running old versions and whether they ought to upgrade.
I'm new to macs, but am about to get an old G4, which was high end in
2001ish (1.5G ram, 2x500MHz cpu) that I would say is not too crufty to
care about.

I think it's reasonable to expect people on macs to upgrade from old OS
(even if it means paying) to a reasonably modern OS if that's doable on
their hardware.

For macs, I think the OS situation is:

10.2: ancient, irrelevant
10.3: very old, probably no reason to be running it
10.4: old, but works on ppc macs
10.5: normal
10.6: somewhere between bleeding edge and new

So I would drop support for 10.3 and lower if it hurts at all.

attachment0 (200 bytes) Download Attachment

Re: cpp in OS X, information needed

2009-12-20T05:31:35Z

On Sun, Dec 20, 2009 at 8:16 AM, Georg Schwarz <georg.schwarz@...> wrote:

>
> Am 20.12.2009 um 13:21 schrieb Julio Merino:
>
>> Also, the question is: what versions of OS X do we care about? Are we
>> really interested in supporting the ancient toolchain that may be in,
>> e.g. OS X 10.2?
>
>
> as always, the answer IMHO depends on the cost involved. If it's just a
> simple, transparent .if .else, then why not.
>
>

It looks like developer tools/xcode 2 included gcc4 (3.x, if I
recall), but I'm not sure if it worked on anything older than 10.4.

xcode 2.2 only supports 10.4 and has gcc 4.0.1

xcode 2.5 was the last release including support for 10.4

3.1.4 is the latest for 10.5 only and ships both gcc 4.0.1 and 4.2.1.
(+ llvm version of each)

3.2 is snow-leopard only and I think they switched the default from
4.0.1 to 4.2.1. I'm not sure if it's the llvm version or not.

Re: cpp in OS X, information needed

2009-12-20T05:28:28Z

On Sun, Dec 20, 2009 at 1:16 PM, Georg Schwarz <georg.schwarz@...> wrote:

Well, yes and no. If we change the default conditionally, we add
complexity for no real gain (unless someone steps up and tests that
things still work in ancient versions). Plus, if we are going to use
this change to fix libtool (instead of my workaround in f2c), we'd be
leaving out old OS X versions broken anyway, thus only fixing part of
the problem.

--
Julio Merino

Re: cpp in OS X, information needed

2009-12-20T05:16:09Z

Am 20.12.2009 um 13:21 schrieb Julio Merino:

> Also, the question is: what versions of OS X do we care about? Are we
> really interested in supporting the ancient toolchain that may be in,
> e.g. OS X 10.2?

as always, the answer IMHO depends on the cost involved. If it's just
a simple, transparent .if .else, then why not.

--
Georg Schwarz http://home.pages.de/~schwarz/
georg.schwarz@... +49 151 11559652

Re: cpp in OS X, information needed

2009-12-20T04:21:54Z

On Sun, Dec 20, 2009 at 12:18 PM, OBATA Akio <obache@...> wrote:

> Hi!
>
> On Sun, 20 Dec 2009 21:09:28 +0900, Julio Merino <jmmv84@...> wrote:
>
>> Hello,
>>
>> I'm investigating why pkgsrc sets CPP to gcc in OS X. The comment in
>> the code says it's because we need to use the gcc-provided cpp, but in
>> Leopard cpp is just a wrapper around gcc.
>>
>> If you have 10.4 or earlier, could you please provide the following
>> details?
>
> On my accessible 10.4.11:
>
>> - Whether /usr/bin/cpp is a script or a binary.
>
> script (wrapper of gcc -E ?)

Thanks!

>> Depending on the information we get, we may revert the special setting
>> in OS X and just use cpp.
>
> For safe side, how about setting conditionally?
> keep current settings for ancient Darwin.

No because the current situation breaks the new libtool badly. I want
to fix it everywhere and then remove the workaround I put in f2c.

Also, the question is: what versions of OS X do we care about? Are we
really interested in supporting the ancient toolchain that may be in,
e.g. OS X 10.2?

--
Julio Merino

Re: cpp in OS X, information needed

2009-12-20T04:18:47Z

Hi!

On Sun, 20 Dec 2009 21:09:28 +0900, Julio Merino <jmmv84@...> wrote:

> Hello,
>
> I'm investigating why pkgsrc sets CPP to gcc in OS X. The comment in
> the code says it's because we need to use the gcc-provided cpp, but in
> Leopard cpp is just a wrapper around gcc.
>
> If you have 10.4 or earlier, could you please provide the following details?

On my accessible 10.4.11:

> - Whether /usr/bin/cpp is a script or a binary.

script (wrapper of gcc -E ?)

> Depending on the information we get, we may revert the special setting
> in OS X and just use cpp.

For safe side, how about setting conditionally?
keep current settings for ancient Darwin.

--
"Of course I love NetBSD":-)
OBATA Akio / obache@...

cpp in OS X, information needed

2009-12-20T04:09:28Z

Hello,

I'm investigating why pkgsrc sets CPP to gcc in OS X. The comment in
the code says it's because we need to use the gcc-provided cpp, but in
Leopard cpp is just a wrapper around gcc.

If you have 10.4 or earlier, could you please provide the following details?

- Whether /usr/bin/cpp is a script or a binary.
- If it is a binary, whether it is part of the gcc toolchain or not.
"cpp --version" should give you these details.
- If you have any idea why CPP was explicitly set. The CVS logs
provide no real information about this.

Depending on the information we get, we may revert the special setting
in OS X and just use cpp.

Thanks,

--
Julio Merino

Re: Broken shared libraries in OS X

2009-12-20T04:03:33Z

On Sun, Dec 20, 2009 at 11:47:43AM +0000, Julio Merino wrote:
> I'm still wondering what the right solution to this could be.

Well, your patch is definitely better than the current broken state.
Could you please commit it?

> First of all, why are we setting CPP to gcc in OS X?

Probably historic reasons.

> But it turns out /usr/bin/cpp is just a shell wrapper around gcc.

The question is what it is under older versions of Mac OS X.

Kind regards

--
Matthias Scheler http://zhadum.org.uk/

Re: Broken shared libraries in OS X

2009-12-20T03:47:43Z

On Sun, Dec 20, 2009 at 11:32 AM, Matthias Scheler <tron@...> wrote:
> On Sat, Dec 19, 2009 at 01:01:29PM +0000, Julio Merino wrote:
>> See attached patch; will submit later.
>
> This fixes my problems, thanks a lot.

You're welcome.

> There is however a small problem in your patch:
>
> -BUILD_DEPENDS+= f2c>20090411:../../lang/f2c # translator
> +BUILD_DEPENDS+= f2c>20090411nb2:../../lang/f2c # translator

Yeah, I caught that too when using pkgsrc right after changing the
file (and after sending the email) :)

> This should either read "f2c>20090411nb1" or "f2c>=20090411nb2".
>
>> I'm not sure if the PKGREVISION changes are good enough.
>
> You should also bump "LIBTOOL_REQD" in "pkgsrc/mk/bsd.pkg.use.mk".

OK, done!

I'm still wondering what the right solution to this could be. First
of all, why are we setting CPP to gcc in OS X? Why not use cpp? I
see the following in Darwin.mk:

# Use the GNU cpp, not the OS X cpp, don't look in "/usr/local/include"
# before "/usr/include".
CPP_PRECOMP_FLAGS?= -no-cpp-precomp -isystem /usr/include

But it turns out /usr/bin/cpp is just a shell wrapper around gcc. And
the reason cpp works and gcc doesn't is because cpp explicitly sets
the language of the source file to C, thus bypassing the .F suffix and
skipping the Fortran check.

--
Julio Merino

Re: Broken shared libraries in OS X

2009-12-20T03:32:18Z

On Sat, Dec 19, 2009 at 01:01:29PM +0000, Julio Merino wrote:
> See attached patch; will submit later.

This fixes my problems, thanks a lot.

There is however a small problem in your patch:

-BUILD_DEPENDS+= f2c>20090411:../../lang/f2c # translator
+BUILD_DEPENDS+= f2c>20090411nb2:../../lang/f2c # translator

This should either read "f2c>20090411nb1" or "f2c>=20090411nb2".

> I'm not sure if the PKGREVISION changes are good enough.

You should also bump "LIBTOOL_REQD" in "pkgsrc/mk/bsd.pkg.use.mk".

Kind regards

--
Matthias Scheler http://zhadum.org.uk/

daily pkgsrc CVS update output

2009-12-19T17:05:52Z

Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/databases/java-tokyocabinet/Makefile
P pkgsrc/databases/lua-tokyocabinet/Makefile
P pkgsrc/databases/p5-tokyocabinet/Makefile
P pkgsrc/databases/ruby-tokyocabinet/Makefile
P pkgsrc/databases/tokyocabinet/Makefile
P pkgsrc/databases/tokyocabinet/buildlink3.mk
U pkgsrc/databases/tokyocabinet/options.mk
P pkgsrc/databases/tokyotyrant/Makefile
P pkgsrc/doc/CHANGES-2009
P pkgsrc/doc/TODO
P pkgsrc/mk/defaults/options.description
P pkgsrc/mk/platform/OSF1.mk
P pkgsrc/mk/tools/tools.Interix.mk
P pkgsrc/textproc/tokyodystopia/Makefile
P pkgsrc/textproc/tokyodystopia/buildlink3.mk
P pkgsrc/www/drupal/Makefile
P pkgsrc/www/drupal/PLIST
U pkgsrc/www/drupal/distinfo
P pkgsrc/www/drupal6/Makefile
P pkgsrc/www/drupal6/PLIST
U pkgsrc/www/drupal6/distinfo
P pkgsrc/www/drupal6/files/drupal.conf

Killing core files:

Updating pkgsrc-2009Q3 pkgsrc tree (/ftp/pub/pkgsrc/pkgsrc-2009Q3):
U pkgsrc/doc/CHANGES-pkgsrc-2009Q3
P pkgsrc/www/drupal/Makefile
P pkgsrc/www/drupal/PLIST
U pkgsrc/www/drupal/distinfo
P pkgsrc/www/drupal6/Makefile
P pkgsrc/www/drupal6/PLIST
U pkgsrc/www/drupal6/distinfo
P pkgsrc/www/drupal6/files/drupal.conf

Re: CVS commit: pkgsrc

2009-12-19T16:30:28Z

On Wed, Dec 16, 2009 at 10:40 AM, Matthias Scheler <tron@...> wrote:

> On Tue, Dec 15, 2009 at 05:35:37PM +0000, Joerg Sonnenberger wrote:
>> Module Name: pkgsrc
>> Committed By: joerg
>> Date: Tue Dec 15 17:35:37 UTC 2009
>>
>> Modified Files:
>> pkgsrc/devel/libltdl: Makefile PLIST buildlink3.mk
>> pkgsrc/devel/libtool: Makefile Makefile.common PLIST distinfo
>> pkgsrc/devel/libtool-base: Makefile PLIST
>> pkgsrc/devel/libtool-info: Makefile
>> pkgsrc/devel/libtool/patches: manual-libtool.m4 patch-aa patch-ab
>> patch-ac patch-ad
>> pkgsrc/mk/compiler: f2c.mk
>> Removed Files:
>> pkgsrc/devel/libtool/patches: patch-ae
>>
>> Log Message:
>> Update to libtool-2.2.6b. This switches libtool to the new main branch.
>> Changes are many, important for pkgsrc:
>> - much higher speed (up to 30% faster for the overall build of libX11)
>> - less magic for detection of the tag
>>
>> The pkgsrc integration of f2c has been changed to be more sane.
>> libtool itself now depends on the f2c frontend to use proper
>> auto-configuration and only fakes up the library. This part is
>> encapsulated in mk/compiler/f2c.mk.
>
> This breaks Mac OS X (at least Snow Leopard) badly:

I'm pretty sure this is related to the fact that shared libraries are
no longer working in OS X. See the thread I started (just yesterday)
and the patch attached to it.

Cheers,

--
Julio Merino

Re: CVS commit: pkgsrc

2009-12-19T13:57:06Z

On Sat, Dec 19, 2009 at 4:51 PM, Joerg Sonnenberger
<joerg@...> wrote:
> On Sat, Dec 19, 2009 at 04:32:28PM -0500, matthew sporleder wrote:
>> I have a package (cfengine3) that compiles on its own but fails with
>> pgksrc on osx due to linking problems. Would you wan tto look at
>> .//work/.wrapper/bin/libtool
>> or
>> .//work/cfengine-3.0.2/libtool
>> ?
>
> You could start by telling what problem you have...

===> Building for cfengine-3.0.2
Making all in pub
gnumake[1]: Nothing to be done for `all'.
Making all in src
/usr/bin/gnumake all-am
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wreturn-type
-Wmissing-prototypes -Wuninitialized -pipe -O2 -I/usr/pkg/include/db4
-I/usr/include -I/usr/pkg/include -I/usr/pkg/include/db4 -pipe -O2
-I/usr/pkg/include/db4 -I/usr/include -I/usr/pkg/include
-I/usr/pkg/include/db4 -version-info 1:0:0 -no-undefined -Xlinker -m
-L/usr/pkg/lib -L/usr/lib -L/usr/pkg/lib -o libpromises.la -rpath
/usr/pkg/lib libpromises_la-cf3parse.lo libpromises_la-cf3lex.lo
libpromises_la-patches.lo libpromises_la-attributes.lo
libpromises_la-install.lo libpromises_la-generic_agent.lo
libpromises_la-dtypes.lo libpromises_la-classes.lo
libpromises_la-env_context.lo libpromises_la-files_interfaces.lo
libpromises_la-files_properties.lo libpromises_la-files_select.lo
libpromises_la-files_operators.lo libpromises_la-files_repository.lo
libpromises_la-files_copy.lo libpromises_la-files_editline.lo
libpromises_la-files_edit.lo libpromises_la-files_links.lo
libpromises_la-files_hashes.lo libpromises_la-files_names.lo
libpromises_la-chflags.lo libpromises_la-modes.lo
libpromises_la-exec_tools.lo libpromises_la-nfs.lo
libpromises_la-item-lib.lo libpromises_la-cf_sql.lo
libpromises_la-client_protocol.lo libpromises_la-client_code.lo
libpromises_la-communication.lo libpromises_la-net.lo
libpromises_la-sockaddr.lo libpromises_la-recursion.lo
libpromises_la-processes_select.lo libpromises_la-fncall.lo
libpromises_la-cf3globals.lo libpromises_la-reporting.lo
libpromises_la-evalfunction.lo libpromises_la-sysinfo.lo
libpromises_la-conversion.lo libpromises_la-scope.lo
libpromises_la-assoc.lo libpromises_la-comparray.lo
libpromises_la-vars.lo libpromises_la-args.lo libpromises_la-hashes.lo
libpromises_la-crypto.lo libpromises_la-expand.lo
libpromises_la-matching.lo libpromises_la-selfdiagnostic.lo
libpromises_la-instrumentation.lo libpromises_la-granules.lo
libpromises_la-timeout.lo libpromises_la-promises.lo
libpromises_la-constraints.lo libpromises_la-iteration.lo
libpromises_la-rlist.lo libpromises_la-syntax.lo
libpromises_la-logging.lo libpromises_la-signals.lo
libpromises_la-transaction.lo libpromises_la-cfstream.lo
libpromises_la-pipes.lo libpromises_la-html.lo
libpromises_la-interfaces.lo libpromises_la-storage_tools.lo
libpromises_la-verify_reports.lo libpromises_la-verify_processes.lo
libpromises_la-enterprise_stubs.lo libpromises_la-mod_common.lo
libpromises_la-mod_access.lo libpromises_la-mod_exec.lo
libpromises_la-mod_methods.lo libpromises_la-mod_interfaces.lo
libpromises_la-mod_packages.lo libpromises_la-mod_files.lo
libpromises_la-mod_report.lo libpromises_la-mod_storage.lo
libpromises_la-mod_knowledge.lo libpromises_la-mod_measurement.lo
libpromises_la-mod_databases.lo libpromises_la-mod_process.lo -ldb
-L/usr/lib -lcrypto -lpthread -lpcre -lldap -lm -lpcreposix -L../pub
-lcfpub
gcc -dynamiclib -o .libs/libpromises.1.0.0.dylib
.libs/libpromises_la-cf3parse.o .libs/libpromises_la-cf3lex.o
.libs/libpromises_la-patches.o .libs/libpromises_la-attributes.o
.libs/libpromises_la-install.o .libs/libpromises_la-generic_agent.o
.libs/libpromises_la-dtypes.o .libs/libpromises_la-classes.o
.libs/libpromises_la-env_context.o
.libs/libpromises_la-files_interfaces.o
.libs/libpromises_la-files_properties.o
.libs/libpromises_la-files_select.o
.libs/libpromises_la-files_operators.o
.libs/libpromises_la-files_repository.o
.libs/libpromises_la-files_copy.o
.libs/libpromises_la-files_editline.o
.libs/libpromises_la-files_edit.o .libs/libpromises_la-files_links.o
.libs/libpromises_la-files_hashes.o .libs/libpromises_la-files_names.o
.libs/libpromises_la-chflags.o .libs/libpromises_la-modes.o
.libs/libpromises_la-exec_tools.o .libs/libpromises_la-nfs.o
.libs/libpromises_la-item-lib.o .libs/libpromises_la-cf_sql.o
.libs/libpromises_la-client_protocol.o
.libs/libpromises_la-client_code.o
.libs/libpromises_la-communication.o .libs/libpromises_la-net.o
.libs/libpromises_la-sockaddr.o .libs/libpromises_la-recursion.o
.libs/libpromises_la-processes_select.o .libs/libpromises_la-fncall.o
.libs/libpromises_la-cf3globals.o .libs/libpromises_la-reporting.o
.libs/libpromises_la-evalfunction.o .libs/libpromises_la-sysinfo.o
.libs/libpromises_la-conversion.o .libs/libpromises_la-scope.o
.libs/libpromises_la-assoc.o .libs/libpromises_la-comparray.o
.libs/libpromises_la-vars.o .libs/libpromises_la-args.o
.libs/libpromises_la-hashes.o .libs/libpromises_la-crypto.o
.libs/libpromises_la-expand.o .libs/libpromises_la-matching.o
.libs/libpromises_la-selfdiagnostic.o
.libs/libpromises_la-instrumentation.o .libs/libpromises_la-granules.o
.libs/libpromises_la-timeout.o .libs/libpromises_la-promises.o
.libs/libpromises_la-constraints.o .libs/libpromises_la-iteration.o
.libs/libpromises_la-rlist.o .libs/libpromises_la-syntax.o
.libs/libpromises_la-logging.o .libs/libpromises_la-signals.o
.libs/libpromises_la-transaction.o .libs/libpromises_la-cfstream.o
.libs/libpromises_la-pipes.o .libs/libpromises_la-html.o
.libs/libpromises_la-interfaces.o .libs/libpromises_la-storage_tools.o
.libs/libpromises_la-verify_reports.o
.libs/libpromises_la-verify_processes.o
.libs/libpromises_la-enterprise_stubs.o
.libs/libpromises_la-mod_common.o .libs/libpromises_la-mod_access.o
.libs/libpromises_la-mod_exec.o .libs/libpromises_la-mod_methods.o
.libs/libpromises_la-mod_interfaces.o
.libs/libpromises_la-mod_packages.o .libs/libpromises_la-mod_files.o
.libs/libpromises_la-mod_report.o .libs/libpromises_la-mod_storage.o
.libs/libpromises_la-mod_knowledge.o
.libs/libpromises_la-mod_measurement.o
.libs/libpromises_la-mod_databases.o
.libs/libpromises_la-mod_process.o
-L/Users/msporleder/Documents/development/pkgsrc/wip/cfengine3/work/.buildlink/lib
-ldb4 -lcrypto -lpthread
/Users/msporleder/Documents/development/pkgsrc/wip/cfengine3/work/.buildlink/lib/libpcre.dylib
-lldap -lm /Users/msporleder/Documents/development/pkgsrc/wip/cfengine3/work/.buildlink/lib/libpcreposix.dylib
-L/Users/msporleder/Documents/development/pkgsrc/wip/cfengine3/work/cfengine-3.0.2/pub
-lcfpub -Wl,-m -install_name /usr/pkg/lib/libpromises.1.dylib
-compatibility_version 2 -current_version 2.0 -Wl,-single_module
ld warning: option -m is obsolete and being ignored
ld: duplicate symbol _CFRUNCOMMAND in .libs/libpromises_la-signals.o
and .libs/libpromises_la-logging.o
collect2: ld returned 1 exit status
gnumake[2]: *** [libpromises.la] Error 1
gnumake[1]: *** [all] Error 2
gnumake: *** [all-recursive] Error 1
*** Error code 2

Stop.
bmake: stopped in /Users/msporleder/Documents/development/pkgsrc/wip/cfengine3
*** Error code 1

Stop.
bmake: stopped in /Users/msporleder/Documents/development/pkgsrc/wip/cfengine3

Re: CVS commit: pkgsrc

2009-12-19T13:51:22Z

On Sat, Dec 19, 2009 at 04:32:28PM -0500, matthew sporleder wrote:
> I have a package (cfengine3) that compiles on its own but fails with
> pgksrc on osx due to linking problems. Would you wan tto look at
> .//work/.wrapper/bin/libtool
> or
> .//work/cfengine-3.0.2/libtool
> ?

You could start by telling what problem you have...

Joerg

Re: CVS commit: pkgsrc

2009-12-19T13:32:28Z

On Fri, Dec 18, 2009 at 5:02 PM, Joerg Sonnenberger
<joerg@...> wrote:

> On Wed, Dec 16, 2009 at 10:40:01AM +0000, Matthias Scheler wrote:
>> > The pkgsrc integration of f2c has been changed to be more sane.
>> > libtool itself now depends on the f2c frontend to use proper
>> > auto-configuration and only fakes up the library. This part is
>> > encapsulated in mk/compiler/f2c.mk.
>>
>> This breaks Mac OS X (at least Snow Leopard) badly:
>
> For starters, can someone send me the output of "bmake configure" for
> libtool-base and the resulting libtool? Ideally the old libtool script,
> too.
>

I have a package (cfengine3) that compiles on its own but fails with
pgksrc on osx due to linking problems. Would you wan tto look at
.//work/.wrapper/bin/libtool
or
.//work/cfengine-3.0.2/libtool
?

Re: fix buildlinking or bump BUILDLINK_API_DEPENDS.startup-notification?

2009-12-19T11:33:16Z

On Sat, Dec 19, 2009 at 06:57:24PM +0000, Jonathan A. Kollasch wrote:
> On Sat, Dec 19, 2009 at 08:02:06AM -0600, Jeremy C. Reed wrote:
[...]
> Is there perhaps a way to conditionally include the xcb
> buildlinks based on the installed s-n version?

That'd be hackish.

> I take responsibility for breaking this. However, I'm
> only going to fix it if I know I won't get complaints
> about the fix.

Then you won't fix it, because one way or another some people won't be
happy :-)

It's not a new problem, it comes up every now and then, notably when
there are updates to X.Org pacakges that have a good enough version
in the host system. The last time I discussed it with Joerg, all I got
was a shrug and a mumble about not updating all possible packages.

I think the right way to do that would be to include the bl3.mk file
into the binary pacakge so that pkgsrc can use information from the
installed package and not the one in-tree. But it is a rather complex
task and I'm not sure the way the bl3.mk files currently work can be
translated into such a scheme very easily.

And if I tell you that it is the right way to fix it, you'll reply
something along the lines of "hell, no, I only care about this pacakge"
and I wouldn't really be able to blame you...

--
Quentin Garnier - cube@... - cube@...
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

attachment0 (498 bytes) Download Attachment

Re: fix buildlinking or bump BUILDLINK_API_DEPENDS.startup-notification?

2009-12-19T10:57:24Z

On Sat, Dec 19, 2009 at 08:02:06AM -0600, Jeremy C. Reed wrote:

> I see the startup-notification's buildlink3.mk added:
> .include "../../x11/libxcb/buildlink3.mk"
> .include "../../x11/xcb-util/buildlink3.mk"
>
> But the
> BUILDLINK_API_DEPENDS.startup-notification+=startup-notification>=0.5
> stayed the same.
>
> I have an acceptable startup-notification version installed (0.9). So
> building pcmanfm which includes x11/startup-notification/buildlink3.mk
> fails with:
>
> ERROR: xcb-util>=0.3.3 is not installed; can't buildlink files.
>
> Simple fix is to bump BUILDLINK_API_DEPENDS.startup-notification.
>
> The ERROR doesn't make it easy as it doesn't show what actually required
> this. Also why doesn't it try to install that if it knows it is needed?
>
> For now I commented out the two includes above and pcmanfm builds for
> me.

And obache thinks I should adjust ABI_DEPENDS and revbump(1).
I consulted with Joerg after being poked about that, he said
it was at most a API bump. I infered from this conversation
that pkgsrc didn't have a good way to handle this situation.

As no part of the 0.9 ABI/API changed in 0.10, I'm hesitant
to require 0.10 for either.

Is there perhaps a way to conditionally include the xcb
buildlinks based on the installed s-n version?

I take responsibility for breaking this. However, I'm
only going to fix it if I know I won't get complaints
about the fix.

Jonathan Kollasch

Re: Broken shared libraries in OS X

2009-12-19T06:25:33Z

On Sat, 19 Dec 2009 15:24:05 +0100
Tobias Nygren <tnn@...> wrote:

> On platforms it is initialised in bootstrap-mk-files.

s/platforms/some platforms/

I didn't mean to imply that bootstrap-mk-files is the right place to do
it, I have no idea.

Re: Broken shared libraries in OS X

2009-12-19T06:24:05Z

On Sat, 19 Dec 2009 14:14:32 +0000
Julio Merino <jmmv84@...> wrote:

> I agree, but a quick look at mk/platforms showed that only Darwin is
> using gcc for cpp. (Not to mention I wasn't sure how to make this
> platform agnostic, other than forcing CPP=cpp in this package.)

On platforms it is initialised in bootstrap-mk-files.

Re: Broken shared libraries in OS X

2009-12-19T06:14:32Z

On Sat, Dec 19, 2009 at 2:09 PM, Tobias Nygren <tnn@...> wrote:

> On Sat, 19 Dec 2009 13:01:29 +0000
> Julio Merino <jmmv84@...> wrote:
>
>> See attached patch; will submit later. I'm not sure if the
>> PKGREVISION changes are good enough.
>
> It's quite possible things will fail in similar ways on other
> platforms. A fix for this issue should be platform agnostic.
>
> I'll check what happens on Solaris and Tru64.

I agree, but a quick look at mk/platforms showed that only Darwin is
using gcc for cpp. (Not to mention I wasn't sure how to make this
platform agnostic, other than forcing CPP=cpp in this package.)

--
Julio Merino

Re: Broken shared libraries in OS X

2009-12-19T06:09:55Z

On Sat, 19 Dec 2009 13:01:29 +0000
Julio Merino <jmmv84@...> wrote:

> See attached patch; will submit later. I'm not sure if the
> PKGREVISION changes are good enough.

It's quite possible things will fail in similar ways on other
platforms. A fix for this issue should be platform agnostic.

I'll check what happens on Solaris and Tru64.

fix buildlinking or bump BUILDLINK_API_DEPENDS.startup-notification?

2009-12-19T06:02:06Z

I see the startup-notification's buildlink3.mk added:
.include "../../x11/libxcb/buildlink3.mk"
.include "../../x11/xcb-util/buildlink3.mk"

But the
BUILDLINK_API_DEPENDS.startup-notification+=startup-notification>=0.5
stayed the same.

I have an acceptable startup-notification version installed (0.9). So
building pcmanfm which includes x11/startup-notification/buildlink3.mk
fails with:

ERROR: xcb-util>=0.3.3 is not installed; can't buildlink files.

Simple fix is to bump BUILDLINK_API_DEPENDS.startup-notification.

The ERROR doesn't make it easy as it doesn't show what actually required
this. Also why doesn't it try to install that if it knows it is needed?

For now I commented out the two includes above and pcmanfm builds for
me.

Re: Broken shared libraries in OS X

2009-12-19T05:01:29Z

On Thu, Dec 17, 2009 at 7:38 PM, Julio Merino <jmmv84@...> wrote:
> Hello,
>
> After the recent libtool upgrade, I cannot build shared libraries any
> more in OS X 10.5 (both intel and ppc). I've been looking at this for
> a while and found that configuring libtool *without* the pkgsrc
> wrappers results in:
[...]

Alright, found the problem.

The f2c-f77 script uses gcc as the precompiler. But that breaks
miserably when CPP is set to gcc, because running gcc, even in
precompilation mode on a .F file, will result in an error saying that
fortran is not supported. This happens both in OS X and in NetBSD.
However, the problem does not appear in NetBSD because CPP=cpp,
whereas in OS X is something along the lines of CPP=gcc -E.

Making f2c-f77 use cpp directly on OS X fixes the issue.

See attached patch; will submit later. I'm not sure if the
PKGREVISION changes are good enough.

--
Julio Merino

patch.diff (3K) Download Attachment

Re: Packages without DESTDIR support

2009-12-19T02:14:42Z

On Wed, 9 Dec 2009, Joerg Sonnenberger wrote:
> http://www.netbsd.org/~joerg/missing-destdir
> has a list of all packages that currently lack DESTDIR support.
> Please help with reducing that less as far as possible.

So here's a patch for mail/procmail

--
Steven
1: Linux - will work for fish.
2: The Linux penguin - looks stuffed to the brim with herring.
( make your own conclusions )
Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/mail/procmail/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- Makefile 18 Jul 2009 03:15:18 -0000 1.43
+++ Makefile 19 Dec 2009 10:07:36 -0000
@@ -10,6 +10,8 @@ MAINTAINER= kim@...
HOMEPAGE= http://www.procmail.org/
COMMENT= Local mail delivery agent

+PKG_DESTDIR_SUPPORT= destdir
+
PKG_INSTALLATION_TYPES= overwrite pkgviews

MAKE_JOBS_SAFE= no
@@ -45,14 +47,14 @@ pre-configure:
do-install:
cd ${WRKSRC}/new; \
for f in procmail formail lockfile; do \
- ${INSTALL_PROGRAM} $$f ${PREFIX}/bin/$$f; \
+ ${INSTALL_PROGRAM} $$f ${DESTDIR}${PREFIX}/bin/$$f; \
done; \
- ${INSTALL_SCRIPT} mailstat ${PREFIX}/bin/mailstat; \
+ ${INSTALL_SCRIPT} mailstat ${DESTDIR}${PREFIX}/bin/mailstat; \
for f in procmail.1 formail.1 lockfile.1; do \
- ${INSTALL_MAN} $$f ${PREFIX}/${PKGMANDIR}/man1/$$f; \
+ ${INSTALL_MAN} $$f ${DESTDIR}${PREFIX}/${PKGMANDIR}/man1/$$f; \
done; \
for f in procmailex.5 procmailrc.5 procmailsc.5; do \
- ${INSTALL_MAN} $$f ${PREFIX}/${PKGMANDIR}/man5/$$f; \
+ ${INSTALL_MAN} $$f ${DESTDIR}${PREFIX}/${PKGMANDIR}/man5/$$f; \
done
${SH} ${WRKSRC}/suid.sh
.endif
Index: distinfo
===================================================================
RCS file: /cvsroot/pkgsrc/mail/procmail/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo 18 Jul 2009 03:15:18 -0000 1.12
+++ distinfo 19 Dec 2009 10:07:36 -0000
@@ -6,8 +6,8 @@ Size (procmail-3.22.tar.gz) = 226817 byt
SHA1 (patch-aa) = 6e29885f53d24662c5c69ac906ccc36a26665be2
SHA1 (patch-ab) = 5233a6033198dc2baec135a6fba987e7e2b89ff2
SHA1 (patch-ac) = fe2350e704546c2262d546bb615175dd0591ba8b
-SHA1 (patch-ad) = 569d357c6afb9d7644c8094878aec08d22ae609d
-SHA1 (patch-ae) = 91a3f83d41ba84e218a14c8bfc262fdbb1bc252c
+SHA1 (patch-ad) = b35d6d508a15b8e70734ac7ccd58c19db31717ab
+SHA1 (patch-ae) = b5ac027b337c8d9cf9c6096a48ef534315e18250
SHA1 (patch-af) = 889f937f50561308c644d5a4bd836eccabbb2938
SHA1 (patch-ag) = 66ae907f1b7ccfa10b5278443a9d9b0277923e61
SHA1 (patch-ba) = 5b0d2513e5320de26696cfaad9475f462579dae3
Index: patches/patch-ad
===================================================================
RCS file: /cvsroot/pkgsrc/mail/procmail/patches/patch-ad,v
retrieving revision 1.3
diff -u -p -r1.3 patch-ad
--- patches/patch-ad 26 Aug 2000 14:26:58 -0000 1.3
+++ patches/patch-ad 19 Dec 2009 10:07:36 -0000
@@ -1,8 +1,8 @@
$NetBSD: patch-ad,v 1.3 2000/08/26 14:26:58 wiz Exp $

---- src/recommend.c.orig Thu Nov 25 04:13:36 1999
+--- src/recommend.c.orig 1999-10-20 04:47:45.000000000 +0000
+++ src/recommend.c
-@@ -19,7 +19,6 @@
+@@ -19,7 +19,6 @@ int main(argc,argv)const int argc;const
{ fprintf(stderr,"Please run this program via 'make recommend'\n");
return EX_USAGE;
}
@@ -10,3 +10,29 @@ $NetBSD: patch-ad,v 1.3 2000/08/26 14:26
for(p=checkf;*p;p++)
if(!stat(*p,&stbuf)&&stbuf.st_mode&S_ISGID)
{ if(stbuf.st_mode&S_ISGID)
+@@ -36,19 +35,19 @@ int main(argc,argv)const int argc;const
+ }
+ if(gid!=stbuf.st_gid)
+ sgid=0;
+- printf("chown root %s\n",argv[1]);
++ printf("chown root ${DESTDIR}%s\n",argv[1]);
+ if(sgid)
+ if(grp=getgrgid(gid))
+- printf("chgrp %s %s %s\n",grp->gr_name,argv[1],argv[2]);
++ printf("chgrp %s ${DESTDIR}%s ${DESTDIR}%s\n",grp->gr_name,argv[1],argv[2]);
+ else
+- printf("chgrp %u %s %s\n",(unsigned)gid,argv[1],argv[2]);
+- printf("chmod %lo %s\n",(unsigned long)(sgid|S_ISUID|PERMIS),argv[1]);
++ printf("chgrp %u ${DESTDIR}%s ${DESTDIR}%s\n",(unsigned)gid,argv[1],argv[2]);
++ printf("chmod %lo ${DESTDIR}%s\n",(unsigned long)(sgid|S_ISUID|PERMIS),argv[1]);
+ if(sgid)
+- printf("chmod %lo %s\n",(unsigned long)(sgid|PERMIS),argv[2]);
++ printf("chmod %lo ${DESTDIR}%s\n",(unsigned long)(sgid|PERMIS),argv[2]);
+ else if(chmdir==1)
+ goto nogchmod;
+ if(chmdir)
+- printf("chmod %c+w %s/.\n",chmdir==1?'g':'a',mailspooldir);
++ printf("chmod %c+w ${DESTDIR}%s/.\n",chmdir==1?'g':'a',mailspooldir);
+ nogchmod:
+ return EXIT_SUCCESS;
+ }
Index: patches/patch-ae
===================================================================
RCS file: /cvsroot/pkgsrc/mail/procmail/patches/patch-ae,v
retrieving revision 1.6
diff -u -p -r1.6 patch-ae
--- patches/patch-ae 20 Jan 2003 22:55:44 -0000 1.6
+++ patches/patch-ae 19 Dec 2009 10:07:36 -0000
@@ -2,30 +2,75 @@ $NetBSD: patch-ae,v 1.6 2003/01/20 22:55

If the ``Housekeeping'' lines stay, `make install; make deinstall; make install' fails.

---- Makefile.1.orig Tue Sep 11 00:53:09 2001
-+++ Makefile.1 Mon Jan 20 17:21:22 2003
-@@ -88,7 +88,7 @@
- @-$(MKDIRS) $(MAN1DIR) 2>$(DEVNULL); exit 0
- @-test -d $(MAN5DIR) || $(RM) $(MAN5DIR); exit 0
- @-$(MKDIRS) $(MAN5DIR) 2>$(DEVNULL); exit 0
+--- Makefile.1.orig 2001-09-11 04:53:09.000000000 +0000
++++ Makefile.1
+@@ -73,49 +73,47 @@ suid.sh: recommend
+ install-suid: suid.sh install.bin
+ @cat suid.sh
+ @$(SHELL) ./suid.sh
+- @cd $(BINDIR); echo Installed in $(BINDIR); ls -l $(BINSS)
++ @cd ${DESTDIR}$(BINDIR); echo Installed in ${DESTDIR}$(BINDIR); ls -l $(BINSS)
+
+ $(MANS): mans
+
+ $(BINS): bins
+
+-$(BASENAME):
+- $(MKDIRS) $(BASENAME)
++${DESTDIR}$(BASENAME):
++ $(MKDIRS) ${DESTDIR}$(BASENAME)
+
+ install.man: $(MANS) $(BASENAME)
+- @-$(MKDIRS) $(MANDIR) 2>$(DEVNULL); exit 0
+- @-test -d $(MAN1DIR) || $(RM) $(MAN1DIR); exit 0
+- @-$(MKDIRS) $(MAN1DIR) 2>$(DEVNULL); exit 0
+- @-test -d $(MAN5DIR) || $(RM) $(MAN5DIR); exit 0
+- @-$(MKDIRS) $(MAN5DIR) 2>$(DEVNULL); exit 0
- @chmod 0644 $(MANS)
++ @-$(MKDIRS) ${DESTDIR}$(MANDIR) 2>$(DEVNULL); exit 0
++ @-test -d ${DESTDIR}$(MAN1DIR) || $(RM) ${DESTDIR}$(MAN1DIR); exit 0
++ @-$(MKDIRS) ${DESTDIR}$(MAN1DIR) 2>$(DEVNULL); exit 0
++ @-test -d ${DESTDIR}$(MAN5DIR) || $(RM) ${DESTDIR}$(MAN5DIR); exit 0
++ @-$(MKDIRS) ${DESTDIR}$(MAN5DIR) 2>$(DEVNULL); exit 0
+ @${CHMOD} 0644 $(MANS)
@for a in $(MANS1S); \
- do $(INSTALL) new/$$a.1 $(MAN1DIR)/$$a.$(MAN1SUFFIX) || exit 1; \
+- do $(INSTALL) new/$$a.1 $(MAN1DIR)/$$a.$(MAN1SUFFIX) || exit 1; \
++ do $(INSTALL) new/$$a.1 ${DESTDIR}$(MAN1DIR)/$$a.$(MAN1SUFFIX) || exit 1; \
+ if test "X$(MANCOMPRESS)" != "X"; \
+- then $(MANCOMPRESS) -c new/$$a.1 >$(MAN1DIR)/$$a.$(MAN1SUFFIX); \
++ then $(MANCOMPRESS) -c new/$$a.1 >${DESTDIR}$(MAN1DIR)/$$a.$(MAN1SUFFIX); \
+ else :; fi; \
+ done
+ @for a in $(MANS5S); \
+- do $(INSTALL) new/$$a.5 $(MAN5DIR)/$$a.$(MAN5SUFFIX) || exit 1; \
++ do $(INSTALL) new/$$a.5 ${DESTDIR}$(MAN5DIR)/$$a.$(MAN5SUFFIX) || exit 1; \
if test "X$(MANCOMPRESS)" != "X"; \
-@@ -101,14 +101,12 @@
- then $(MANCOMPRESS) -c new/$$a.5 >$(MAN5DIR)/$$a.$(MAN5SUFFIX); \
+- then $(MANCOMPRESS) -c new/$$a.5 >$(MAN5DIR)/$$a.$(MAN5SUFFIX); \
++ then $(MANCOMPRESS) -c new/$$a.5 >${DESTDIR}$(MAN5DIR)/$$a.$(MAN5SUFFIX); \
else :; fi; \
done
- echo Housekeeping file >install.man

install.bin: $(BINS) $(BASENAME)
- @-$(MKDIRS) $(BINDIR) 2>$(DEVNULL); exit 0
+- @-$(MKDIRS) $(BINDIR) 2>$(DEVNULL); exit 0
- @chmod 0755 $(BINS)
-+ @${CHMOD} 0755 $(BINS)
- $(INSTALL) $(BINS) $(BINDIR)
- @-dirname / >$(DEVNULL) || $(INSTALL) examples/dirname $(BINDIR)
+- $(INSTALL) $(BINS) $(BINDIR)
+- @-dirname / >$(DEVNULL) || $(INSTALL) examples/dirname $(BINDIR)
- echo Housekeeping file >install.bin
++ @-$(MKDIRS) ${DESTDIR}$(BINDIR) 2>$(DEVNULL); exit 0
++ @${CHMOD} 0755 $(BINS)
++ $(INSTALL) $(BINS) ${DESTDIR}$(BINDIR)
++ @-dirname / >$(DEVNULL) || $(INSTALL) examples/dirname ${DESTDIR}$(BINDIR)

install:
@$(MAKE) install.man install.bin
+ @echo
+- @cd $(BINDIR); echo Installed in $(BINDIR); ls -l $(BINSS)
+- @cd $(MAN1DIR); echo Installed in $(MAN1DIR); ls -l $(MANS1)
+- @cd $(MAN5DIR); echo Installed in $(MAN5DIR); ls -l $(MANS5)
++ @cd ${DESTDIR}$(BINDIR); echo Installed in ${DESTDIR}$(BINDIR); ls -l $(BINSS)
++ @cd ${DESTDIR}$(MAN1DIR); echo Installed in ${DESTDIR}$(MAN1DIR); ls -l $(MANS1)
++ @cd ${DESTDIR}$(MAN5DIR); echo Installed in ${DESTDIR}$(MAN5DIR); ls -l $(MANS5)
+ @$(MAKE) recommend
+
+ deinstall:

daily pkgsrc CVS update output

2009-12-18T17:41:22Z

Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/comms/asterisk/Makefile
P pkgsrc/comms/asterisk/distinfo
P pkgsrc/comms/fidogate/Makefile
P pkgsrc/comms/fidogate/distinfo
P pkgsrc/comms/fidogate/patches/patch-ab
P pkgsrc/comms/fidogate/patches/patch-ad
P pkgsrc/comms/fidogate/patches/patch-ae
P pkgsrc/comms/fidogate/patches/patch-af
P pkgsrc/comms/fidogate/patches/patch-ag
P pkgsrc/comms/fidogate/patches/patch-ah
P pkgsrc/comms/fidogate/patches/patch-ai
P pkgsrc/comms/fidogate/patches/patch-aj
P pkgsrc/comms/fidogate/patches/patch-ak
P pkgsrc/comms/fidogate/patches/patch-al
P pkgsrc/comms/fidogate/patches/patch-am
P pkgsrc/comms/fidogate/patches/patch-an
P pkgsrc/comms/fidogate/patches/patch-ao
P pkgsrc/comms/fidogate/patches/patch-ap
P pkgsrc/comms/fidogate/patches/patch-aq
P pkgsrc/comms/fidogate/patches/patch-ar
P pkgsrc/comms/fidogate/patches/patch-as
P pkgsrc/comms/fidogate/patches/patch-at
U pkgsrc/comms/fidogate/patches/patch-au
P pkgsrc/comms/fidogate/patches/patch-av
P pkgsrc/comms/fidogate/patches/patch-aw
P pkgsrc/comms/fidogate/patches/patch-ax
P pkgsrc/comms/fidogate/patches/patch-ay
P pkgsrc/comms/fidogate/patches/patch-az
P pkgsrc/comms/fidogate/patches/patch-ba
P pkgsrc/comms/fidogate/patches/patch-bb
P pkgsrc/comms/fidogate/patches/patch-bc
P pkgsrc/comms/fidogate/patches/patch-bd
P pkgsrc/comms/fidogate/patches/patch-be
P pkgsrc/comms/fidogate/patches/patch-bf
U pkgsrc/comms/fidogate/patches/patch-bg
U pkgsrc/comms/fidogate/patches/patch-bh
U pkgsrc/comms/fidogate/patches/patch-bi
U pkgsrc/comms/fidogate/patches/patch-bj
U pkgsrc/comms/fidogate/patches/patch-bk
U pkgsrc/comms/fidogate/patches/patch-bl
U pkgsrc/comms/fidogate/patches/patch-bm
U pkgsrc/comms/fidogate/patches/patch-bn
U pkgsrc/comms/fidogate/patches/patch-bo
U pkgsrc/comms/fidogate/patches/patch-bp
U pkgsrc/comms/fidogate/patches/patch-bq
U pkgsrc/comms/fidogate/patches/patch-br
U pkgsrc/comms/fidogate/patches/patch-bs
U pkgsrc/comms/fidogate/patches/patch-bt
U pkgsrc/comms/fidogate/patches/patch-bu
P pkgsrc/devel/libtool/distinfo
P pkgsrc/devel/libtool/patches/patch-ab
P pkgsrc/devel/libtool-base/Makefile
P pkgsrc/doc/CHANGES-2009
P pkgsrc/lang/erlang/distinfo
U pkgsrc/lang/erlang/patches/patch-aw
P pkgsrc/lang/intercal/Makefile
U pkgsrc/lang/intercal/PLIST
U pkgsrc/lang/intercal/distinfo
U pkgsrc/lang/intercal/patches/patch-aa
cvs update: pkgsrc/lang/intercal/patches/patch-ab is no longer in the repository
cvs update: pkgsrc/lang/intercal/patches/patch-ac is no longer in the repository
U pkgsrc/lang/intercal/patches/patch-ad
U pkgsrc/lang/intercal/patches/patch-ae
U pkgsrc/lang/intercal/patches/patch-af
P pkgsrc/print/foomatic4-filters/Makefile
P pkgsrc/security/gnupg2/buildlink3.mk
P pkgsrc/security/gnupg2/distinfo
P pkgsrc/security/gnupg2/options.mk
U pkgsrc/security/gnupg2/patches/patch-al
P pkgsrc/security/libgcrypt/Makefile
P pkgsrc/security/libgcrypt/distinfo
P pkgsrc/security/libgcrypt/options.mk
U pkgsrc/security/libgcrypt/files/idea-patch
U pkgsrc/security/libgcrypt/patches/patch-ba
U pkgsrc/security/libgcrypt/patches/patch-bb
U pkgsrc/security/libgcrypt/patches/patch-bc
P pkgsrc/security/libprelude/distinfo
cvs update: pkgsrc/security/libprelude/patches/patch-af is no longer in the repository
P pkgsrc/www/clearsilver/buildlink3.mk

Killing core files:

Updating tar files:

building list of README.html files
pkgsrc: collecting ... building .gz ... replacing... building .bz2 ... replacing...
pkgsrc-readmes: collecting ... building .gz ... replacing... building .bz2 ... replacing... done

Updating pkgsrc-2009Q3 pkgsrc tree (/ftp/pub/pkgsrc/pkgsrc-2009Q3):

Updating pkgsrc pkgsrc-2009Q3 tar files:
pkgsrc: collecting ... building .gz ... replacing... building .bz2 ... replacing... done

Re: CVS commit: pkgsrc

2009-12-18T14:02:22Z

On Wed, Dec 16, 2009 at 10:40:01AM +0000, Matthias Scheler wrote:
> > The pkgsrc integration of f2c has been changed to be more sane.
> > libtool itself now depends on the f2c frontend to use proper
> > auto-configuration and only fakes up the library. This part is
> > encapsulated in mk/compiler/f2c.mk.
>
> This breaks Mac OS X (at least Snow Leopard) badly:

For starters, can someone send me the output of "bmake configure" for
libtool-base and the resulting libtool? Ideally the old libtool script,
too.

Joerg

Re: How to define DEPENDS to accept all py* variant packages.

2009-12-18T03:10:00Z

On Fri, 18 Dec 2009 18:12:41 +0900, Joerg Sonnenberger <joerg@...> wrote:

> On Fri, Dec 18, 2009 at 12:10:10PM +0900, OBATA Akio wrote:
>> How to define DEPENDS (and CONFLICTS) pattern to accept all py* variant
>> packages?
>
> In short, don't. The results will generally not be what you or the user
> expects, unless the dependency is already installed.

Then, result in same as suggestion from tnn@:
DEPENDS+= ${PYPKGPREFIX}-ibus>=1.2:../../wip/ibus

Should ibus-qt package also contains ${PYPKGPREFIX} as its PKGNAME?

--
"Of course I love NetBSD":-)
OBATA Akio / obache@...

Re: How to define DEPENDS to accept all py* variant packages.

2009-12-18T01:12:41Z

On Fri, Dec 18, 2009 at 12:10:10PM +0900, OBATA Akio wrote:
> How to define DEPENDS (and CONFLICTS) pattern to accept all py* variant
> packages?

In short, don't. The results will generally not be what you or the user
expects, unless the dependency is already installed.

Joerg

Re: How to define DEPENDS to accept all py* variant packages.

2009-12-18T01:07:44Z

On Fri, 18 Dec 2009 12:10:10 +0900
"OBATA Akio" <obache@...> wrote:

> How to define DEPENDS (and CONFLICTS) pattern to accept all py* variant packages?
> DEPENDS+= py[0-9][0-9]-ibus>=1.2:../../wip/ibus

Use ${PYPKGPREFIX}:

DEPENDS+= ${PYPKGPREFIX}-ibus>=1.2:../../wip/ibus