Re: [Fink-devel] non-fatal error in fink git sandbox-build branch

[Jack Howarth]

In particular, I am confused as to why...

 if ( !-z "$Fink::Config::basepath/etc/fink.sb" && $sandbox_request ) {
my $sandbox = "$Fink::Config::basepath/etc/fink.sb";

triggers those warnings whereas...

if (-f "$Fink::Config::basepath/bin/dpkg-lockwait") {
"$Fink::Config::basepath/bin/dpkg-lockwait";

and

if (-f "$Fink::Config::basepath/bin/apt-get-lockwait") {
"$Fink::Config::basepath/bin/apt-get-lockwait";

and

"$Fink::Config::basepath/bin/apt-get
1>/dev/null 2>/dev/null",

don't.
 Jack

On Mon, Nov 21, 2016 at 7:15 AM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
> Daniel and Alexander,
>After injecting the updated sandbox-build fink git branch on my
> machine, I noticed a non-fatal warning of...
>
> ./Services/execute_nonroot_okay.t  1/12 Use of uninitialized
> value $Fink::Config::basepath in concatenation (.) or string at
> /sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
> line 613.
> Use of uninitialized value $Fink::Config::basepath in concatenation
> (.) or string at
> /sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
> line 614.
> Use of uninitialized value $Fink::Config::basepath in concatenation
> (.) or string at
> /sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
> line 613.
> Use of uninitialized value $Fink::Config::basepath in concatenation
> (.) or string at
> /sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
> line 614.
> Use of uninitialized value $Fink::Config::basepath in concatenation
> (.) or string at
> /sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
> line 613.
> Use of uninitialized value $Fink::Config::basepath in concatenation
> (.) or string at
> /sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
> line 614.
>
> which still results in clean test suite results...
>
> All tests successful.
> Files=48, Tests=1065, 11 wallclock secs ( 0.31 usr  0.12 sys +  6.04
> cusr  1.24 csys =  7.71 CPU)
>
> Any idea how to suppress that warning?
>   Jack

--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] non-fatal error in fink git sandbox-build branch

[Jack Howarth]

Daniel and Alexander,
   After injecting the updated sandbox-build fink git branch on my
machine, I noticed a non-fatal warning of...

./Services/execute_nonroot_okay.t  1/12 Use of uninitialized
value $Fink::Config::basepath in concatenation (.) or string at
/sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
line 613.
Use of uninitialized value $Fink::Config::basepath in concatenation
(.) or string at
/sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
line 614.
Use of uninitialized value $Fink::Config::basepath in concatenation
(.) or string at
/sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
line 613.
Use of uninitialized value $Fink::Config::basepath in concatenation
(.) or string at
/sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
line 614.
Use of uninitialized value $Fink::Config::basepath in concatenation
(.) or string at
/sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
line 613.
Use of uninitialized value $Fink::Config::basepath in concatenation
(.) or string at
/sw/src/fink.build/fink-0.41.99.git-20161121.1208/t/../perlmod/Fink/Services.pm
line 614.

which still results in clean test suite results...

All tests successful.
Files=48, Tests=1065, 11 wallclock secs ( 0.31 usr  0.12 sys +  6.04
cusr  1.24 csys =  7.71 CPU)

Any idea how to suppress that warning?
  Jack

--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] llvm-clang needed for gromacs-2016-1

[Jack Howarth]

Hanspeter,
  It has been a couple of weeks now since I emailed David Fang
about the update to the llvm39 package to add the proposed llvm-clang,
libomp-dev and libomp-shlibs split-offs required to cleanly support
packages like the gromacs/gromacs-mpi-2016-1 updates which require a
clang that supports -fopenmp without tethering the package to a
specific llvmXY release. The proposed changes are quite sensible,
straight-forward and safe...

https://sourceforge.net/p/fink/package-submissions/4831/
https://sourceforge.net/p/fink/package-submissions/4827/

Index: llvm39.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/languages/llvm39.info,v
retrieving revision 1.2
diff -u -r1.2 llvm39.info
--- llvm39.info 27 Oct 2016 04:01:28 - 1.2
+++ llvm39.info 13 Nov 2016 18:26:26 -
@@ -1,7 +1,7 @@
 Info3: <<
 Package: llvm39
 Version: 3.9.0
-Revision: 1
+Revision: 2
 Description: Modular and reusable compiler
 License: BSD
 Maintainer: David Fang 
@@ -54,8 +54,8 @@

 PatchFile: %n.patch
 PatchFile-MD5: 6addcbd4c9fe449b3cd006eb48f5219b
-#PatchFile2: %n-clang.patch
-#PatchFile2-MD5: d2a2b4207c19b7f09f197ae9769a51d2
+PatchFile2: %n-clang.patch
+PatchFile2-MD5: 25a45c309e14611b278c30b782f0d7e5
 #PatchFile3: %n-compiler-rt.patch
 #PatchFile3-MD5: 60ed1415e15b1781f2d58c0db17aab78
 #PatchFile4: %n-polly.patch
@@ -65,7 +65,7 @@
 #PatchFile6: %n-clang-omp.patch
 #PatchFile6-MD5: 8067f4cc1f58030f7746521d58c776c2
 PatchFile7: %n-clang-iomp5.patch
-PatchFile7-MD5: 33f21b006473cbdd5feced616b05903b
+PatchFile7-MD5: d5d9686fd0727c0e1cd953f585f4481d

 PatchScript: <<
  #!/bin/sh -ev
@@ -108,7 +108,7 @@
  pushd tools/clang
   # Apply clang-omp merge before clang patch
   #$patch_filter %{PatchFile6} | patch -p1
-  #$patch_filter %{PatchFile2} | patch -p1
+  $patch_filter %{PatchFile2} | patch -p1
   $patch_filter %{PatchFile7} | patch -p1
  popd
  pushd tools/polly
@@ -1078,15 +1078,6 @@
  iprefix=%i/$stem
  prefix=%p/$stem

- # Pass path to libLTO.dylib with -lto_library using ld shell script
- pushd $iprefix/bin
- cat < ./ld
-#!/bin/sh
-exec /usr/bin/ld -lto_library %p/opt/llvm-3.9/lib/libLTO.dylib "\$@"
-EOF
- chmod ugo+x ./ld
- popd
-
 # convenient clang symlinks
  mkdir -p %i/bin
  pushd %i/bin
@@ -1112,6 +1103,26 @@
  cp %b/../build/last/*-check.log testlogs/
  cp %b/../build/last-libcxx/*-check.log testlogs/
  popd
+
+# place omp.h in %p/include/libomp for common libomp-dev package
+ install -d %i/include/libomp
+ pushd %i/opt/llvm-$brv/lib/clang/%v/include
+ mv omp.h %i/include/libomp
+ popd
+
+# place libomp.dylib in libomp subdirectory for common libomp-shlibs package
+# leave legacy copy in %p/opt/llvm-$brv/lib for clang39-shlibs
+ install -d %i/lib/libomp
+ pushd %i/opt/llvm-$brv/lib
+ cp libomp.dylib %i/lib/libomp
+ ln -s libomp.dylib %i/lib/libomp/libiomp5.dylib
+ ln -s libomp.dylib %i/lib/libomp/libgomp.dylib
+ popd
+ install_name_tool -id %p/lib/libomp/libomp.dylib %i/lib/libomp/libomp.dylib
+
+# create compiler symlinks for common llvm-clang split-off
+ ln -s clang-$brv %i/bin/llvm-clang
+ ln -s clang++-$brv %i/bin/llvm-clang++
 <<
 SplitOff: <<
  Package: clang39-tools
@@ -1178,7 +1189,9 @@
  # odcctools,
  # choosing to require opt-in instead of defaulting to libcxx1-dev
  # libcxx1-dev,
+ libomp-dev (>= %v-%r),
  clang39-shlibs (= %v-%r),
+ libomp-shlibs (>= %v-%r),
  polly39-shlibs (= %v-%r)
  <<
  Description: Executables and runtime for clang compiler
@@ -1186,7 +1199,6 @@
  Files: <<
  bin/clang*
  opt/llvm-3.9/bin/clang*
- opt/llvm-3.9/bin/ld
  opt/llvm-3.9/lib/clang
  <<
  DescUsage: <<
@@ -1313,6 +1325,37 @@
  <<
 <<
 SplitOff14: <<
+ Package: libomp-shlibs
+ Description: Standard library for libomp
+ Files: <<
+ (%m != powerpc) lib//libomp/lib*omp*.dylib
+ <<
+ DocFiles: <<
+ projects/openmp/CREDITS.txt
+ projects/openmp/LICENSE.txt
+ <<
+ Shlibs: <<
+ (%m != powerpc) %p/lib/libomp/libomp.dylib 5.0.0 %n (>= 3.9.0-2)
+ <<
+<<
+SplitOff15: <<
+ Package: libomp-dev
+ Description: Standard library header for libomp
+ Depends: libomp-shlibs (= %v-%r)
+ BuildDependsOnly: false
+ Files: include/libomp/omp.h
+ DescPackaging: <<
+ BuildDependsOnly set to false since clang compiler always needs
+ access to omp.h at run-time.
+ <<
+<<
+SplitOff16: <<
+ Package: llvm-clang
+ Description: LLVM.org clang compilers
+ Depends: clang39 (= %v-%r)
+ Files: bin/llvm-clang bin/llvm-clang++
+<<
+SplitOff17: <<
  Package: %N-bundle
  Description: Bundle of LLVM/Clang compiler tools
  Type: bundle

I would also point out that David left the details of the openmp
support in the llvmXY packaging up to me since I was working with the
upstream developers to make sure the openmp support on darwin had no
regressions compared to linux.
 Please go ahead and commit the attached packaging files into the
10.9-libc++ tree so we can have the current version of gromacs and
gromacs-mpi. Thanks in advance.

   

Re: [Fink-devel] llvm-clang needed for gromacs-2016-1

[Jack Howarth]

Hanspeter,
   Actually, gromacs got a minor update to 2016.1 so attached are
the info files and patch to build gromacs-2016.1-1 and
gromacs-mpi-2016.1-1.
Jack
ps These are also posted on fink tracker as
https://sourceforge.net/p/fink/package-submissions/4840/

On Sun, Nov 13, 2016 at 1:42 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
> Hanspeter,
>   It has been a couple of weeks now since I emailed David Fang
> about the update to the llvm39 package to add the proposed llvm-clang,
> libomp-dev and libomp-shlibs split-offs required to cleanly support
> packages like the gromacs/gromacs-mpi-2016-1 updates which require a
> clang that supports -fopenmp without tethering the package to a
> specific llvmXY release. The proposed changes are quite sensible,
> straight-forward and safe...
>
> https://sourceforge.net/p/fink/package-submissions/4831/
> https://sourceforge.net/p/fink/package-submissions/4827/
>
> Index: llvm39.info
> ===
> RCS file: 
> /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/languages/llvm39.info,v
> retrieving revision 1.2
> diff -u -r1.2 llvm39.info
> --- llvm39.info 27 Oct 2016 04:01:28 - 1.2
> +++ llvm39.info 13 Nov 2016 18:26:26 -
> @@ -1,7 +1,7 @@
>  Info3: <<
>  Package: llvm39
>  Version: 3.9.0
> -Revision: 1
> +Revision: 2
>  Description: Modular and reusable compiler
>  License: BSD
>  Maintainer: David Fang <fang...@users.sourceforge.net>
> @@ -54,8 +54,8 @@
>
>  PatchFile: %n.patch
>  PatchFile-MD5: 6addcbd4c9fe449b3cd006eb48f5219b
> -#PatchFile2: %n-clang.patch
> -#PatchFile2-MD5: d2a2b4207c19b7f09f197ae9769a51d2
> +PatchFile2: %n-clang.patch
> +PatchFile2-MD5: 25a45c309e14611b278c30b782f0d7e5
>  #PatchFile3: %n-compiler-rt.patch
>  #PatchFile3-MD5: 60ed1415e15b1781f2d58c0db17aab78
>  #PatchFile4: %n-polly.patch
> @@ -65,7 +65,7 @@
>  #PatchFile6: %n-clang-omp.patch
>  #PatchFile6-MD5: 8067f4cc1f58030f7746521d58c776c2
>  PatchFile7: %n-clang-iomp5.patch
> -PatchFile7-MD5: 33f21b006473cbdd5feced616b05903b
> +PatchFile7-MD5: d5d9686fd0727c0e1cd953f585f4481d
>
>  PatchScript: <<
>   #!/bin/sh -ev
> @@ -108,7 +108,7 @@
>   pushd tools/clang
># Apply clang-omp merge before clang patch
>#$patch_filter %{PatchFile6} | patch -p1
> -  #$patch_filter %{PatchFile2} | patch -p1
> +  $patch_filter %{PatchFile2} | patch -p1
>$patch_filter %{PatchFile7} | patch -p1
>   popd
>   pushd tools/polly
> @@ -1078,15 +1078,6 @@
>   iprefix=%i/$stem
>   prefix=%p/$stem
>
> - # Pass path to libLTO.dylib with -lto_library using ld shell script
> - pushd $iprefix/bin
> - cat < ./ld
> -#!/bin/sh
> -exec /usr/bin/ld -lto_library %p/opt/llvm-3.9/lib/libLTO.dylib "\$@"
> -EOF
> - chmod ugo+x ./ld
> - popd
> -
>  # convenient clang symlinks
>   mkdir -p %i/bin
>   pushd %i/bin
> @@ -1112,6 +1103,26 @@
>   cp %b/../build/last/*-check.log testlogs/
>   cp %b/../build/last-libcxx/*-check.log testlogs/
>   popd
> +
> +# place omp.h in %p/include/libomp for common libomp-dev package
> + install -d %i/include/libomp
> + pushd %i/opt/llvm-$brv/lib/clang/%v/include
> + mv omp.h %i/include/libomp
> + popd
> +
> +# place libomp.dylib in libomp subdirectory for common libomp-shlibs package
> +# leave legacy copy in %p/opt/llvm-$brv/lib for clang39-shlibs
> + install -d %i/lib/libomp
> + pushd %i/opt/llvm-$brv/lib
> + cp libomp.dylib %i/lib/libomp
> + ln -s libomp.dylib %i/lib/libomp/libiomp5.dylib
> + ln -s libomp.dylib %i/lib/libomp/libgomp.dylib
> + popd
> + install_name_tool -id %p/lib/libomp/libomp.dylib %i/lib/libomp/libomp.dylib
> +
> +# create compiler symlinks for common llvm-clang split-off
> + ln -s clang-$brv %i/bin/llvm-clang
> + ln -s clang++-$brv %i/bin/llvm-clang++
>  <<
>  SplitOff: <<
>   Package: clang39-tools
> @@ -1178,7 +1189,9 @@
>   # odcctools,
>   # choosing to require opt-in instead of defaulting to libcxx1-dev
>   # libcxx1-dev,
> + libomp-dev (>= %v-%r),
>   clang39-shlibs (= %v-%r),
> + libomp-shlibs (>= %v-%r),
>   polly39-shlibs (= %v-%r)
>   <<
>   Description: Executables and runtime for clang compiler
> @@ -1186,7 +1199,6 @@
>   Files: <<
>   bin/clang*
>   opt/llvm-3.9/bin/clang*
> - opt/llvm-3.9/bin/ld
>   opt/llvm-3.9/lib/clang
>   <<
>   DescUsage: <<
> @@ -1313,6 +1325,37 @@
>   <<
>  <<
>  SplitOff14: <<
> + Package: libomp-shlibs
> + Description: Standard library for libomp
> + Files: <<
> + (%m != powerpc) lib//libomp/lib*omp*.dylib
> + <<
> + DocFiles: <<
> +

Re: [Fink-devel] reworked sandboxing support

[Jack Howarth]

In case anyone is interested in testing bootstraps of the revised
sandboxing patches applied to the current fink 0.41.0 sources, the
attached fink_sandboxing_v4.diff is identical to
fink_sandboxing_v3.diff with the following fink.sb.5.in manage
corrections...

--- fink_sandboxing_v3.diff 2016-11-06 19:55:56.0 -0500
+++ fink_sandboxing_v4.diff 2016-11-07 11:01:56.0 -0500
@@ -36,7 +36,7 @@
 +/opt/local
 diff -uNr fink-0.41.0.orig/fink.sb.5.in fink-0.41.0/fink.sb.5.in
 --- fink-0.41.0.orig/fink.sb.5.in 1969-12-31 19:00:00.0 -0500
-+++ fink-0.41.0/fink.sb.5.in 2016-11-06 18:40:34.0 -0500
 fink-0.41.0/fink.sb.5.in 2016-11-07 11:00:48.0 -0500
 @@ -0,0 +1,56 @@
 +.\" -*- nroff -*-
 +.Dd November 2011
@@ -53,17 +53,17 @@
 +.\"
 +.\"
 +.Sh DESCRIPTION
-+When
++The
 +.Xr fink 8
-+is initially installed it prompts you for whether you wish to enable the
-+building of packages within a protected sandbox which blacklists access to
-+those directories listed in
++packaging system defaults to compiling packages within a protected
sandbox that blacklists
++access to directories listed in
 +.Nm
-+by hand. In general, these options are meant for advanced users only.
++In general, modifying the list of blacklisted directories meant for
advanced users only.
 +.Pp
-+Your
++The default
 +.Nm
-+defaults to blacklisting the following directories
++blacklists the following directories
++
 +.Bl -tag -width flag -offset indent -compact
 +.It /usr/local
 +.It /opt/local

I would be curious to hear about success or failure reports. I have no
issues bootstrapping and using the sandboxing.
Just make sure to grab the sandbox friendly updates for gcc5/gcc6 and
llvm-gcc42 from

https://sourceforge.net/p/fink/package-submissions/4835/
https://sourceforge.net/p/fink/package-submissions/4834/


On Sun, Nov 6, 2016 at 10:34 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
> Daniel and Alexander,
> The attached patch reworks the previously proposed sandboxing
> support by...
>
> 1) Enabling the sandbox usage by default (except during fink bootstraps)
> 2) Adding a 'NoSandbox' field for the Info files which can be used to
> disable the sandbox on a per package basis.
> 3) Retaining the --build-in-sandbox/--no-build-in-sandbox fink flags
> which override the other settings.
>
> The --no-build-in-sandbox fink flag can be used to disable the sandbox
> in any fink build while the --build-in-sandbox fink flag can be used
> to override 'NoSandbox: true' in a particular info file.
>
> The attached fink_sandboxing_v3.diff, applied to stock fink-0.41.0,
> has been verified to bootstrap on 10.11 and exhibit the behaviors
> described above.
> Jack
diff -uNr fink-0.41.0.orig/MANIFEST fink-0.41.0/MANIFEST
--- fink-0.41.0.orig/MANIFEST   2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/MANIFEST2016-11-06 18:40:34.0 -0500
@@ -24,6 +24,8 @@
 fink.8.in
 fink.conf.5.in
 fink.csh
+fink.sb
+fink.sb.5.in
 fink.sh
 images/finkDoneFailed.png
 images/finkDonePassed.png
diff -uNr fink-0.41.0.orig/fink.8.in fink-0.41.0/fink.8.in
--- fink-0.41.0.orig/fink.8.in  2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/fink.8.in   2016-11-06 18:40:34.0 -0500
@@ -103,6 +103,14 @@
 .It Cm --no-build-as-nobody
 Force the the unpack, patch, compile, and install phases to be 
 performed as root.
+.It Cm --build-in-sandbox
+Execute packaging within a sandbox which blacklists read access to 
+those directories listed in
+.Pa @PREFIX@/etc/fink.sb.
+.It Cm --no-build-in-sandbox
+Don't execute within a sandbox, opposite of the
+.Cm --build-in-sandbox
+flag.
 .It Cm -m, --maintainer
 Perform actions useful to package maintainers: run validation on
 the .info file before building and on the .deb after building a
diff -uNr fink-0.41.0.orig/fink.sb fink-0.41.0/fink.sb
--- fink-0.41.0.orig/fink.sb1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb 2016-11-06 18:40:34.0 -0500
@@ -0,0 +1,2 @@
+/usr/local
+/opt/local
diff -uNr fink-0.41.0.orig/fink.sb.5.in fink-0.41.0/fink.sb.5.in
--- fink-0.41.0.orig/fink.sb.5.in   1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb.5.in2016-11-07 11:00:48.0 -0500
@@ -0,0 +1,56 @@
+.\" -*- nroff -*-
+.Dd November 2011
+.Dt FINK.SB 5
+.Sh NAME
+.Nm fink.sb
+.Nd sandboxing configuration file for
+.Xr fink 8
+.Sh SYNOPSIS
+@PREFIX@/etc/fink.sb
+.\"
+.\"
+.\" DESCRIPTION
+.\"
+.\"
+.Sh DESCRIPTION
+The
+.Xr fink 8
+packaging system defaults to compiling packages within a protected sandbox 
that blacklists 
+access to directories listed in
+.Nm
+In general, modifying the list of blacklisted directories meant for advanced 
users only.
+.Pp
+The default
+.Nm
+blacklists the following directories
+
+.Bl -tag -width flag -offset indent -compact
+.It /usr/local
+.It /opt/local
+.El
+.Pp
+The blacklisted directories appe

[Fink-devel] reworked sandboxing support

[Jack Howarth]

Daniel and Alexander,
The attached patch reworks the previously proposed sandboxing
support by...

1) Enabling the sandbox usage by default (except during fink bootstraps)
2) Adding a 'NoSandbox' field for the Info files which can be used to
disable the sandbox on a per package basis.
3) Retaining the --build-in-sandbox/--no-build-in-sandbox fink flags
which override the other settings.

The --no-build-in-sandbox fink flag can be used to disable the sandbox
in any fink build while the --build-in-sandbox fink flag can be used
to override 'NoSandbox: true' in a particular info file.

The attached fink_sandboxing_v3.diff, applied to stock fink-0.41.0,
has been verified to bootstrap on 10.11 and exhibit the behaviors
described above.
Jack
diff -uNr fink-0.41.0.orig/MANIFEST fink-0.41.0/MANIFEST
--- fink-0.41.0.orig/MANIFEST   2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/MANIFEST2016-11-06 18:40:34.0 -0500
@@ -24,6 +24,8 @@
 fink.8.in
 fink.conf.5.in
 fink.csh
+fink.sb
+fink.sb.5.in
 fink.sh
 images/finkDoneFailed.png
 images/finkDonePassed.png
diff -uNr fink-0.41.0.orig/fink.8.in fink-0.41.0/fink.8.in
--- fink-0.41.0.orig/fink.8.in  2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/fink.8.in   2016-11-06 18:40:34.0 -0500
@@ -103,6 +103,14 @@
 .It Cm --no-build-as-nobody
 Force the the unpack, patch, compile, and install phases to be 
 performed as root.
+.It Cm --build-in-sandbox
+Execute packaging within a sandbox which blacklists read access to 
+those directories listed in
+.Pa @PREFIX@/etc/fink.sb.
+.It Cm --no-build-in-sandbox
+Don't execute within a sandbox, opposite of the
+.Cm --build-in-sandbox
+flag.
 .It Cm -m, --maintainer
 Perform actions useful to package maintainers: run validation on
 the .info file before building and on the .deb after building a
diff -uNr fink-0.41.0.orig/fink.sb fink-0.41.0/fink.sb
--- fink-0.41.0.orig/fink.sb1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb 2016-11-06 18:40:34.0 -0500
@@ -0,0 +1,2 @@
+/usr/local
+/opt/local
diff -uNr fink-0.41.0.orig/fink.sb.5.in fink-0.41.0/fink.sb.5.in
--- fink-0.41.0.orig/fink.sb.5.in   1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb.5.in2016-11-06 18:40:34.0 -0500
@@ -0,0 +1,56 @@
+.\" -*- nroff -*-
+.Dd November 2011
+.Dt FINK.SB 5
+.Sh NAME
+.Nm fink.sb
+.Nd sandboxing configuration file for
+.Xr fink 8
+.Sh SYNOPSIS
+@PREFIX@/etc/fink.sb
+.\"
+.\"
+.\" DESCRIPTION
+.\"
+.\"
+.Sh DESCRIPTION
+When
+.Xr fink 8
+is initially installed it prompts you for whether you wish to enable the
+building of packages within a protected sandbox which blacklists access to
+those directories listed in
+.Nm
+by hand. In general, these options are meant for advanced users only.
+.Pp
+Your
+.Nm
+defaults to blacklisting the following directories
+.Bl -tag -width flag -offset indent -compact
+.It /usr/local
+.It /opt/local
+.El
+.Pp
+The blacklisted directories appear one per line in the file.
+.El
+.\"
+.\"
+.\" AUTHOR
+.\"
+.\"
+.Sh AUTHOR
+This manpage is maintained by the Fink Core Group 
.
+.\"
+.\"
+.\" ACKNOWLEDGEMENTS
+.\"
+.\"
+.Sh ACKNOWLEDGEMENTS
+.Nm fink
+is developed and maintained by The Fink Project (http://www.finkproject.org).
+.\"
+.\"
+.\" SEE ALSO
+.\"
+.\"
+.Sh "SEE ALSO"
+.Xr apt-get 8 ,
+.Xr fink 8
diff -uNr fink-0.41.0.orig/install.sh fink-0.41.0/install.sh
--- fink-0.41.0.orig/install.sh 2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/install.sh  2016-11-06 18:40:34.0 -0500
@@ -70,8 +70,10 @@
 
 install -c -p -m 755 postinstall.pl "$basepath/lib/fink/"
 install -c -p -m 644 shlibs.default "$basepath/etc/dpkg/"
+install -c -p -m 644 fink.sb "$basepath/etc/"
 install -c -p -m 644 fink.8 "$basepath/share/man/man8/"
 install -c -p -m 644 fink.conf.5 "$basepath/share/man/man5/"
+install -c -p -m 644 fink.sb.5 "$basepath/share/man/man5/"
 install -c -p -m 644 images/*.png "$basepath/share/fink/images/"
 
 # copy executables
diff -uNr fink-0.41.0.orig/perlmod/Fink/Bootstrap.pm 
fink-0.41.0/perlmod/Fink/Bootstrap.pm
--- fink-0.41.0.orig/perlmod/Fink/Bootstrap.pm  2016-09-20 14:16:24.0 
-0400
+++ fink-0.41.0/perlmod/Fink/Bootstrap.pm   2016-11-06 18:58:41.0 
-0500
@@ -500,6 +500,8 @@
Fink::Config::set_options( { 'use_binary' => -1 });
# bootstrap as root
Fink::Config::set_options( { 'build_as_nobody' => 0 });
+   # don't use sandbox during bootstrap
+   Fink::Config::set_options( { 'build_in_sandbox' => 0 });
 
# make sure we have the package descriptions
Fink::Package->require_packages();
@@ -581,6 +583,8 @@
 
# bootstrap as root
Fink::Config::set_options( { 'build_as_nobody' => 0 });
+   # don't use sandbox during bootstrap
+   Fink::Config::set_options( { 'build_in_sandbox' => 0 });
# use normal install routines, but do not use buildlocks
Fink::Config::set_options( { 

Re: [Fink-devel] completed sandboxing support for fink

[Jack Howarth]

Daniel and Alexander,
Just a heads up that I have found a proper solution to the FSF gcc
bootstrap and compiler failures under an Apple sandbox which denies
file access to /usr/local.

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00521.html

This approach avoids using --with-local--prefix while retains the
functionality of the compilers with regard to builds using /usr/local
outside of the sandbox.

I've updated the gcc5-5.4.0-3 and gcc6-6.2.0-3 sandbox friendly
packaging on tracker at
https://sourceforge.net/p/fink/package-submissions/4834/ to just use

 # make remove_duplicates() sandbox friendly
perl -pi.bak -e "s|if \(errno \!\= ENOENT\)|if \(\(errno \!\= ENOENT\)
\&\& \(errno \!\= EPERM\)\)|g" gcc/incpath.c

in the PatchScript.

I've also update the proposed lvm-gcc42-2336.11-8/18/28/38 on tracker
at https://sourceforge.net/p/fink/package-submissions/4835/ to just
use

# make remove_duplicates() sandbox friendly
perl -pi.bak -e "s|if \(errno \!\= ENOENT\)|if \(\(errno \!\= ENOENT\)
\&\& \(errno \!\= EPERM\)\)|g" %b/gcc/c-incpath.c

So the sandbox changes are pretty much ready to land. The only
remaining enhancement that I am still exploring (but isn't really a
blocker) is adding support for a BuildSandbox field to the fink Info
file syntax so the we can disable sandboxing at the info file level
rather than just with UseSandbox in %p/etc/fink.conf and
--build-in-sandbox/--no-build-in-sandbox.
   Jack


On Sat, Nov 5, 2016 at 2:33 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
> Daniel and Alexander,
>
>  An enhanced version of the previous patch which adds the installation
> of a fink.sb.5 man page.
>
>          Jack
>
> On Sat, Nov 5, 2016 at 8:34 AM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>>
>> Daniel and Alexander,
>>The pull request to add sandboxing support is now completed on fink
>> git against master at https://github.com/fink/fink/pull/135/files, but
>> upstream master seem to have unrelated bootstrap issues. However, the
>> attached fink_sandboxing.diff applies these same changes onto the current
>> fink-0.41.0 and bootstraps cleanly.
>>The current sandbox changes provides configuration of fink.conf to
>> add the desired state for the new UseSandbox setting in fink.conf. The
>> changes also provide runtime options of --build-in-sandbox and
>> --no-build-in-sandbox to override the UseSandbox setting in fink.conf.
>> The sandboxing of fink can easily be verified with 'ps -le | grep
>> sandbox-exec' during a fink build. Which will show...
>>
>>0  4232  4084 4106   0  31  0  2455672   3064 -  S+
>> 0 ttys0270:00.01 sudo -u fink-bld sandbox-exec -p (version 1) ^J(allow
>> default) ^J(deny file* ^J^I(subpath "/usr/local")^J^I(subpath
>> "/opt/local")^J)^J env CCACHE_DIR=/sw/var/ccache
>> CFLAGS=-D_DARWIN_NO_64_BIT_INODE -O2 -g -Wall CPPFLAGS=-I/sw/include
>> HOME=/tmp/fink-build-HOME.RCOdx6VWFB
>> INFOPATH=/sw/share/info:/sw/info:/usr/share/info LDFLAGS=-L/sw/lib
>> MACOSX_DEPLOYMENT_TARGET=10.11 MAKEFLAGS=-j8
>> MANPATH=/sw/share/man:/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:/sw/lib/perl5/5.18.2/man
>> PATH=/sw/var/lib/fink/path-prefix-libcxx:/sw/var/lib/fink/path-prefix-clang:/sw/bin:/sw/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/opt/X11/bin
>> PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin
>> PWD=/sw/src/fink.build/cvs-1.12.13-18 SHLVL=2 TERM=xterm-256color
>> __CFPREFERENCES_AVOID_DAEMON=1 sh -c /tmp/fink.5o7aZ
>>
>>
>> for 'UseSandbox: true"' in fink.conf or --build-in-sandbox on the fink
>> command line. The usage of  sandbox-exec won't be seen for either
>> 'UseSandbox: false"' in fink.conf or --no-build-in-sandbox on the fink
>> command line.
>>Jack
>
>

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] completed sandboxing support for fink

[Jack Howarth]

Daniel and Alexander,

 An enhanced version of the previous patch which adds the installation
of a fink.sb.5 man page.

 Jack

On Sat, Nov 5, 2016 at 8:34 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Daniel and Alexander,
>The pull request to add sandboxing support is now completed on fink
> git against master at https://github.com/fink/fink/pull/135/files, but
> upstream master seem to have unrelated bootstrap issues. However, the
> attached fink_sandboxing.diff applies these same changes onto the current
> fink-0.41.0 and bootstraps cleanly.
>The current sandbox changes provides configuration of fink.conf to
> add the desired state for the new UseSandbox setting in fink.conf. The
> changes also provide runtime options of --build-in-sandbox and
> --no-build-in-sandbox to override the UseSandbox setting in fink.conf.
> The sandboxing of fink can easily be verified with 'ps -le | grep
> sandbox-exec' during a fink build. Which will show...
>
>0  4232  4084 4106   0  31  0  2455672   3064 -  S+
>   0 ttys0270:00.01 sudo -u fink-bld sandbox-exec -p (version 1)
> ^J(allow default) ^J(deny file* ^J^I(subpath "/usr/local")^J^I(subpath
> "/opt/local")^J)^J env CCACHE_DIR=/sw/var/ccache 
> CFLAGS=-D_DARWIN_NO_64_BIT_INODE
> -O2 -g -Wall CPPFLAGS=-I/sw/include HOME=/tmp/fink-build-HOME.RCOdx6VWFB
> INFOPATH=/sw/share/info:/sw/info:/usr/share/info LDFLAGS=-L/sw/lib
> MACOSX_DEPLOYMENT_TARGET=10.11 MAKEFLAGS=-j8 MANPATH=/sw/share/man:/usr/
> share/man:/Applications/Xcode.app/Contents/Developer/usr/
> share/man:/Applications/Xcode.app/Contents/Developer/
> Toolchains/XcodeDefault.xctoolchain/usr/share/man:/sw/lib/perl5/5.18.2/man
> PATH=/sw/var/lib/fink/path-prefix-libcxx:/sw/var/lib/
> fink/path-prefix-clang:/sw/bin:/sw/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/opt/X11/bin
> PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin 
> PWD=/sw/src/fink.build/cvs-1.12.13-18
> SHLVL=2 TERM=xterm-256color __CFPREFERENCES_AVOID_DAEMON=1 sh -c
> /tmp/fink.5o7aZ
>
> for 'UseSandbox: true"' in fink.conf or --build-in-sandbox on the fink
> command line. The usage of  sandbox-exec won't be seen for either 'UseSandbox:
> false"' in fink.conf or --no-build-in-sandbox on the fink command line.
>Jack
>
diff -uNr fink-0.41.0.orig/MANIFEST fink-0.41.0/MANIFEST
--- fink-0.41.0.orig/MANIFEST   2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/MANIFEST2016-11-05 13:18:29.0 -0400
@@ -24,6 +24,8 @@
 fink.8.in
 fink.conf.5.in
 fink.csh
+fink.sb
+fink.sb.5.in
 fink.sh
 images/finkDoneFailed.png
 images/finkDonePassed.png
diff -uNr fink-0.41.0.orig/fink.8.in fink-0.41.0/fink.8.in
--- fink-0.41.0.orig/fink.8.in  2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/fink.8.in   2016-11-05 07:50:59.0 -0400
@@ -103,6 +103,19 @@
 .It Cm --no-build-as-nobody
 Force the the unpack, patch, compile, and install phases to be 
 performed as root.
+.It Cm --build-in-sandbox
+Execute packaging within a sandbox which blacklists read access to 
+those directories listed in
+.Pa @PREFIX@/etc/fink.sb.
+This is the default unless overridden by a setting of
+.Pa UseSandbox`: false
+in
+.Pa fink.conf
+configuration file.
+.It Cm --no-build-in-sandbox
+Don't execute within a sandbox, opposite of the
+.Cm --build-in-sandbox
+flag.
 .It Cm -m, --maintainer
 Perform actions useful to package maintainers: run validation on
 the .info file before building and on the .deb after building a
diff -uNr fink-0.41.0.orig/fink.conf.5.in fink-0.41.0/fink.conf.5.in
--- fink-0.41.0.orig/fink.conf.5.in 2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/fink.conf.5.in  2016-11-05 07:52:31.0 -0400
@@ -204,6 +204,12 @@
 uses the value of this option in MAKEFLAGS=-j. Running
 .Cm fink configure
 will tell you how many active CPUs/cores are available on your system.
+.It Cm UseSandbox: Ar boolean
+Causes
+.Nm fink
+to execute within a sandbox which blacklists file read access to
+those directories listed in 
+.Pa @PREFIX@/etc/fink.sb
 .It Cm AutoUid: Ar boolean
 This option specifies whether fink should dynamically allocate the UID and GID
 of its unprivileged fink-bld user if that user is absent.
diff -uNr fink-0.41.0.orig/fink.sb fink-0.41.0/fink.sb
--- fink-0.41.0.orig/fink.sb1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb 2016-11-05 07:52:55.0 -0400
@@ -0,0 +1,2 @@
+/usr/local
+/opt/local
diff -uNr fink-0.41.0.orig/fink.sb.5.in fink-0.41.0/fink.sb.5.in
--- fink-0.41.0.orig/fink.sb.5.in   1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb.5.in2016-11-05 13:19:50.0 -0400
@@ -0,0 +1,56 @@
+.\" -*- nroff -*-
+.Dd November 2011
+.Dt FINK.SB 5
+.Sh NAME
+.Nm fink.sb
+.Nd sandboxing configuration file for
+.Xr fink 8
+.Sh SYNOPSIS
+@PREFIX@/etc/fink.sb
+.\"
+.\"
+.\&q

[Fink-devel] completed sandboxing support for fink

[Jack Howarth]

Daniel and Alexander,
   The pull request to add sandboxing support is now completed on fink
git against master at https://github.com/fink/fink/pull/135/files, but
upstream master seem to have unrelated bootstrap issues. However, the
attached fink_sandboxing.diff applies these same changes onto the current
fink-0.41.0 and bootstraps cleanly.
   The current sandbox changes provides configuration of fink.conf to
add the desired state for the new UseSandbox setting in fink.conf. The
changes also provide runtime options of --build-in-sandbox and
--no-build-in-sandbox to override the UseSandbox setting in fink.conf.
The sandboxing of fink can easily be verified with 'ps -le | grep
sandbox-exec' during a fink build. Which will show...

   0  4232  4084 4106   0  31  0  2455672   3064 -  S+
0 ttys0270:00.01 sudo -u fink-bld sandbox-exec -p (version 1)
^J(allow default) ^J(deny file* ^J^I(subpath "/usr/local")^J^I(subpath
"/opt/local")^J)^J env CCACHE_DIR=/sw/var/ccache
CFLAGS=-D_DARWIN_NO_64_BIT_INODE -O2 -g -Wall CPPFLAGS=-I/sw/include
HOME=/tmp/fink-build-HOME.RCOdx6VWFB
INFOPATH=/sw/share/info:/sw/info:/usr/share/info LDFLAGS=-L/sw/lib
MACOSX_DEPLOYMENT_TARGET=10.11 MAKEFLAGS=-j8
MANPATH=/sw/share/man:/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:/sw/lib/perl5/5.18.2/man
PATH=/sw/var/lib/fink/path-prefix-libcxx:/sw/var/lib/fink/path-prefix-clang:/sw/bin:/sw/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/opt/X11/bin
PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin
PWD=/sw/src/fink.build/cvs-1.12.13-18 SHLVL=2 TERM=xterm-256color
__CFPREFERENCES_AVOID_DAEMON=1 sh -c /tmp/fink.5o7aZ

for 'UseSandbox: true"' in fink.conf or --build-in-sandbox on the fink
command line. The usage of  sandbox-exec won't be seen for either 'UseSandbox:
false"' in fink.conf or --no-build-in-sandbox on the fink command line.
   Jack
diff -uNr fink-0.41.0.orig/MANIFEST fink-0.41.0/MANIFEST
--- fink-0.41.0.orig/MANIFEST   2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/MANIFEST2016-11-05 07:49:06.0 -0400
@@ -24,6 +24,7 @@
 fink.8.in
 fink.conf.5.in
 fink.csh
+fink.sb
 fink.sh
 images/finkDoneFailed.png
 images/finkDonePassed.png
diff -uNr fink-0.41.0.orig/fink.8.in fink-0.41.0/fink.8.in
--- fink-0.41.0.orig/fink.8.in  2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/fink.8.in   2016-11-05 07:50:59.0 -0400
@@ -103,6 +103,19 @@
 .It Cm --no-build-as-nobody
 Force the the unpack, patch, compile, and install phases to be 
 performed as root.
+.It Cm --build-in-sandbox
+Execute packaging within a sandbox which blacklists read access to 
+those directories listed in
+.Pa @PREFIX@/etc/fink.sb.
+This is the default unless overridden by a setting of
+.Pa UseSandbox`: false
+in
+.Pa fink.conf
+configuration file.
+.It Cm --no-build-in-sandbox
+Don't execute within a sandbox, opposite of the
+.Cm --build-in-sandbox
+flag.
 .It Cm -m, --maintainer
 Perform actions useful to package maintainers: run validation on
 the .info file before building and on the .deb after building a
diff -uNr fink-0.41.0.orig/fink.conf.5.in fink-0.41.0/fink.conf.5.in
--- fink-0.41.0.orig/fink.conf.5.in 2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/fink.conf.5.in  2016-11-05 07:52:31.0 -0400
@@ -204,6 +204,12 @@
 uses the value of this option in MAKEFLAGS=-j. Running
 .Cm fink configure
 will tell you how many active CPUs/cores are available on your system.
+.It Cm UseSandbox: Ar boolean
+Causes
+.Nm fink
+to execute within a sandbox which blacklists file read access to
+those directories listed in 
+.Pa @PREFIX@/etc/fink.sb
 .It Cm AutoUid: Ar boolean
 This option specifies whether fink should dynamically allocate the UID and GID
 of its unprivileged fink-bld user if that user is absent.
diff -uNr fink-0.41.0.orig/fink.sb fink-0.41.0/fink.sb
--- fink-0.41.0.orig/fink.sb1969-12-31 19:00:00.0 -0500
+++ fink-0.41.0/fink.sb 2016-11-05 07:52:55.0 -0400
@@ -0,0 +1,2 @@
+/usr/local
+/opt/local
diff -uNr fink-0.41.0.orig/install.sh fink-0.41.0/install.sh
--- fink-0.41.0.orig/install.sh 2016-09-20 14:16:24.0 -0400
+++ fink-0.41.0/install.sh  2016-11-05 07:53:26.0 -0400
@@ -70,6 +70,7 @@
 
 install -c -p -m 755 postinstall.pl "$basepath/lib/fink/"
 install -c -p -m 644 shlibs.default "$basepath/etc/dpkg/"
+install -c -p -m 644 fink.sb "$basepath/etc/"
 install -c -p -m 644 fink.8 "$basepath/share/man/man8/"
 install -c -p -m 644 fink.conf.5 "$basepath/share/man/man5/"
 install -c -p -m 644 images/*.png "$basepath/share/fink/images/"
diff -uNr fink-0.41.0.orig/perlmod/Fink/Config.pm 
fink-0.41.0/perlmod/Fink/Config.pm
--- fink-0.41.0.orig/perlmod/Fink/Config.pm 2016-09-20 14:16:24.0 
-0400
+++ fink-0.41.0/perlmod/Fink/Config.pm  2016-11-05 07:54:40.0 -0400
@@ -219,6 +219,7 @@
map( { $_ => 0 } qw(dontask interactive 

[Fink-devel] patches to add sandboxing to fink

[Jack Howarth]

I have posted a pull request at https://github.com/fink/fink/pull/135
to add automatic sandboxing of fink builds. The patches emulate the
MacPorts approach of creating a sandboxing profile string and passing it to
'sandbox-exec -p'. The blacklisted directories are set from the list of
directories in the %p/etc/fink.sb control file. This allows users who want
to permit builds against /usr/local to simply remove it from the file or
users who want to blacklist Xquartz to simply append /opt/X11 to the file.
 I have verified that the sandboxing does prevent the gcc5 and gcc6
builds from accessing the headers in /usr/local. However, their Info files
do require the same workaround as MacPorts to allow the bootstrap to
succeed...

Index: gcc5.info

===

RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/languages/
gcc5.info,v

retrieving revision 1.9

diff -u -r1.9 gcc5.info

--- gcc5.info 8 Oct 2016 11:03:42 - 1.9

+++ gcc5.info 4 Nov 2016 00:25:58 -

@@ -71,6 +71,7 @@

  --with-isl=%p \

  --with-mpc=%p \

  --with-system-zlib \

+ --with-local-prefix=%p \

  --program-suffix=-fsf-5

 <<

 InfoTest: <<

Index: gcc6.info

===

RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/languages/
gcc6.info,v

retrieving revision 1.4

diff -u -r1.4 gcc6.info

--- gcc6.info 8 Oct 2016 20:26:47 - 1.4

+++ gcc6.info 4 Nov 2016 00:25:58 -

@@ -71,6 +71,7 @@

  --with-isl=%p \

  --with-mpc=%p \

  --with-system-zlib \

+ --with-local-prefix=%p \

  --program-suffix=-fsf-6

 <<

 InfoTest: <<

 I'll start building through the fink package set and look for any other
instances were we need to tweak due to the sandboxing.
   Jack
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

[Jack Howarth]

On Thu, Nov 3, 2016 at 7:56 PM, Hanspeter Niederstrasser
 wrote:
>
> On 11/2/16 6:48 PM, Alexander Hansen wrote:
> > We had thought that libXt wasn’t actually linked in the X11 tree, but this 
> > appears not to be so.
> >
> > It’s linked by:
> > /opt/X11/lib/libXaw6.6.dylib
> > /opt/X11/lib/libXaw7.7.dylib:
> > /opt/X11/lib/libXaw8.8.dylib:
> > /opt/X11/lib/libXaw3d.8.dylib:
> > (these may not matter since we’ve got libxaw3dxft2)
> > /opt/X11/lib/libxkbui.1.dylib
> > /opt/X11/lib/libXmu.6.dylib
> >
> > The last one appears to be what is causing runtime failures with xemacs, 
> > since xemacs links to /opt/X11/lib/libXmu.6.dylib and to 
> > /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib 
> > (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from 
> > libxt-shlibs.
> >
> > Unfortunately, the whole rationale for having our own libxt (not so much 
> > for libxt-flat) was to try to provide a consistent libXt so that people 
> > wouldn’t have things break when updating from Xquartz 2.7.8 to later 
> > versions where libXt has been mucked with.
> >
> > Here are some options:
> >
> > 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
>
> I've been keeping an X11 set of packages mostly up to date:
> http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11 and
> x11-system directories.
>
> The libraries are current. xorg-server is not current and I haven't used
> it in probably 3 years (and I was running 10.7 at the time). Although it
> ran, there were several things that still needed patching (xinit I
> believe was looking in wrong paths). Also, IIRC, StartupItems behavior
> has changed since then and would probably need to be fixed in these
> packages. Also, there currently is no xorg-libxt-flat package in my set.
>
> I'm agnostic on rolling our own versus forcing an update to 2.7.11. The
> latter is less work, but we are at the mercy of another fix from upstream.
>
> Hanspeter


Hanspeter,
  FYI, I have posted patches for fink to support sandboxing at
https://github.com/fink/fink/pull/135 which will allow you easily
blacklist /opt/X11. The patches use a %p/etc/fink.sb file containing a
simple list of directories to be blacklisted.
 Jack

>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

[Jack Howarth]

Daniel,
 I am seeing...

$ xemacs
Error: Couldn't find per display information

for

ii  xemacs 21.4.22-8  Highly customizable text editor
ii  libxaw3dxft1.6.2-6Athena widget set with 3D look
ii  libxaw3dxft-sh 1.6.2-6Athena widget set with 3D look
ii  libxt  1.1.5-2X toolkit library
ii  libxt-flat-shl 1.1.5-2X toolkit library
ii  libxt-shlibs   1.1.5-2X toolkit library

under Xquartz 2.7.11 despite the back port the Debian fix for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327655.
The only thing that solves the issue here on 10.11 is to link both
libxaw3dxft and xemacs against the libXt from Xquartz.
  Jack

On Wed, Nov 2, 2016 at 7:48 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

> We had thought that libXt wasn’t actually linked in the X11 tree, but this
> appears not to be so.
>
> It’s linked by:
> /opt/X11/lib/libXaw6.6.dylib
> /opt/X11/lib/libXaw7.7.dylib:
> /opt/X11/lib/libXaw8.8.dylib:
> /opt/X11/lib/libXaw3d.8.dylib:
> (these may not matter since we’ve got libxaw3dxft2)
> /opt/X11/lib/libxkbui.1.dylib
> /opt/X11/lib/libXmu.6.dylib
>
> The last one appears to be what is causing runtime failures with xemacs,
> since xemacs links to /opt/X11/lib/libXmu.6.dylib and to
> /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib
> (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from
> libxt-shlibs.
>
> Unfortunately, the whole rationale for having our own libxt (not so much
> for libxt-flat) was to try to provide a consistent libXt so that people
> wouldn’t have things break when updating from Xquartz 2.7.8 to later
> versions where libXt has been mucked with.
>
> Here are some options:
>
> 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
> 2)  Ditch libxt, and force people to install Xquartz-2.7.11.  Right now
> we’d have to use the “system-pkgconfig-xorg-server” virtual package to do
> this.  In principle we could adjust system-xfree86* to get the aggregate
> Xquartz release version instead of the “2:7.2” that we’ve been using for
> ages, but I don’t know if that gets stored anywhere but the package
> receipt, and that’s somewhat fragile to rely on.
>
> We’d want to adjust the fink-package-precedence script appropriately for
> whichever option we pick.
>
> #2 seems like the least work in the short term, but I know that some folks
> in the community don’t like it when we force dependencies on particular
> versions of non-Fink tools (e.g. the Xcode CL tools).
> #1 would rely on some kind soul being willing/able to maintain a Fink
> Xquartz, and we’d have to modify our existing X11-using packages to use
> only a Fink Xquartz.
>
> Though I’m leaning towards the following options:
>
> 3)  Stop bothering with X11 packages
> 4)  Give the hell up
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] llvm39-3.9.0-2 to add common llvm-clang, libomp-dev and libomp-shlibs split-offs

[Jack Howarth]

David and Hanspeter,
   I've updated the packaging on
https://sourceforge.net/p/fink/package-submissions/4831/ for llvm39-3.9.0-2
to eliminate the need for a symlink to omp.h in
%p/opt/llvm-$brv/lib/clang/%v/include
by adopting the MacPorts solution of patching cfe/lib/Driver/Tools.cpp to
change...

@@ -5031,6 +5037,8 @@
 case OMPRT_OMP:
 case OMPRT_IOMP5:
   // Clang can generate useful OpenMP code for these two runtime
libraries.
+  // Automatically find omp.h from libomp-dev
+  CmdArgs.push_back("-I@FINK_PREFIX@/include/libomp");
   CmdArgs.push_back("-fopenmp");

   // If no option regarding the use of TLS in OpenMP codegeneration is

The packaging is now complete.
  Jack

On Tue, Nov 1, 2016 at 2:48 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> David and Hanspeter,
>The deprecation of Boost support, in favor of OpenMP, in the
> gromacs 2016 release motivated me to enhance the llvm39 and future llvmXY
> packaging so that fink package maintainers can use the LLVM.org clang
> compilers for OpenMP support in a more transparent manner. The proposed
> changes for llvm39-3.9.0-2 cover the following...
>
> 1) Back ported the upstream changes to clang which cause the compiler
> unconditionally emit -lto_library to assist the linker in locating the
> correct libLTO.dylib for -flto. This eliminates the need for the previous
> local ld shell script hack. The new changes also allow clang to find the
> correct location even when the compiler is invoked through a symlink.
>
> 2) Copy libomp.dylib as well as the libgomp.dylib and libiomp5.dylib
> symlinks to %p/lib/libomp for a new common libomp-shlibs split-off package.
> Note that libomp shared library is an odd duck in that it exists without an
> explicit so version by design so there is no libomp.dylib for the new
> common libomp-dev split-off. Each clangXY package will run against the
> latest libomp-dev and libomp-shlibs just as it does with the common
> libcxx1-dev and libcxx1-shlibs packages.
>
> 3) Since the initial llvm39-3.9.0-1 release still had libomp.dylib located
> at %p/opt/llvm-$brv/lib, a copy is retained there for legacy binaries. This
> legacy copy will be dropped in the llvm40 packaging as that will never have
> libomp.dylib in %p/opt/llvm-$brv/lib.
>
> 4) Move the omp.h header into a new common libomp-dev split-off package at
> %p/include/libomp with the existing copy in the clang39 package
> at %p/opt/llvm-$brv/lib/clang/%v/include replaced by a symlink pointing
> at the common copy from libomp-dev at %p/include/libomp/omp.h. The new
> libomp-dev package is BuildDependsOnly: false as it has to remain present
> for multiple clangXY packages.
>
> 5) Add a new common llvm-clang split-off package containing symlinks to
> the clang compilers as llvm-clang and llvm-clang++.
>
> This packaging is posted on fink tracker at https://sourceforge.net/p/
> fink/package-submissions/4831/ and its use demonstrated for the new
> gromacs 2016 release at https://sourceforge.net/p/
> fink/package-submissions/4827/.
>
> This redesign of the llvm39 and future packages means that all any
> maintainer who wants to use OpenMP has to add is...
>
> BuildDepends: llvm-clang, libomp-dev
> Depends: libomp-shlibs
> SetCC: llvm-clang
> SetCXX: llvm-clang++
>
> which will decouple the builds from any specific release of llvmXY as long
> as it provides llvm-clang.
>   Jack
> ps David, at some point we may want to add a cctools package back to fink
> built like MacPorts against the latest llvm.org release. The -flto option
> requires an ar and ranlib compiled against the newest llvm release in order
> to create library archives as previously noted in the DescUsage of the
>  clang39 split-off...
>
> To use LTO, make sure builds set AR=%p/opt/llvm-3.9/bin/llvm-ar
> and RANLIB=%p/opt/llvm-3.9/bin/llvm-ranlib.
>
>
> pps I really doubt we will ever see Apple add libomp to Xcode as there is
> no marketing reason to do it as the OpenMP parallel programing standard
> competes with Blocks.
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] llvm39-3.9.0-2 to add common llvm-clang, libomp-dev and libomp-shlibs split-offs

[Jack Howarth]

David and Hanspeter,
   The deprecation of Boost support, in favor of OpenMP, in the gromacs
2016 release motivated me to enhance the llvm39 and future llvmXY packaging
so that fink package maintainers can use the LLVM.org clang compilers for
OpenMP support in a more transparent manner. The proposed changes for
llvm39-3.9.0-2 cover the following...

1) Back ported the upstream changes to clang which cause the compiler
unconditionally emit -lto_library to assist the linker in locating the
correct libLTO.dylib for -flto. This eliminates the need for the previous
local ld shell script hack. The new changes also allow clang to find the
correct location even when the compiler is invoked through a symlink.

2) Copy libomp.dylib as well as the libgomp.dylib and libiomp5.dylib
symlinks to %p/lib/libomp for a new common libomp-shlibs split-off package.
Note that libomp shared library is an odd duck in that it exists without an
explicit so version by design so there is no libomp.dylib for the new
common libomp-dev split-off. Each clangXY package will run against the
latest libomp-dev and libomp-shlibs just as it does with the common
libcxx1-dev and libcxx1-shlibs packages.

3) Since the initial llvm39-3.9.0-1 release still had libomp.dylib located
at %p/opt/llvm-$brv/lib, a copy is retained there for legacy binaries. This
legacy copy will be dropped in the llvm40 packaging as that will never have
libomp.dylib in %p/opt/llvm-$brv/lib.

4) Move the omp.h header into a new common libomp-dev split-off package at
%p/include/libomp with the existing copy in the clang39 package
at %p/opt/llvm-$brv/lib/clang/%v/include replaced by a symlink pointing at
the common copy from libomp-dev at %p/include/libomp/omp.h. The new
libomp-dev package is BuildDependsOnly: false as it has to remain present
for multiple clangXY packages.

5) Add a new common llvm-clang split-off package containing symlinks to the
clang compilers as llvm-clang and llvm-clang++.

This packaging is posted on fink tracker at
https://sourceforge.net/p/fink/package-submissions/4831/ and its use
demonstrated for the new gromacs 2016 release at
https://sourceforge.net/p/fink/package-submissions/4827/.

This redesign of the llvm39 and future packages means that all any
maintainer who wants to use OpenMP has to add is...

BuildDepends: llvm-clang, libomp-dev
Depends: libomp-shlibs
SetCC: llvm-clang
SetCXX: llvm-clang++

which will decouple the builds from any specific release of llvmXY as long
as it provides llvm-clang.
  Jack
ps David, at some point we may want to add a cctools package back to fink
built like MacPorts against the latest llvm.org release. The -flto option
requires an ar and ranlib compiled against the newest llvm release in order
to create library archives as previously noted in the DescUsage of the
 clang39 split-off...

To use LTO, make sure builds set AR=%p/opt/llvm-3.9/bin/llvm-ar
and RANLIB=%p/opt/llvm-3.9/bin/llvm-ranlib.


pps I really doubt we will ever see Apple add libomp to Xcode as there is
no marketing reason to do it as the OpenMP parallel programing standard
competes with Blocks.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fink packages dependent on motif officially broken

[Jack Howarth]

On Mon, Oct 24, 2016 at 11:06 AM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> On Oct 24, 2016, at 05:59, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
>
>
> On Sun, Oct 23, 2016 at 8:38 PM, Kevin Horton <khorto...@rogers.com>
> wrote:
>
>> Jack,
>>
>> Thanks for all your work.  I'm finally back home today after most of the
>> last two months on the road, and had time to test tracker item 4779, for
>> xephem.
>>
>> I've tested this with fink -m on macOS 10.12, and ran it with XQuartz
>> 2.7.9 and 2.7.10, with no issues.  I tried to commit it, but I'm getting
>> "cvs [server aborted]: "commit" requires write access to the repository”.
>> I’ve run out of time to troubleshoot tonight, tomorrow is crazy all day,
>> and I might be on the road again starting Tuesday.
>>
>> I'd appreciate it if someone with working commit privledges could commit
>> the changes in this tracker item.
>>
>
> Unfortunately all of the proposed fixed packaging will have to be revised.
> The fink core developers want to go with the approach of entirely replacing
> the libXt from Xquartz with their own libxt and libxt-flat BuildDependOnly
> packages that install in %p. This will require all packages that link libXt
> to either BuildDepends/Depends on libxt/libxt-shlibs or
> libxt-flat/libxt-flat-shlibs.
>   Jack
> ps I have serious reservations about this approach as it potentially will
> make builds of packages that aren't updated properly non-deterministic in
> that the libXt used for linkage could either be from libxt or libxt-flat
> depending upon what happens to be installed at the time of the build.
>
>
> How?  If libxt and libxt-flat are mutually conflicting BuildDepends, as
> they should be, then only one form _can_ be installed at the time of the
> build.
>

My point is, unless we strictly enforce the usage of BuildDepends on libxt
for non-motif x11 packages, we run the risk of accidental non-deterministic
builds. We have a hard enough time getting developers to bother to run
'fink -m' on their packages, never mind asking them to manually search for
linkages of binaries on libXt in order to determine if the explicit libxt
BuildDepends is required in addition to x11-dev.


>
> The possibility of picking up libXt from Xquartz exists of course, but we
> can handle that the same way as we handle the possibility of builds picking
> up libping, freetype, … from Xquartz.
>
> Also requiring all of the developers to find the libXt linkages in
> binaries on their on, without a reminder from 'fink validate', seems like a
> heavy lift.
>
>
>
> Are there that many, really?
>
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fink packages dependent on motif officially broken

[Jack Howarth]

On Sun, Oct 23, 2016 at 8:38 PM, Kevin Horton <khorto...@rogers.com> wrote:

> Jack,
>
> Thanks for all your work.  I'm finally back home today after most of the
> last two months on the road, and had time to test tracker item 4779, for
> xephem.
>
> I've tested this with fink -m on macOS 10.12, and ran it with XQuartz
> 2.7.9 and 2.7.10, with no issues.  I tried to commit it, but I'm getting
> "cvs [server aborted]: "commit" requires write access to the repository”.
> I’ve run out of time to troubleshoot tonight, tomorrow is crazy all day,
> and I might be on the road again starting Tuesday.
>
> I'd appreciate it if someone with working commit privledges could commit
> the changes in this tracker item.
>

Unfortunately all of the proposed fixed packaging will have to be revised.
The fink core developers want to go with the approach of entirely replacing
the libXt from Xquartz with their own libxt and libxt-flat BuildDependOnly
packages that install in %p. This will require all packages that link libXt
to either BuildDepends/Depends on libxt/libxt-shlibs or
libxt-flat/libxt-flat-shlibs.
  Jack
ps I have serious reservations about this approach as it potentially will
make builds of packages that aren't updated properly non-deterministic in
that the libXt used for linkage could either be from libxt or libxt-flat
depending upon what happens to be installed at the time of the build. Also
requiring all of the developers to find the libXt linkages in binaries on
their on, without a reminder from 'fink validate', seems like a heavy lift.


>
> https://sourceforge.net/p/fink/package-submissions/4779/
>
> Thanks.
>
> Kevin Horton - xephem package maintainer
>
>
> On Oct 22, 2016, at 12:39 , Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
> FYI, the Xquartz 2.7.10 release is now out so all of the fink packages
> that are dependent on motif are now broken so it is time to start pushing
> the fixes on tracker.
>
> https://sourceforge.net/p/fink/package-submissions/4779/
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org <http://slashdot.org/>!
> http://sdm.link/slashdot___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] proposed libxt and libxt-flat issues

[Jack Howarth]

On Sun, Oct 23, 2016 at 2:20 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Daniel,
>  The proposed libxt/libxt-flat packaging in your experimental, which
> places both in %p rather than buried subdirectories, would seem to require
> either...
>
> every single package building against Xquartz in fink have a BuildDepends
> on libxt and a Depends on libxt-shlibs added (which is a real pain)
>
> or
>
> fink be enhanced to interpret the a BuildDepends on x11-dev as implying
> both x11-dev and libxt and to interpret a Depends on x11-shlibs as implying
> both a x11-shlibs and libxt-shlibs
>
> The second approach, to automate the process, will require that libxt and
> libxt-flat be allowed to co-exist by burying the devel files of libxt-flat.
> The motif packages would then just prefix the path to this buried
> libxt-flat directory (similar to what the currently proposed packaging on
> tracker does).
>Jack
>

Alexander noted on fink irc that we don't want BuildDependsOnly packages to
co-exist. However, if the libxt-flat package used buried directories for
its development files, there would be no reason for it to remain as
BuildDependsOnly: true.

In the absence of automating the addition of libxt to the BuildDepends and
libxt-shlibs to the Depends for x11 packages, the builds x11 packages will
become non-determininsitc depending on whether the user happened to left
libxt or libxt-flat installed.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] proposed libxt and libxt-flat issues

[Jack Howarth]

Daniel,
 The proposed libxt/libxt-flat packaging in your experimental, which
places both in %p rather than buried subdirectories, would seem to require
either...

every single package building against Xquartz in fink have a BuildDepends
on libxt and a Depends on libxt-shlibs added (which is a real pain)

or

fink be enhanced to interpret the a BuildDepends on x11-dev as implying
both x11-dev and libxt and to interpret a Depends on x11-shlibs as implying
both a x11-shlibs and libxt-shlibs

The second approach, to automate the process, will require that libxt and
libxt-flat be allowed to co-exist by burying the devel files of libxt-flat.
The motif packages would then just prefix the path to this buried
libxt-flat directory (similar to what the currently proposed packaging on
tracker does).
   Jack
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] fink packages dependent on motif officially broken

[Jack Howarth]

FYI, the Xquartz 2.7.10 release is now out so all of the fink packages that
are dependent on motif are now broken so it is time to start pushing the
fixes on tracker.

https://sourceforge.net/p/fink/package-submissions/4771/
https://sourceforge.net/p/fink/package-submissions/4772/
https://sourceforge.net/p/fink/package-submissions/4773/
https://sourceforge.net/p/fink/package-submissions/4774/
https://sourceforge.net/p/fink/package-submissions/4775/
https://sourceforge.net/p/fink/package-submissions/4776/
https://sourceforge.net/p/fink/package-submissions/4777/
https://sourceforge.net/p/fink/package-submissions/4778/
https://sourceforge.net/p/fink/package-submissions/4779/
https://sourceforge.net/p/fink/package-submissions/4780/
https://sourceforge.net/p/fink/package-submissions/4781/
https://sourceforge.net/p/fink/package-submissions/4782/
https://sourceforge.net/p/fink/package-submissions/4783/
https://sourceforge.net/p/fink/package-submissions/4784/
https://sourceforge.net/p/fink/package-submissions/4785/
https://sourceforge.net/p/fink/package-submissions/4786/
https://sourceforge.net/p/fink/package-submissions/4787/
https://sourceforge.net/p/fink/package-submissions/4788/
https://sourceforge.net/p/fink/package-submissions/4789/
https://sourceforge.net/p/fink/package-submissions/4790/
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Use of uninitialized value $abs in string

[Jack Howarth]

Daniel,
 I am seeing a build failure for libnetsnmp30-shlibs-5.7.2-3 of

./snmplib/transports/.libs/snmpUnixDomain.d
Use of uninitialized value $abs in string ne at
/sw/bin/fink-package-precedence line 164.
Use of uninitialized value $abs in exists at
/sw/bin/fink-package-precedence line 167.
Use of uninitialized value $abs in hash element at
/sw/bin/fink-package-precedence line 167.
fileparse(): need a valid pathname at /sw/bin/fink-package-precedence line
169.
### execution of /tmp/fink.vHV7Q failed, exit code 255
### execution of /tmp/fink.BZlns failed, exit code 255
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-libnetsnmp30-shlibs-5.7.2-3

with fink-package-precedence-0.30-1 on 10.11.
  Jack
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ncurses 6.0 packages for fink base

[Jack Howarth]

On Fri, Oct 7, 2016 at 8:06 AM, Daniel Johnson <daniel.johnso...@gmail.com>
wrote:

>
> > On Oct 7, 2016, at 6:55 AM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Oct 6, 2016 at 5:40 PM, Daniel Johnson <
> daniel.johnso...@gmail.com> wrote:
> >
> > > On Oct 6, 2016, at 1:32 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> > >
> > > I noticed that Fedora is building both --with-abi-version=5 and
> --with-abi-version=6 in their ncurses 6.0 package...
> > >
> > > http://pkgs.fedoraproject.org/cgit/rpms/ncurses.git/tree/ncurses.spec
> > >
> > > but that the installed headers will only be for the
> --with-abi-version=6 build. Thus the legacy --with-abi-version=5 shlibs are
> only there for back-ward compatibility and not new builds.
> > >
> >
> > Note I forgot to update the version in libncursesw5.info and
> ncurses.info to match and have now done so.
> >
> > The ncurses5 packages build with --with-abi-version=5 to be backward
> compatible while using the 6.0 source. The ncurses6 packages only use
> --with-abi-version=6. We’re going to need both for some time until
> everything can get updated. This way they can coexist.
> >
> >
> > I think you are still missing one step to fully mimic the Fedora
> packaging approach. You need to convert your current ncurses.info into a
> libncurses5.info which no longer contains the ncurses split-off and move
> that one into libncurses6 instead (which could be refactored back into a
> ncurses.info)
>
> I didn’t do that because ncurses5 is Essential. I wasn’t sure what the
> interactions would be. That’s why I wanted others to weigh in.
>

I would assume that ncurse6 will also need to be Essential as the logical
move is to start migrating packages to it and readline7 at the same time.


>
> Daniel
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ncurses 6.0 packages for fink base

[Jack Howarth]

On Thu, Oct 6, 2016 at 5:40 PM, Daniel Johnson <daniel.johnso...@gmail.com>
wrote:

>
> > On Oct 6, 2016, at 1:32 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> >
> > I noticed that Fedora is building both --with-abi-version=5 and
> --with-abi-version=6 in their ncurses 6.0 package...
> >
> > http://pkgs.fedoraproject.org/cgit/rpms/ncurses.git/tree/ncurses.spec
> >
> > but that the installed headers will only be for the --with-abi-version=6
> build. Thus the legacy --with-abi-version=5 shlibs are only there for
> back-ward compatibility and not new builds.
> >
>
> Note I forgot to update the version in libncursesw5.info and ncurses.info
> to match and have now done so.
>
> The ncurses5 packages build with --with-abi-version=5 to be backward
> compatible while using the 6.0 source. The ncurses6 packages only use
> --with-abi-version=6. We’re going to need both for some time until
> everything can get updated. This way they can coexist.
>
>
I think you are still missing one step to fully mimic the Fedora packaging
approach. You need to convert your current ncurses.info into a
libncurses5.info which no longer contains the ncurses split-off and move
that one into libncurses6 instead (which could be refactored back into a
ncurses.info)

Daniel
>
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ncurses 6.0 packages for fink base

[Jack Howarth]

I noticed that Fedora is building both --with-abi-version=5 and
--with-abi-version=6 in their ncurses 6.0 package...

http://pkgs.fedoraproject.org/cgit/rpms/ncurses.git/tree/ncurses.spec

but that the installed headers will only be for the --with-abi-version=6
build. Thus the legacy --with-abi-version=5 shlibs are only there for
back-ward compatibility and not new builds.

On Thu, Oct 6, 2016 at 1:21 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Thu, Oct 6, 2016 at 11:41 AM, Daniel Johnson <
> daniel.johnso...@gmail.com> wrote:
>
>>
>> > On Oct 6, 2016, at 10:19 AM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> >
>> > Chris,
>> >  I've posted packaging for libncursesw6-6.0-1 and ncurses6-6.0-1 to
>> fink tracking...
>> >
>> > https://sourceforge.net/p/fink/package-submissions/4803/
>> >
>> > as well as an update to libncursesw5-5.9-20110507-2 to make it aware of
>> libncursesw6.
>> >
>> > https://sourceforge.net/p/fink/package-submissions/4804/
>> >
>> > The only part that I am concerned about is that handling of the
>> overlapping files between the ncurses and ncurses6 packages as both are
>> marked as Essential. So far, simply appending ncurses to the Replaces field
>> in the ncurses6 packages seems to be sufficient to handle that issue.
>> >Jack
>>
>> There’s no reason to have a libncursesw6 package. Just have one
>> libncurses6 package that always uses wide chars and have it C/R with
>> regular ncurses. I posted packages to my experimental cvs dir quite a while
>> ago and asked for opinions but nothing came of it. There’s also newer
>> versions available. Most recent version is http://invisible-mirror.net/ar
>> chives/ncurses/current/ncurses-6.0-20161001.tgz. Packages are at
>> http://fink.cvs.sourceforge.net/viewvc/fink/experimental/danielj/
>>
>>
> I replaced the proposed ncurses6.info with libncurses6-shlibs.info to
> allow for the common ncurses split-off (in case they decide to go with a
> separate libncursesw6 package and not use --with-abi-version=5).
> Jack
> ps The only only Distro that I see using --with-abi-version=5 is Debian
> but they appear to build completely with -with-abi-version=5 and never use
> -with-abi-version=6 at all.
>
> Daniel
>>
>>
>>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] apple-gdb and gdb vs 10.12"

[Jack Howarth]

  We should add an additional comment to the existing code-signing
instructions of the DescUsage section in the apple-gdb and gdb packages...

Apple has increased the security on Sierra so that the additional set of
executing...

$ csrutil enable --without debug

while rebooted under the Recovery Partition is required for the
code-signing to be honored under 10.12.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] pil-systempython27-1.1.7-7 build failure

[Jack Howarth]

Daniel,
 I am seeing the following build failure in pil-systempython27-1.1.7-7
on darwin15

cc -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common
-fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall
-Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall
-Wstrict-prototypes -DENABLE_DTRACE -pipe
-I/System/Library/Frameworks/Tcl.framework/Headers
-I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging
-I/sw/include/freetype2 -I/sw/include
-I/System/Library/Frameworks/Python.framework/Versions/2.7/include
-I/usr/include
-I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-c _imagingft.c -o build/temp.macosx-10.11-intel-2.7/_imagingft.o
_imagingft.c:73:10: fatal error: 'fterrors.h' file not found
#include 
 ^
1 error generated.

The following fix works here...

Index: pil-systempython.info
===
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/graphics/
pil-systempython.info,v
retrieving revision 1.3
diff -u -r1.3 pil-systempython.info
--- pil-systempython.info 6 Apr 2016 17:27:44 - 1.3
+++ pil-systempython.info 4 Oct 2016 15:00:37 -
@@ -21,7 +21,7 @@
 PatchFile-MD5: d4940dfb66a0168b61eb0c33dea352e5
 PatchScript: <<
   sed 's|@PREFIX@|%p|g' < %{PatchFile} | patch -p1
-  perl -pi -e 's|freetype/fterrors.h|fterrors.h|' _imagingft.c
+  perl -pi -e 's|freetype/fterrors.h|freetype2/freetype/fterrors.h|'
_imagingft.c
 <<
 CompileScript: <<
  ARCHFLAGS=" " /usr/bin/python%type_raw[python] setup.py build

   Jack
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] error: /Library/Developer/CommandLineTools/usr/bin/otool-classic: unknown char `-'

[Jack Howarth]

Daniel,
  The texinfo-6.3-103 packaging needs a versioned BuildDepends
on fink-package-precedence_0.30-1 to avoid the build failure...

Found use of headers from 3 fink packages:
libgettext8-dev
libiconv-dev
libncurses5
Scanning binaries for incorrect dyld linking...
error: /Library/Developer/CommandLineTools/usr/bin/otool-classic: unknown
char `-' in flag _0021---_002e--_002e-_003f-_0040.html

 Jack
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Xquartz 2.7.10-rc2 breakage

[Jack Howarth]

Xquartz is currently testing the upcoming 2.7.10 release which has the
following significant change

libXt

Both libXt.6.dylib and libXt.7.dylib are two-level-namespaced now
A flat_namespace version of libXt is available in
/opt/X11/lib/flat_namespace to help ease the transition (#96292)

Set DYLD_LIBRARY_PATH=/opt/X11/lib/flat_namespace when executing older
non-compliant software (eg: Motif-based applications)
Motif users are encouraged to file bugs against Motif to encourage them to
fix that library

 Upstream is attempting to deprecate out the libXt.7.dylib with a
symlink to libXt.6.dylib (as both are now linked as two-level namespace).
Unfortunately, they didn't think this one through as it breaks all binaries
linked against libXt under Xquartz 2.7.9 (as those expect the library to
have the 8.0.0 soversion from libXt.7.dylib instead of the 7.0.0 one from
libXt.6.dylib). Currently you have to rebuild any packages built under
Xquartz 2.7.9 which linked libXt after upgrading to Xquartz 2.7.10-rc2.

 I've alerted upstream of this issue

https://lists.macosforge.org/pipermail/xquartz-dev/2016-September/004008.html

and expect they will solve this by releasing an -rc3 with the symlink for
libXt.7.dylib replaced by the actual shared library as in 2.7.9. Note that
in 2.7.10, libXt.dyib points at libXt.6.dylib since its flat-namespace
linkage has been replaced with two-level namespace linkage for both.
Jack
ps Note that the flat-namespace libXt.6.dylib provided by Xquartz in 2.7.10
in /opt/X11/lib/flat_namespace can't be used for builds as the path in its
install name is intentionally set to /opt/X11/lib.

I've placed proposed libxt-flat-namespace-shlibs packaging on fink tracker
to provide the missing flat-namespace libXt.6.dylib for use in builds of
and against openmotif4. I've also placed updated packaging for those
packages that use openmotif4 on fink tracking which uses this new
libxt-flat-namespace-shlibs package.
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] xcode 8 fix for fink-buildenv-modules

[Jack Howarth]

On Sun, Sep 11, 2016 at 8:21 AM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> On Sep 11, 2016, at 03:13, Hanspeter Niederstrasser <
> f...@snaggledworks.com> wrote:
>
> On 9/9/16 11:47 AM, Jack Howarth wrote:
>
> Hanspeter,
>  The current fink-buildenv-modules package is not savvy to the SDK
> changes in Xcode8 and requires the following change...
>
> --- /sw/lib/fink-buildenv-modules/base.sh 2016-08-09 17:49:45.0
> -0400
> +++ /sw/lib/fink-buildenv-modules/base.sh.new 2016-09-09
> 12:40:57.0
> -0400
> @@ -47,9 +47,12 @@
>  if [ `dpkg --compare-versions $XCODE_VERSION lt 7` ]; then
>  export SDK_PATH=`xcodebuild -version -sdk macosx${OSX_MAJOR_VERSION} Path`
>  export SDK_VERSION=`xcodebuild -version -sdk macosx${OSX_MAJOR_VERSION}
> SDKVersion`
> - else
> + elif [ `dpkg --compare-versions $XCODE_VERSION lt 8` ]; then
>  export SDK_PATH=`xcodebuild -version -sdk macosx10.11 Path`
>  export SDK_VERSION=`xcodebuild -version -sdk macosx10.11 SDKVersion`
> + else
> + export SDK_PATH=`xcodebuild -version -sdk macosx10.12 Path`
> + export SDK_VERSION=`xcodebuild -version -sdk macosx10.12 SDKVersion`
>  fi
> fi
>
> to the fink-buildenv-modules/base.sh script so that SDK_PATH and
> SDK_VERSION are populated with the correct values for Xcode 8 on 10.11.
>   Jack
>
>
>
> Xcode 8 is only available for 10.11 and 10.12 (not for 10.10)?
>
> Hanspeter
>
>
>
> Correct.  The change for 10.10 above is because of the lack of a 10.10 SDK
> on Xcode 7.
>
>
And now that Apple has settled into a yearly OS release cycle, we can
expect this going forward as well.
The last Xcode supported on the previous OS release will always be missing
its own SDK in favor of the
one from the next OS release.


> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
> 
> --
>
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] xcode 8 fix for fink-buildenv-modules

[Jack Howarth]

Hanspeter,
  The current fink-buildenv-modules package is not savvy to the SDK
changes in Xcode8 and requires the following change...

--- /sw/lib/fink-buildenv-modules/base.sh 2016-08-09 17:49:45.0
-0400
+++ /sw/lib/fink-buildenv-modules/base.sh.new 2016-09-09 12:40:57.0
-0400
@@ -47,9 +47,12 @@
  if [ `dpkg --compare-versions $XCODE_VERSION lt 7` ]; then
  export SDK_PATH=`xcodebuild -version -sdk macosx${OSX_MAJOR_VERSION} Path`
  export SDK_VERSION=`xcodebuild -version -sdk macosx${OSX_MAJOR_VERSION}
SDKVersion`
- else
+ elif [ `dpkg --compare-versions $XCODE_VERSION lt 8` ]; then
  export SDK_PATH=`xcodebuild -version -sdk macosx10.11 Path`
  export SDK_VERSION=`xcodebuild -version -sdk macosx10.11 SDKVersion`
+ else
+ export SDK_PATH=`xcodebuild -version -sdk macosx10.12 Path`
+ export SDK_VERSION=`xcodebuild -version -sdk macosx10.12 SDKVersion`
  fi
 fi

to the fink-buildenv-modules/base.sh script so that SDK_PATH and
SDK_VERSION are populated with the correct values for Xcode 8 on 10.11.
   Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Xcode8 build breakage for qt5

[Jack Howarth]

Hanspeter,
Building through the qt5 dependencies for wireshark, only qt5-base
requires this fix. I also compared...

ls /Applications/Xcode.app/Contents/Developer/usr/bin/xc*

for Xcode 7.3 which shows...

xcdevice xcrun xcsbuildd xcsdeviced xcsgenerator xctest
xcodebuild xcsbridge xcscontrol xcsdiagnose xcssecurity

to Xcode 8 GM which only shows

xcdevice xcodebuild xcsbridge xcscontrol xcsdiagnose xcsgenerator
xcssecurity xctest

so xcrun has definitely been deprecated out of the app itself in favor to
the system copy in /usr/bin .
 Jack


On Fri, Sep 9, 2016 at 12:18 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Hanspeter,
> I seem to have stumbled across a behavioral change in xcrun for
> Xcode 8 on 10.10 which breaks the qt5-mac-qtbase-5.6.0-1 build.
>
> $ /usr/bin/xcrun -find xcrun
> xcrun: error: unable to find utility "xcrun", not a developer tool or in
> PATH
>
> fortunately this can be fixed with...
>
> diff -u -r1.7 qt5-qtbase.info
> --- qt5-qtbase.info 18 Apr 2016 14:30:16 - 1.7
> +++ qt5-qtbase.info 9 Sep 2016 16:02:37 -
> @@ -55,6 +55,7 @@
>  PatchScript: <<
>   #!/bin/sh -ev
>   . %p/sbin/fink-buildenv-helper.sh
> + perl -pi -e 's|find xcrun|find /usr/bin/xcrun|g' configure
> mkspecs/features/mac/default_pre.prf
>   unset X11_BASE_DIR
>   unset X11_INCLUDE_DIR
>   unset X11_LIBRARY_DIR
>
> since...
>
> $ /usr/bin/xcrun -find /usr/bin/xcrun
> /usr/bin/xcrun
>
> still works. I would note that I am using Xcode 8 GM with Xcode GM beta 6
> on 10.10 (since Apple has failed to post the GM for the CLI).
>
>   Jack
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] grep-2.25-1

[Jack Howarth]

Max,
Also note that we have at least one (if not more) CVE bug fix addressed
since the 2.20 release...

2015-02-01  Jim Meyering  <meyer...@fb.com>

maint: reference CVE-2015-1345 from NEWS
* NEWS: Mention the CVE that was addressed by v2.21-13-g83a95bd,
"grep -F: fix a heap buffer (read) overrun".

  Jack

On Tue, Aug 16, 2016 at 11:04 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Max,
>  I have uploaded packaging to update grep to the current 2.25 release
> onto fink tracking at...
>
> https://sourceforge.net/p/fink/package-submissions/4745/
>
> The only major change is adding a hunk to the patch for
> tests/pcre-jitstack to change the usage of 'base64 -d' to the more generic
> 'base64 --decode' which is understood by both the system base64 and the
> coreutils-default copy.
>   Jack
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] grep-2.25-1

[Jack Howarth]

Max,
 I have uploaded packaging to update grep to the current 2.25 release
onto fink tracking at...

https://sourceforge.net/p/fink/package-submissions/4745/

The only major change is adding a hunk to the patch for tests/pcre-jitstack
to change the usage of 'base64 -d' to the more generic 'base64 --decode'
which is understood by both the system base64 and the coreutils-default
copy.
  Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.2.1-2 to re-enable nls support

[Jack Howarth]

On Sun, Aug 14, 2016 at 11:48 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> On Sun, Aug 14, 2016 at 10:23 AM, Max Horn <m...@quendi.de> wrote:
>
>> Jack,
>>
>> > On 12 Aug 2016, at 20:44, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> >
>> > Max,
>> > It appears to be safe again to re-enable the default nls support in
>> the make 4.2.1 build as upstream have fixed the signaling issue
>> >
>> > http://savannah.gnu.org/bugs/index.php?46261#comment12
>>
>> That indicates that a change was made which *might* fix the issues that
>> troubled make.
>>
>> But has anybody actually verified that this really does fix the issue? I
>> am reluctant to disable the workaround until this is clear -- considering
>> that broken builds are much worse than missing nls support.
>>
>> Max,
>  Yes. I have been exhaustingly rebuilding all of the previously
> problematic packages like openmpi, libgettext8-shlibs and gcc5 with the
> newer make 4.2.1 having nls re-enabled on 8 cores. The problem with EINTR
> failures has indeed been fixed.
> Jack
>

Also confirmed stability of core 8 builds with nls-enabled make 4.2.1 for
the previously problematic builds of cmake, libcurl4, texlive-base and
r-base32.


>
>
>> Cheers,
>> Max
>
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.2.1-2 to re-enable nls support

[Jack Howarth]

On Sun, Aug 14, 2016 at 10:23 AM, Max Horn <m...@quendi.de> wrote:

> Jack,
>
> > On 12 Aug 2016, at 20:44, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> >
> > Max,
> > It appears to be safe again to re-enable the default nls support in
> the make 4.2.1 build as upstream have fixed the signaling issue
> >
> > http://savannah.gnu.org/bugs/index.php?46261#comment12
>
> That indicates that a change was made which *might* fix the issues that
> troubled make.
>
> But has anybody actually verified that this really does fix the issue? I
> am reluctant to disable the workaround until this is clear -- considering
> that broken builds are much worse than missing nls support.
>
> Max,
 Yes. I have been exhaustingly rebuilding all of the previously
problematic packages like openmpi, libgettext8-shlibs and gcc5 with the
newer make 4.2.1 having nls re-enabled on 8 cores. The problem with EINTR
failures has indeed been fixed.
Jack


> Cheers,
> Max
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] aclocal.m4 error compiling under 10.12

[Jack Howarth]

Note that the Xcode 8 Beta 4 release notes finally acknowledges this issue
under the "Known Issues in Xcode 8 beta 4 - Swift and Apple LLVM Compilers"
section...

Command Line Tools

• Currently the new LLVM-based otool(1) exits with a non-zero status on the
first error it encounters for the files on the command line, including
treating non-object files as errors. This differs from the previous
otool(1), available now as otool-classic(1), that will process all files on
the command line even if some have errors. otool-classic(1) will treat
non-object files as a warning instead of an error. (26828015)

The use of 'currently' does suggest that they intend to address this issue
before release of Xcode 8.

On Mon, Aug 8, 2016 at 8:26 AM, <isb...@verizon.net> wrote:

>  Thanks Daniel & Alexander,
>
>
> I tried the new version of fink-package-precedence but that didn't fix the
> problem. In the end I, used the tip from Jack Howarth to get past the otool
> errors:
>
>
> cd /Library/Developer/CommandLineTools/usr/bin; sudo ln -sf otool-classic
> otool
>
>
> Since I added this workaround, I've successfully built a large number of
> packages under 10.12. Occasionally I'll get an error of an unresolved
> dependence of package X by package Y.
> When that occurs, I modify the .info file for package X to add 10.12 to
> the explicit list of Distributions. For example, this came up with
> 'help2man-perl' and the change was:
>
>
> 8c8,9
> < (%type_pkg[systemperl] = 5182) 10.11
> ---
> > (%type_pkg[systemperl] = 5182) 10.11,
> > (%type_pkg[systemperl] = 5182) 10.12
>
>
> So to recap where I stand now, with residual problems only in a few
> specific packages:
>
>
> 1) say 'NO' to binary packages for now
> 2) patch the bootstrap modules to get Fink to build under 10.12
> 3) apply the otool workaround above
> 4) modify .info files as needed to add 10.12 as a valid distribution
>
>
> I'll keep pushing forward to determine which packages aren't building
> properly, but many have succeeded now (including gcc5) and it's going quite
> smoothly.
>
>
> Thanks for the good advice,
> John
>
> On 08/06/16, Daniel Macks<dma...@netspace.org> wrote:
>
> On Sat, 6 Aug 2016 11:56:46 -0700, Alexander Hansen
> <alexanderk.han...@gmail.com> wrote:
> > > On Aug 6, 2016, at 11:50, John Lillibridge <isb...@verizon.net> wrote:
> > > > I managed to get Fink to build via bootstrap under 10.12 beta
> > (now 3). But certain packages fail to compile with the following
> > types of errors when checking dependencies:
> > > > fink-package-precedence --no-headers .
> > > > Scanning binaries for incorrect dyld linking...
> > > >
> > /Applications/Xcode-beta.app/Contents/Developer/Toolchains/
> XcodeDefault.xctoolchain/usr/bin/objdump: 'aclocal.m4': The file was not
> recognized as a valid object
> > file.
> > > > fatal error:
> > /Applications/Xcode-beta.app/Contents/Developer/Toolchains/
> XcodeDefault.xctoolchain/usr/bin/otool: internal objdump command
> > failed
> > > > Error reading /usr/bin/otool -L: 256
> > > > I get the same type of error using the Xcode-8-beta app as well
> > as the Command Line Tools.
> > > > Any ideas how to work around this?
> >
> > Apple decided to change the behavior of otool for Xcode 8 (how nice
> > of them) and it now throws an error instead of silently ignoring
> > non-object files.
> >
> > As a workaround, change line 263 of /sw/bin/pathsetup.sh to my $otool
> > = '/usr/bin/otool-classic
> >
> > (I don’t have the Xcode 8 command-line tools deployed, so I’m not
> > 100% sure that otool-classic is accessible there, however.)
>
> I uploaded a new version of fink-package-precedence (0.19-1) that uses
> "otool-classic" if present (falling back to "otool" if not), which
> should resolve the problem. Please let me know--I don't have xcode8, so
> I'm just implementing what Alexander, and several others on IRC and
> other places, have reported.
>
> dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
> 
> --
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] xemacs-1:21.4.22-6

[Jack Howarth]

On Fri, Jul 1, 2016 at 1:48 AM, Giacomo Mauro D'Ariano <dari...@unipv.it>
wrote:

> It was just another independent Mac book. I just opened  XEmacs locally,
> as usual.
>
>
Actually that particular error does seem to be reported for both HomeBrew
and MacPorts for users on XQuartz 2.7.9...

https://bugs.freedesktop.org/show_bug.cgi?id=96416
http://apple.stackexchange.com/questions/240521/x11-applications-dont-open-after-xquartz-update-os-x-10-10-4

Have you tried

fink rebuild libxaw3dxft-shlibs
fink rebuild xemacs

on both machines? That should be sufficient to solve the problem (note that
'fink rebuild' will automatically reinstall the rebuilt packages).
   Jack



> Sent from my iPhone
>
> On 30 Jun 2016, at 20:54, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
>
>
> On Thu, Jun 30, 2016 at 2:17 PM, Alexander Hansen <
> alexanderk.han...@gmail.com> wrote:
>
>>
>> On Jun 30, 2016, at 11:15, Giacomo Mauro D'Ariano <dari...@unipv.it>
>> wrote:
>>
>> I tried on my second Mac: it doesn’t work!!
>>
>> You get the message:
>>
>> Couldn’t find per display information
>>
>>
> That error actually sounds like you are trying to run xemacs remotely from
> the second Mac but don't have X11 forwarding enabled. in
> /etc/ssh/sshd_config  on the remote machine's sshd.
>
>>
>>
>> You need to run all the three lines that you send me!!!
>>
>>
>> Thank you again!!
>>
>>
>> Giacomo Mauro D'Ariano
>> Professor of Theoretical Physics
>> Quantum Foundations
>> and Quantum Information
>>
>> Dipartimento di Fisica,
>> via Bassi 6, I-27100 Pavia, Italy
>>
>> email:dari...@unipv.it
>> tel:+39 <+39> 0382 987 484
>> fax:+39 0382 987 793
>> mobile:+39 347 0329998
>> skype: giacomo_mauro_dariano
>> AIM: dariano13
>>
>> WEBSITES:
>> www.qubit.it
>> www.quantummechanics.it
>> www.quantumoptics.it
>> www.meccanicaquantistica.it
>> www.otticaquantistica.it
>>
>>
>>
>> Thanks for the information!  Luckily these aren’t huge builds.
>>
>> —akh
>>
>>
>>
>> --
>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> List archive:
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel
>>
>>
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] xemacs-1:21.4.22-6

[Jack Howarth]

On Thu, Jun 30, 2016 at 2:17 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> On Jun 30, 2016, at 11:15, Giacomo Mauro D'Ariano 
> wrote:
>
> I tried on my second Mac: it doesn’t work!!
>
> You get the message:
>
> Couldn’t find per display information
>
>
That error actually sounds like you are trying to run xemacs remotely from
the second Mac but don't have X11 forwarding enabled. in
/etc/ssh/sshd_config  on the remote machine's sshd.

>
>
> You need to run all the three lines that you send me!!!
>
>
> Thank you again!!
>
>
> Giacomo Mauro D'Ariano
> Professor of Theoretical Physics
> Quantum Foundations
> and Quantum Information
>
> Dipartimento di Fisica,
> via Bassi 6, I-27100 Pavia, Italy
>
> email:dari...@unipv.it
> tel:+39 <+39> 0382 987 484
> fax:+39 0382 987 793
> mobile:+39 347 0329998
> skype: giacomo_mauro_dariano
> AIM: dariano13
>
> WEBSITES:
> www.qubit.it
> www.quantummechanics.it
> www.quantumoptics.it
> www.meccanicaquantistica.it
> www.otticaquantistica.it
>
>
>
> Thanks for the information!  Luckily these aren’t huge builds.
>
> —akh
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] xemacs-1:21.4.22-6

[Jack Howarth]

On Wed, Jun 29, 2016 at 9:56 AM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> > On Jun 29, 2016, at 01:29, Giacomo Mauro D'Ariano 
> wrote:
> >
> > It is a known fact on the web that xemacs doesn’t work anymore with the
> current version of XQuartz.
> >
> > Error:
> >
> > Error: attempt to add non-widget child "Progress" to parent
> "clip-window" which supports only widgets
> >
> >
> > Should I abandon xemacs after more than 20 years of usage (including
> Linux)?
> >
> > --
> > Package manager version: 0.39.3
> > Distribution version: selfupdate-rsync Wed Jun 29 10:26:03 2016, 10.11,
> x86_64
> > Mac OS X version: 10.11.5
> > Unable to determine Developer Tools version
> > gcc version: 7.3.0 (clang-703.0.31)
> > make version: 4.1
> > Feedback Courtesy of FinkCommander
> >
> >
> > Giacomo Mauro D'Ariano
> > Professor of Theoretical Physics
> > Quantum Foundations
> > and Quantum Information
> >
> > Dipartimento di Fisica,
> > via Bassi 6, I-27100 Pavia, Italy
> >
> > email:dari...@unipv.it
> > tel:+39 0382 987 484
> > fax:+39 0382 987 793
> > mobile:+39 347 0329998
> > skype: giacomo_mauro_dariano
> > AIM: dariano13
> >
> > WEBSITES:
> > www.qubit.it
> > www.quantummechanics.it
> > www.quantumoptics.it
> > www.meccanicaquantistica.it
> > www.otticaquantistica.it
> >
>
> (plain text please)
>
> As I suggested on our mailing lists a number of times (I don’t know if
> you’re looking at our list archives or other places), “fink rebuild xemacs”
> should fix that for you.
>
>
Actually the issue is solved by rebuilding libxaw3dxft so that the package
is no longer linked to libXt.6.dylib under the newer XQuartz, no?


--
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Xcode 8 linker now defaults to PIE executables for all deployment targets

[Jack Howarth]

  Apple made one significant linker change in Xcode 8 which caused a
build failure in the sbcl package. The linker now creates PIE executables
regardless of deployment target setting. The previous workaround of passing
'-mmacosx-version-min=10.6' to the compiler no longer suffices and an
explicit passage of '-Wl, -no_pie' is now required for code that is not
ASLR compatible.
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fink validation fixes for ghc libs packages

[Jack Howarth]

The devel/hscolour.info file needs the attached correction of ...

Index: hscolour.info

===

RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/devel/
hscolour.info,v

retrieving revision 1.2

diff -r1.2 hscolour.info

3c3

< Revision: 1

---

> Revision: 2

23a24,27

> Shlibs: <<

>   @rpath/libHShscolour-1.23-D9eX1LEa8SaE1RFFjW0myg-ghc7.10.3.dylib 0.0.0
%n (>= 1.23-1)

> <<

>

to pass fink validation. Also attached is the info file for rust-1.9.0-1
with patching to support builds on Clang 8.0.0.
 Jack


On Sat, Jun 18, 2016 at 2:58 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Brendan,
>  Most of the files in libs/ghc fail to pass fink validation due to
> incorrect Shlibs entries. I am attaching a file,
> fink_validation_fixes_libs_ghc.diff, containing the changes required to
> solve those. Note that they also needed a revision bump as well as the
> shlibs entry fix as the current revision is embedding the wrong filename in
> the debs. The pandoc package also requires the fix contained in
> fink_validation_fix_pandoc.diff.
> Jack
>
Index: hscolour.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/devel/hscolour.info,v
retrieving revision 1.2
diff -r1.2 hscolour.info
3c3
< Revision: 1
---
> Revision: 2
23a24,27
> Shlibs: <<
>   @rpath/libHShscolour-1.23-D9eX1LEa8SaE1RFFjW0myg-ghc7.10.3.dylib 0.0.0 %n 
> (>= 1.23-1)
> <<
> 


rust.info
Description: Binary data
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] fink validation fixes for ghc libs packages

[Jack Howarth]

Brendan,
 Most of the files in libs/ghc fail to pass fink validation due to
incorrect Shlibs entries. I am attaching a file,
fink_validation_fixes_libs_ghc.diff, containing the changes required to
solve those. Note that they also needed a revision bump as well as the
shlibs entry fix as the current revision is embedding the wrong filename in
the debs. The pandoc package also requires the fix contained in
fink_validation_fix_pandoc.diff.
Jack
Index: ghc-aeson.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-aeson.info,v
retrieving revision 1.4
diff -r1.4 ghc-aeson.info
3c3
< Revision: 1
---
> Revision: 2
23c23
<   @rpath/libHSaeson-0.10.0.0-0jTqLysUaUV48FrZWcfgKI-ghc7.10.3.dylib 0.0.0 %n 
(>= 0.10.0.0-1)
---
>   @rpath/libHSaeson-0.10.0.0-1vbNSxTuNC3L3MYwmRrXj9-ghc7.10.3.dylib 0.0.0 %n 
> (>= 0.10.0.0-1)
Index: ghc-attoparsec.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-attoparsec.info,v
retrieving revision 1.4
diff -r1.4 ghc-attoparsec.info
3c3
< Revision: 2
---
> Revision: 3
15c15
<   @rpath/libHSattoparsec-0.13.0.1-2FdFrGI1H7BFYxoTdLHZV5-ghc7.10.3.dylib 
0.0.0 %n (>= 0.13.0.1-1)
---
>   @rpath/libHSattoparsec-0.13.0.1-9xFmhb7ffquGhbZS7wthPh-ghc7.10.3.dylib 
> 0.0.0 %n (>= 0.13.0.1-1)
Index: ghc-blaze-builder.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-blaze-builder.info,v
retrieving revision 1.3
diff -r1.3 ghc-blaze-builder.info
3c3
< Revision: 1
---
> Revision: 2
14c14
<   @rpath/libHSblaze-builder-0.4.0.1-7D6Na2HAomq3FxaKuJX0DE-ghc7.10.3.dylib 
0.0.0 %n (>= 0.4.0.1-1)
---
>   @rpath/libHSblaze-builder-0.4.0.1-HecOjmY0iuOKsSwNiH2ZTc-ghc7.10.3.dylib 
> 0.0.0 %n (>= 0.4.0.1-1)
Index: ghc-blaze-html.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-blaze-html.info,v
retrieving revision 1.3
diff -r1.3 ghc-blaze-html.info
3c3
< Revision: 1
---
> Revision: 2
16c16
<   @rpath/libHSblaze-html-0.8.1.1-FByOTVlJXmvFitqrcOmNok-ghc7.10.3.dylib 0.0.0 
%n (>= 0.8.1.1-1)
---
>   @rpath/libHSblaze-html-0.8.1.1-8C4ffLEWe3XH2Iiu1QtOQC-ghc7.10.3.dylib 0.0.0 
> %n (>= 0.8.1.1-1)
Index: ghc-blaze-markup.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-blaze-markup.info,v
retrieving revision 1.3
diff -r1.3 ghc-blaze-markup.info
3c3
< Revision: 1
---
> Revision: 2
15c15
<   @rpath/libHSblaze-markup-0.7.0.3-KHuH8QXnlq29LQ51QRCHo0-ghc7.10.3.dylib 
0.0.0 %n (>= 0.7.0.3-1)
---
>   @rpath/libHSblaze-markup-0.7.0.3-Crk3OwRatygHUl6yiIchmw-ghc7.10.3.dylib 
> 0.0.0 %n (>= 0.7.0.3-1)
Index: ghc-case-insensitive.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-case-insensitive.info,v
retrieving revision 1.3
diff -r1.3 ghc-case-insensitive.info
3c3
< Revision: 1
---
> Revision: 2
15c15
<   @rpath/libHScase-insensitive-1.2.0.5-FEOKgbOKlTVG5A7KrFIMjj-ghc7.10.3.dylib 
0.0.0 %n (>= 1.2.0.5-1)
---
>   @rpath/libHScase-insensitive-1.2.0.5-4kv9YgLSANyC5Zk58ScJzJ-ghc7.10.3.dylib 
> 0.0.0 %n (>= 1.2.0.5-1)
Index: ghc-cgi.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-cgi.info,v
retrieving revision 1.3
diff -r1.3 ghc-cgi.info
3c3
< Revision: 1
---
> Revision: 2
22c22
<   @rpath/libHScgi-3001.2.2.2-CEOwOunYNPs8KwnXyLMnk8-ghc7.10.3.dylib 0.0.0 %n 
(>= 3001.2.2.2-1)
---
>   @rpath/libHScgi-3001.2.2.2-DgGiEB6S9ISEbCxv367lVY-ghc7.10.3.dylib 0.0.0 %n 
> (>= 3001.2.2.2-1)
Index: ghc-cmark.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-cmark.info,v
retrieving revision 1.2
diff -r1.2 ghc-cmark.info
3c3
< Revision: 1
---
> Revision: 2
14c14
<   @rpath/libHScmark-0.5.0-5B4hp1poKRZJiy57C4hGAe-ghc7.10.3.dylib 0.0.0 %n (>= 
0.5.0-1)
---
>   @rpath/libHScmark-0.5.0-16JicXMgq4WALLnGJXGy5z-ghc7.10.3.dylib 0.0.0 %n (>= 
> 0.5.0-1)
Index: ghc-cookie.info
===
RCS file: 
/cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/ghc/ghc-cookie.info,v
retrieving revision 1.1
diff -r1.1 ghc-cookie.info
3c3
< Revision: 1
---
> Revision: 2
17c17
<   @rpath/libHScookie-0.4.1.6-AVkwk5YrJib95NkYf2NW6E-ghc7.10.3.dylib 0.0.0 %n 
(>= 0.4.1.6-1)
---
>   @rpath/libHScookie-0.4.1.6-ERCOcQyQSqi4gKWLWHTnex-ghc7.10.3.dylib 0.0.0 %n 
> (>= 0.4.1.6-1)
Index: ghc-gluraw.info
===
RCS file: 

[Fink-devel] Xcode 8 beta on 10.11

[Jack Howarth]

If anyone is interested in testing the Xcode 8 beta for bootstrapping fink
and building packages on fink, the direct url for the associated 10.11
 Command Line Tools is
https://developer.apple.com/services-account/download?path=/Developer_Tools/Command_Line_Tools_OS_X_10.11_for_Xcode_8_beta/Command_Line_Tools_OS_X_10.11_for_Xcode_8_beta.dmg
(for
those without paid ADC accounts). Apple is behind on updating the More
Downloads page at https://developer.apple.com/download/ to contain that
link.
Jack
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] rstudio-desktop/rstudio-server-0.99.902-1 updates

[Jack Howarth]

BABA,
 I've posted updates for rstudio-desktop/rstudio-server-0.99.902-1 on
fink tracking at https://sourceforge.net/p/fink/package-submissions/4674/
to allow the package to build on 10.11 by using fink openssl100 in the
build and to switch the package from R 3.2 to 3.3. The
rstudio-desktop.patch contains two new hunks...

diff -uNr rstudio-0.99.902.orig/src/cpp/desktop-mac/GwtCallbacks.mm
rstudio-0.99.902/src/cpp/desktop-mac/GwtCallbacks.mm
--- rstudio-0.99.902.orig/src/cpp/desktop-mac/GwtCallbacks.mm   2016-05-11
12:03:49.0 -0400
+++ rstudio-0.99.902/src/cpp/desktop-mac/GwtCallbacks.mm2016-06-13
23:52:23.0 -0400
@@ -297,8 +297,8 @@
   event4 = CGEventCreateKeyboardEvent (NULL, (CGKeyCode)6, false);
   event5 = CGEventCreateKeyboardEvent (NULL, (CGKeyCode)56, false);
   event6 = CGEventCreateKeyboardEvent (NULL, (CGKeyCode)55, false);
-  CGEventSetFlags(event3, kCGEventFlagMaskCommand |
kCGEventFlagMaskShift);
-  CGEventSetFlags(event4, kCGEventFlagMaskCommand |
kCGEventFlagMaskShift);
+  CGEventSetFlags(event3, (CGEventFlags)(kCGEventFlagMaskCommand |
kCGEventFlagMaskShift));
+  CGEventSetFlags(event4, (CGEventFlags)(kCGEventFlagMaskCommand |
kCGEventFlagMaskShift));
   CGEventPost(kCGHIDEventTap, event1);
   CGEventPost(kCGHIDEventTap, event2);
   CGEventPost(kCGHIDEventTap, event3);

to deal with Xcode 7 compiler strictness and

diff -uNr rstudio-0.99.902.orig/src/cpp/core/CMakeLists.txt
rstudio-0.99.902/src/cpp/core/CMakeLists.txt
--- rstudio-0.99.902.orig/src/cpp/core/CMakeLists.txt   2016-05-11
12:03:49.0 -0400
+++ rstudio-0.99.902/src/cpp/core/CMakeLists.txt2016-06-13
23:52:08.0 -0400
@@ -177,22 +177,14 @@

# handle El Capitan moving OpenSSL away
if(APPLE)
-  if(${MACOSX_VERSION} VERSION_GREATER "10.10"
-AND EXISTS "/usr/local/opt/openssl")
-
  set(CORE_SYSTEM_LIBRARIES
 ${CORE_SYSTEM_LIBRARIES}
--lssl -lcrypto)
+@PREFIX@/lib/libssl.dylib @PREFIX@/lib/libcrypto.dylib)

  set(CORE_INCLUDE_DIRS
 ${CORE_INCLUDE_DIRS}
-/usr/local/opt/openssl/include)
+@PREFIX@/include)

- if(NOT DEFINED OPENSSL_ROOT_DIR)
-set(OPENSSL_ROOT_DIR
-   /usr/local/opt/openssl)
- endif()
-  endif()
endif()

if(RSTUDIO_SERVER)

to use the fink openssl100 package.
   Jack
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] 3.3 variant for rnmr-r

[Jack Howarth]

BABA,
 The simple info file change

Index: sci/rnmr-r.info
===
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/sci/
rnmr-r.info,v
retrieving revision 1.6
diff -r1.6 rnmr-r.info
4c4
< Type: r (3.2 3.1)
---
> Type: r (3.3 3.2 3.1)

is sufficient for the rnmr-r package. The resulting rnmr-r33 variant runs
fine against R 3.3.0.
 Jack
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] missing dependencies from rmod updates

[Jack Howarth]

BABA,
  The cran-stringi-r.info packaging doesn't validate due to the missing
header split-off. You need the change...

Index: cran-stringi-r.info
===
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/rmods/
cran-stringi-r.info,v
retrieving revision 1.1
diff -r1.1 cran-stringi-r.info
6c6
< Revision: 1
---
> Revision: 2
34a35,41
> SplitOff: <<
>   Package: %N-dev
>   Description: Headers for CRAN stringi
>   BuildDependsOnly: true
>   Depends: %N (=%v-%r)
>   Files: lib/R/%type_raw[rversion]/site-library/stringi/include
> <<

to pass fink validation.
  Jack
ps You always have to run these packages through the validator because even
minor version updates can result in the CRAN packages starting to
distribute headers.

On Mon, Jun 13, 2016 at 9:22 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> BABA,
>  The download for bioconductor-limma-r33-3.28.5-1 fails. Looks like
> the version is wrong for the 3.3 Bioconductor release and we need the
> change...
>
> Index: rmods/bioconductor-limma-r.info
> ===
> RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/rmods/
> bioconductor-limma-r.info,v
> retrieving revision 1.5
> diff -r1.5 bioconductor-limma-r.info
> 5c5
> < Version: 3.28.5
> ---
> > Version: 3.28.6
> 12c12
> < Source-MD5: 0692fa171651f40f5749c932796b30a5
> ---
> > Source-MD5: a33ac32d02811c1c4cd51a32276481e1
>
>    Jack
>
> On Sun, Jun 12, 2016 at 9:04 PM, 美彦 馬場 <babayoshih...@mac.com> wrote:
>
>> Jack,
>>
>>
>> 2016/06/13 5:52、Jack Howarth <howarth.at.f...@gmail.com> のメール：
>>
>> > Baba,
>> >  It appears that during your recent rmod updates to support R 3.3
>> that you neglected to commit the new dependencies on some of the package
>> updates. For example,
>> >
>> > WARNING: While resolving dependency "cran-magrittr-r33" for package
>> "cran-stringr-r33-1.0.0-1", package "cran-magrittr-r33" was not found.
>> > Can't resolve dependency "cran-magrittr-r33" for package
>> "cran-stringr-r33-1.0.0-1" (no matching packages/versions found)
>> >
>> > I believe 'fink selfupdate' for the cvs mode should tell you which
>> files present in your local libs/rmods subdirectory haven't been committed
>> to the tree yet.
>> > Jack
>>
>>
>> Thank you for letting me know.  I am now having problems with:
>>
>> bioconductor-preprocessorcore-r.info
>> bioconductor-protgenerics-r.info
>> cran-ggally-r.info
>> cran-magrittr-r.info
>> cran-nloptr-r.info  (downloads another source during installation)
>> cran-stringi-r.info
>>
>> I will fix them today.
>>
>> --
>> BABA Yoshihiko
>>
>>
>>
>


cran-stringi-r.info
Description: Binary data
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] missing dependencies from rmod updates

[Jack Howarth]

BABA,
 The download for bioconductor-limma-r33-3.28.5-1 fails. Looks like the
version is wrong for the 3.3 Bioconductor release and we need the change...

Index: rmods/bioconductor-limma-r.info
===
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/rmods/
bioconductor-limma-r.info,v
retrieving revision 1.5
diff -r1.5 bioconductor-limma-r.info
5c5
< Version: 3.28.5
---
> Version: 3.28.6
12c12
< Source-MD5: 0692fa171651f40f5749c932796b30a5
---
> Source-MD5: a33ac32d02811c1c4cd51a32276481e1

   Jack

On Sun, Jun 12, 2016 at 9:04 PM, 美彦 馬場 <babayoshih...@mac.com> wrote:

> Jack,
>
>
> 2016/06/13 5:52、Jack Howarth <howarth.at.f...@gmail.com> のメール：
>
> > Baba,
> >  It appears that during your recent rmod updates to support R 3.3
> that you neglected to commit the new dependencies on some of the package
> updates. For example,
> >
> > WARNING: While resolving dependency "cran-magrittr-r33" for package
> "cran-stringr-r33-1.0.0-1", package "cran-magrittr-r33" was not found.
> > Can't resolve dependency "cran-magrittr-r33" for package
> "cran-stringr-r33-1.0.0-1" (no matching packages/versions found)
> >
> > I believe 'fink selfupdate' for the cvs mode should tell you which files
> present in your local libs/rmods subdirectory haven't been committed to the
> tree yet.
> > Jack
>
>
> Thank you for letting me know.  I am now having problems with:
>
> bioconductor-preprocessorcore-r.info
> bioconductor-protgenerics-r.info
> cran-ggally-r.info
> cran-magrittr-r.info
> cran-nloptr-r.info  (downloads another source during installation)
> cran-stringi-r.info
>
> I will fix them today.
>
> --
> BABA Yoshihiko
>
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] missing dependencies from rmod updates

[Jack Howarth]

Baba,
 It appears that during your recent rmod updates to support R 3.3 that
you neglected to commit the new dependencies on some of the package
updates. For example,

WARNING: While resolving dependency "cran-magrittr-r33" for package
"cran-stringr-r33-1.0.0-1", package "cran-magrittr-r33" was not found.
Can't resolve dependency "cran-magrittr-r33" for package
"cran-stringr-r33-1.0.0-1" (no matching packages/versions found)

I believe 'fink selfupdate' for the cvs mode should tell you which files
present in your local libs/rmods subdirectory haven't been committed to the
tree yet.
Jack
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Fwd: Solved: XEmacs no longer works with XQuartz 2.7.9

[Jack Howarth]

-- Forwarded message --
From: Jack Howarth <howarth.at.f...@gmail.com>
Date: Tue, Jun 7, 2016 at 2:06 PM
Subject: Re: [Fink-devel] Solved: XEmacs no longer works with XQuartz 2.7.9
To: Alexander Hansen <alexanderk.han...@gmail.com>


An alternate, but equally ugly approach, is to build libxaw3dxft with
-flat_namespace using...

--- /sw/fink/10.11/stable/main/finkinfo/x11/libxaw3dxft.info 2015-11-14
22:52:40.0 -0500
+++ libxaw3dxft.info 2016-06-07 13:58:47.0 -0400
@@ -1,6 +1,6 @@
 Package: libxaw3dxft
 Version: 1.6.2
-Revision: 3
+Revision: 4
 BuildDependsOnly: true

 Source: mirror:sourceforge:sf-xpaint/libXaw3dXft-%v.tar.bz2
@@ -39,6 +39,7 @@
 <<

 ConfigureParams: --enable-arrow-scrollbars --disable-static
--disable-silent-rules
+SetLDFLAGS: -Wl,-flat_namespace
 Compilescript: <<
  autoreconf -fi
  %{default_script}

This suppresses the crashes in gv and xemacs when libxaw3dxft is linked
against libXt.6.dylib while still allowing them to run normally when
libxaw3dxft is linked against libXt.7.dylib.
 Jack

On Mon, Jun 6, 2016 at 12:15 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> > On Jun 6, 2016, at 08:47, Merle Reinhart <merlereinh...@mac.com> wrote:
> >
> > Alexander,
> >
> > That could potentially create some issues for some users in that 2.7.9
> breaks some other non-fink things that won't be fixed until 2.7.10.
> Forcing an upgrade to 2.7.9 will create a quandary since some can't go to
> 2.7.9 which might force those users into a very laborious fink update
> process since update-all would no longer be an option.  So, there's a bit
> more than normal to consider in this situation.
> >
> > Merle
>
> Thanks for the info.  I was afraid that there might be issues like that.
> I really wasn’t that wild about the idea, to be honest.
>
> I’m not sure what we can do then in the absence of our own X11, unless we
> provide our own libxt with libxt.7.dylib buried in a private directory so
> that builds on earlier Xquartz and Xquartz 2.7.9 at least link to the same
> libraries.
>
> —akh
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] tar 1.29 breaks fink packager

[Jack Howarth]

On Sun, Jun 5, 2016 at 11:48 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Sun, Jun 5, 2016 at 11:28 AM, TheSin <the...@southofheaven.org> wrote:
>
>> I haven’t tried yet so I’m not seeing it yet.  But I did have lots of
>> problems with gnu vs bad tar when I started updating dpkg years ago, so I
>> know I made lots of changes to the calls.  I don’t think it’s used the same
>> way at all anymore, it’s been a bit so I’ll have not go over the patch
>> again but search for tar params in the patch not execlp.  In newer dpkg
>> they have their own exec functions now.
>>
>> I’ll install tar 1.28 and test it with my version to see if it happens,
>> I’ll also check in current debian see if it’s happening there and what they
>> are doing about it.  I’ll try and make time to check and test it out
>> tonight.
>>
>
> I assume that you are against the newer test dpkg right? On the current
> older dpkg, the issue is easily reproduced with the test tar-1.29-1
> packaging by simply trying to rebuild it a second time after the first
> build/install of the new tar.
>Jack
> ps I wouldn't waste time with tar 1.28 as it obviously doesn't exhibit the
> regression. The priority should be to puzzle out the exact invocation of
> tar within older dpkg which is misbehaving under the new tar 1.29 release
> so we can report back upstream on that permutation.
>

One issue that really puzzles me is this. Against tar-1.29-1, the /DEBIAN
directory seems to be created during either...

Unpacking fink-buildlock-tar-1.29-1 (from
.../fink-buildlock-tar-1.29-1_2016.06.05-12.25.59_darwin-x86_64.deb) ...

or

Setting up fink-buildlock-tar-1.29-1 (2016.06.05-12.25.59) ...

however, under the tar-1.26-4 release, I don't see a DEBIAN subdirectory
being created anywhere on the volume in those steps (at least that isn't
immediately removed so that a search with 'find / . -name DEBIAN' doesn't
report its location,


>
>> ---
>> TS
>> http://www.southofheaven.org/
>> Life begins and ends with chaos, live between the chaos!
>>
>> > On Jun 5, 2016, at 9:00 AM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Sun, Jun 5, 2016 at 10:47 AM, TheSin <the...@southofheaven.org>
>> wrote:
>> > our version of dpkg is FAR too old to report upstream, not to mention
>> I’m sure it is fixed upstream by now.  Check the patch in my PR see if it’s
>> still needed.  I haven’t had a chance but i’m gonna try it.  I’m pretty
>> sure I have a test case already in dpkg 1.15.x for gnu vs bad tar at the
>> very least.
>> >
>> > Are you saying that you have already found a similar failure in dpkg
>> when using it against the tar 1.27 or 1.28 releases? Also in
>> http://fink.cvs.sourceforge.net/viewvc/fink/experimental/thesin/finkinfo/new/
>> I don't see any evidence of the execlp part of dpkg.patch since the changes
>> are all based on the newer dpkg. Since this really might represent a
>> previously unknown regression in the newer tar, we really ought to try to
>> puzzle out a reproducer to submit back upstream (assuming that this is just
>> an invocation of tar with options that no longer behaves as expected).
>> >   Jack
>> >
>> > ---
>> > TS
>> > http://www.southofheaven.org/
>> > Life begins and ends with chaos, live between the chaos!
>> >
>> > > On Jun 5, 2016, at 8:35 AM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> > >
>> > >  The new tar 1.29 release (which is available on fink tracker at
>> https://sourceforge.net/p/fink/package-submissions/4664/) passes its
>> test suite cleanly on x86_64-apple-darwin15 but causes fink to exhibit
>> broken behavior when installed. The problem is that, when a package is
>> built under the new tar 1.29 release, the creation of the build-lock
>> misplaces the DEBIAN control directory at the root level. This creates debs
>> that incorrectly have the DEBIAN control directory placed at root as well
>> and thus all conflict with each other.
>> > >  We should try to puzzle out if the tar hacks used in dpkg.patch
>> really valid and, if so, try to create a stand-alone test case to report
>> back upstream to the bug-tar mailing list (as this glitch isn't being
>> captured by their current test suite).
>> > >   Jack
>> > > ps The main changes I see here are...
>> > >
>> > > -execlp(TAR,"tar","-cf", "-", "-T", "-", "--null",
>> "--no-recursi

Re: [Fink-devel] tar 1.29 breaks fink packager

[Jack Howarth]

On Sun, Jun 5, 2016 at 11:28 AM, TheSin <the...@southofheaven.org> wrote:

> I haven’t tried yet so I’m not seeing it yet.  But I did have lots of
> problems with gnu vs bad tar when I started updating dpkg years ago, so I
> know I made lots of changes to the calls.  I don’t think it’s used the same
> way at all anymore, it’s been a bit so I’ll have not go over the patch
> again but search for tar params in the patch not execlp.  In newer dpkg
> they have their own exec functions now.
>
> I’ll install tar 1.28 and test it with my version to see if it happens,
> I’ll also check in current debian see if it’s happening there and what they
> are doing about it.  I’ll try and make time to check and test it out
> tonight.
>

I assume that you are against the newer test dpkg right? On the current
older dpkg, the issue is easily reproduced with the test tar-1.29-1
packaging by simply trying to rebuild it a second time after the first
build/install of the new tar.
   Jack
ps I wouldn't waste time with tar 1.28 as it obviously doesn't exhibit the
regression. The priority should be to puzzle out the exact invocation of
tar within older dpkg which is misbehaving under the new tar 1.29 release
so we can report back upstream on that permutation.


> ---
> TS
> http://www.southofheaven.org/
> Life begins and ends with chaos, live between the chaos!
>
> > On Jun 5, 2016, at 9:00 AM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> >
> >
> >
> > On Sun, Jun 5, 2016 at 10:47 AM, TheSin <the...@southofheaven.org>
> wrote:
> > our version of dpkg is FAR too old to report upstream, not to mention
> I’m sure it is fixed upstream by now.  Check the patch in my PR see if it’s
> still needed.  I haven’t had a chance but i’m gonna try it.  I’m pretty
> sure I have a test case already in dpkg 1.15.x for gnu vs bad tar at the
> very least.
> >
> > Are you saying that you have already found a similar failure in dpkg
> when using it against the tar 1.27 or 1.28 releases? Also in
> http://fink.cvs.sourceforge.net/viewvc/fink/experimental/thesin/finkinfo/new/
> I don't see any evidence of the execlp part of dpkg.patch since the changes
> are all based on the newer dpkg. Since this really might represent a
> previously unknown regression in the newer tar, we really ought to try to
> puzzle out a reproducer to submit back upstream (assuming that this is just
> an invocation of tar with options that no longer behaves as expected).
> >   Jack
> >
> > ---
> > TS
> > http://www.southofheaven.org/
> > Life begins and ends with chaos, live between the chaos!
> >
> > > On Jun 5, 2016, at 8:35 AM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> > >
> > >  The new tar 1.29 release (which is available on fink tracker at
> https://sourceforge.net/p/fink/package-submissions/4664/) passes its test
> suite cleanly on x86_64-apple-darwin15 but causes fink to exhibit broken
> behavior when installed. The problem is that, when a package is built under
> the new tar 1.29 release, the creation of the build-lock misplaces the
> DEBIAN control directory at the root level. This creates debs that
> incorrectly have the DEBIAN control directory placed at root as well and
> thus all conflict with each other.
> > >  We should try to puzzle out if the tar hacks used in dpkg.patch
> really valid and, if so, try to create a stand-alone test case to report
> back upstream to the bug-tar mailing list (as this glitch isn't being
> captured by their current test suite).
> > >   Jack
> > > ps The main changes I see here are...
> > >
> > > -execlp(TAR,"tar","-cf", "-", "-T", "-", "--null",
> "--no-recursion", (char*)0);
> > > +execlp(TAR,"tar","-cf", "-", "--null", "-T", "-",
> "--no-recursion", (char*)0);
> > >
> > >
> > > for dpkg-1.10.21/dpkg-deb/build.c.
> > >
> > >
> > >
> --
> > > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > > patterns at an interface-level. Reveals which users, apps, and
> protocols are
> > > consuming the most bandwidth. Provides multi-vendor support for
> NetFlow,
> > > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > > planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
> > > Fink-devel mailing list
> > > Fin

Re: [Fink-devel] tar 1.29 breaks fink packager

[Jack Howarth]

On Sun, Jun 5, 2016 at 10:47 AM, TheSin <the...@southofheaven.org> wrote:

> our version of dpkg is FAR too old to report upstream, not to mention I’m
> sure it is fixed upstream by now.  Check the patch in my PR see if it’s
> still needed.  I haven’t had a chance but i’m gonna try it.  I’m pretty
> sure I have a test case already in dpkg 1.15.x for gnu vs bad tar at the
> very least.
> ---
>

This appears to be a new regression introduced in the 1.29 release of tar.
A quick and dirty test of a fink build against a symlinked /sw/bin/tar
pointing at the MacPorts /opt/local/bin/gnutar 1.28 package doesn't produce
the root level DEBIAN directory. So we definitely should try to create a
test case for reporting back upstream.
Jack


> TS
> http://www.southofheaven.org/
> Life begins and ends with chaos, live between the chaos!
>
> > On Jun 5, 2016, at 8:35 AM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> >
> >  The new tar 1.29 release (which is available on fink tracker at
> https://sourceforge.net/p/fink/package-submissions/4664/) passes its test
> suite cleanly on x86_64-apple-darwin15 but causes fink to exhibit broken
> behavior when installed. The problem is that, when a package is built under
> the new tar 1.29 release, the creation of the build-lock misplaces the
> DEBIAN control directory at the root level. This creates debs that
> incorrectly have the DEBIAN control directory placed at root as well and
> thus all conflict with each other.
> >  We should try to puzzle out if the tar hacks used in dpkg.patch
> really valid and, if so, try to create a stand-alone test case to report
> back upstream to the bug-tar mailing list (as this glitch isn't being
> captured by their current test suite).
> >   Jack
> > ps The main changes I see here are...
> >
> > -execlp(TAR,"tar","-cf", "-", "-T", "-", "--null", "--no-recursion",
> (char*)0);
> > +execlp(TAR,"tar","-cf", "-", "--null", "-T", "-", "--no-recursion",
> (char*)0);
> >
> >
> > for dpkg-1.10.21/dpkg-deb/build.c.
> >
> >
> >
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
> > Fink-devel mailing list
> > Fink-devel@lists.sourceforge.net
> > List archive:
> > http://news.gmane.org/gmane.os.apple.fink.devel
> > Subscription management:
> > https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] tar 1.29 breaks fink packager

[Jack Howarth]

 The new tar 1.29 release (which is available on fink tracker at
https://sourceforge.net/p/fink/package-submissions/4664/) passes its test
suite cleanly on x86_64-apple-darwin15 but causes fink to exhibit broken
behavior when installed. The problem is that, when a package is built under
the new tar 1.29 release, the creation of the build-lock misplaces the
DEBIAN control directory at the root level. This creates debs that
incorrectly have the DEBIAN control directory placed at root as well and
thus all conflict with each other.
 We should try to puzzle out if the tar hacks used in dpkg.patch really
valid and, if so, try to create a stand-alone test case to report back
upstream to the bug-tar mailing list (as this glitch isn't being captured
by their current test suite).
  Jack
ps The main changes I see here are...

-execlp(TAR,"tar","-cf", "-", "-T", "-", "--null", "--no-recursion",
(char*)0);
+execlp(TAR,"tar","-cf", "-", "--null", "-T", "-", "--no-recursion",
(char*)0);


for dpkg-1.10.21/dpkg-deb/build.c.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Solved: XEmacs no longer works with XQuartz 2.7.9

[Jack Howarth]

On Thu, Jun 2, 2016 at 10:57 AM, Stefan Bruda <ste...@bruda.ca> wrote:

> At 10:02 -0400 on 2016-6-2 Jack Howarth wrote:
>  >
>  > So I assume you are talking about using extensions to emacs like
>  > https://github.com/Malabarba/spinner.el/blob/master/README.org
>  > rather than just the stock configuration?
>
> Strangely enough this is (was, see below) all standard configuration.
> After some thought I realized that it is quite possible that any
> Athena item could cause the crash.  Sure enough, attempting to open a
> file using the menu (which opens a dialogue) rather than the shortcut
> (which uses the minibuffer) would cause the same kind of crash.  In
> the end I concluded that the Athena library is the culprit.  I thus
> rebuilt libxaw3dxft and libxaw3dxft-shlibs, then rebuilt xemacs, and
> sure enough everything appears to be back in working order.
>

The only change that I can imagine happening on the rebuild of  libxaw3dxft
is that the linkage on libXt is switched from the flat-namespace copy,
/opt/X11/lib/libXt.6.dylib, to the newer two-level namespace
one, /opt/X11/lib/libXt.7.dylib. If this fixes xemacs, it is the total
opposite situation from motif (where the flat-namespace copy of libXt is
required),


>  > If so, it might be worth installing MacPorts (using their binary
>  > repo) and trying their xemacs.
>
> Fortunately this is no longer necessary.
>
>  > Both of our packages are based on the 21.4.22 release whereas many
>  > of the linux releases are based on newer development snapshots of
>  > xemacs.  Note that MacPorts tried to switch to those but backed off
>  > to the 21.4.22 release for stability.
>
> The 21.5 branch does not add any Earth-shattering features really so
> sticking with the tried and true seems to be the way to go.
>
> In case you are wondering why am I insisting on using a dinosaur such
> as XEmacs, I tried really hard to like the shiny new stuff and kind of
> failed.  Having lost XEmacs on my main machine (however temporarily)
> and thus my email client I have switched to the latest and greatest
> namely, GNU Emacs 24.x.  The transition was kind of painless, though I
> did have to get several elisp packages to reproduce behaviour already
> included in XEmacs and I missed the ability to have buttons in the
> menu bar.  This being said, GNU Emacs is dog slow compared to the gool
> ol' XEmacs.  For example, hitting reply in XEmacs produces the
> composition frame quasi-instantaneously, while in GNU Emacs I get to
> enjoy watching the frame opening for several seconds before having a
> composition buffer...
>
> I any event, thank you for all the suggestions and sorry for the rant.
> I hope that the information about libxaw3dxft is useful.
>
> Cheers,
> Stefan
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] XEmacs no longer works with XQuartz 2.7.9

[Jack Howarth]

On Wed, Jun 1, 2016 at 11:47 PM, Stefan Bruda <ste...@bruda.ca> wrote:

> Hello,
>
> At 19:49 -0400 on 2016-6-1 Jack Howarth wrote:
>  >
>  > Can you try building the packaging posted on fink tracker at
>  > https://sourceforge.net/p/fink/package-submissions/4663/ and see if
>  > that helps? This packaging addresses the 'missing sentinel in
>  > function call' warnings, which according to
>  >
> http://stackoverflow.com/questions/2407605/c-warning-missing-sentinel-in-function-call
>  > can cause memory issues.
>
> Using this version does not fix the issue at hand.  Progress bars and
> other such widgets all cause XEmacs to crash.  For what it is worth,
> the very same version of XEmacs with the very same init runs fine on
> several Linux boxes with the same or newer version of the Xorg server.
>

Stefan,
So I assume you are talking about using extensions to emacs like
https://github.com/Malabarba/spinner.el/blob/master/README.org rather than
just the stock configuration? If so, it might be worth installing MacPorts
(using their binary repo) and trying their xemacs. Both of our packages are
based on the 21.4.22 release whereas many of the linux releases are based
on newer development snapshots of xemacs. Note that MacPorts tried to
switch to those but backed off to the 21.4.22 release for stability.
   Jack


> Cheers,
> Stefan
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] XEmacs does not run withno longer works with XQuartz 2.7.9

[Jack Howarth]

Stefan,
  Can you try building the packaging posted on fink tracker at
https://sourceforge.net/p/fink/package-submissions/4663/ and see if that
helps? This packaging addresses the 'missing sentinel in function call'
warnings, which according to
http://stackoverflow.com/questions/2407605/c-warning-missing-sentinel-in-function-call
can
cause memory issues.
  Jack

On Wed, Jun 1, 2016 at 11:42 AM, Stefan Bruda  wrote:

> Hello,
>
> After the latest XQuartz update (to version 2.7.9) XEmacs refuses to
> run under X (but runs just fine in a terminal).  Here is how it fails:
>
> < godel:~ > xemacs
> Error: attempt to add non-widget child "*scratch*" to parent "Buffers"
> which supports only widgets
>
> To be on the safe side I did an selfupdate, update-all, and then
> rebuild XEmacs but the issue remains.
>
> The environment is as follows:
>
> < godel:~ > sw_vers
> ProductName:Mac OS X
> ProductVersion: 10.10.5
> BuildVersion:   14F1808
> < godel:~ > fink list xcode
> Information about 9387 packages read in 1 seconds.
>  i   xcode7.2.0.0.1.1447  [virtual package representing
> the developer tools]
>  i   xcode.app7.2.1-1 [virtual package representing
> Xcode]
>
> Advice is much appreciated.
>
> Best regards,
> Stefan
>
> --
> Stefan D. Bruda, PhD
> Professor of Computer Science
> Bishop's University
> 2600 College St, Sherbrooke, Quebec J1M 1Z7, Canada
> Phone: +1-819-822-9600 x2374, Fax: +1-819-822-9661
> Web: , Email: 
> PGP public key: <
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xD5DD6092>
> * No HTML emails and proprietary attachments please  >
> * Quid latine dictum sit altum videtur
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] missing dependency and a bug in (fsf-)gdb

[Jack Howarth]

   The existing gdb package containing fef-gdb uses a shell script to alert
the user that they need to code sign the program in order for it to run
properly as non-root. The info file has instructions for this...

To execute fsf-gdb without using sudo, the binary needs to be codesigned
on each machine that it is installed on. This requires the creation
of a certificate and signing of the fsf-gdb binary with the following
steps.

1) Open the application 'Keychain Access' from the Utilities folder.
2) In the Keychain Access application, select the 'Create a
   Certificate...' submenu item from the 'Keychain Access' menu and
   the 'Certificate Assistant' submenu.
3) In the 'Certificate Assistant' panel, enter 'gdb-cert' for the name
   of the certificate and leave the Identity Type as 'Self Signed Root'.
   Set the Certificate Type to 'Code Signing' and enable the 'Let me
   override defaults' checkbox. Click the 'Continue'  button. You may
   wish to lengthen the default 365 day lifespan of the certificate
   to 3650 days.
4) Continue clicking the 'Continue' buttons that appear until you see
   the panel to 'Specify a Location For The Certificate'. Set the
   Keychain to 'System' at this point. If you can't store the
   certificate in the 'System' keychain, create it in the 'login'
   keychain, then export it. You can then import it into the 'System'
   keychain.
5) Select the 'System' entry in the Keychains listing of the Keychain
   Access window. Select your newly created 'gdb-cert' certificate and
   select the 'Get Info' contextual menu item, expand the 'Trust'
   item and set 'Code Signing' to '"Always Trust'.
6) Quit the 'Keychain Access' application.
7) On darwin12 or later, you must edit the line in the file
   /System/Library/LaunchDaemons/com.apple.taskgated.plist from

   -s

   to

   -sp

   adding the '-p' option. Due to kernel caching, a restart is needed
   for the changes to take effect.
8) After the restart, the actual codesigning should be done with the
   command 'sudo codesign -s gdb-cert %p/lib/fsf-gdb/fsf-gdb'. Note it
   can take over five minutes for the codesigning to complete.

Note that you also need to edit
 /System/Library/LaunchDaemons/com.apple.taskgated.plist to pass the -p
option in order for gdb to properly handle tasks...

http://ntraft.com/installing-gdb-on-os-x-mavericks/

Under El Capitan, you will have to temporarily disable SIP to the the
modification to /System/Library/LaunchDaemons/com.apple.taskgated.plist.
Apple treats debuggers as a security threat and has progressively
restricted the ability to run as non-root over time so one has to jump
through a lot of hoops to do that.
  Jack
ps I added the shell script and the checks to remind users when they need
to code sign or re-add the -p option should they reinstall OS X.

On Thu, Mar 3, 2016 at 6:12 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

> 
>
> > On Mar 3, 2016, at 14:07, Roseli Wedemann 
> wrote:
> >
> > Hello,
> >
> > I tried to install fsf-gdb and gdb via fink today on OS X El Capitan
> 10.11.3.
> >
>
> There is no “fsf-gdb” Fink package.  I can only assume that you mean the
> “fsf-gdb” executable in the “gdb” package, and that “gdb” refers to the
> “gdb” executable from the “apple-gdb” package.
>
> When filing bug reports with us use the _package_ names, not just the
> _executable_ names.
>
> > First of all, a dependency is missing (libtool needed to be installed
> manually for fsf-gdb [perhaps also for gdb]).
> >
>
> What error did you get?  The packages build OK for me without libtool2
> (there  is no “libtool" for 10.11).  If you got a build or linker error
> that pertains to some other package then that only impacts (apple-)gdb
> indirectly and should be filed as a bug against _that_ package.
>
> > Secondly, gdb runs ok via sudo, but not without sudo (I did the code
> signing as described in the package description). For the error see below:
> >
> > gdb IntFokkerPlanck
> > GNU gdb 6.3.50.20050815-cvs (Thu Oct 15 12:32:49 UTC 2015)
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> are
> > welcome to change it and/or distribute copies of it under certain
> conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> > This GDB was configured as "i686-apple-darwin15.0.0"...Reading symbols
> for shared libraries .. done
> >
> > (gdb) break 154
> > Breakpoint 1 at 0x1080f: file IntFokkerPlanck.c, line 154.
> > (gdb) run
> > Starting program:
> /Users/roseliwedemann/tudo/Neural/FokkerPlanckModel/Program/IntFokkerPlanck
> > Unable to find Mach task port for process-id 1257: (os/kern) failure
> (0x5).
> > (gdb)
> >
> >
> > Thirdly, fsf-gdb does not run via sudo nor without sudo.
> >
> > error with sudo:
> >
> > sudo fsf-gdb IntFokkerPlanck
> > Password:
> > Throw 

Re: [Fink-devel] afni sources

[Jack Howarth]

   Proposed fix for location of sources and legacy flat_namespace libXt in
https://sourceforge.net/p/fink/package-submissions/4610/

On Wed, Feb 17, 2016 at 11:18 AM, Hanspeter Niederstrasser <
f...@snaggledworks.com> wrote:

> On Wed, February 17, 2016 10:10 am, Jack Howarth wrote:
> > Hanspeter,
> >  The https://afni.nimh.nih.gov/pub/dist/tgz/AFNI_ARCHIVE/  site
> > doesn't
> > include the TTatlas+tlrc.BRIK.gz and TTatlas+tlrc.HEAD files though.
> >  Jack
>
> https://afni.nimh.nih.gov/pub/dist/tgz/
>
> Hanspeter
>
> --
> More agile than a turtle, stronger than a mouse, nobler than a lettuce
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] afni sources

[Jack Howarth]

Hanspeter,
 The https://afni.nimh.nih.gov/pub/dist/tgz/AFNI_ARCHIVE/  site doesn't
include the TTatlas+tlrc.BRIK.gz and TTatlas+tlrc.HEAD files though.
 Jack

On Wed, Feb 17, 2016 at 10:52 AM, Hanspeter Niederstrasser <
f...@snaggledworks.com> wrote:

> On Wed, February 17, 2016 9:34 am, Jack Howarth wrote:
> >   While adjusting afni-2010.10.19.1028-2 to build against the legacy
> > flat_namespace libXt in the upcoming Xquartz 2.7.9 release, I noticed
> that
> > the package's source mirror is no longer available at
> > http://mrires.stjosham.on.ca/~addavis/. Those sources should be uploaded
> > to
> > the fink mirror if anyone has those available locally.
>
> The sources seem to be available here:
>
> https://afni.nimh.nih.gov/pub/dist/tgz/AFNI_ARCHIVE/
>
> Hanspeter
>
> --
> More agile than a turtle, stronger than a mouse, nobler than a lettuce
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] afni sources

[Jack Howarth]

  While adjusting afni-2010.10.19.1028-2 to build against the legacy
flat_namespace libXt in the upcoming Xquartz 2.7.9 release, I noticed that
the package's source mirror is no longer available at
http://mrires.stjosham.on.ca/~addavis/. Those sources should be uploaded to
the fink mirror if anyone has those available locally.
Jack
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] procmail for 10.11

[Jack Howarth]

Greg,
   Daniel Macks used to maintain a procmail-3.22-1 package which is
still available in 10.4/10.5-EOL at...

http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/stable/main/finkinfo/10.5-EOL/utils/procmail.info
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/stable/main/finkinfo/10.5-EOL/utils/procmail.patch

 Jack


On Mon, Jan 4, 2016 at 9:46 PM, Greg Minshall  wrote:

> hi.  i just updated to 10.11.  Apple removed various things, including
> RCS and procmail.  there's a fink package for RCS, but i don't see one
> for procmail.  i downloaded the source, made a few mods
> (s/getline/pr_getline/g; mv INSTALL INSTALL.txt), and it appears to
> work.
>
> is there a more formal way of getting procmail?  (i couldn't *ask* the
> question until i had my e-mail back up and running, sigh... :)
>
> other than that, in particular the fink parts of the upgrade were great.
>
> cheers, Greg
>
>
> --
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] coreutils-default missing base64

[Jack Howarth]

Jesse,
 I am seeing /usr/bin/base64 present on El Capitan and...

$ lsbom /System/Library/Receipts/com.apple.pkg.Essentials.bom | grep
"\/usr\/bin\/base64"
./usr/bin/base64 100755 0/0 23136 2685920996

shows it to still be part of the Essentials package.
  Jack

On Sun, Dec 27, 2015 at 3:09 PM, Jesse Alama  wrote:

> I just noticed that gbase64 is available in coreutils, but the analogue in
> coreutils-default is missing.  The DescDetails talks about a conflict with
> the base64 package, but it seems that package is no longer available.
>
> http://pdb.finkproject.org/pdb/browse.php?summary=base64
>
> Any chance of putting base64 into coreutils-default?
>
> Jesse
>
>
> --
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for remaining fink make failures on 10.11

[Jack Howarth]

On Sat, Oct 24, 2015 at 11:30 AM, Max Horn <m...@quendi.de> wrote:

> Thanks for all the work and testing. I have no committed a revised version
> of the .info file, which drops the patch and uses --disable-nls.
>
> Cheers,
> Max
>
>
FYI, looking at this some more in order to try to find where exactly the CF
calls from gettext are leaked into the make code path, the answer seems to
be pretty much everywhere. It looks like the offender is...

makeint.h:#define _(msgid)gettext (msgid)

which if you execute...

grep "_(" *.c

shows that macro is used widely across the entire code path.
Jack



> > On 24.10.2015, at 12:32, Jack Howarth <howarth.at.f...@gmail.com> wrote:
> >
> >
> >
> > On Sat, Oct 24, 2015 at 6:12 AM, Martin Costabel <costa...@wanadoo.fr>
> wrote:
> > On 24/10/15 08:22, Jack Howarth wrote:
> > []
> >Since we don't want to remove the CoreFoundation support from
> > libgettext8-shlibs and gettext-tools, the obvious solution is to use the
> > proposed make-4.1-4 packaging
> >
> > https://sourceforge.net/p/fink/package-submissions/4563/
> >
> > which passes --disable-nls to ConfigureParams to avoid linking against
> > libintl entirely.
> > []
> >
> > I confirm that --disable-nls added to the configure params in make-4.1-2
> - even without the patch file from make-4.1-3 - fixes the build failure of
> libcurl4 with -j8 on OSX 10.11.
> >
> > --
> > Martin
> >
> > I am seeing that here as well with libcurl4 at -j8 so I guess we can
> drop the current make.patch from make-4.1-4.
> >
> >
> >
> --
> > ___
> > Fink-devel mailing list
> > Fink-devel@lists.sourceforge.net
> > List archive:
> > http://news.gmane.org/gmane.os.apple.fink.devel
> > Subscription management:
> > https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for remaining fink make failures on 10.11

[Jack Howarth]

A cursory look through the sources of CF-1153.18 from the 10.10.5 Apple
OpenSource release shows that there isn't any effort made in those source
files to handle EINTR error codes returned on read, write and (f)stat calls.

On Sat, Oct 24, 2015 at 12:48 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Max,
>   I finally have a good handle on the origin of the breakage in 10.11.
> Looking through the sources for intl in gettext-0.19.5.1, I only found a
> fstat call missing the EINTR handling but adding that didn't fix the
> parallel make regressions in the openmpi and gcc5 builds under make 4-1-3.
> However I dd notice that gettext builds and links against the
> CoreFoundation framework. So I did the test of rebuilding
> libgettext8-shlibs and gettext-tools with...
>
> gt_cv_func_CFPreferencesCopyAppValue=no \
> gt_cv_func_CFLocaleCopyCurrent=no \
> gt_cv_func_CFPreferencesCopyAppValue=no \
> gt_cv_func_CFLocaleCopyCurrent=no
>
> passed to ConfigureParams in order to avoid building against the
> CoreFoundation framework. The resulting libintl now allows the current
> make-4.1-3 (which is built with the NLS support) to parallel build both the
> openmpi and gcc5 package.
>   Since we don't want to remove the CoreFoundation support from
> libgettext8-shlibs and gettext-tools, the obvious solution is to use the
> proposed make-4.1-4 packaging
>
> https://sourceforge.net/p/fink/package-submissions/4563/
>
> which passes --disable-nls to ConfigureParams to avoid linking against
> libintl entirely.
> Jack
> ps I'll probably file a radar but I don't have much hope that Apple can be
> convinced to code review CFPreferencesCopyAppValue, CFLocaleCopyCurrent,
> CFPreferencesCopyAppValue and CFLocaleCopyCurrent with their associated
> calls for EINTR handling on system calls.
> pps This actually isn't that surprising. On MacPorts, we have to use the
> -CoreFoundation variant of their tcl package to allow pymol to run properly
> and pymol does a fork()/exec() like make does.
>
>
> On Fri, Oct 23, 2015 at 4:30 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> Since make 4.1 built with --enable-nls only links against
>> /sw/lib/libintl.8.dylib, the only likely candidate I see is...
>>
>>   __builtin_expect (fstat (fd, ) != 0, 0)
>>
>> in gettext-0.19.5.1/gettext-runtime/intl/loadmsgcat.c. It's not clear how
>> we manage to keep the __builtin_expect macro wrapper while also looping on
>> fstat with the missing check for EINTR added.
>> Jack
>> ps In theory, we probably should also check the i/o system calls for
>> missing EINTR checks in /sw/lib/libiconv.2.dylib since libintl.8.dylib is
>> linked against that.
>>
>> On Fri, Oct 23, 2015 at 3:22 PM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>>
>>> Max,
>>>   I did an exhaustive check by adding EINTRLOOP macros to every
>>> single POSIX system call in the make 4.1 sources which can return EINTR.
>>> None of that helped eliminate the build failures here in openmpi and gcc5.
>>> I finally stumbled in a workaround that suppresses the failures. Passing
>>> --disable-nls to the ConfigureParms in the make 4.1 build produces a binary
>>> that doesn't exhibit this bug on 10.11.
>>>  This work-around actually makes sense to me. If the read/write/stat
>>> calls in the make 4.1 sources require addition of an EINTRLOOP macro
>>> wrapper, then why shouldn't the same be true of those function calls in the
>>> gettext library itself.. Any i/o in that library should be under that same
>>> restrictions as those in the make 4.1 sources themselves, no?
>>>Jack
>>> ps The attached make-4.1-4 applies --disable-nls universally to the
>>> build so that binaries built prior to the upgrade to 10.11 will have the
>>> same necessary elimination of that feature.
>>> ppc The explanation of the failure being due to the NLS support also has
>>> the added benefit of explaining why this issue was quasi-latent in prior
>>> darwin releases...
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827#c5
>>>
>>> Looking at the gettext-0.19.5.1 sources, I see that their read calls use
>>> a while loop to check for EINTR being returned but this doesn't rule out
>>> that some other POSIX call in there is missing the required EINTR checks.
>>> For instance in gettext-tools/gnulib-lib/pipe-filter-ii.c,
>>>
>>>   read (fd[0], buf, bufsize > SSIZE_MAX ? SSIZE_MAX :
>>> bufsize);
>>

Re: [Fink-devel] fix for remaining fink make failures on 10.11

[Jack Howarth]

Max,
  I finally have a good handle on the origin of the breakage in 10.11.
Looking through the sources for intl in gettext-0.19.5.1, I only found a
fstat call missing the EINTR handling but adding that didn't fix the
parallel make regressions in the openmpi and gcc5 builds under make 4-1-3.
However I dd notice that gettext builds and links against the
CoreFoundation framework. So I did the test of rebuilding
libgettext8-shlibs and gettext-tools with...

gt_cv_func_CFPreferencesCopyAppValue=no \
gt_cv_func_CFLocaleCopyCurrent=no \
gt_cv_func_CFPreferencesCopyAppValue=no \
gt_cv_func_CFLocaleCopyCurrent=no

passed to ConfigureParams in order to avoid building against the
CoreFoundation framework. The resulting libintl now allows the current
make-4.1-3 (which is built with the NLS support) to parallel build both the
openmpi and gcc5 package.
  Since we don't want to remove the CoreFoundation support from
libgettext8-shlibs and gettext-tools, the obvious solution is to use the
proposed make-4.1-4 packaging

https://sourceforge.net/p/fink/package-submissions/4563/

which passes --disable-nls to ConfigureParams to avoid linking against
libintl entirely.
Jack
ps I'll probably file a radar but I don't have much hope that Apple can be
convinced to code review CFPreferencesCopyAppValue, CFLocaleCopyCurrent,
CFPreferencesCopyAppValue and CFLocaleCopyCurrent with their associated
calls for EINTR handling on system calls.
pps This actually isn't that surprising. On MacPorts, we have to use the
-CoreFoundation variant of their tcl package to allow pymol to run properly
and pymol does a fork()/exec() like make does.


On Fri, Oct 23, 2015 at 4:30 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Since make 4.1 built with --enable-nls only links against
> /sw/lib/libintl.8.dylib, the only likely candidate I see is...
>
>   __builtin_expect (fstat (fd, ) != 0, 0)
>
> in gettext-0.19.5.1/gettext-runtime/intl/loadmsgcat.c. It's not clear how
> we manage to keep the __builtin_expect macro wrapper while also looping on
> fstat with the missing check for EINTR added.
> Jack
> ps In theory, we probably should also check the i/o system calls for
> missing EINTR checks in /sw/lib/libiconv.2.dylib since libintl.8.dylib is
> linked against that.
>
> On Fri, Oct 23, 2015 at 3:22 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> Max,
>>   I did an exhaustive check by adding EINTRLOOP macros to every
>> single POSIX system call in the make 4.1 sources which can return EINTR.
>> None of that helped eliminate the build failures here in openmpi and gcc5.
>> I finally stumbled in a workaround that suppresses the failures. Passing
>> --disable-nls to the ConfigureParms in the make 4.1 build produces a binary
>> that doesn't exhibit this bug on 10.11.
>>  This work-around actually makes sense to me. If the read/write/stat
>> calls in the make 4.1 sources require addition of an EINTRLOOP macro
>> wrapper, then why shouldn't the same be true of those function calls in the
>> gettext library itself.. Any i/o in that library should be under that same
>> restrictions as those in the make 4.1 sources themselves, no?
>>Jack
>> ps The attached make-4.1-4 applies --disable-nls universally to the build
>> so that binaries built prior to the upgrade to 10.11 will have the same
>> necessary elimination of that feature.
>> ppc The explanation of the failure being due to the NLS support also has
>> the added benefit of explaining why this issue was quasi-latent in prior
>> darwin releases...
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827#c5
>>
>> Looking at the gettext-0.19.5.1 sources, I see that their read calls use
>> a while loop to check for EINTR being returned but this doesn't rule out
>> that some other POSIX call in there is missing the required EINTR checks.
>> For instance in gettext-tools/gnulib-lib/pipe-filter-ii.c,
>>
>>   read (fd[0], buf, bufsize > SSIZE_MAX ? SSIZE_MAX :
>> bufsize);
>>
>> looks like it might need a EINTR check. IMHO, gnu-lib might be the best
>> place to start as that code isn't under the direct control of the gettext
>> developers. It also seems to do write() and stat() calls without checking
>> for EINTR in places within the gnu-lib sources.
>>
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] fix for remaining fink make failures on 10.11

[Jack Howarth]

Max,
  I did an exhaustive check by adding EINTRLOOP macros to every single
POSIX system call in the make 4.1 sources which can return EINTR. None of
that helped eliminate the build failures here in openmpi and gcc5. I
finally stumbled in a workaround that suppresses the failures. Passing
--disable-nls to the ConfigureParms in the make 4.1 build produces a binary
that doesn't exhibit this bug on 10.11.
 This work-around actually makes sense to me. If the read/write/stat
calls in the make 4.1 sources require addition of an EINTRLOOP macro
wrapper, then why shouldn't the same be true of those function calls in the
gettext library itself.. Any i/o in that library should be under that same
restrictions as those in the make 4.1 sources themselves, no?
   Jack
ps The attached make-4.1-4 applies --disable-nls universally to the build
so that binaries built prior to the upgrade to 10.11 will have the same
necessary elimination of that feature.
ppc The explanation of the failure being due to the NLS support also has
the added benefit of explaining why this issue was quasi-latent in prior
darwin releases...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827#c5

Looking at the gettext-0.19.5.1 sources, I see that their read calls use a
while loop to check for EINTR being returned but this doesn't rule out that
some other POSIX call in there is missing the required EINTR checks. For
instance in gettext-tools/gnulib-lib/pipe-filter-ii.c,

  read (fd[0], buf, bufsize > SSIZE_MAX ? SSIZE_MAX : bufsize);

looks like it might need a EINTR check. IMHO, gnu-lib might be the best
place to start as that code isn't under the direct control of the gettext
developers. It also seems to do write() and stat() calls without checking
for EINTR in places within the gnu-lib sources.


make.info
Description: Binary data


make.patch
Description: Binary data
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for remaining fink make failures on 10.11

[Jack Howarth]

Since make 4.1 built with --enable-nls only links against
/sw/lib/libintl.8.dylib, the only likely candidate I see is...

  __builtin_expect (fstat (fd, ) != 0, 0)

in gettext-0.19.5.1/gettext-runtime/intl/loadmsgcat.c. It's not clear how
we manage to keep the __builtin_expect macro wrapper while also looping on
fstat with the missing check for EINTR added.
Jack
ps In theory, we probably should also check the i/o system calls for
missing EINTR checks in /sw/lib/libiconv.2.dylib since libintl.8.dylib is
linked against that.

On Fri, Oct 23, 2015 at 3:22 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Max,
>   I did an exhaustive check by adding EINTRLOOP macros to every single
> POSIX system call in the make 4.1 sources which can return EINTR. None of
> that helped eliminate the build failures here in openmpi and gcc5. I
> finally stumbled in a workaround that suppresses the failures. Passing
> --disable-nls to the ConfigureParms in the make 4.1 build produces a binary
> that doesn't exhibit this bug on 10.11.
>  This work-around actually makes sense to me. If the read/write/stat
> calls in the make 4.1 sources require addition of an EINTRLOOP macro
> wrapper, then why shouldn't the same be true of those function calls in the
> gettext library itself.. Any i/o in that library should be under that same
> restrictions as those in the make 4.1 sources themselves, no?
>Jack
> ps The attached make-4.1-4 applies --disable-nls universally to the build
> so that binaries built prior to the upgrade to 10.11 will have the same
> necessary elimination of that feature.
> ppc The explanation of the failure being due to the NLS support also has
> the added benefit of explaining why this issue was quasi-latent in prior
> darwin releases...
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827#c5
>
> Looking at the gettext-0.19.5.1 sources, I see that their read calls use a
> while loop to check for EINTR being returned but this doesn't rule out that
> some other POSIX call in there is missing the required EINTR checks. For
> instance in gettext-tools/gnulib-lib/pipe-filter-ii.c,
>
>   read (fd[0], buf, bufsize > SSIZE_MAX ? SSIZE_MAX : bufsize);
>
> looks like it might need a EINTR check. IMHO, gnu-lib might be the best
> place to start as that code isn't under the direct control of the gettext
> developers. It also seems to do write() and stat() calls without checking
> for EINTR in places within the gnu-lib sources.
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

Ugh. This other permutation of the parallel make failure...

make[5]: *** read jobs pipe: No such file or directory.  Stop.

may not be easy to fix. The offending code seems to be in the section...

#else
/* Set interruptible system calls, and read() for a job token.  */
set_child_handler_action_flags (1, waiting_jobs != NULL);
got_token = read (job_rfd, , 1);
saved_errno = errno;
set_child_handler_action_flags (0, waiting_jobs != NULL);

in job.c. As I understand this code, it is using its own interrupt handling
setup in set_child_handler_action_flags(). and so the EINTRLOOP() macro fix
would be inappropriate there. Sigh,

On Wed, Oct 21, 2015 at 9:02 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> It looks like we are still missing some instances of  EINTRLOOP() macro
> usage. The gcc5 build with fink make still fails with the proposed fix
> starting at...
>
> make[5]: *** read jobs pipe: No such file or directory.  Stop.
> make[5]: *** Waiting for unfinished jobs
>
> and resulting in
>
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>
> I am certain that the issue is missing instances of EINTRLOOP() on file
> i/o in make 4.x but we will just have to weed through all of the different
> cases. This makes sense as the exact initial context of the make error does
> vary across the different failing package builds but always ends in the
> jobs being reduced to 1. The likely candidate for the failure with the gcc5
> build is the instance of...
>
> got_token = read (job_rfd, , 1);
>
> which is missing the  EINTRLOOP()  macro.
> Jack
>
> On Tue, Oct 20, 2015 at 10:52 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> Of course the 10.12 should be 10.11 (doh). FYI, the original discussion
>> of the requirement for the EINTRLOOP() macros can be found at...
>>
>> https://lists.gnu.org/archive/html/make-alpha/2001-05/msg8.html
>>
>> On Tue, Oct 20, 2015 at 10:29 PM, Jack Howarth <howarth.at.f...@gmail.com
>> > wrote:
>>
>>> FYI, I've also opened a bug report at...
>>>
>>> https://savannah.gnu.org/bugs/index.php?46261
>>>
>>> and posted the proposed fix there as well.
>>>
>>> On Tue, Oct 20, 2015 at 10:16 PM, Jack Howarth <
>>> howarth.at.f...@gmail.com> wrote:
>>>
>>>> The attached packaging adds the change...
>>>>
>>>> diff -uNr make-4.1.orig/main.c make-4.1/main.c
>>>> --- make-4.1.orig/main.c2014-10-05 12:24:51.0 -0400
>>>> +++ make-4.1/main.c 2015-10-20 22:08:00.0 -0400
>>>> @@ -3364,9 +3364,12 @@
>>>>  #else
>>>>/* Close the write side, so the read() won't hang.  */
>>>>close (job_fds[1]);
>>>> -
>>>> -  while (read (job_fds[0], , 1) == 1)
>>>> +  int r;
>>>> +  EINTRLOOP (r, read (job_fds[0], , 1));
>>>> +  while (r == 1) {
>>>>  ++tcnt;
>>>> +   EINTRLOOP (r, read (job_fds[0], , 1));
>>>> +  }
>>>>  #endif
>>>>
>>>>if (tcnt != master_job_slots)
>>>>
>>>> which seems to eliminate the build failures with make 4.1 on 10.12 here
>>>> by adding the missing usage of the EINTRLOOP() on the read calls in main.c.
>>>>  Jack
>>>>
>>>
>>>
>>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

On Wed, Oct 21, 2015 at 10:09 AM, Max Horn  wrote:

> Hi Jack,
>
> thanks for analyzing this.  I made some minor tweaks to the .info file you
> sent (mainly: update the DescPort text to explain the patch). I was about
> to commit it, but then read that there are still issues.
>
> For the time being, I am still on 10.8, so I cannot help with this.
> Anyway, if you have a working patch, I'll be happy to commit it.
>
> Cheers,
> Max


Max,
 Unfortunately, the current patch only solves one permutation of the
make 4.1 parallel build failures on 10.11 (libcurl4) . The gcc5 build fails
in a someone different fashion where the first error shown is...

make[5]: *** read jobs pipe: No such file or directory. Stop.

and ends with the usual...

make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!

If you read the original proposal for the addition of the EINTRLOOP macro
back in 2001...

https://lists.gnu.org/archive/html/make-alpha/2001-05/msg8.html

the author questioned whether all of the system calls should be wrapped
with that macro.  I suspect as Apple deviates further away from POSIX
behavior some of those will be tickled.
Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

Max,
 Actually, the remaining build failure with gcc5 using fink make-4.1-3
on 10.11 may be unique to that package. I reviewed my previous gcc bug
reports and the errors we are seeing on 10.11 with fink make look identical
to those I reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827#c5
which appeared and went latent in gcc trunk. The issue is occurring now in
the libjava build as it did then so we may simply be re-exposing a bug in
the Makefiles for libjava.
 I would go ahead and commit the changes I previously posted on
http://sourceforge.net/p/fink/package-submissions/4562/ so we can start to
accumulate more testing on the completeness of this fix for 10.11 (outside
of the gcc5 libjava build). So far it fixes the libcurl4 and r-base32
builds here with fink make on 10.11.
Jack

On Wed, Oct 21, 2015 at 6:29 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Wed, Oct 21, 2015 at 10:09 AM, Max Horn <m...@quendi.de> wrote:
>
>> Hi Jack,
>>
>> thanks for analyzing this.  I made some minor tweaks to the .info file
>> you sent (mainly: update the DescPort text to explain the patch). I was
>> about to commit it, but then read that there are still issues.
>>
>> For the time being, I am still on 10.8, so I cannot help with this.
>> Anyway, if you have a working patch, I'll be happy to commit it.
>>
>> Cheers,
>> Max
>
>
> Max,
>  Unfortunately, the current patch only solves one permutation of the
> make 4.1 parallel build failures on 10.11 (libcurl4) . The gcc5 build fails
> in a someone different fashion where the first error shown is...
>
> make[5]: *** read jobs pipe: No such file or directory. Stop.
>
> and ends with the usual...
>
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>
> If you read the original proposal for the addition of the EINTRLOOP macro
> back in 2001...
>
> https://lists.gnu.org/archive/html/make-alpha/2001-05/msg8.html
>
> the author questioned whether all of the system calls should be wrapped
> with that macro.  I suspect as Apple deviates further away from POSIX
> behavior some of those will be tickled.
> Jack
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

It looks like we are still missing some instances of  EINTRLOOP() macro
usage. The gcc5 build with fink make still fails with the proposed fix
starting at...

make[5]: *** read jobs pipe: No such file or directory.  Stop.
make[5]: *** Waiting for unfinished jobs

and resulting in

make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!

I am certain that the issue is missing instances of EINTRLOOP() on file i/o
in make 4.x but we will just have to weed through all of the different
cases. This makes sense as the exact initial context of the make error does
vary across the different failing package builds but always ends in the
jobs being reduced to 1. The likely candidate for the failure with the gcc5
build is the instance of...

got_token = read (job_rfd, , 1);

which is missing the  EINTRLOOP()  macro.
Jack

On Tue, Oct 20, 2015 at 10:52 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Of course the 10.12 should be 10.11 (doh). FYI, the original discussion of
> the requirement for the EINTRLOOP() macros can be found at...
>
> https://lists.gnu.org/archive/html/make-alpha/2001-05/msg8.html
>
> On Tue, Oct 20, 2015 at 10:29 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> FYI, I've also opened a bug report at...
>>
>> https://savannah.gnu.org/bugs/index.php?46261
>>
>> and posted the proposed fix there as well.
>>
>> On Tue, Oct 20, 2015 at 10:16 PM, Jack Howarth <howarth.at.f...@gmail.com
>> > wrote:
>>
>>> The attached packaging adds the change...
>>>
>>> diff -uNr make-4.1.orig/main.c make-4.1/main.c
>>> --- make-4.1.orig/main.c2014-10-05 12:24:51.0 -0400
>>> +++ make-4.1/main.c 2015-10-20 22:08:00.0 -0400
>>> @@ -3364,9 +3364,12 @@
>>>  #else
>>>/* Close the write side, so the read() won't hang.  */
>>>close (job_fds[1]);
>>> -
>>> -  while (read (job_fds[0], , 1) == 1)
>>> +  int r;
>>> +  EINTRLOOP (r, read (job_fds[0], , 1));
>>> +  while (r == 1) {
>>>  ++tcnt;
>>> +   EINTRLOOP (r, read (job_fds[0], , 1));
>>> +  }
>>>  #endif
>>>
>>>if (tcnt != master_job_slots)
>>>
>>> which seems to eliminate the build failures with make 4.1 on 10.12 here
>>> by adding the missing usage of the EINTRLOOP() on the read calls in main.c.
>>>  Jack
>>>
>>
>>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] tentative cause of make 4.1 regressions under fink

