quot;$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 wrote:
> Daniel and Alexander,
>After injecting the updated sandbox-build fink git branch on my
> machine, I noticed a non-fatal wa
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.4
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 su
13, 2016 at 1:42 PM, Jack Howarth 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 l
urceforge.net/p/fink/package-submissions/4834/
On Sun, Nov 6, 2016 at 10:34 PM, Jack Howarth wrote:
> Daniel and Alexander,
> The attached patch reworks the previously proposed sandboxing
> support by...
>
> 1) Enabling the sandbox usage by default (except during
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) Re
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
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
wrote:
> Daniel and Alexander,
>The pull request to add sandboxing support is now comple
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
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
directori
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/libXaw
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
_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
wrote:
> David and Hanspeter,
>The deprecation of Boost support, in favor of OpenMP
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 pro
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 wrote:
>
>
>
> On Sun, Oct 23, 2016 at 8:38 PM, Kevin Horton
> wrote:
>
>> Jack,
>>
>> Thanks for all your work
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
On Sun, Oct 23, 2016 at 2:20 PM, Jack Howarth
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 Xqua
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 r
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://sourcefor
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 16
On Fri, Oct 7, 2016 at 8:06 AM, Daniel Johnson
wrote:
>
> > On Oct 7, 2016, at 6:55 AM, Jack Howarth
> wrote:
> >
> >
> >
> > On Thu, Oct 6, 2016 at 5:40 PM, Daniel Johnson <
> daniel.johnso...@gmail.com> wrote:
> >
> > > On Oct 6, 20
On Thu, Oct 6, 2016 at 5:40 PM, Daniel Johnson
wrote:
>
> > On Oct 6, 2016, at 1:32 PM, Jack Howarth
> wrote:
> >
> > I noticed that Fedora is building both --with-abi-version=5 and
> --with-abi-version=6 in their ncurses 6.0 package...
> >
> >
-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
wrote:
>
>
> On Thu, Oct 6, 2016 at 11:41 AM, Daniel Johnson <
> daniel.johnso...@gmail.com> wrote:
>
>>
>> > On Oct 6, 2016,
On Thu, Oct 6, 2016 at 11:41 AM, Daniel Johnson
wrote:
>
> > On Oct 6, 2016, at 10:19 AM, Jack Howarth
> wrote:
> >
> > Chris,
> > I've posted packaging for libncursesw6-6.0-1 and ncurses6-6.0-1 to
> fink tracking...
> >
> > https
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/
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 P
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 -
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/C
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)
S
We should discourage fink users from installing Xcode 8 on 10.11. Apple
pulled the 10.11 Command Line Tools package at the last moment because they
accidentally were distributing the 10.11 SDK installed in / rather than the
10.12 SDK which is required by the Swift 3 compiler. It doesn't appear that
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
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
PM, Jack Howarth
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
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
uffer (read) overrun".
Jack
On Tue, Aug 16, 2016 at 11:04 AM, Jack Howarth
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 m
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 'base
On Sun, Aug 14, 2016 at 11:48 AM, Jack Howarth
wrote:
> On Sun, Aug 14, 2016 at 10:23 AM, Max Horn wrote:
>
>> Jack,
>>
>> > On 12 Aug 2016, at 20:44, Jack Howarth
>> wrote:
>> >
>> > Max,
>> > It appears to be safe again to re-
On Sun, Aug 14, 2016 at 10:23 AM, Max Horn wrote:
> Jack,
>
> > On 12 Aug 2016, at 20:44, Jack Howarth
> 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
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
Wed 09 Mar 2016 04:46:00 AM UTC, comment #12:
I modified the implementation of the jobserver fun
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 o
hat
'fink rebuild' will automatically reinstall the rebuilt packages).
Jack
> Sent from my iPhone
>
> On 30 Jun 2016, at 20:54, Jack Howarth wrote:
>
>
>
> On Thu, Jun 30, 2016 at 2:17 PM, Alexander Hansen <
> alexanderk.han...@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
> 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
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: atte
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
explic
lds on Clang 8.0.0.
Jack
On Sat, Jun 18, 2016 at 2:58 PM, Jack Howarth
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 r
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 cur
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
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.pat
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/%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
Jack
On Sun, Jun 12, 2016 at 9:04 PM, 美彦 馬場 wrote:
> Jack,
>
>
> 2016/06/13 5:52、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
>
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
-- Forwarded message --
From: Jack Howarth
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
An alternate, but equally ugly approach, is to build libxaw3dxft with
-flat_namespace using...
--- /sw
On Sun, Jun 5, 2016 at 11:48 AM, Jack Howarth
wrote:
>
>
> On Sun, Jun 5, 2016 at 11:28 AM, TheSin 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
nder 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
> wrote:
> >
> >
> >
e 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,
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
> wrote:
> >
> > The new tar 1.2
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
On Thu, Jun 2, 2016 at 10:57 AM, Stefan Bruda 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 j
On Wed, Jun 1, 2016 at 11:47 PM, Stefan Bruda 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
>
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-warni
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 mach
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:
>
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.
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
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/
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
On Sun, Oct 25, 2015 at 3:06 PM, Jack Howarth
wrote:
>
>
> On Sat, Oct 24, 2015 at 11:30 AM, Max Horn 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.
>>
ely across the entire code path.
Jack
> > On 24.10.2015, at 12:32, Jack Howarth wrote:
> >
> >
> >
> > On Sat, Oct 24, 2015 at 6:12 AM, Martin Costabel
> wrote:
> > On 24/10/15 08:22, Jack Howarth wrote:
> > []
> >Since we don't
On Sat, Oct 24, 2015 at 6:12 AM, Martin Costabel
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
>&g
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
wrote:
> Max,
&
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
wrote:
> Since make 4.1 built
o 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, Jac
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
--dis
/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
wrote:
>
>
&g
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
p 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
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
>
2 PM, Jack Howarth
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,
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
wrote:
> FYI, I've also open
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
wrote:
> The attached packaging adds the change...
>
> diff -uNr make-4.1.orig/main.c make-4.1/main.c
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
(etc).
On Tue, Oct 20, 2015 at 9:03 PM, Jack Howarth
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 F
to be undefined in
the fink make 4.1 build?
On Tue, Oct 20, 2015 at 8:20 PM, Jack Howarth
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 o
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
Any thoughts on the following issue? In an attempt to pinpoint the
exact trigger of the fink make failures under the system perl, I have tried
the following experiment in the past. Starting with a failing build (in
this case the InfoTest of libcurl4) with fink make installed, I executed
'ps -le
Another observation that seems to point at SIGCHLD handling being the issue
is the failure seen in building texinfo under fink make on 10.11
make[5]: *** read jobs pipe: No such file or directory. Stop.
make[5]: *** Waiting for unfinished jobs
during the InfoTest. Note that in the make 4
On Sun, Oct 18, 2015 at 1:37 PM, Jack Howarth
wrote:
> On Sat, Oct 17, 2015 at 8:01 PM, Jack Howarth
> 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
On Sat, Oct 17, 2015 at 8:01 PM, Jack Howarth
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...
>
>
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 d
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
> wrote:
>
>
> On Oct 1, 2015, at 11:41, Alexander Hansen
> wrote:
>
>
> On Oct 1, 2015, at 11:24, Jack Howarth wrote:
>
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
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 wrote:
>
>
>
> On Thu, Oct 1, 2015 at 12:02 PM, Jack Howarth
> wrote:
>
>>
>>
>> On Thu, Oct 1, 2015 at 12:33 AM, Wil
On Thu, Oct 1, 2015 at 12:02 PM, Jack Howarth
wrote:
>
>
> 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
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
Alexander,
Please consider all of my packages as unmaintained and reassign them
as Maintainer: None . Thanks in advance.
Jack
--
___
Fink-devel mailing list
Fink-de
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 wxwidgets
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
-
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
On Tue, Sep 22, 2015 at 9:52 AM, Jack Howarth
wrote:
> Daniel,
> Thats is
>
> On Tue, Sep 22, 2015 at 9:35 AM, Daniel Johnson > wrote:
>
>>
>> > On Sep 20, 2015, at 12:08 PM, Jack Howarth
>> wrote:
>> >
>> > There is no reaso
Daniel,
Thats is
On Tue, Sep 22, 2015 at 9:35 AM, Daniel Johnson
wrote:
>
> > On Sep 20, 2015, at 12:08 PM, Jack Howarth
> wrote:
> >
> > There is no reason to carry along the ilmbase and libopenexr6
> packaging into the 10.9-libc++ tree when the newer i
1 - 100 of 1300 matches
Mail list logo