[Jack Howarth]

So far my testing on 10.12 suggests that the trigger for the regression
in using fink make 4.1 under 10.12 is due to the flock() usage in
Services.pm. The most reliable reproducer of this regression on my system
has been the InfoTest of libcurl4 which always fails in the compilation of
the test suite under make 4.1. Using the following hack...

--- Services.pm.orig 2015-10-20 20:06:57.0 -0400
+++ Services.pm 2015-10-20 20:09:39.0 -0400
@@ -1756,11 +1756,11 @@
  }

  my $mode = $exclusive ? LOCK_EX : LOCK_SH;
- if (flock $lockfile_FH, $mode | LOCK_NB) {
- return wantarray ? ($lockfile_FH, 0) : $lockfile_FH;
- } else {
+# if (flock $lockfile_FH, $mode | LOCK_NB) {
+# return wantarray ? ($lockfile_FH, 0) : $lockfile_FH;
+# } else {
  # Maybe the system doesn't support locking?
- if ($! == EOPNOTSUPP || $! == ENOLCK) {
+# if ($! == EOPNOTSUPP || $! == ENOLCK) {
  require Fink::Config;
  if (!defined $Fink::Config::config ||
  !$Fink::Config::config->get_option("LockWarning", 0)) {
@@ -1772,7 +1772,7 @@
  if defined $Fink::Config::config;
  }
  return ($lockfile_FH, 0);
- }
+# }

  return (wantarray ? (0, 0) : 0) if $no_block;

@@ -1808,7 +1808,7 @@
  close $lockfile_FH;
  return wantarray ? (0, 0) : 0;
  }
- }
+# }
 }

 =item dpkg_lockwait

to avoid the flock() calls in perl suppresses the failure under make 4.1 on
10.12.
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] tentative cause of make 4.1 regressions under fink

[Jack Howarth]

This is starting to make sense. The code section that I have been
suspecting in make 4.1 (which is the only place that resets the job_slots
to 1) is...

#ifndef WINDOWS32
#ifdef HAVE_FCNTL
# define FD_OK(_f) ((fcntl ((_f), F_GETFD) != -1) || (errno != EBADF))
#else
# define FD_OK(_f) 1
#endif
  /* Create a duplicate pipe, that will be closed in the SIGCHLD
 handler.  If this fails with EBADF, the parent has closed the pipe
 on us because it didn't think we were a submake.  If so, print a
 warning then default to -j1.  */
  else if (!FD_OK (job_fds[0]) || !FD_OK (job_fds[1])
   || (job_rfd = dup (job_fds[0])) < 0)
{
  if (errno != EBADF)
pfatal_with_name (_("dup jobserver"));

  O (error, NILF,
 _("warning: jobserver unavailable: using -j1.  Add '+' to
parent make rule."));
  job_slots = 1;
  job_fds[0] = job_fds[1] = -1;
}
#endif

whereas the same code section in make 3.82 (which doesn't show this bug)
is...

  /* Create a duplicate pipe, that will be closed in the SIGCHLD
 handler.  If this fails with EBADF, the parent has closed the pipe
 on us because it didn't think we were a submake.  If so, print a
 warning then default to -j1.  */

  else if ((job_rfd = dup (job_fds[0])) < 0)
{
  if (errno != EBADF)
pfatal_with_name (_("dup jobserver"));

  error (NILF,
 _("warning: jobserver unavailable: using -j1.  Add `+' to
parent make rule."));
  job_slots = 1;
}

So only make 4.1 is executing the fnctl() calls via the FD_OK macro.
Perhaps we can hack around this by causing HAVE_FCNTL to be undefined in
the fink make 4.1 build?

On Tue, Oct 20, 2015 at 8:20 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> So far my testing on 10.12 suggests that the trigger for the
> regression in using fink make 4.1 under 10.12 is due to the flock() usage
> in Services.pm. The most reliable reproducer of this regression on my
> system has been the InfoTest of libcurl4 which always fails in the
> compilation of the test suite under make 4.1. Using the following hack...
>
> --- Services.pm.orig 2015-10-20 20:06:57.0 -0400
> +++ Services.pm 2015-10-20 20:09:39.0 -0400
> @@ -1756,11 +1756,11 @@
>   }
>
>   my $mode = $exclusive ? LOCK_EX : LOCK_SH;
> - if (flock $lockfile_FH, $mode | LOCK_NB) {
> - return wantarray ? ($lockfile_FH, 0) : $lockfile_FH;
> - } else {
> +# if (flock $lockfile_FH, $mode | LOCK_NB) {
> +# return wantarray ? ($lockfile_FH, 0) : $lockfile_FH;
> +# } else {
>   # Maybe the system doesn't support locking?
> - if ($! == EOPNOTSUPP || $! == ENOLCK) {
> +# if ($! == EOPNOTSUPP || $! == ENOLCK) {
>   require Fink::Config;
>   if (!defined $Fink::Config::config ||
>   !$Fink::Config::config->get_option("LockWarning", 0)) {
> @@ -1772,7 +1772,7 @@
>   if defined $Fink::Config::config;
>   }
>   return ($lockfile_FH, 0);
> - }
> +# }
>
>   return (wantarray ? (0, 0) : 0) if $no_block;
>
> @@ -1808,7 +1808,7 @@
>   close $lockfile_FH;
>   return wantarray ? (0, 0) : 0;
>   }
> - }
> +# }
>  }
>
>  =item dpkg_lockwait
>
> to avoid the flock() calls in perl suppresses the failure under make 4.1
> on 10.12.
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] tentative cause of make 4.1 regressions under fink

[Jack Howarth]

The MacPorts developers suggest that problem may be in the code in make
4.1's main.c...

3365   /* Close the write side, so the read() won't hang.  */
3366   close (job_fds[1]);
3367
3368   while (read (job_fds[0], , 1) == 1)
3369 ++tcnt;
3370 #endif
3371
3372   if (tcnt != master_job_slots)
3373 ONN (error, NILF,
3374  "INTERNAL: Exiting with %u jobserver tokens
available; should be %u!",
3375  tcnt, master_job_slots);
3376
3377 #ifdef WINDOWS32
3378   free_jobserver_semaphore ();
3379 #else
3380   close (job_fds[0]);
3381 #endif
3382

where there is no error checking on this read()...

while (read (job_fds[0], , 1) == 1)

and if it always fails, could leave tcnt at 1 as we observe. They suggest
this could be failing with EINTR and needs the EINTRLOOP() macro as seen in
the writes (etc).

On Tue, Oct 20, 2015 at 9:03 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> This is starting to make sense. The code section that I have been
> suspecting in make 4.1 (which is the only place that resets the job_slots
> to 1) is...
>
> #ifndef WINDOWS32
> #ifdef HAVE_FCNTL
> # define FD_OK(_f) ((fcntl ((_f), F_GETFD) != -1) || (errno != EBADF))
> #else
> # define FD_OK(_f) 1
> #endif
>   /* Create a duplicate pipe, that will be closed in the SIGCHLD
>  handler.  If this fails with EBADF, the parent has closed the pipe
>  on us because it didn't think we were a submake.  If so, print a
>  warning then default to -j1.  */
>   else if (!FD_OK (job_fds[0]) || !FD_OK (job_fds[1])
>|| (job_rfd = dup (job_fds[0])) < 0)
> {
>   if (errno != EBADF)
> pfatal_with_name (_("dup jobserver"));
>
>   O (error, NILF,
>  _("warning: jobserver unavailable: using -j1.  Add '+' to
> parent make rule."));
>   job_slots = 1;
>   job_fds[0] = job_fds[1] = -1;
> }
> #endif
>
> whereas the same code section in make 3.82 (which doesn't show this bug)
> is...
>
>   /* Create a duplicate pipe, that will be closed in the SIGCHLD
>  handler.  If this fails with EBADF, the parent has closed the pipe
>  on us because it didn't think we were a submake.  If so, print a
>  warning then default to -j1.  */
>
>   else if ((job_rfd = dup (job_fds[0])) < 0)
> {
>   if (errno != EBADF)
> pfatal_with_name (_("dup jobserver"));
>
>   error (NILF,
>  _("warning: jobserver unavailable: using -j1.  Add `+' to
> parent make rule."));
>   job_slots = 1;
> }
>
> So only make 4.1 is executing the fnctl() calls via the FD_OK macro.
> Perhaps we can hack around this by causing HAVE_FCNTL to be undefined in
> the fink make 4.1 build?
>
> On Tue, Oct 20, 2015 at 8:20 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> So far my testing on 10.12 suggests that the trigger for the
>> regression in using fink make 4.1 under 10.12 is due to the flock() usage
>> in Services.pm. The most reliable reproducer of this regression on my
>> system has been the InfoTest of libcurl4 which always fails in the
>> compilation of the test suite under make 4.1. Using the following hack...
>>
>> --- Services.pm.orig 2015-10-20 20:06:57.0 -0400
>> +++ Services.pm 2015-10-20 20:09:39.0 -0400
>> @@ -1756,11 +1756,11 @@
>>   }
>>
>>   my $mode = $exclusive ? LOCK_EX : LOCK_SH;
>> - if (flock $lockfile_FH, $mode | LOCK_NB) {
>> - return wantarray ? ($lockfile_FH, 0) : $lockfile_FH;
>> - } else {
>> +# if (flock $lockfile_FH, $mode | LOCK_NB) {
>> +# return wantarray ? ($lockfile_FH, 0) : $lockfile_FH;
>> +# } else {
>>   # Maybe the system doesn't support locking?
>> - if ($! == EOPNOTSUPP || $! == ENOLCK) {
>> +# if ($! == EOPNOTSUPP || $! == ENOLCK) {
>>   require Fink::Config;
>>   if (!defined $Fink::Config::config ||
>>   !$Fink::Config::config->get_option("LockWarning", 0)) {
>> @@ -1772,7 +1772,7 @@
>>   if defined $Fink::Config::config;
>>   }
>>   return ($lockfile_FH, 0);
>> - }
>> +# }
>>
>>   return (wantarray ? (0, 0) : 0) if $no_block;
>>
>> @@ -1808,7 +1808,7 @@
>>   close $lockfile_FH;
>>   return wantarray ? (0, 0) : 0;
>>   }
>> - }
>> +# }
>>  }
>>
>>  =item dpkg_lockwait
>>
>> to avoid the flock() calls in perl suppresses the failure under make 4.1
>> on 10.12.
>>
>>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

Of course the 10.12 should be 10.11 (doh). FYI, the original discussion of
the requirement for the EINTRLOOP() macros can be found at...

https://lists.gnu.org/archive/html/make-alpha/2001-05/msg8.html

On Tue, Oct 20, 2015 at 10:29 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> FYI, I've also opened a bug report at...
>
> https://savannah.gnu.org/bugs/index.php?46261
>
> and posted the proposed fix there as well.
>
> On Tue, Oct 20, 2015 at 10:16 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> The attached packaging adds the change...
>>
>> diff -uNr make-4.1.orig/main.c make-4.1/main.c
>> --- make-4.1.orig/main.c2014-10-05 12:24:51.0 -0400
>> +++ make-4.1/main.c 2015-10-20 22:08:00.0 -0400
>> @@ -3364,9 +3364,12 @@
>>  #else
>>/* Close the write side, so the read() won't hang.  */
>>close (job_fds[1]);
>> -
>> -  while (read (job_fds[0], , 1) == 1)
>> +  int r;
>> +  EINTRLOOP (r, read (job_fds[0], , 1));
>> +  while (r == 1) {
>>  ++tcnt;
>> +   EINTRLOOP (r, read (job_fds[0], , 1));
>> +  }
>>  #endif
>>
>>if (tcnt != master_job_slots)
>>
>> which seems to eliminate the build failures with make 4.1 on 10.12 here
>> by adding the missing usage of the EINTRLOOP() on the read calls in main.c.
>>  Jack
>>
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

The attached packaging adds the change...

diff -uNr make-4.1.orig/main.c make-4.1/main.c
--- make-4.1.orig/main.c2014-10-05 12:24:51.0 -0400
+++ make-4.1/main.c 2015-10-20 22:08:00.0 -0400
@@ -3364,9 +3364,12 @@
 #else
   /* Close the write side, so the read() won't hang.  */
   close (job_fds[1]);
-
-  while (read (job_fds[0], , 1) == 1)
+  int r;
+  EINTRLOOP (r, read (job_fds[0], , 1));
+  while (r == 1) {
 ++tcnt;
+   EINTRLOOP (r, read (job_fds[0], , 1));
+  }
 #endif

   if (tcnt != master_job_slots)

which seems to eliminate the build failures with make 4.1 on 10.12 here by
adding the missing usage of the EINTRLOOP() on the read calls in main.c.
 Jack


make.info
Description: Binary data


make.patch
Description: Binary data
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fix for make 4.1 on 10.12

[Jack Howarth]

FYI, I've also opened a bug report at...

https://savannah.gnu.org/bugs/index.php?46261

and posted the proposed fix there as well.

On Tue, Oct 20, 2015 at 10:16 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> The attached packaging adds the change...
>
> diff -uNr make-4.1.orig/main.c make-4.1/main.c
> --- make-4.1.orig/main.c2014-10-05 12:24:51.0 -0400
> +++ make-4.1/main.c 2015-10-20 22:08:00.0 -0400
> @@ -3364,9 +3364,12 @@
>  #else
>/* Close the write side, so the read() won't hang.  */
>close (job_fds[1]);
> -
> -  while (read (job_fds[0], , 1) == 1)
> +  int r;
> +  EINTRLOOP (r, read (job_fds[0], , 1));
> +  while (r == 1) {
>  ++tcnt;
> +   EINTRLOOP (r, read (job_fds[0], , 1));
> +  }
>  #endif
>
>if (tcnt != master_job_slots)
>
> which seems to eliminate the build failures with make 4.1 on 10.12 here by
> adding the missing usage of the EINTRLOOP() on the read calls in main.c.
>  Jack
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make 4.x vs fink on 10.11

[Jack Howarth]

On Sat, Oct 17, 2015 at 8:01 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Looking a bit more at the failures of make 4.x under fink, I noticed that
> fink uses the perl system() call and MacPorts uses tcl's system() call as
> well. However the perl documentation has the following comment...
>
> Since system does a fork and wait it may affect a SIGCHLD handler. See
> perlipc for details.
>
> This may be critical to the bug as the diff of main.c in make 3.8.2 to 4.1
> shows following additional code...
>
> +#ifndef WINDOWS32
> +#ifdef HAVE_FCNTL
> +# define FD_OK(_f) ((fcntl ((_f), F_GETFD) != -1) || (errno != EBADF))
> +#else
> +# define FD_OK(_f) 1
> +#endif
> +  /* Create a duplicate pipe, that will be closed in the SIGCHLD
> + handler.  If this fails with EBADF, the parent has closed the
> pipe
> + on us because it didn't think we were a submake.  If so, print a
> + warning then default to -j1.  */
> +  else if (!FD_OK (job_fds[0]) || !FD_OK (job_fds[1])
> +   || (job_rfd = dup (job_fds[0])) < 0)
> +{
> +  if (errno != EBADF)
> +pfatal_with_name (_("dup jobserver"));
> +
> +  O (error, NILF,
> + _("warning: jobserver unavailable: using -j1.  Add '+' to
> parent make rule."));
> +  job_slots = 1;
> +  job_fds[0] = job_fds[1] = -1;
> +}
> +#endif
>
> So far, I am not seeing the make failures when using the older fink make
> 3.82 packaging on 10.11. Also, note that the errors we are seeing with make
> 4.1 are of the form..
>
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>
> ...where the jobs are being lowered expectedly from 8 to 1 exactly as the
> comment in main.c states. As far as I can tell, the code section above is
> the only place in make 4.1 where job_slots is reset to 1.
> Jack
> ps The MacPorts developers pointed that their system() isn't actually the
> stock tcl one but a custom version...
>
> http://trac.macports.org/browser/trunk/base/src/pextlib1.0/system.c
>
> which uses fork().
>

FYI, MacPorts have been using there own system() call for 12 years or more.
The first version with the system call placed in its own file (before all
the sandbox support was added) is about 6 years old.

http://trac.macports.org/browser/trunk/base/src/pextlib1.0/system.c?rev=53831

and might be a good starting point for a c-version of system() which would
work under perl.
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make 4.x vs fink on 10.11

[Jack Howarth]

On Sun, Oct 18, 2015 at 1:37 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> On Sat, Oct 17, 2015 at 8:01 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>> Looking a bit more at the failures of make 4.x under fink, I noticed that
>> fink uses the perl system() call and MacPorts uses tcl's system() call as
>> well. However the perl documentation has the following comment...
>>
>> Since system does a fork and wait it may affect a SIGCHLD handler. See
>> perlipc for details.
>>
>> This may be critical to the bug as the diff of main.c in make 3.8.2 to
>> 4.1 shows following additional code...
>>
>> +#ifndef WINDOWS32
>> +#ifdef HAVE_FCNTL
>> +# define FD_OK(_f) ((fcntl ((_f), F_GETFD) != -1) || (errno != EBADF))
>> +#else
>> +# define FD_OK(_f) 1
>> +#endif
>> +  /* Create a duplicate pipe, that will be closed in the SIGCHLD
>> + handler.  If this fails with EBADF, the parent has closed the
>> pipe
>> + on us because it didn't think we were a submake.  If so, print a
>> + warning then default to -j1.  */
>> +  else if (!FD_OK (job_fds[0]) || !FD_OK (job_fds[1])
>> +   || (job_rfd = dup (job_fds[0])) < 0)
>> +{
>> +  if (errno != EBADF)
>> +pfatal_with_name (_("dup jobserver"));
>> +
>> +  O (error, NILF,
>> + _("warning: jobserver unavailable: using -j1.  Add '+' to
>> parent make rule."));
>> +  job_slots = 1;
>> +  job_fds[0] = job_fds[1] = -1;
>> +}
>> +#endif
>>
>> So far, I am not seeing the make failures when using the older fink make
>> 3.82 packaging on 10.11. Also, note that the errors we are seeing with make
>> 4.1 are of the form..
>>
>> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>>
>> ...where the jobs are being lowered expectedly from 8 to 1 exactly as the
>> comment in main.c states. As far as I can tell, the code section above is
>> the only place in make 4.1 where job_slots is reset to 1.
>> Jack
>> ps The MacPorts developers pointed that their system() isn't actually the
>> stock tcl one but a custom version...
>>
>> http://trac.macports.org/browser/trunk/base/src/pextlib1.0/system.c
>>
>> which uses fork().
>>
>
> FYI, MacPorts have been using there own system() call for 12 years or
> more. The first version with the system call placed in its own file (before
> all the sandbox support was added) is about 6 years old.
>
>
> http://trac.macports.org/browser/trunk/base/src/pextlib1.0/system.c?rev=53831
>
> and might be a good starting point for a c-version of system() which would
> work under perl.
>

Actually, MacPorts use of their own system() call dates back 13 years...

http://trac.macports.org/browser/trunk/base/src/pextlib1.0/Pextlib.c?rev=214
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] make 4.x vs fink on 10.11

[Jack Howarth]

Looking a bit more at the failures of make 4.x under fink, I noticed that
fink uses the perl system() call and MacPorts uses tcl's system() call as
well. However the perl documentation has the following comment...

Since system does a fork and wait it may affect a SIGCHLD handler. See
perlipc for details.

This may be critical to the bug as the diff of main.c in make 3.8.2 to 4.1
shows following additional code...

+#ifndef WINDOWS32
+#ifdef HAVE_FCNTL
+# define FD_OK(_f) ((fcntl ((_f), F_GETFD) != -1) || (errno != EBADF))
+#else
+# define FD_OK(_f) 1
+#endif
+  /* Create a duplicate pipe, that will be closed in the SIGCHLD
+ handler.  If this fails with EBADF, the parent has closed the pipe
+ on us because it didn't think we were a submake.  If so, print a
+ warning then default to -j1.  */
+  else if (!FD_OK (job_fds[0]) || !FD_OK (job_fds[1])
+   || (job_rfd = dup (job_fds[0])) < 0)
+{
+  if (errno != EBADF)
+pfatal_with_name (_("dup jobserver"));
+
+  O (error, NILF,
+ _("warning: jobserver unavailable: using -j1.  Add '+' to
parent make rule."));
+  job_slots = 1;
+  job_fds[0] = job_fds[1] = -1;
+}
+#endif

So far, I am not seeing the make failures when using the older fink make
3.82 packaging on 10.11. Also, note that the errors we are seeing with make
4.1 are of the form..

make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!

...where the jobs are being lowered expectedly from 8 to 1 exactly as the
comment in main.c states. As far as I can tell, the code section above is
the only place in make 4.1 where job_slots is reset to 1.
Jack
ps The MacPorts developers pointed that their system() isn't actually the
stock tcl one but a custom version...

http://trac.macports.org/browser/trunk/base/src/pextlib1.0/system.c

which uses fork().
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] A few 10.11 glitches and possible workarounds

[Jack Howarth]

On Wed, Oct 14, 2015 at 5:24 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> On Oct 1, 2015, at 12:24, Alexander Hansen <alexanderk.han...@gmail.com>
> wrote:
>
>
> On Oct 1, 2015, at 11:41, Alexander Hansen <alexanderk.han...@gmail.com>
> wrote:
>
>
> On Oct 1, 2015, at 11:24, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
>
>
> On Thu, Oct 1, 2015 at 12:02 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Oct 1, 2015 at 12:33 AM, William G. Scott <wgsc...@ucsc.edu>
>> wrote:
>>
>>> In the course of building some of my packages, a few dependencies failed
>>> to compile, requiring minor tweaks:
>>>
>>> gtk+2  — I had to change to UseMaxBuildJobs: false
>>> libvpx14  — I had to change to UseMaxBuildJobs: false
>>>
>>
>> Bill,
>>  I suspect you have the fink make package installed, no? If so, the
>> failures should have been accompanied with an error message of the form...
>>
>> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>>
>> This breakage in the parallel make of fink make impacts a slew of fink
>> package builds on machines with more than 2 cores (eg the cmake, libcurl4,
>> texlive-base, etc builds).
>> A better fix would be to revert your package back to UseMaxBuildJobs:
>> true but hard code' /usr/bin/make' rather than just 'make'.
>> Jack
>> ps The issue seems to be limited to running fink make from within perl
>> under fink. I've not been able to reproduce the build failures outside of
>> fink or with just within perl itself.
>>
>
> Actually, I never saw a problem building gtk+2 on a dual quad-core MacPro
> but this re-enforces my suspicion that the problem with fink make is a
> threading race condition that will selectively trigger depending on the
> number of cores and processor speed of a given machine (meaning that all
> parallel builds under fink make on 10.11 are fragile). Perhaps a better fix
> would be to have fink conditionally use /usr/bin/make rather than make for
> the CompileScript's default_script when executed on 10.11. This would at
> least automatically solve the issue for all packages using
> %{default_script}.
>
>
>
> We can default to /usr/bin/make on 10.9-10.11 unconditionally and let
> individual packages that need fink’s make override that in their
> CompileScripts.  That’d be simpler, and more consistent with our general
> practices with regard to build tools.
>
> Then we can add a conditional if Apple decides to stop shipping a
> /usr/bin/make with Xcode.
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
> I just created a default-to-usr-bin-make branch off of the fink-0.39.x
> release tree and an accompanying pull request:
>
> https://github.com/fink/fink/pull/125
>
> People who are interested in testing whether defaulting to /usr/bin/make
> has any unforeseen consequences can do so by checking out that branch and
> using inject.pl to install it.
>
> Because this is branched from the release branch, a selfupdate will still
> bring you a new release fink-0.39.x when one comes out.
>
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
> The pull request (which also changes some other system tool invocations
> explicitly to use built-in versions) has been merged into branch_0_39 as
> well as master.
>
> Note that this only overrides the %{default_script} behavior—packages with
> custom CompileScripts that don’t use %{default_script} will need to to
> enforce /usr/bin/make manually if they need to do that.
>

You probably also want to switch the fink make package over to building
gmake and use a symlink to make in a make-default split-off. The make 4.1
release is badly destabilized on 10.11 under fink and I suspect that a
large number of packages will eventually fail for someone or another
depending on their exact hardware configuration (since this seems to be a
race condition).
   Jack
ps I would be interested to find out if anyone manages to trigger these
failures in any package build outside of fink itself. The problem seems to
be entirely specific to running fink make under the fink/perl combination.
MacPorts seems entirely immune but they don't build under perl.


>
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
>
> --
>
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] java16 on El Capitan

[Jack Howarth]

On Sat, Oct 3, 2015 at 2:18 PM, Hanspeter Niederstrasser <
f...@snaggledworks.com> wrote:

> If I'm reading fink-virtual-packages correctly, 1.6 was the last version
> provided by Apple, and 1.7+ must be gotten from Oracle. Is that correct?
>   When Martin's fix gets released, would best practices be to keep
> pointing packages to system-java16 since its a system tool, or would it
> be preferred to point to a newer java if the package allows it
> (virtuoso, which started this thread, has the option to use java17)?
> Java16 is really old.
>
>
There are a few packages like rstudio-desktop/server whose builds still
demand the framework java. Unfortunately, I suspect upstream won't bother
to fix that until java16 actually disappears in 10.12.


> Hanspeter
>
>
> --
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] A few 10.11 glitches and possible workarounds

[Jack Howarth]

On Thu, Oct 1, 2015 at 12:33 AM, William G. Scott  wrote:

> In the course of building some of my packages, a few dependencies failed
> to compile, requiring minor tweaks:
>
> gtk+2  — I had to change to UseMaxBuildJobs: false
> libvpx14  — I had to change to UseMaxBuildJobs: false
>

Bill,
 I suspect you have the fink make package installed, no? If so, the
failures should have been accompanied with an error message of the form...

make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!

This breakage in the parallel make of fink make impacts a slew of fink
package builds on machines with more than 2 cores (eg the cmake, libcurl4,
texlive-base, etc builds).
A better fix would be to revert your package back to UseMaxBuildJobs: true
but hard code' /usr/bin/make' rather than just 'make'.
Jack
ps The issue seems to be limited to running fink make from within perl
under fink. I've not been able to reproduce the build failures outside of
fink or with just within perl itself.

Also, $X11_BASE_DIR doesn’t seem to get set.
>
>
> Bill Scott
>
>
>
>
> --
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] A few 10.11 glitches and possible workarounds

[Jack Howarth]

On Thu, Oct 1, 2015 at 12:02 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Thu, Oct 1, 2015 at 12:33 AM, William G. Scott <wgsc...@ucsc.edu>
> wrote:
>
>> In the course of building some of my packages, a few dependencies failed
>> to compile, requiring minor tweaks:
>>
>> gtk+2  — I had to change to UseMaxBuildJobs: false
>> libvpx14  — I had to change to UseMaxBuildJobs: false
>>
>
> Bill,
>  I suspect you have the fink make package installed, no? If so, the
> failures should have been accompanied with an error message of the form...
>
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>
> This breakage in the parallel make of fink make impacts a slew of fink
> package builds on machines with more than 2 cores (eg the cmake, libcurl4,
> texlive-base, etc builds).
> A better fix would be to revert your package back to UseMaxBuildJobs: true
> but hard code' /usr/bin/make' rather than just 'make'.
> Jack
> ps The issue seems to be limited to running fink make from within perl
> under fink. I've not been able to reproduce the build failures outside of
> fink or with just within perl itself.
>

Actually, I never saw a problem building gtk+2 on a dual quad-core MacPro
but this re-enforces my suspicion that the problem with fink make is a
threading race condition that will selectively trigger depending on the
number of cores and processor speed of a given machine (meaning that all
parallel builds under fink make on 10.11 are fragile). Perhaps a better fix
would be to have fink conditionally use /usr/bin/make rather than make for
the CompileScript's default_script when executed on 10.11. This would at
least automatically solve the issue for all packages using
%{default_script}.


>
> Also, $X11_BASE_DIR doesn’t seem to get set.
>>
>>
>> Bill Scott
>>
>>
>>
>>
>> --
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> List archive:
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel
>>
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] A few 10.11 glitches and possible workarounds

[Jack Howarth]

On Thu, Oct 1, 2015 at 2:41 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

>
> On Oct 1, 2015, at 11:24, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
>
>
> On Thu, Oct 1, 2015 at 12:02 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Oct 1, 2015 at 12:33 AM, William G. Scott <wgsc...@ucsc.edu>
>> wrote:
>>
>>> In the course of building some of my packages, a few dependencies failed
>>> to compile, requiring minor tweaks:
>>>
>>> gtk+2  — I had to change to UseMaxBuildJobs: false
>>> libvpx14  — I had to change to UseMaxBuildJobs: false
>>>
>>
>> Bill,
>>  I suspect you have the fink make package installed, no? If so, the
>> failures should have been accompanied with an error message of the form...
>>
>> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>>
>> This breakage in the parallel make of fink make impacts a slew of fink
>> package builds on machines with more than 2 cores (eg the cmake, libcurl4,
>> texlive-base, etc builds).
>> A better fix would be to revert your package back to UseMaxBuildJobs:
>> true but hard code' /usr/bin/make' rather than just 'make'.
>> Jack
>> ps The issue seems to be limited to running fink make from within perl
>> under fink. I've not been able to reproduce the build failures outside of
>> fink or with just within perl itself.
>>
>
> Actually, I never saw a problem building gtk+2 on a dual quad-core MacPro
> but this re-enforces my suspicion that the problem with fink make is a
> threading race condition that will selectively trigger depending on the
> number of cores and processor speed of a given machine (meaning that all
> parallel builds under fink make on 10.11 are fragile). Perhaps a better fix
> would be to have fink conditionally use /usr/bin/make rather than make for
> the CompileScript's default_script when executed on 10.11. This would at
> least automatically solve the issue for all packages using
> %{default_script}.
>
>
>
> We can default to /usr/bin/make on 10.9-10.11 unconditionally and let
> individual packages that need fink’s make override that in their
> CompileScripts.  That’d be simpler, and more consistent with our general
> practices with regard to build tools.
>
>
It would be a good idea to also modify the fink make package to build
with the g-prefix and implement the make-default split-off to provide the
make symlink to gmake. Then just note that usage of make-default on 10.11
is for masochists only.

Then we can add a conditional if Apple decides to stop shipping a
> /usr/bin/make with Xcode.
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
>
> --
>
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] wxwidgets300.info and deprecating wxcocoa295.info/wxwidgets300-cocoa.info in 10.9-libc++

[Jack Howarth]

Alexander,
  Both the 10.7 and 10.9-libc++ trees need the change...

Index: wxwidgets300.info
===
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/libs/
wxwidgets300.info,v
retrieving revision 1.2
diff -r1.2 wxwidgets300.info
42c42
< system-sdk-10.7 | system-sdk-10.8 | system-sdk-10.9 | system-sdk-10.10,
---
> system-sdk-10.7 | system-sdk-10.8 | system-sdk-10.9 | system-sdk-10.10 |
system-sdk-10.11,

for El Capitan support. Also, is there a reason not to deprecate the legacy
wxcocoa295.info and wxwidgets300-cocoa.info files in the 10.9-libc++ tree?
Only three packages, all maintained by BABA Yoshihiko, are blocking this.
The database/spatialite-gui.info package needs bumped from Depends
wxcocoa295-shlibs and BuildDepends wxcocoa295 to Depends
wxwidgets300-osxcocoa-shlibs and BuildDepends wxwidgets300-osxcocoa. The
sci/grass70.info and sci/saga.info packaging needs bumped from Depends
wxwidgets300-cocoa-shlibs and BuildDepends wxwidgets300-cocoa to Depends
wxwidgets300-osxcocoa-shlibs and BuildDepends wxwidgets300-osxcocoa-shlibs.
 Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] unmaintaining packages

[Jack Howarth]

Alexander,
   Please consider all of my packages as unmaintained and reassign them
as Maintainer: None . Thanks in advance.
Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] pruning ruby packaging in 10.9-libc++ tree

[Jack Howarth]

Daniel,
 Any reason why we can't prune back the five different ruby packages in
the 10.9-libc++ to just the most current ruby22 packaging? I only see a
BuildConflicts on these packages in net/epic5.info and the legacy commented
BuildDepends line in languages/swig.info and languages/swig302.info.
  Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] box.info, box-0.2.2.info and box-0.3.4.info

[Jack Howarth]

Daniel,
  Is there any reason to maintain the box-0.2.2.info and box-0.3.4.info
packaging in the 10.9-libc++ tree? I don't see any packages currently in
the 10.9-libc++ tree with a BuildDepends on libboxcore0.2 or libboxcore0.3.
Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] deprecating openexr6/ilmbase out of 10.9-libc++ tree

[Jack Howarth]

Daniel,
  Thats is

On Tue, Sep 22, 2015 at 9:35 AM, Daniel Johnson <dan...@daniel-johnson.org>
wrote:

>
> > On Sep 20, 2015, at 12:08 PM, Jack Howarth <howarth.at.f...@gmail.com>
> wrote:
> >
> > There is no reason to carry along the ilmbase and libopenexr6
> packaging into the 10.9-libc++ tree when the newer ilmbase12 and
> libopenexr22 packages are fully compatible replacements. We only have a
> very few packages left which need to be adjusted for this change in both
> the 10.7 and 10.9-libc++ trees (note that ilmbase/libopenexr6 remains in
> the 10.7 tree but we want to keep the packaging in sync). The packages
> which need updated for this change are...
> >
> > Pete Woods <f...@pete-woods.com>
> > graphics/enblend-enfuse.info
> >
> > Daniel Johnson <dan...@daniel-johnson.org>
> > graphics/libdevil1.info
> >
> > Hanspeter Niederstrasser <nie...@users.sourceforge.net>
> > graphics/vigra4.info
> > graphics/vigra5.info
> > kde/kdebase4-runtime.info
> > kde/kdelibs4.info
> > kde/kimageformat-plugins.info
> >
> > Thanks in advance for updating those to BDeps ilmbase12/libopenexr22 and
> Dep ilmbase22-shlibs/libopenexr22-shlibs.
> > Jack
>
> I tried, but libdevil1 won’t build with libopenexr22. I get lots of
> undeclared identifier errors for IMATH_NAMESPACE and “error: no type named
> ‘Int64’ in namespace ‘Imf’; did you mean ‘Imath::Int64’”. Looks like the
> openexr api has changed?
>
> Daniel
>
>
Daniel,
  I am not seeing that issue here on 10.11 with the current 10.9-libc++
tree using the attached libdevil1.info which the simple change...

Index: libdevil1.info
===
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/graphics/
libdevil1.info,v
retrieving revision 1.2
diff -r1.2 libdevil1.info
3c3
< Revision: 111
---
> Revision: 112
53c53
< ilmbase,
---
> ilmbase12,
59c59
< libopenexr6,
---
> libopenexr22,
130c130
< libopenexr6-shlibs,
---
> libopenexr22-shlibs,

The build log is also attached.
 Jack


build.log.bz2
Description: BZip2 compressed data


libdevil1.info
Description: Binary data
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] deprecating openexr6/ilmbase out of 10.9-libc++ tree

[Jack Howarth]

On Tue, Sep 22, 2015 at 9:52 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> Daniel,
>   Thats is
>
> On Tue, Sep 22, 2015 at 9:35 AM, Daniel Johnson <dan...@daniel-johnson.org
> > wrote:
>
>>
>> > On Sep 20, 2015, at 12:08 PM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> >
>> > There is no reason to carry along the ilmbase and libopenexr6
>> packaging into the 10.9-libc++ tree when the newer ilmbase12 and
>> libopenexr22 packages are fully compatible replacements. We only have a
>> very few packages left which need to be adjusted for this change in both
>> the 10.7 and 10.9-libc++ trees (note that ilmbase/libopenexr6 remains in
>> the 10.7 tree but we want to keep the packaging in sync). The packages
>> which need updated for this change are...
>> >
>> > Pete Woods <f...@pete-woods.com>
>> > graphics/enblend-enfuse.info
>> >
>> > Daniel Johnson <dan...@daniel-johnson.org>
>> > graphics/libdevil1.info
>> >
>> > Hanspeter Niederstrasser <nie...@users.sourceforge.net>
>> > graphics/vigra4.info
>> > graphics/vigra5.info
>> > kde/kdebase4-runtime.info
>> > kde/kdelibs4.info
>> > kde/kimageformat-plugins.info
>> >
>> > Thanks in advance for updating those to BDeps ilmbase12/libopenexr22
>> and Dep ilmbase22-shlibs/libopenexr22-shlibs.
>> > Jack
>>
>> I tried, but libdevil1 won’t build with libopenexr22. I get lots of
>> undeclared identifier errors for IMATH_NAMESPACE and “error: no type named
>> ‘Int64’ in namespace ‘Imf’; did you mean ‘Imath::Int64’”. Looks like the
>> openexr api has changed?
>>
>> Daniel
>>
>>
> Daniel,
>   I am not seeing that issue here on 10.11 with the current
> 10.9-libc++ tree using the attached libdevil1.info which the simple
> change...
>
> Index: libdevil1.info
> ===
> RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/graphics/
> libdevil1.info,v
> retrieving revision 1.2
> diff -r1.2 libdevil1.info
> 3c3
> < Revision: 111
> ---
> > Revision: 112
> 53c53
> < ilmbase,
> ---
> > ilmbase12,
> 59c59
> < libopenexr6,
> ---
> > libopenexr22,
> 130c130
> < libopenexr6-shlibs,
> ---
> > libopenexr22-shlibs,
>
> The build log is also attached.
>  Jack
>

Daniel,
   You might try deinstalling the current libdevil1 packages before you
try rebuilding against ilmbase12/libopenexr22 on the off chance that the
build is leaky.
 Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.1-3 with make-default split-off

[Jack Howarth]

On Sat, Sep 19, 2015 at 9:13 AM, Max Horn <m...@quendi.de> wrote:

> Hi again,
>
> On 16.09.2015, at 14:42, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
> > MacPorts gmake doesn't show the problem on the command line or in their
> builds but I have only been able to test a rather narrow set of MacPorts
> builds against their gmake. However I have been able to reproduce the build
> failures under fink when the call to 'make' is substituted with
> '/opt/local/bin/make' to invoke their copy.
>
> That's interesting, and a bit weird... But at least it suggest that it is
> directly not our "fault" for breaking GNU make, it may just be broken in
> general on Mac OS X 10.11... Not that this insight helps anybody faced with
> the problem :-/.
>
>
>
> > I doubt a unique set of packages exists to protect from this bug with
> the usage of /usr/bin/make. The bug looks to be a race condition in the
> threading support as tweaking the optimization of make build modulates the
> number of packages that fail under fink make. Likewise reducing the number
> of cores in the parallel build can suppress the bug. Also, when I debugged
> this by adding -d, only one of the failing tests, texlive-base, remained
> and even then only randomly. So the real question will be how many users
> machines have the cores/speed to tickle the bug. My past experience with
> Apple and threading bugs is that it is futile to expect them to be fixed in
> a given OS release and usually you have to wait for the next major kernel
> rewrite.
>
> So, what shall we do then?
>
>
> * Just "patch" affected packages to workaround the issue
>
> * Split "make" as Jack proposed (i.e. package "make" only provides a
> "gmake" binary, and "make-default" provides a "make" symlink to it, similar
> to e.g. coreutils-default).
>However, I'd prefer to *only* do that on 10.11, as to minimize the
> impact this has on users. That said, my hope is that whether Apple's and
> our make is used for most users...
>
>
> Cheers,
> Max


Max,
 The regression seems impossible to duplicate outside of fink. Using
the libcurl4 build which fails in fink make during the InfoTest run and a
copy of fink modified to emit the contents of %ENV with...

 --- PkgVersion.pm.orig 2015-09-21 12:57:25.0 -0400
+++ PkgVersion.pm 2015-09-21 13:05:37.0 -0400
@@ -5230,6 +5230,11 @@
  $nonroot_okay = $nonroot_okay && $build_as_nobody;
  {
  local %ENV = %{$self->get_env($phase)};
+ my @keys = keys %ENV;
+ my @values = values %ENV;
+ while (@keys) {
+ print pop(@keys), '=', pop(@values), "\n";
+ }
  $result = ($script, nonroot_okay=>$nonroot_okay);
  }
  if ($result and !$ignore_result) {

I used the /tmp/fink.U7E7Q InfoTest script left from the failed build with
the addition of...

use lib "/sw/lib/perl5";

and -j8 appended to the make line as well as export lines in the bash
script for all of  the environmentals reportedly set during the failing
InfoTest run. Executing...

[Jack-Howarths-Computer:fink.build/libcurl4-7.44.0-1+10.8/curl-7.44.0]
howarth% sudo -u fink-bld /tmp/fink.U7E7Q

repeatedly succeeds whereas the fink -m build constantly fails in the
InfoTest. Weird.
Jack
ps The only thing left to do is try to craft an additional layer of
indirection such that the execution of /tmp/fink.U7E7Q is done from within
perl rather than on the command line.
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.1-3 with make-default split-off

[Jack Howarth]

On Mon, Sep 21, 2015 at 1:48 PM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Sat, Sep 19, 2015 at 9:13 AM, Max Horn <m...@quendi.de> wrote:
>
>> Hi again,
>>
>> On 16.09.2015, at 14:42, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>
>> > MacPorts gmake doesn't show the problem on the command line or in their
>> builds but I have only been able to test a rather narrow set of MacPorts
>> builds against their gmake. However I have been able to reproduce the build
>> failures under fink when the call to 'make' is substituted with
>> '/opt/local/bin/make' to invoke their copy.
>>
>> That's interesting, and a bit weird... But at least it suggest that it is
>> directly not our "fault" for breaking GNU make, it may just be broken in
>> general on Mac OS X 10.11... Not that this insight helps anybody faced with
>> the problem :-/.
>>
>>
>>
>> > I doubt a unique set of packages exists to protect from this bug with
>> the usage of /usr/bin/make. The bug looks to be a race condition in the
>> threading support as tweaking the optimization of make build modulates the
>> number of packages that fail under fink make. Likewise reducing the number
>> of cores in the parallel build can suppress the bug. Also, when I debugged
>> this by adding -d, only one of the failing tests, texlive-base, remained
>> and even then only randomly. So the real question will be how many users
>> machines have the cores/speed to tickle the bug. My past experience with
>> Apple and threading bugs is that it is futile to expect them to be fixed in
>> a given OS release and usually you have to wait for the next major kernel
>> rewrite.
>>
>> So, what shall we do then?
>>
>>
>> * Just "patch" affected packages to workaround the issue
>>
>> * Split "make" as Jack proposed (i.e. package "make" only provides a
>> "gmake" binary, and "make-default" provides a "make" symlink to it, similar
>> to e.g. coreutils-default).
>>However, I'd prefer to *only* do that on 10.11, as to minimize the
>> impact this has on users. That said, my hope is that whether Apple's and
>> our make is used for most users...
>>
>>
>> Cheers,
>> Max
>
>
> Max,
>  The regression seems impossible to duplicate outside of fink. Using
> the libcurl4 build which fails in fink make during the InfoTest run and a
> copy of fink modified to emit the contents of %ENV with...
>
>  --- PkgVersion.pm.orig 2015-09-21 12:57:25.0 -0400
> +++ PkgVersion.pm 2015-09-21 13:05:37.0 -0400
> @@ -5230,6 +5230,11 @@
>   $nonroot_okay = $nonroot_okay && $build_as_nobody;
>   {
>   local %ENV = %{$self->get_env($phase)};
> + my @keys = keys %ENV;
> + my @values = values %ENV;
> + while (@keys) {
> + print pop(@keys), '=', pop(@values), "\n";
> + }
>   $result = ($script, nonroot_okay=>$nonroot_okay);
>   }
>   if ($result and !$ignore_result) {
>
> I used the /tmp/fink.U7E7Q InfoTest script left from the failed build with
> the addition of...
>
> use lib "/sw/lib/perl5";
>
> and -j8 appended to the make line as well as export lines in the bash
> script for all of  the environmentals reportedly set during the failing
> InfoTest run. Executing...
>
> [Jack-Howarths-Computer:fink.build/libcurl4-7.44.0-1+10.8/curl-7.44.0]
> howarth% sudo -u fink-bld /tmp/fink.U7E7Q
>
> repeatedly succeeds whereas the fink -m build constantly fails in the
> InfoTest. Weird.
> Jack
> ps The only thing left to do is try to craft an additional layer of
> indirection such that the execution of /tmp/fink.U7E7Q is done from within
> perl rather than on the command line.
>

A bit closer to fink was duplicated with...

cd tests
sudo -u fink-bld make clean
cd ..
/usr/bin/perl -e 'system("sudo", "-u". "fink-bld", "/tmp/fink.U7E7Q")'

and this also refuses to trigger the bug outside of fink itself.
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] deprecating openexr6/ilmbase out of 10.9-libc++ tree

[Jack Howarth]

There is no reason to carry along the ilmbase and libopenexr6 packaging
into the 10.9-libc++ tree when the newer ilmbase12 and libopenexr22
packages are fully compatible replacements. We only have a very few
packages left which need to be adjusted for this change in both the 10.7
and 10.9-libc++ trees (note that ilmbase/libopenexr6 remains in the 10.7
tree but we want to keep the packaging in sync). The packages which need
updated for this change are...

Pete Woods 
graphics/enblend-enfuse.info

Daniel Johnson 
graphics/libdevil1.info

Hanspeter Niederstrasser 
graphics/vigra4.info
graphics/vigra5.info
kde/kdebase4-runtime.info
kde/kdelibs4.info
kde/kimageformat-plugins.info

Thanks in advance for updating those to BDeps ilmbase12/libopenexr22 and
Dep ilmbase22-shlibs/libopenexr22-shlibs.
Jack
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.1-3 with make-default split-off

[Jack Howarth]

On Sat, Sep 19, 2015 at 9:13 AM, Max Horn <m...@quendi.de> wrote:

> Hi again,
>
> On 16.09.2015, at 14:42, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
> > MacPorts gmake doesn't show the problem on the command line or in their
> builds but I have only been able to test a rather narrow set of MacPorts
> builds against their gmake. However I have been able to reproduce the build
> failures under fink when the call to 'make' is substituted with
> '/opt/local/bin/make' to invoke their copy.
>
> That's interesting, and a bit weird... But at least it suggest that it is
> directly not our "fault" for breaking GNU make, it may just be broken in
> general on Mac OS X 10.11... Not that this insight helps anybody faced with
> the problem :-/.
>
>
>
> > I doubt a unique set of packages exists to protect from this bug with
> the usage of /usr/bin/make. The bug looks to be a race condition in the
> threading support as tweaking the optimization of make build modulates the
> number of packages that fail under fink make. Likewise reducing the number
> of cores in the parallel build can suppress the bug. Also, when I debugged
> this by adding -d, only one of the failing tests, texlive-base, remained
> and even then only randomly. So the real question will be how many users
> machines have the cores/speed to tickle the bug. My past experience with
> Apple and threading bugs is that it is futile to expect them to be fixed in
> a given OS release and usually you have to wait for the next major kernel
> rewrite.
>
> So, what shall we do then?
>
>
> * Just "patch" affected packages to workaround the issue
>
> * Split "make" as Jack proposed (i.e. package "make" only provides a
> "gmake" binary, and "make-default" provides a "make" symlink to it, similar
> to e.g. coreutils-default).
>However, I'd prefer to *only* do that on 10.11, as to minimize the
> impact this has on users. That said, my hope is that whether Apple's and
> our make is used for most users...
>
>
> Cheers,
> Max


Max,
 I've been exploring this issue on MacPorts under 10.11 with the
change...

--- /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl.orig 2015-09-18
16:23:32.0 -0400
+++ /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl 2015-09-18
18:52:23.0 -0400
@@ -56,7 +56,7 @@
  variable unzip_path "/usr/bin/unzip"
  variable zip_path "/usr/bin/zip"
  variable lsbom_path "/usr/bin/lsbom"
- variable make_path "/usr/bin/make"
+ variable make_path "/opt/local/bin/gmake"
  variable gnumake_path "/usr/bin/gnumake"
  variable bsdmake_path ""
  variable mkbom_path "/usr/bin/mkbom"

and...

sandbox_enable  no

in /opt/local/etc/macports/macports.conf to disable their default use of
Apple's sandbox during port builds. Building through a large number of
packages (including many that trigger the bug on fink), I have been unable
to trigger the bug (despite the fact the the gmake built by MacPorts can
trigger the bug in fink builds).
  I suspect we are looking at some issue specific to building as an
exec() under perl. Unfortunately, so far I have been unable to replicate
the failures when building manually on the command line from inside of the
system perl. The most sensible approach is to continue down that path and
try to enhance the command line testing from within perl until we fully
duplicate the steps being used by fink. Only thing can we file a sensible
radar bug report.
Jack
ps I have also been able to reproduce some of these failures under
fink with MaxBuildJobs: 4,
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.1-3 with make-default split-off

[Jack Howarth]

On Sat, Sep 19, 2015 at 9:41 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Sat, Sep 19, 2015 at 9:13 AM, Max Horn <m...@quendi.de> wrote:
>
>> Hi again,
>>
>> On 16.09.2015, at 14:42, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>
>> > MacPorts gmake doesn't show the problem on the command line or in their
>> builds but I have only been able to test a rather narrow set of MacPorts
>> builds against their gmake. However I have been able to reproduce the build
>> failures under fink when the call to 'make' is substituted with
>> '/opt/local/bin/make' to invoke their copy.
>>
>> That's interesting, and a bit weird... But at least it suggest that it is
>> directly not our "fault" for breaking GNU make, it may just be broken in
>> general on Mac OS X 10.11... Not that this insight helps anybody faced with
>> the problem :-/.
>>
>>
>>
>> > I doubt a unique set of packages exists to protect from this bug with
>> the usage of /usr/bin/make. The bug looks to be a race condition in the
>> threading support as tweaking the optimization of make build modulates the
>> number of packages that fail under fink make. Likewise reducing the number
>> of cores in the parallel build can suppress the bug. Also, when I debugged
>> this by adding -d, only one of the failing tests, texlive-base, remained
>> and even then only randomly. So the real question will be how many users
>> machines have the cores/speed to tickle the bug. My past experience with
>> Apple and threading bugs is that it is futile to expect them to be fixed in
>> a given OS release and usually you have to wait for the next major kernel
>> rewrite.
>>
>> So, what shall we do then?
>>
>>
>> * Just "patch" affected packages to workaround the issue
>>
>> * Split "make" as Jack proposed (i.e. package "make" only provides a
>> "gmake" binary, and "make-default" provides a "make" symlink to it, similar
>> to e.g. coreutils-default).
>>However, I'd prefer to *only* do that on 10.11, as to minimize the
>> impact this has on users. That said, my hope is that whether Apple's and
>> our make is used for most users...
>>
>>
>> Cheers,
>> Max
>
>
> Max,
>  I've been exploring this issue on MacPorts under 10.11 with the
> change...
>
> --- /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl.orig 2015-09-18
> 16:23:32.0 -0400
> +++ /opt/local/libexec/macports/lib/port1.0/port_autoconf.tcl 2015-09-18
> 18:52:23.0 -0400
> @@ -56,7 +56,7 @@
>   variable unzip_path "/usr/bin/unzip"
>   variable zip_path "/usr/bin/zip"
>   variable lsbom_path "/usr/bin/lsbom"
> - variable make_path "/usr/bin/make"
> + variable make_path "/opt/local/bin/gmake"
>   variable gnumake_path "/usr/bin/gnumake"
>   variable bsdmake_path ""
>   variable mkbom_path "/usr/bin/mkbom"
>
> and...
>
> sandbox_enable  no
>
> in /opt/local/etc/macports/macports.conf to disable their default use of
> Apple's sandbox during port builds. Building through a large number of
> packages (including many that trigger the bug on fink), I have been unable
> to trigger the bug (despite the fact the the gmake built by MacPorts can
> trigger the bug in fink builds).
>   I suspect we are looking at some issue specific to building as an
> exec() under perl. Unfortunately, so far I have been unable to replicate
> the failures when building manually on the command line from inside of the
> system perl. The most sensible approach is to continue down that path and
> try to enhance the command line testing from within perl until we fully
> duplicate the steps being used by fink. Only thing can we file a sensible
> radar bug report.
> Jack
> ps I have also been able to reproduce some of these failures under
> fink with MaxBuildJobs: 4,
>
>
>
Alternatively, perhaps dpkg is the trigger? Does anyone know if it is
possible to trick fink's dpkg to build a package on the command line
outside of fink and thus the system perl? That would be an interesting test
to use on one of the failing package builds.
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Issue with fink-buildenv-modules and Xcode 7 on 10.10.

[Jack Howarth]

On Fri, Sep 18, 2015 at 10:58 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

> % xcodebuild -version -sdk macosx10
>
> xcodebuild: error: SDK "macosx10" cannot be located.
>
>
> On Fri, Sep 18, 2015 at 10:55 AM, Hanspeter Niederstrasser <
> f...@snaggledworks.com> wrote:
>
>>
>> On Thu, September 17, 2015 6:47 pm, Alexander Hansen wrote:
>> > Hi.
>> >
>> > %p/sbin/fink-buildenv-helper.sh appears to assume that there is an SDK
>> > directory corresponding to the OS X version.  However, with Xcode 7 on
>> > 10.10 this isn’t the case—there is only a 10.11 SDK.  This results
>> in
>> > $SDK_PATH not being set.
>> >
>> > I’m not sure how many packages care.  wxwidgets300 currently uses
>> > $SDK_PATH, but it doesn’t seem like the build really needs that to be
>> > set any more.
>> >
>> > Just thought you might like to know in case folks started complaining.
>> :-)
>>
>> The SDK_* variables were originally introduced to deal with cmake that was
>> often stoopid when SDK_VERSION and MACOSX_DEPLOYMENT_TARGET versions
>> didn't agree. Since we generally don't cross compile, not sure how many
>> packages actually need to have the SDK_PATH available (but it can't hurt
>> to have f-b-m be smarter about what the current available SDK is).
>>
>> On 10.10 with 10.11 SDK only, what does 'xcodebuild -version -sdk
>> macosx10' output?
>>
>> Hanspeter
>>
>> --
>>
>>
Note that current make 3.3.x won't throw an error over this. It only emits
a warning that the SDK is newer than the deployment target and proceeds.
However you may run into issues with headers which are fully deprecated in
the newer SDK (like openssl in 10.11) and need to resort to...

-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \
-DCMAKE_OSX_SYSROOT:STRING=/ \

in order to get the 10.10 SDK installed by the 'legacy' CLI,


>>
>>
>> --
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> List archive:
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel
>>
>
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Issue with fink-buildenv-modules and Xcode 7 on 10.10.

[Jack Howarth]

% xcodebuild -version -sdk macosx10

xcodebuild: error: SDK "macosx10" cannot be located.


On Fri, Sep 18, 2015 at 10:55 AM, Hanspeter Niederstrasser <
f...@snaggledworks.com> wrote:

>
> On Thu, September 17, 2015 6:47 pm, Alexander Hansen wrote:
> > Hi.
> >
> > %p/sbin/fink-buildenv-helper.sh appears to assume that there is an SDK
> > directory corresponding to the OS X version.  However, with Xcode 7 on
> > 10.10 this isn’t the case—there is only a 10.11 SDK.  This results in
> > $SDK_PATH not being set.
> >
> > I’m not sure how many packages care.  wxwidgets300 currently uses
> > $SDK_PATH, but it doesn’t seem like the build really needs that to be
> > set any more.
> >
> > Just thought you might like to know in case folks started complaining.
> :-)
>
> The SDK_* variables were originally introduced to deal with cmake that was
> often stoopid when SDK_VERSION and MACOSX_DEPLOYMENT_TARGET versions
> didn't agree. Since we generally don't cross compile, not sure how many
> packages actually need to have the SDK_PATH available (but it can't hurt
> to have f-b-m be smarter about what the current available SDK is).
>
> On 10.10 with 10.11 SDK only, what does 'xcodebuild -version -sdk
> macosx10' output?
>
> Hanspeter
>
> --
>
>
>
>
> --
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] pruning the llvm* packages

[Jack Howarth]

David,
   With the new 10.9-libcxx tree, we should take the opportunity to
prune down the number of llvm* packages. Also, I am leaning towards pruning
out the dragonegg-gcc packaging as it is dead upstream and the last
upstream release doesn't build against clang 3.5 or any gcc newer than 4.8.
Is it okay if we remove...

llvm31.info
llvm31.patch
llvm32.info
llvm32.patch
llvm33.patch
llvm34-clang-iomp5.patch
llvm34-clang-omp.patch
llvm34-clang.patch
llvm34-compiler-rt.patch
llvm34-libcxx.patch
llvm34-openmp-cmake.patch
llvm34-polly.patch
llvm34.info
llvm34.patch
dragonegg-gcc.info
dragonegg-gcc.patch

in the process of adding the new llvm37 packaging? This still will leave us
with the three most recent llvm releases.
   Jack
ps We have a precedence for this pruning in the removal of the earlier
python releases.
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.1-3 with make-default split-off

[Jack Howarth]

On Wed, Sep 16, 2015 at 5:43 AM, Max Horn <m...@quendi.de> wrote:

> Jack,
>
> On 15.09.2015, at 03:18, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
> > Max,
> >
> > El Capitan GM currently produces an instability in fink make for a
> variety of builds (cmake, libcurl4, texlive-base, r-base32, etc) resulting
> in random failures of the form...
> >
> > make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
> >
> > during parallel builds on my MacPro 3,1 with 8 cores.
>
> In a previous email you mentioned that MacPorts' make doesn't show this
> problem? Does it apply any patches to make? And did you verify that your
> test builds with MacPorts really used their GNU make, and not the system
> make after all?
>
>
>
MacPorts gmake doesn't show the problem on the command line or in their
builds but I have only been able to test a rather narrow set of MacPorts
builds against their gmake. However I have been able to reproduce the build
failures under fink when the call to 'make' is substituted with
'/opt/local/bin/make' to invoke their copy.

> Since only a few packages in fink have a dependency on fink make, those
> could be updated to invoke it as gmake and allow the average user to keep
> using the system make unless they really want to change the default using
> make-default.
>
> I am not 100% comfortable with changing the behavior of the make package
> like this -- people who are relying on "GNU make" will be caught by
> surprise if the "make" package suddenly does not provide gmake under the
> name "make" anymore. Also, packages which depend on "make" would have to be
> changed at the exact same time as this change is applied (for this I'd need
> to know which packages are affected, though, which I don't right now... do
> we have an effective way to do that?)
>
> More workable would be to changes this just for 10.11, i.e. split make
> into a pre-10.11 version and a 10.11+ version.
>
> Since I don't have 10.11, I can't do test that myself, and I am not even
> sure whether 10.11 is going to use the 10.7 tree, or a fresh tree ? If it
> does use 10.7, I could add a make-10.11.info based on what you sent, with
> a revision of 1001 and "Distribution: 10.11"
>
>
>
I doubt a unique set of packages exists to protect from this bug with the
usage of /usr/bin/make. The bug looks to be a race condition in the
threading support as tweaking the optimization of make build modulates the
number of packages that fail under fink make. Likewise reducing the number
of cores in the parallel build can suppress the bug. Also, when I debugged
this by adding -d, only one of the failing tests, texlive-base, remained
and even then only randomly. So the real question will be how many users
machines have the cores/speed to tickle the bug. My past experience with
Apple and threading bugs is that it is futile to expect them to be fixed in
a given OS release and usually you have to wait for the next major kernel
rewrite.


Cheers,
> Max
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] make-4.1-3 with make-default split-off

[Jack Howarth]

On Wed, Sep 16, 2015 at 8:25 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:

>
>
> On Wed, Sep 16, 2015 at 5:43 AM, Max Horn <m...@quendi.de> wrote:
>
>> Jack,
>>
>> On 15.09.2015, at 03:18, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>>
>> > Max,
>> >
>> > El Capitan GM currently produces an instability in fink make for a
>> variety of builds (cmake, libcurl4, texlive-base, r-base32, etc) resulting
>> in random failures of the form...
>> >
>> > make: INTERNAL: Exiting with 1 jobserver tokens available; should be 8!
>> >
>> > during parallel builds on my MacPro 3,1 with 8 cores.
>>
>> In a previous email you mentioned that MacPorts' make doesn't show this
>> problem? Does it apply any patches to make? And did you verify that your
>> test builds with MacPorts really used their GNU make, and not the system
>> make after all?
>>
>>
>>
> MacPorts gmake doesn't show the problem on the command line or in their
> builds but I have only been able to test a rather narrow set of MacPorts
> builds against their gmake. However I have been able to reproduce the build
> failures under fink when the call to 'make' is substituted with
> '/opt/local/bin/make' to invoke their copy.
>
> > Since only a few packages in fink have a dependency on fink make, those
>> could be updated to invoke it as gmake and allow the average user to keep
>> using the system make unless they really want to change the default using
>> make-default.
>>
>> I am not 100% comfortable with changing the behavior of the make package
>> like this -- people who are relying on "GNU make" will be caught by
>> surprise if the "make" package suddenly does not provide gmake under the
>> name "make" anymore. Also, packages which depend on "make" would have to be
>> changed at the exact same time as this change is applied (for this I'd need
>> to know which packages are affected, though, which I don't right now... do
>> we have an effective way to do that?)
>>
>> More workable would be to changes this just for 10.11, i.e. split make
>> into a pre-10.11 version and a 10.11+ version.
>>
>> Since I don't have 10.11, I can't do test that myself, and I am not even
>> sure whether 10.11 is going to use the 10.7 tree, or a fresh tree ? If it
>> does use 10.7, I could add a make-10.11.info based on what you sent,
>> with a revision of 1001 and "Distribution: 10.11"
>>
>>
>>
> I doubt a unique set of packages exists to protect from this bug with the
> usage of /usr/bin/make. The bug looks to be a race condition in the
> threading support as tweaking the optimization of make build modulates the
> number of packages that fail under fink make. Likewise reducing the number
> of cores in the parallel build can suppress the bug. Also, when I debugged
> this by adding -d, only one of the failing tests, texlive-base, remained
> and even then only randomly. So the real question will be how many users
> machines have the cores/speed to tickle the bug. My past experience with
> Apple and threading bugs is that it is futile to expect them to be fixed in
> a given OS release and usually you have to wait for the next major kernel
> rewrite.
>
>
>
One other comment. It isn't particularly surprising that this bug isn't
suppressed by disabling SIP...

https://developer.apple.com/library/prerelease/ios/documentation/Security/Conceptual/System_Integrity_Protection_Guide/System_Integrity_Protection_Guide.pdf

The previous kernel code path, which didn't have the ability to do kernel
level pruning of environmental variables from processes, is unlikely to be
restored simply by disabling SIP. More likely the just security pruning
itself is disabled.


> Cheers,
>> Max
>
>
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel