Re: [Fink-devel] Language specific versions - man pages
On Mon, 24 Jul 2017 09:25:44 -0700, Alexander Hansen wrote: > > > On Jul 23, 2017, at 15:45, Scott Hannahs via Fink-devel wrote: > > > > Once again…. Since I am updating some of my fink packages, I should do > > them all! > > > > I seem to be unclear on how a language version typed build installs > > non-version typed man pages? > > > > I am updating config-inifiles-pm as it has gone horribly out of date. It > > is a fairly vanilla bare bones .info file. But the build -m gives the > > error: > > > > Validating .deb dir /sw/src/fink.build/root-config-inifiles-pm5162-2.94-5... > > Error: File in a language-versioned package does not have a pathname > > specific to that version. > > Offending file: /sw/share/man/man3/Config::IniFiles.3pm > > > > Well, yes, the man page is not versioned. So where should I put it? > > Should it be versioned? Or should the man page be the same for both > > > > The type is the normal: > > Type: perl (5.16.2 5.18.2) > > > > And my dependencies are: > > # Dependencies > > Depends: << > >perl%type_pkg[perl]-core, > >scalar-list-utils-pm%type_pkg[perl], > >io-stringy-pm > > << > > > > The install phase uses whatever is done for default testing and > > installation for perl modules: > > # Install Phase: > > UpdatePOD: true > > DocFiles: Changes LICENSE MANIFEST README > > > > I think I can build it as a non-typed language file but it has a dependency > > on scalar-list-utils-pm which is typed. It seems that once you have a > > version specific file any builds that depend on that version must also be > > version specific. > > > > Do I explicitly write out the install phase and then change the man page to > > Config::IniFiles-pm5162.3pm or something ugly like that? Google only > > points me to a failed build world list that Hanspeter posted and the manual > > seems to show that man pages for different versions are all in the same > > location. (i.e. there is no /$version/ sub directory for man1 and man3). > > From the fink manual: > > It looks like the manual needs updating. There is actually a relatively easy > workaround available, which is the perl-versioned locations available in > MANPATH: > > $ printenv MANPATH > /sw/share/man:/sw/lib/perl5/5.18.2/man:/usr/local/share/man:/usr/share/man:/opt/X11/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:/sw/lib/perl5-core/5.16.2/man:/sw/lib/perl5/5.16.2/man > > If you install the manpages under %p/lib/perl5/%type_raw[perl]/man they will > be available automatically. Check the .info for almost any existing version-specific perl module and you'll find a fairly standard InstallScript incantation that puts the files in this MANPATH place. The secondary question's answer is "yes, you do need to be varianted once any of your dependencies are varianted". And in this case, even though perl core itself contains a scalar-list-utils-pm, the vesion supplied by these perl variants is too old for what your module wants, so you do need the explicit dependency. A minor nit is that you don't need to include the MANIFEST as a DocFiles. That file is a list of the files that were present in the source tarball, which isn't so useful to have in the final binary package. dan -- 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: https://sourceforge.net/p/fink/mailman/fink-devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] nedit-5.6cvs20081118-4
On Mon, 24 Oct 2016 15:11:32 -0700, Alexander Hansen wrote: >> >> > On Oct 24, 2016, at 02:29, Michael Endler wrote: >> > >> > Feedback: not good >> > >> > After installing XQuartz 2.7.10, I get the following error message when >> > trying to start nedit: >> > >> > Error: Shell widget nedit has zero width and/or height >> > >> > Suggestions how to avoid this problem are welcome! >> > >> > -- >> > Package manager version: 0.38.8 >> > Distribution version: selfupdate-rsync Mon Oct 24 11:04:56 2016, 10.8, >> > x86_64 >> > Mac OS X version: 10.8.5 >> > Unable to determine Developer Tools version >> > gcc version: 5.1 (clang-503.0.40) (based on LLVM 3.4svn) >> > make version: 3.81 >> > Feedback Courtesy of FinkCommander >> > >> > -- >> > >> > Michael Endler >> > Max-Planck-Institut für Plasmaphysik >> > Teilinstitut Greifswald >> > Wendelsteinstraße 1 >> > D-17491 Greifswald >> > Germany >> > Tel.: +49-3834-88-2340 >> > FAX: +49-3834-88-2809 >> > email: end...@ipp.mpg.de >> > IPP web page: www.ipp.mpg.de >> > —— >> > >> >> The solution to avoid the problem is not to update Xquartz, unfortunately. Xquartz 2.7.10 breaks backwards compatibility for Motif-based applications. We’re working on our solution. OS X 10.8 has not been supported for a while. We just solved this xquartz mess on the supported platforms (10.9+) and I suspect it will not be easy to backport "just one package fix" because any way we would fix it entails adjusting a few dozen packages in concert:(danTry nedit_1:5.6a-2 -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik ___ 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-package-precedence-0.30 error
On Wed, 5 Oct 2016 21:27:19 -0500, Hanspeter Niederstrasser wrote: > >Building scite-3.4.1-1 with f-p-p-0.30 gets the following error: > > fink-package-precedence --depfile-ext='\.(mak|d)' . >Scanning /\.(mak|d)$/ dependency files... >./scintilla/gtk/Accessor.d >... >./scite/gtk/Widget.d >./scite/win32/deps.mak >./scite/win32/scite.mak >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. > >When I downgrade f-p-p to 0.29, the f-p-p check works as expected with no errors. (apologies in advance if this message is a formatting mess...new email client)I don't see that with scite-3.4.1-1 on my 10.11. But my f-p-p call is just:fink-package-precedence --depfile-ext='\.(d)' .I only see it if I also check .mak. The you get is triggered by the following line in scintilla/test/unit/test.mak:INCLUDEDIRS = /I../../include /I../../src /I../../lexlibNot surprising that those pathnames break a parser that looks at pathnames on the local live system. Older f-p-p was lax about trying to process paths that were not absolute and canonical. So first, this path is clearly(?) an upstream bug, or targetted for a toolchain other than normal compilers (maybe something Windows-like that uses leading slash instead of hypen as CLI flag character?). And second, what is in the .mak that is not already in the .d? Easy enough to tighten f-p-p (or add a heuristic for things to give up and skip), but not sure what a *valid* trigger would look like.dan -- 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] aclocal.m4 error compiling under 10.12
On Tue, 9 Aug 2016 11:52:39 -0700, Alexander Hansen wrote: > > On Aug 6, 2016, at 20:42, Daniel Macks wrote: > > > On Sat, 6 Aug 2016 11:56:46 -0700, Alexander Hansen > > wrote: > >>> On Aug 6, 2016, at 11:50, John Lillibridge 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 > > otool-classic appears to be buried: > > 11:35am] howarth: note that otool-clasic is buried in > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > and > /Library/Developer/CommandLineTools/usr/bin > [11:38am] I guess we’d want to check the command-line tools location first. Done in f-p-p 0.20 dan -- Daniel Macks dma...@netspace.org -- 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
On Sat, 6 Aug 2016 11:56:46 -0700, Alexander Hansen wrote: > > On Aug 6, 2016, at 11:50, John Lillibridge 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
Re: [Fink-devel] procmail for 10.11
On Wed, 06 Jan 2016 11:13:42 -0800, Greg Minshall wrote:
Daniel,
>
> thanks! sadly, it doesn't install on my system.
>
> Selecting previously deselected package procmail.
> (Reading database ... 351452 files and directories currently installed.)
> Unpacking procmail (from .../procmail_3.22-2_darwin-x86_64.deb) ...
> Setting up procmail (3.22-2) ...
> chgrp: /sw/bin/procmail: No such file or directory
> chgrp: /sw/bin/lockfile: No such file or directory
> /sw/bin/dpkg: error processing procmail (--install):
> subprocess post-installation script returned error exit status 1
> Errors were encountered while processing:
> procmail
> ### execution of /sw/bin/dpkg-lockwait failed, exit code 1
>
> maybe (i was guessing) because my file system is (sadly)
> case-independent, so that "make install" sees INSTALL, says "nothing to
> do"? that was my assumption anyway, which caused me to move
> INSTALL{,.txt}.
Ah yes, case-(in)sensitivity. Fixed in revision -3 (which also improves
the PATH in effect for recipes at runtime).
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
Re: [Fink-devel] procmail for 10.11
On Mon, 04 Jan 2016 18:46:41 -0800, 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. I just migrated our old procmail package to the current (10.9+) distro. Thanks for the getline() fix! I didn't need to alter INSTALL. Debian has a ton of patches, I will look into them later this week. 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
Re: [Fink-devel] hdf5.10 build failure (invalid control file)
On Thu, 26 Nov 2015 18:34:40 -0800, Alexander Hansen wrote: > > On Nov 26, 2015, at 15:36, Derek Homeier > wrote: > > > building hdf5-bin_1.8.16 fails with > > > env LANG=C LC_ALL=C dpkg-deb -b root-hdf5-bin-1.8.16-1 > /sw/fink/10.10/stable/main/binary-darwin-x86_64/sci > > /sw/bin/dpkg-deb: parse error, in file > `root-hdf5-bin-1.8.16-1/DEBIAN/control' near line 10 package > `hdf5-bin': > > `Replaces' field, syntax error after reference to package `hdf5-oldapi-bin’ > > > It seems there are missing commas after hdf5-oldapi-bin, > hdf5.8-oldapi as well as Conflicts: … hdf5.8-oldapi > > > in the hdf5-bin SplitOff description. > > > Cheers, > > Derek > > > > > Thanks. I added these after doing the build test (never a good idea), > and fink’s package description validator doesn’t catch missing > commas in the conflicts/replaces. > > Look for revision 2 to fix this. Bug in validator, now fixed in git master: missing comma was not detected in multiline fields that were in splitoffs where the missing comma would have been the last character in a line (*phew*). hdf5.10.info and hdf5.10-oldapi.info each trigger a warning. 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] MAKEFLAGS for -j1
We used to not support parallel builds, but had an unofficial way that one could hack one's local fink to pass -jN via the MAKEFLAGS env var. Now fink supports -jN itself. Formerly, packages that did not work with -jN had .info settings to supress paassing the MAKEFLAGS env var and/or to re-set it to -j1. Now fink supports a .info setting that specifically controls fink's -jN feature, which also indicates this effect in the diagnostic message when package-building fails so that debugging is easier. I'm going to remove the legacy MAKEFLAGS settings and replace them with the modern UseMaxBuildJobs settings throughout the whole live distro shortly. dan -- Daniel Macks dma...@netspace.org -- Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/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] Fink
On Mon, 23 Nov 2015 17:06:18 +0100, Max Horn wrote: Hi Dave, > [CC: fink-devel], > > > On 22 Nov 2015, at 21:39, David R. Morrison wrote: > > > Hi Max. > > > I have indeed been inactive but am planning to resume activity > soon. (As soon as I get one of my machines upgraded to a El Capitan.) > I'll assess my packages after I do that and might release some of > them as unmaintained. > > Great news :) Excellent! dan -- Daniel Macks dma...@netspace.org -- Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/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] Transition of packages from system-openssl-dev
On Wed, 14 Oct 2015 10:58:58 -0500, Hanspeter Niederstrasser wrote: Dear Fink Developer, > > As you may be aware, OS X 10.11 does not provide a full install of OpenSSL > in /usr (it only has the dylib, but not the headers). Therefore, the > package system-openssl-dev is no longer available on 10.11. To fill this > dependency gap, packages must transition to a Fink package that provides > SSL functionality (like openssl100 or gnutls28). I've added a list of all > packages that are currently using system-openssl-dev in the 10.9-libcxx > tree to the Fink wiki: > > http://wiki.finkproject.org/index.php/Fink:Policy:system-openssl#Deprecation_of_system-openssl-dev Thanbks for checking into this! If a package has the option of building to use either openssl or gnutls, any feel for which way I should go with it? 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] applesystemfonts behavior and pathname problems
Minor: the package creates all its files via PostInstScript including the directory in which they reside. That makes it difficult for sysadmins to determine what package owns those files because nothing about them is managed by dpkg. It appears that creating the files at that stage makes sense, but that the directory-name would be known at InstallScript (it's in %p and based on data published by another quite stable package). Having the directory in the .deb would at least make *that* level known to dpkg, giving a correct clue to the package that handes the files within. Easily fixable, will do so in a day or two unless someone complains. Major 1: the PostInstScript hardcodes full paths to several executables in /usr/X11R6/bin, an x11 prefix that is not the real x11 prefix on any supported platform (and hasn't been for many years). It remains as a symlink (when the installer doesn't screw up) on currently supported platforms, but who knows what might happen in the future. Fink's init.sh is designed to add the correct x11 paths to PATH and is always loaded for all dpkg package scripts, so there's no need to hardcode at all. That avoids having to update or fork the package for different x11 vendors (of which 10.7 is different than 10.8+). Easily fixable, will do so in a day or two unless someone complains. Major 2: the PostInstScript, running as root, silently seems to alter files in all users' homedirs. That's not very nice! And it links them all into a public (in %p) location. Not good to expose user's private filenames to each other (even if the files themselves are protected by permissions). And it creates all those links in a single location, so multiple users' file-links would overwrite each other. That means it's broken for all users except the "last" one, since presumably those whose were overwritten would not have permission to the last-one's files. This all might make sense on a single-user machine, but not beyond that. This is all badly broken by design and I don't know a correct solution. Is there a way to have the users' data cached in each user's own space, or at least in subdirs? 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] Perl-module variant upgrades
We're missing lots of -pm5182 variants, and even some -pm5162. Over the next day or two, I will be adding lots of variants, with testing limited to: buildability on 10.10, dep-tree self-consistency. I will not be making any version upgrades or other changes at this point unless things don't build or have noticeable missing dependencies, except for adjusting C/R if there are variant-mutually-exclusive sets. If you do not want me to touch your packages, speak now and/or add a note to your .info files. 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
Re: [Fink-devel] bogus BuildDepends onsystem-openssl-dev inlibgnomecups-shlibs
On Mon, 15 Jun 2015 22:55:17 -0400, Daniel Macks wrote: On Sun, 14 Jun 2015 10:17:30 -0400, Jack Howarth > wrote: > There appears to be a bogus BuildDepends on system-openssl-dev in > > libgnomecups-shlibs as there seems to be no instances of the ssl > > headers being used in that package. Shouldn't that BuildDepends be > > dropped? > > libgnomecups inherits flags from 'cups-config', which is apple's. Now > apple is publishing flags for the Security framework (at least as far > back as 10.8SDK and a live 10.8.5 box). Previously it had published > openssl flags. I'll check 10.7 and old 10.8 to verify it's now > Security framework everywhere, or else make separate .info. It is, so BDep removed. 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
Re: [Fink-devel] bogus BuildDepends on system-openssl-dev inlibgnomecups-shlibs
On Sun, 14 Jun 2015 10:17:30 -0400, Jack Howarth wrote: There appears to be a bogus BuildDepends on system-openssl-dev in > libgnomecups-shlibs as there seems to be no instances of the ssl > headers being used in that package. Shouldn't that BuildDepends be > dropped? libgnomecups inherits flags from 'cups-config', which is apple's. Now apple is publishing flags for the Security framework (at least as far back as 10.8SDK and a live 10.8.5 box). Previously it had published openssl flags. I'll check 10.7 and old 10.8 to verify it's now Security framework everywhere, or else make separate .info. 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
Re: [Fink-devel] convertall source not available
On Sat, 9 May 2015 15:46:15 -0400, Kevin Horton wrote: On May 9, 2015 at 2:07:30 PM, Kevin Horton (khorto...@rogers.com) wrote: > > > On May 9, 2015, at 11:47, Daniel Macks wrote: > > > > I just tried to update "convertall" to the latest in fink, but: > > > > curl --connect-timeout 30 -f -L -A 'fink/0.38.99.git' -O > http://www.kilohotel.com/fink/convertall-0.6.0.tar.gz > > % Total % Received % Xferd Average Speed Time Time Time Current > > Dload Upload Total Spent Left Speed > > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The > requested URL returned error: 404 Not Found > > > > I couldn't find it on the master-mirrors pool either (it's all > self-consistent...the mirror-scripts are reporting that they could > not download the original to mirror it). > > Drat! That was a stupid blunder on my part - a relic of the previous > time I attempted to upgrade this package, before Fink had the needed > QT4 version. The source has moved since then, but I already had it in > my /sw/src, so I missed the error. > > I'm on the road today without my computer. I'll fix this tonight or tomorrow. > > Thanks for the report. > > Kevin > > I got home earlier than expected. I committed an updated > convertall.info that fixes this problem. Downloads fine directly, and now also propagating around the mirror pool. Thanks! dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] convertall source not available
I just tried to update "convertall" to the latest in fink, but: curl --connect-timeout 30 -f -L -A 'fink/0.38.99.git' -O http://www.kilohotel.com/fink/convertall-0.6.0.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 404 Not Found I couldn't find it on the master-mirrors pool either (it's all self-consistent...the mirror-scripts are reporting that they could not download the original to mirror it). dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] dbi-pm fails to compile
On Mon, 04 May 2015 10:22:26 -0400, Daniel Macks wrote: On Mon, 4 May 2015 08:41:55 -0400, Kevin Horton wrote: > I’m looking at taking over dbi-pm from Benjamin Reed, but I’ve > discovered a problem with the existing package that has me stumped. > > > dbi-pm5182-1:1.630-1 fails to compile on OS X 10.10.4 (beta) with: > > > > cp lib/DBI/Const/GetInfoType.pm blib/lib/DBI/Const/GetInfoType.pm > > "/usr/bin/arch" -x86_64 perl5.18 -x86_64 perl5.18 "-Iblib/arch" > > "-Iblib/lib" dbilogstrip.PL dbilogstrip > > "/usr/bin/arch" -x86_64 perl5.18 -x86_64 perl5.18 "-Iblib/arch" > > "-Iblib/lib" dbiprof.PL dbiprof > > "/usr/bin/arch" -x86_64 perl5.18 -x86_64 perl5.18 "-Iblib/arch" > > "-Iblib/lib" dbiproxy.PL dbiproxy > > Can't open perl script "perl5.18": No such file or directory > > Can't open perl script "perl5.18": No such file or directory > > make: *** [dbiproxy] Error 2 > > > > Any hints would be greatly appreciated. > > It's double-passing "-x86_64 perl5.18". That's a bug in...some > version of some underlying perlmod used in the build toolchain, can't > remember which. Will look it up later today. It's a bug/regression in recent versions of ExtUtils::MakeMaker that affects several perlmod packages that supply scripts. Adding extutils-makemaker-pmXXX maintainer to CC. A few months ago I narrowed down what version introduced this problem...somewhere on #fink...can't find it. dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] libdmtx
Thanks for getting us this far! I'll adjust to list you as former maintainer, with the package itself up for grabs, and maybe hack on it a bit myself. dan On Mon, 4 May 2015 11:53:13 -0700, peterwong wrote: hi daniel, > > unfortunately, i don't really have the bandwidth to be maintaining > this package any longer. whatever you see fit to do with it is fine > with me (including removing it from the fink distro). thanks for > reaching out, and sorry for the lack of responsiveness about it. > > On Mon, May 4, 2015 at 7:58 AM, Daniel Macks wrote: > > Your "libdmtx" package-suite is one of the very last in fink using > the imagemagick7 libraries (imagemagick itself has been upgraded). > Mind if I push your package to use the newer imagemagick suite? I > think there might be a newer version of libdmtx itself. Any thoughts > about updating it? > > dan > > -- > Daniel Macks > dma...@netspace.org > > -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] libdmtx
Your "libdmtx" package-suite is one of the very last in fink using the imagemagick7 libraries (imagemagick itself has been upgraded). Mind if I push your package to use the newer imagemagick suite? I think there might be a newer version of libdmtx itself. Any thoughts about updating it? dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] dbi-pm fails to compile
On Mon, 4 May 2015 08:41:55 -0400, Kevin Horton wrote: I’m looking at taking over dbi-pm from Benjamin Reed, but I’ve discovered a problem with the existing package that has me stumped. > > dbi-pm5182-1:1.630-1 fails to compile on OS X 10.10.4 (beta) with: > > cp lib/DBI/Const/GetInfoType.pm blib/lib/DBI/Const/GetInfoType.pm > "/usr/bin/arch" -x86_64 perl5.18 -x86_64 perl5.18 "-Iblib/arch" > "-Iblib/lib" dbilogstrip.PL dbilogstrip > "/usr/bin/arch" -x86_64 perl5.18 -x86_64 perl5.18 "-Iblib/arch" > "-Iblib/lib" dbiprof.PL dbiprof > "/usr/bin/arch" -x86_64 perl5.18 -x86_64 perl5.18 "-Iblib/arch" > "-Iblib/lib" dbiproxy.PL dbiproxy > Can't open perl script "perl5.18": No such file or directory > Can't open perl script "perl5.18": No such file or directory > make: *** [dbiproxy] Error 2 > > Any hints would be greatly appreciated. It's double-passing "-x86_64 perl5.18". That's a bug in...some version of some underlying perlmod used in the build toolchain, can't remember which. Will look it up later today. dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] libming1 giflib upgrade
libming1-shlibs 0.4.5-3 is one of the last remaining packages to use the old-version "giflib" library. I stole another distro's patches for giflib7 (fink's packaging of the newer lib) support and put it in my experimental dir (on cvs.sf). Okay to commit? dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] Process to take over a package?
On Sun, 3 May 2015 14:30:47 -0400, Kevin Horton wrote: Is there a defined way to take over a package? I note that image-exiftool-pm (owned by Benjamin Reed) is way out of date. I contacted Benjamin to offer an updated info file, or to take over as maintainer, and he said that he was happy for me to take over any or all of his packages. I certainly don’t want all of his packages, but there are a few that I do use, and have an interest in keeping up to date. > > I’ve got CVS access. Would I just commit an update with myself as > the maintainer? I’d add a reference to Benjamin as the maintainer > for versions X and older. Sounds like the perfect process for the ones you want. I've been surrogate parent for his perlmods and many others for a few years but don't keep close track of all their CPAN releases on a regular basis...feel free to formally claim any you want. Along the way you can always remove: UseMaxBuildJobs:true since that's now default (lots of packages have slow release cycles, dating back to when that was not-default behavior). dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] Handling flat_namespace on 10.10+
On Tue, 28 Apr 2015 07:52:03 -0700, Alexander Hansen wrote: > > On Apr 21, 2015, at 19:31, Daniel Macks wrote: > > On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser > wrote: > > On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote: > > Summary: GNU libtool effectively assumed that there would be no 10.10, so > a bunch of packages inherited conditional logic that treats 10.10 like > 10.1. We’ve been patching against this, and put a .deb validator check > for flat_namespace builds. > > Problem: openmpi apparently requires flat_namespace. Other packages > might also need it, too, but I don’t happen to know of any offhand. > > There are a couple of options to address the problem: > > 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info > and have that turn off the .deb validation check. > > This seems like a gateway to propagating new fields with very limited > usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody, > etc) had a significantly wider need. So far BuildFlatNamespace has N=1. > Would it make more sense to have a new more general field that can receive > a comma separated list of pre-set values, and each value would indicate a > action? > > RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna > > Could Type: be extended in this manner? > > 2) Get rid of the .deb validation check and instead apply mandatory tests > in the earlier phases. For example, to test at the end of the compile > phase fink-package-precedence could be extended also to check for > flat_namespace and packages which need flat_namespace wouldn’t use > f-p-p; or an additional option flag could be added to f-p-p. We could > also check config.status before the compile phase. > > Would built debs still be validatable (by hand)? > > If it controls a validator test, it needs to be in the .deb control > file, which means we have to tweak dpkg itself to accept a new foreign > field. All for an apparently *very* rare special case? No thanks. > > Support via f-p-p or a new "fink-library-check" (either one controlled > by comand-line flags in the CompileScript) or internal to fink itself > prior to rolling the .deb (controllable by some .info field) would make > it happen in fink runtime and not require .deb/dpkg hackery. As a > bonus, it keeps the buggy-library from ever making it into a .deb for > anyone rather than lurking and spreading until someone uses -m to catch > it. > > We already have support for a special token in Shlibs entries to > control certain binary library features (32/64-bit cross-arch), so a > new "Flat" token could be added there. I think it's a per-file idea, > not per-package? I dislike doing it via grep of config.status...we want > to catch bad results regardless of how they came about, not just the > one way we currently see. Likewise, fink-library-check would take a > list of specific file(s) to allow to be flat, not just enable/disable > the whole mode (and would allow scanning .so not just .dylib). There > are some other sanity checks we might want to do on modules and libs > (unresolved symbols? list of runtime deps?), this new script would be a > home for them all. > > dan > > -- > Daniel Macks > dma...@netspace.org > > Yeah, I’d definitely prefer not to have problematic .debs actually get built. > > However, since we kind of need to get a release out shortly, and we > currently don’t have code in Fink to handle this, I’d like to > know whether to turn off the current flat_namespace check in the > validator so that openmpi can get added to the binary distribution or > just leave it as-is. Knock it down to a non-fatal (remove $looks_good=0)? That way it can be caught by buildworld and maintainers who look closely, but won't prohibit. dan -- Daniel Macks dma...@netspace.org -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] Handling flat_namespace on 10.10+
On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser wrote: > On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote: > > Summary: GNU libtool effectively assumed that there would be no 10.10, so > > a bunch of packages inherited conditional logic that treats 10.10 like > > 10.1. We’ve been patching against this, and put a .deb validator check > > for flat_namespace builds. > > > > Problem: openmpi apparently requires flat_namespace. Other packages > > might also need it, too, but I don’t happen to know of any offhand. > > > > There are a couple of options to address the problem: > > > > 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info > > and have that turn off the .deb validation check. > > This seems like a gateway to propagating new fields with very limited > usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody, > etc) had a significantly wider need. So far BuildFlatNamespace has N=1. > Would it make more sense to have a new more general field that can receive > a comma separated list of pre-set values, and each value would indicate a > action? > > RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna > > Could Type: be extended in this manner? > > > 2) Get rid of the .deb validation check and instead apply mandatory tests > > in the earlier phases. For example, to test at the end of the compile > > phase fink-package-precedence could be extended also to check for > > flat_namespace and packages which need flat_namespace wouldn’t use > > f-p-p; or an additional option flag could be added to f-p-p. We could > > also check config.status before the compile phase. > > Would built debs still be validatable (by hand)? If it controls a validator test, it needs to be in the .deb control file, which means we have to tweak dpkg itself to accept a new foreign field. All for an apparently *very* rare special case? No thanks. Support via f-p-p or a new "fink-library-check" (either one controlled by comand-line flags in the CompileScript) or internal to fink itself prior to rolling the .deb (controllable by some .info field) would make it happen in fink runtime and not require .deb/dpkg hackery. As a bonus, it keeps the buggy-library from ever making it into a .deb for anyone rather than lurking and spreading until someone uses -m to catch it. We already have support for a special token in Shlibs entries to control certain binary library features (32/64-bit cross-arch), so a new "Flat" token could be added there. I think it's a per-file idea, not per-package? I dislike doing it via grep of config.status...we want to catch bad results regardless of how they came about, not just the one way we currently see. Likewise, fink-library-check would take a list of specific file(s) to allow to be flat, not just enable/disable the whole mode (and would allow scanning .so not just .dylib). There are some other sanity checks we might want to do on modules and libs (unresolved symbols? list of runtime deps?), this new script would be a home for them all. dan -- Daniel Macks dma...@netspace.org -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ 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] geant4.9-cernlib compiler upgrade
I tagged the cernlib variant it as Distribution:10.[78] only to match gcc47. The non-cernlib variant does not have a gcc47 dependency, so I left it available in all distros for now. dan On Mon, 23 Mar 2015 13:42:11 +, Remi Mommsen wrote: Hi Dan, > > the geant version in fink is very outdated and IIRC does not work > with newer gcc versions. I started working on packaging the latest > geant version a while ago, but this needs more time than I have right > now. One option would be to just retire the current geant from fink. > > Cheers, > Remi > > On 23 Mar 2015, at 05:53 am, Daniel Macks wrote: > > > This package is one of the few still using the very old gcc47 > compiler, which is only available on OS X up to 10.8. Its underlying > cernlib2006 has been using gcc49 for a while now. Can geant migrate > to gcc49 also? > > > dan > > > -- > > Daniel Macks > > dma...@netspace.org > > - > > -- > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your > hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join > the conversation now. http://goparallel.sourceforge.net/ > > - > > ___ > 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 > -- Daniel Macks dma...@netspace.org -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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] geant4.9-cernlib compiler upgrade
This package is one of the few still using the very old gcc47 compiler, which is only available on OS X up to 10.8. Its underlying cernlib2006 has been using gcc49 for a while now. Can geant migrate to gcc49 also? dan -- Daniel Macks dma...@netspace.org -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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] automake1.15-1.15-1
On Wed, 18 Mar 2015 08:44:08 -0700, Alexander Hansen wrote: > On Mar 18, 2015, at 8:36 AM, Jack Howarth wrote: > > > I can't test this until later today, but one possibility would be > > to try Epoch'ing dejagnu back to 1.5.1 to make sure that the failure > > isn't coming from the newer 1.5.2 release. > > For _test_ purposes, one could also grab the prior dejagnu.info > version out of the cvs history, stash it in a local tree, then use > “fink install dejagnu-1.5.1”, too. There’s no real need to use > an Epoch yet, since this is just a test being done on a local machine > and a manual downgrade suffices. Rolling back my 10.7 machine to dejagnu-1.5.1-2 does not alter the fort4 test-fail on automake1.14. dan -- Daniel Macks dma...@netspace.org -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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] nightfall_1.86-2
On Wed, 18 Mar 2015 09:38:32 -0700, Alexander Hansen wrote: > > On Mar 18, 2015, at 9:08 AM, Derek Homeier > wrote: > > > Hi, > > > the nightfall update is still failing with name conflicts on > case-sensitive HFS > > (and is silently losing 2 of the files in question on insensitive ones). > > This can be fixed with a > > TarFilesRename: bh_virB.dat:bh_virBoldZ.dat bh_virV.dat:bh_virVoldZ.dat > > > see also the last update to > > https://sourceforge.net/p/fink/package-submissions/4423/ > > > Cheers, > > Derek > > > Thanks! I’ve synced the relevant changes the tracker item over, > so 1.86-4 should have everything, including having you as official > maintainer. Thanks! dan -- Daniel Macks dma...@netspace.org -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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] automake1.15-1.15-1
On Wed, 18 Mar 2015 11:07:33 -0400, Jack Howarth wrote: The new automake1.15-1.15-1 packaging is failing 'fink -m' on > x86_64-apple-darwin14... > > FAIL: t/fort4.sh > > which was previously reported upstream without any response from the > developers. > > http://lists.gnu.org/archive/html/bug-automake/2015-02/msg0.html > http://lists.gnu.org/archive/html/bug-automake/2015-02/msg1.html automake1.12 just failed that same test in the same way for me on 10.8. dan -- Daniel Macks dma...@netspace.org -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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] bottleneck-py-1.0.0-1
On Tue, 17 Feb 2015 00:33:53 +0100, Derek Homeier wrote: Hi Jack, > > > as the entire test suite fails with an import error with 1.8 > (apparently crashes the > interpreter, thus the failure was not caught be the original Test field). I think the usual pattern for TestScript is: some command sequence || exit 2 rather than an intermediate TESTFAIL variable. If "some command sequence" doesn't succeed, exit 2 is what fink wants to see to be fatal. If it does succeed, then a normal success exit-code (e.g., not explicitly 2) is default. But your package already looks like the test suite requires manual tricks, so it's possible even the exit-handler needs special tricks too. dan -- Daniel Macks dma...@netspace.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ 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] Emerrgency update to scientificpython-py27
On Thu, 5 Feb 2015 21:38:11 -0800, Alexander Hansen
wrote:
I jumped the gun on deprecating libdap9 after putting out an update to
libnc-dap3 which uses libdap11 instead. I’ve done a quickie test of
an update to scientificpython-py27 which is slightly modified to deal
with libdap11—specifically its private directory structure.
I’ve attached the modified .info file. If there aren’t any
problems with it (I didn’t have a way to do a runtime test), then
one of us can commit it.
I’m very sorry about the rush—I had honestly thought that we’d
closed down all of the libdap9 users. I guess there’s some
consolation in the fact that most of the packages I broke were mine.
:-\
Builds fine for me on 10.8. Attached are some additional cleanups to
make sure it's sanely using only that new libdap (it doesn't use the
headers, but seemed risky not to also pass -I; and f-p-p just to be
sure).
dan
--
Daniel Macks
dma...@netspace.org
Info2: <<
Package: scientificpython-py%type_pkg[python]
Version: 2.9.1
Revision: 4
Distribution: (%type_pkg[python] = 23) 10.4, (%type_pkg[python] = 24) 10.4,
(%type_pkg[python] = 24) 10.5
Type: python (2.7)
Maintainer: Kurt Schwehr
Depends: <<
libdap11-shlibs,
libnc-dap3-shlibs (>= 1:3.7.3-9),
numpy-py%type_pkg[python],
python%type_pkg[python]
<<
# FIX: Needs pyro-py for taskmanager
BuildDepends: <<
fink-package-precedence,
libdap11,
libnc-dap3 (>= 1:3.7.3-9)
<<
Conflicts: scientificpython-py23-bin, scientificpython-py24-bin,
scientificpython-py25-bin, scientificpython-py26-bin,
scientificpython-py27-bin
Replaces: scientificpython-py23-bin, scientificpython-py24-bin,
scientificpython-py25-bin, scientificpython-py26-bin,
scientificpython-py27-bin
#
# Warning! There is this strange number right after the php that really
controls what is downloaded!
#
Source:
https://sourcesup.cru.fr/frs/download.php/3420/ScientificPython-%v.tar.gz
Source-MD5: f27bfb3abda022b73a93cd6ada06338f
PatchFile: %{ni}.patch
PatchFile-MD5: ee9fdbc23b851d11cc86b0d94b1c2270
# libdap11 uses separate directory, %n doesn't read its .pc
SetCPPFLAGS: -MD -I%p/opt/libdap11/include
SetLDFLAGS: -L%p/opt/libdap11/lib
CompileScript: <<
%p/bin/python%type_raw[python] setup.py build --numpy --netcdf_prefix=%p
fink-package-precedence --depfile-ext='\.d' .
<<
InstallScript: <<
%p/bin/python%type_raw[python] setup.py install --root %d --netcdf_prefix=%p
mkdir -p %i/share/doc/%n/HTML
mkdir -p %i/share/doc/%n/PDF
mv %i/bin/bsp_virtual %i/bin/bsp_virtual%type_pkg[python]
# mv %i/bin/task_manager %i/bin/task_manager%type_pkg[python]
# task_manager needs pyro to be packaged
rm %i/bin/task_manager
cp -R Examples %i/share/doc/%n
cp -R Doc/* %i/share/doc/%n
<<
PostInstScript: <<
# Add --verbose to update-alternatives for debugging
update-alternatives --verbose --install %p/bin/bsp-virtual
scientificpython-py %p/bin/bsp_virtual%type_pkg[python] %type_pkg[python]
<<
# task_manager needs pyro... not currently packaged
# --slave %p/bin/task_manager task_manager %p/bin/task_manager%type_pkg[python]
PreRmScript: <<
if [ $1 != "upgrade" ]; then
update-alternatives --verbose --remove scientificpython-py
%p/bin/bsp_virtual%type_pkg[python]
fi
<<
License: OSI-Approved
DocFiles: README LICENSE
Description: Python modules for scientific computing
DescDetail: <<
In this collection you will find modules that
cover basic geometry (vectors, tensors, transformations, vector and
tensor fields), quaternions, automatic derivatives, (linear)
interpolation, polynomials, elementary statistics, nonlinear
least-squares fits, unit calculations, Fortran-compatible text
formatting, 3D visualization via VRML, and two Tk widgets for
simple line plots and 3D wireframe models.
There are also interfaces to the netCDF library.
The netCDF module is OPeNDAP enabled, that is URLs for
OPeNDAP/DODS servers can be opened like regular netCDF disk files.
<<
DescPackaging: <<
Use libnc's netcdf instead of netcdf itself because it's better.
<<
#Homepage: http://starship.python.net/crew/hinsen/scientific.html
Homepage: http://sourcesup.cru.fr/projects/scientific-py
<<
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
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] nasty circular dependencies
On Mon, 26 Jan 2015 08:46:31 -0500, Jack Howarth wrote: Currently, we are unable to install giflib7-shlibs from a clean tree. > > % fink install giflib7 > Password: > Scanning package description files.. > Information about 11437 packages read in 2 seconds. > > fink needs help picking an alternative to satisfy a virtual > dependency. The candidates: > > (1) w3m: Text-mode WWW browser with tables/frames > (2) lynx: Console based web browser > (3) elinks: Development version of Links text WWW browser > (4) links: Lynx-like text WWW browser with tables > > Pick one: [1] 1 > The following package will be installed or updated: > giflib7 > The following 5 additional packages will be installed: > giflib7-shlibs imlib2 imlib2-shlibs w3m xmlto > Default answer will be chosen in 60 seconds... > Do you want to continue? [Y/n] y > Failed: Problem resolving dependencies. Check for circular dependencies. I think that's only if you pick w3m (w3m, but not the other options, appears to cycle back to giflib7). I'll work on a fix for giflib7 to break the cycle even in this one optional case later this week. dan -- Daniel Macks dma...@netspace.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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 install inkscape failure
On Sat, 17 Jan 2015 15:47:17 +0900, Akio Sakai wrote: Dear Daniel, > > I have successfully installed inkscape on MacOSX10.8.5. > > i inkscape 0.48.5-4 SVG editor > > For your reference in unsuccessful Yosemite case (I tried 2 times before I sent), I attach full log file. > - > > On 2015/01/15, at 16:33, Akio Sakai wrote: > > Dear Daniel, > > I tried to install inkscape, but it failed. Would you advise me of it? I attach the whole run file for your reference. > > environment: MacOSX 10.10.1 I parsed out the error message, but I have no idea how to solve it. I'm only on 10.7 and 10.8. CXX selection-chemistry.o In file included from selection-chemistry.cpp:97: In file included from ./ui/tool/multi-path-manipulator.h:21: ./ui/tool/node.h:23:10: fatal error: 'tr1/functional' file not found #include ^ I'm pretty sure tr1 is one of the function collections that is evolving in c++11 or boost, but I thought inkscape finally had a portable solution. I don't have 10.10 to test. dan -- Daniel Macks dma...@netspace.org -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ 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] glew-1.11.0-1
On Sat, 13 Dec 2014 16:48:19 -0500, Daniel Macks wrote: On Fri, 12 Dec 2014 20:51:37 -0500, Jack Howarth > wrote: > Benjamin, > > Could you update the glew package to the latest 1.11.0 release? > I'll hack on this this weekend. There are some obsolete details in > the packaging, and also some versioning details that might not be > portable for simply bumping %v. Now have glew1.11 for the new version in fink. dan -- Daniel Macks dma...@netspace.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ 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] glew-1.11.0-1
On Fri, 12 Dec 2014 20:51:37 -0500, Jack Howarth wrote: Benjamin, > Could you update the glew package to the latest 1.11.0 release? I'll hack on this this weekend. There are some obsolete details in the packaging, and also some versioning details that might not be portable for simply bumping %v. dan -- Daniel Macks dma...@netspace.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ 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] bowtie2 giving help2man warnings(?) on Yosemitewith exporter-pm installed
On Mon, 24 Nov 2014 10:05:44 -0800, Alexander Hansen wrote: > > On Nov 24, 2014, at 4:06 AM, Hanspeter Niederstrasser > wrote: > > >> wrote: > >> Hi. I saw this when building bowtie2 on Yosemite with exporter-pm-5.68-1 > >> installed: > >> >> >> make install PREFIX=/sw > DESTDIR=/sw/src/fink.build/root-bowtie2-2.2.4-1 > >> help2man --name="wrapper for bowtie2-align" --no-info \ > >> `pwd`/bowtie2 > bowtie2.1 > >> Constant subroutine main::LC_ALL redefined at > /sw/lib/perl5/Exporter.pm line > >> 66. > >> at /sw/bin/help2man line 28. > >> Prototype mismatch: sub main::LC_ALL () vs none at > /sw/lib/perl5/Exporter.pm > >> line 66. > >> at /sw/bin/help2man line 28. > >> help2man --name="building a colorspace index for bowtie2" --no-info \ > >> `pwd`/bowtie2-build > bowtie2-build.1 > >> Constant subroutine main::LC_ALL redefined at > /sw/lib/perl5/Exporter.pm line > >> 66. > >> at /sw/bin/help2man line 28. > > > Can you try this change to > > /sw/lib/perl5/5.16.2/darwin-thread-multi-2level/Locale/gettext.pm > (fix > path to whatever system-perl is for you). This file belongs > to > locale-gettext-pm5XXX. Maintainer cc'd in case it works. > > > --- /sw/lib/perl5/5.16.2/darwin-thread-multi-2level/Locale/gettext.pm > > +++ /sw/lib/perl5/5.16.2/darwin-thread-multi-2level/Locale/gettext.pm > > @@ -32,6 +32,7 @@ > > =cut > > > use Carp; > > +use POSIX qw(:locale_h); > > > require Exporter; > > require DynaLoader; > > > Hanspeter > > > [1] https://rt.cpan.org/Public/Bug/Display.html?id=35680 > > Works for me with Perl-5.18.2. Pushed in revision 4. Thanks for all the debugging legwork! dan -- Daniel Macks dma...@netspace.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ 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] xvfb-run oddity
On Mon, 17 Nov 2014 16:57:54 -0800, Alexander Hansen wrote: On 11/17/14, 4:33 PM, Jack Howarth wrote: > > > > Is it expected that invoking xvfb-run is insufficient to trigger > > the launching of Xquartz (even after the application has been run once > > in an account)? I was very surprised by this behavior as every other X > > windows program that I have run manages to trigger the launch of > > Xquartz. In the case of xvfb-run, if Xquartz isn't already running, one > > gets the error… > > > > Xvfb failed to start > > I'm pretty sure this used to work as intended. > > I tried starting Xquartz by running xterm, then quit it, and xvfb-run > has been working after that. This was on Xquartz-2.7.7 on Yosemite. > > I haven't rebooted yet. The expectation is that xvfb-run is sufficient to do whatever it has to do to get itself working. If that means triggering the launch of Xquartz, then it needs to do that, and I'm also surprised that running Xvfb would not trigger it. The xvfb-run script is just a wrapper around Xvfb itself that handles xauth, avoids race conditions when picking various arbitrary/dummy screen parameters, and graceful shutdown. Probably the simplest (or at least first) test would be to see if just "Xvfb :10" from the commandline fails. I don't have a 10.10 box to test. dan -- Daniel Macks dma...@netspace.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ 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] Some perlmods to be Yosemified
On Thu, 13 Nov 2014 13:20:05 -0500, Daniel Johnson wrote: > > On Nov 13, 2014, at 1:16 PM, Alexander Hansen > wrote: > > > I’m installing the perlmods needed for the mirror validation > script in the fink-mirrors source, and the following modules didn’t > have pm5182 variants yet: > > > html-form-pm (Daniel J.) > > http-response-encoding-pm (Daniel M.) > > > I’ve got updated packaging which just adds pm5182 variants to > the existing packages, and I can add that to the distro if there are > no objections (these are in the dep chain for www-mechanize-pm). > > -- > Alexander Hansen, Ph.D. > > Fink User Liaison > > Fine with me. You can do that with any of my packages as long as > they pass tests. I seem to have been distracted by other things. Ditto for me. If all you do is add the variant and it passes all self-tests and there are no splitoffs (foo-pmXXX-bin, etc), akh is welcome to commit. dan -- Daniel Macks dma...@netspace.org -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ 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] libtool2 update needed for Yosemite
There's a new upstream version that also has the fix, builds and seems
to pass tests:
138 tests behaved as expected.
31 tests were skipped.
Only change was that the PatchScript was looking for
libltdl/m4/libtool.m4, which has now moved up a level to m4/libtool.m4.
However, the installation-time filename munging did not seem to work.
Despite seemingly the same "transform" related entries in Makefile,
libtoolize is directly created as "libtoolize" rather than
"glibtoolize" (which I only noticed because the next InstallScript
command failed when trying to symlink). It's no problem to switch the
sense of linkname and targetname (which is real vs link), but clearly
something is misbehaving and I don't know what.
Unrelatedly, TestDepends could bump from automake1.11 to automake1.14.
It's still a circular dependency, but may as well reduce dependence on
such an old am that isn't used by so many other packages.
dan
On Thu, 30 Oct 2014 22:47:25 -0400, Jack Howarth
wrote:
Max, We need an fixed libtool2 package for Yosemite. The current
one has the libtool.m4 bug which confused 10.10 with 10.1 and results
in shared library being linked with "-dynamiclib -flat_namespace"
rather than the appropriate "-dynamiclib -undefined dynamic_lookup".
While this is fixed in the new libtool 2.4.3 release, they appear to
have broken --program-prefix=g in that release.
> Attached is a libtool2-2.4.2-4 packaging which uses the same back
> port of the fix as home-brew.
>
> https://raw.githubusercontent.com/Homebrew/homebrew/master/Library/Formula/libtool.rb
>
> Index: libtool2.info
> ===
> RCS file:
> /cvsroot/fink/dists/10.7/stable/main/finkinfo/devel/libtool2.info,v
> retrieving revision 1.5
> diff -r1.5 libtool2.info
> 19c19
> < Revision: 3
> ---
> > Revision: 4
> 26c26,28
> < Source-MD5: d2f3b7d4627e69e13514a40e72a24d50
> ---
> > Source-MD5: d2f3b7d4627e69e13514a40e72a24d50
> > PatchFile: %n.patch
> > PatchFile-MD5: da6decbe2f0b7a3572db27c4bddcadb5
> 29a32
> > %{default_script}
>
> This version passes 'fink -m' and also produces a glib tool which
> properly links
> the files in cyrus-sasl2-shlibs on Yosemite.
> Jack
> ps The current fink 0.38.2 release now treats the absence of the
> TWOLEVEL flag from the output of 'toool -hv' on a non-bundle shared
> library as a marker for the use of -flat_namespace and uses a fatal
> validation error. The inappropriate use of -dynamiclib
> -flat_namespace causes major runtime regressions for packages like
> gmp/mpfr/gmp and libgfortran from FSF gcc.
>
> -
>
> --
>
> -
>
> _______
> 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
>
--
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
Re: [Fink-devel] Fwd: validation test for Puma-linked shared librarieson darwin14 and later
That otool-hv is the same test we first encountered in the original transition to two-level namespaces. Was that gcc3.3ish? Quick and easy because all we care about is the bit (the detail of the whole library), not the detailed symbol-by-symbol analysis. dan On Tue, 28 Oct 2014 22:09:29 -0400, Jack Howarth wrote: > -- Forwarded message -- > From: Jack Howarth > Date: Tue, Oct 28, 2014 at 10:08 PM > Subject: Re: [Fink-devel] validation test for Puma-linked shared > libraries on darwin14 and later > To: Alexander Hansen > > Alternatively, the Apple linker developer pointed out, we can use... > > # otool -hv libgdbm.3.0.0.dylib > libgdbm.3.0.0.dylib: > Mach header > magic cputype cpusubtype caps filetype ncmds sizeofcmds flags > MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 14 > 1536 NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS > > vs > > # otool -hv libgdbm.3.0.0.dylib > libgdbm.3.0.0.dylib: > Mach header > magic cputype cpusubtype caps filetype ncmds sizeofcmds flags > MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 14 > 1536 DYLDLINK NO_REEXPORTED_DYLIBS > > and look for the presence of TWOLEVEL. > > On Tue, Oct 28, 2014 at 9:38 PM, Jack Howarth > wrote: > > As I mentioned to Alexander on fink irc, it appears that we can use.. > > # /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind > .libs/libgdbm.3.0.0.dylib > bind information: > segment section address type addend > dylib symbol > __DATA __got 0x4000 pointer 0 > libSystem ___stack_chk_guard > __DATA __nl_symbol_ptr 0x4008 pointer 0 > libSystem dyld_stub_binder > > vs > > # /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind > .libs/libgdbm.3.0.0.dylib | grep flat > __DATA __got 0x4000 pointer 0 > flat-namespace ___stack_chk_guard > __DATA __got 0x4008 pointer 0 > flat-namespace _gdbm_errno > __DATA __nl_symbol_ptr 0x4010 pointer 0 > flat-namespace dyld_stub_binder > > and just grep the output for flat-namespace. > Jack > > On Tue, Oct 28, 2014 at 9:14 PM, Alexander Hansen > wrote: > > On 10/28/14, 6:05 PM, Jack Howarth wrote: > > As I mentioned to Alexander on fink irc, I think we can add a > fatal fink validation error for the dynamic shared libraries on darwin14 > and later that are erroneously linked with -flat_namespace rather than > -undefined dynamic_lookup due to the buggy libtool. We can use the > following approach... > > 1) test with the 'file' command to make sure the shared library isn't > really a bundle > 2) if not a bundle, use 'otool -H | grep Hint' to look for... > > Two-level namespace hints table (0 hints) > > which shared libraries created with -flat_namespace should be missing. > > If this test fails on darwin14 or later, this should be treated as a > fatal validation error with the appropriate error message. > > Jack > > The good news is that Validation.pm already has a loop over the > installed dylibs in a .deb, excluding bundles, so adding an extra > test won't be too difficult. > > The bad news is that my test case (libtcd-shlibs on 10.10 with and > without the PatchScript) didn't seem to give different "otool -H " > output whether or not -flat_namespace was used. > -- Alexander Hansen, Ph.D. > Fink User Liaison > My package updates: http://finkakh.wordpress.com/ > > - > > ------ > > - > > ___ > 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 > -- 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
Re: [Fink-devel] [cvs] dists/10.7/stable/main/finkinfo/scinetcdf-c7.info, 1.13, 1.14
On Mon, 27 Oct 2014 10:29:59 -0700, Alexander Hansen wrote: > > I believe that I'm an active maintainer, and I want the common > courtesy of being informed when people touch ANY of my packages > BEFORE any commits are made, so that I can check them out for myself. > Everybody should consider themselves informed: EVERY ONE OF MY > PACKAGES IS OFF LIMITS UNLESS I SAY OTHERWISE. > > I don't care how trivial the change is. Nor do I care if it affects > your day job--that's what the local tree is for. > > It's almost never the case that I don't answer email for several > days, so I'm astounded by this change having been made without any > attempt to contact me about it. Note that this is policy. It's not a new policy. The agreement of being a maintainer with a commit bit to a common directory where other maintainers all have the same permissions to everyone's files is that you still have the self-control to not touch other people's stuff without talking to them first. 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
Re: [Fink-devel] Results of 2014 Fink buildworld run on 10.9
On Sat, 20 Sep 2014 16:42:43 -0500, Hanspeter Niederstrasser wrote: Dear Fink developers: > > The recent buildworld run did not validate the .info and .deb files. > I've manually run the builworld debs through the validator and the > following debs came out with errors: I tossed those results onto the fink wiki at http://wiki.finkproject.org/index.php/Whiteboard-validation Everyone is welcome to work on any orphans, remove entries when fixed, etc. dan -- Daniel Macks dma...@netspace.org -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ 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's blt-2.4z-161 fails - missing dependency?
On Fri, 29 Aug 2014 08:50:02 -0700, "William G. Scott" wrote: > On Aug 29, 2014, at 4:11 AM, Kevin Horton wrote: > > > I’m gradually building up my list of installed Fink packages in > OS X 10.10 beta. blt-2.4z-161 fails to build due to a missing > tkint.h. > = > > I took a quick look at the available tk packages, but there are so > many that it wasn’t completely clear which one I’m missing. My > first guess would be tklib. > > > What package do I need to install to get tkint.h? > > Hi Kevin: > > I’m just catching up with you. > > Briefly, the problem is tcltk 8.5 rather than 8.6 is getting > installed on 10.10. I haven’t had a chance to try to figure out > why. There is a conditional test in blt that, ironically, would have > failed in such a way as to make this work, until I fixed the syntax > for 10.10. > > Ultimately, we are better off getting the right tcltk (8.6) > installing on 10.10. Fixed (I think...tcltk 8.5ish on 10.7/10.8 and 8.6ish on 10.9/10.10) dan -- Daniel Macks dma...@netspace.org -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.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] OS X version comparisons (was Re: zsh-templates with OS X 10.10)
A quick grep for this construct found 43 of them in *.info, but there are lots more similar cases not as easy to find with a one-liner. A more portable way might be what sqlite3.info does: cut off the major-version (just compare N not 10.N) and do numerical (not string) comparison. dan On Wed, 27 Aug 2014 19:02:14 -0700, "William G. Scott" wrote: Hi Kevin: > > It looks like all (or at least most) of the problems are due to > conditional tests of the form > > if [[ $(sw_vers -productVersion) < 10.N ]]; then > > (where N is 4, 5, 6, 7, 8, 9. 10.10 is evaluated as 10.1.) > > I’ll try to come up with a reasonable fix. > > Bill > > > > > On Aug 27, 2014, at 1:51 PM, Kevin Horton wrote: > > > I’m running the second public beta of OS X 10.10 on my secondary > computer. zsh-templates works mostly well, but something is awry > with dirstack, cd? and gdirs. All three emit three “-i used with > no filenames on the command line, reading from STDIN.” lines in the > terminal for each entry (i.e. 60 lines of this spurious output, for > the default 20 returned values). The functions do work, but their > usefulness is greatly reduced at the CLI, as you must scroll and > visually parse the output to find the directory stack lines. > > > I’d be happy to help debug in any way - just tell me what > additional info you need. > > > Thanks for zsh-templates. > > > -- > Kevin Horton > > Ottawa, Canada > > > -- > Slashdot TV. Video for Nerds. Stuff that matters. > http://tv.slashdot.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 > > -- Daniel Macks dma...@netspace.org -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.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
Re: [Fink-devel] gcc48 & gcc49 info/patch files for successful buildunder Yosemite 10.10
On Mon, 25 Aug 2014 15:54:33 -0400, John Lillibridge - NOAA Federal wrote: Greetings Fink Developers, > > In my continuing efforts to install Fink packages under Yosemite > Public Beta (now #2), I have finally succeeded in getting gcc48 and > gcc49 to build from scratch. I had a hunch that gcc was confused by > the 2-digit minor version in OS-X (10.10.x) since all previous > releases of OS-X had been single digit (10.0.x-10.9.x). Sure enough, > that was the problem in two files: gcc/config/darwin-c.c and > gcc/config/darwin-driver.c. I found the fix at MacPorts, as well as > under the gcc page at sourceforge.net. I appended the patches for the > two 'darwin' files onto gcc48.patch and gcc49.patch, and then updated > the gcc48.info and gcc49.info files with the new PatchFile-MD5 > checksums. Attached are the info and patch files that allowed gcc48 > and gcc49 to build under the HalfDome version of Fink under Yosemite > 10.10. Thanks for debugging and finding the fix! As to a larger issue, I wonder if we should use this as an opportunity to migrate more fully to gcc49 so we don't have to keep dragging along older compilers at all? dan -- Daniel Macks dma...@netspace.org -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.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
Re: [Fink-devel] Results of 2014 Fink buildworld run on 10.9
On Wed, 20 Aug 2014 17:44:00 +0200, Max Horn wrote: Hi, > > On 19.08.2014, at 19:57, Daniel Macks wrote: > > > On Tue, 19 Aug 2014 13:47:58 +0200, Max Horn wrote: > > [...] > > >> cp: /sw/share/info/dir.bak: Permission denied > >> >> I think this is caused by the install-info tool and the fact > that the >> affected packages (e.g. grep) use the "InfoDocs" fields. > I don't >> think a package author can do much about that, can they? > As such, >> perhaps you could check if the above line is the only one > with >> "permission denied", and in that case, demote the "failure" > to a >> "warning" ? > > > In a packaging context, install-info should be deferred to the > actual > live install (.deb -> %p) rather than during the writing to > the staging > directory (InstallScript -> %i). InfoDocs automatically > does the > former. Some build systems automatically disable > install-info in the %i > context, but others need to be disabled > explicitly by the maintainer. > It's always doable, but there are > many variations among the build tools > (sometimes an autoconf flag, > sometimes a make variable, sometimes > manually commenting out part > of a makefile). Any hints on how to do that, or perhaps examples of > packages that do that? > Many of the affected cases are actually straight GNU packages, such as > diffutils, gawk, grep, gzip, sed I just looked at grep, which appears to use a standard automake recipe that can be controlled by: -make install DESTDIR=%d +make install DESTDIR=%d AM_UPDATE_INFO_DIR=no dan -- Daniel Macks dma...@netspace.org -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.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
Re: [Fink-devel] Results of 2014 Fink buildworld run on 10.9
On Tue, 19 Aug 2014 13:47:58 +0200, Max Horn wrote: Dear Hanspeter, > > On 17.08.2014, at 21:18, Hanspeter Niederstrasser > wrote: > > > Dear Fink developers and users, > > > I've just published the results of a buildworld run on a 10.9 > system. > The buildworld tries to build every package in the Fink > tree from > scratch on a clean environment and so will find packaging > problems that > may be hidden on a production system. > > Thanks for that! > > > > The general report broken down by results category is here: > > http://www.snaggledworks.com/fink/buildworld/2014-07-24/out/report.html > > > The listing by maintainer is here: > > http://www.snaggledworks.com/fink/buildworld/2014-07-24/out/maintindex.html > > On both of these, there is a link to "failure category definitions", > pointing to > > http://www.snaggledworks.com/fink/buildworld/2014-07-24/out/filters.xml > > but this gives me a 404 error. > > > In any case, I fixed some of the issues you pointed out (in sdl2, > fflas-ffpack, mc, the-silver-searcher) but now am mostly left with > "failures/project/insufficient_permission" failures, but I am not > quite sure what the failure indicates. Perhaps this: > > cp: /sw/share/info/dir.bak: Permission denied > > I think this is caused by the install-info tool and the fact that the > affected packages (e.g. grep) use the "InfoDocs" fields. I don't > think a package author can do much about that, can they? As such, > perhaps you could check if the above line is the only one with > "permission denied", and in that case, demote the "failure" to a > "warning" ? In a packaging context, install-info should be deferred to the actual live install (.deb -> %p) rather than during the writing to the staging directory (InstallScript -> %i). InfoDocs automatically does the former. Some build systems automatically disable install-info in the %i context, but others need to be disabled explicitly by the maintainer. It's always doable, but there are many variations among the build tools (sometimes an autoconf flag, sometimes a make variable, sometimes manually commenting out part of a makefile). 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
Re: [Fink-devel] Results of 2014 Fink buildworld run on 10.9
A huge public "thank you" for doing this! While working on one of the warnings seen in: http://www.snaggledworks.com/fink/buildworld/2014-07-24/logs/io-aio-pm5124.log I found a symptom of a general problem with portability of fdatasync(). Compiling "succeeds", but the function doesn't actually work as expected. Could you grep the build logs for mentions of that string to see if there are other packages that need attention? 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
Re: [Fink-devel] Yosemite (Alexander Hansen) - (some) successbuilding Fink under 10.10 Yosemite
On Fri, 8 Aug 2014 16:18:57 -0400, John Lillibridge - NOAA Federal wrote: Hi Alexander, > > Sorry I wasn't more explicit. The failure occurred in the > openssl100-dev package that CVS depends upon. I had seen similar > pod2man errors "Expected text after =item, not a number" and thought > it was a more generic problem. Perhaps a newer version of Perl under > Yosemite 10.10? In any case, here are the error messages for the > OpenSSL package: > > > created directory `/sw/src/fink.build/root-openssl100-dev-1.0.1e-3/sw/share' > created directory > `/sw/src/fink.build/root-openssl100-dev-1.0.1e-3/sw/share/man' > created directory > `/sw/src/fink.build/root-openssl100-dev-1.0.1e-3/sw/share/man/man1' > created directory > `/sw/src/fink.build/root-openssl100-dev-1.0.1e-3/sw/share/man/man3' > created directory > `/sw/src/fink.build/root-openssl100-dev-1.0.1e-3/sw/share/man/man5' > created directory > `/sw/src/fink.build/root-openssl100-dev-1.0.1e-3/sw/share/man/man7' > > installing man1/CA.pl.1 > installing man1/asn1parse.1 > installing man1/ca.1 > installing man1/ciphers.1 > installing man1/cms.1 > > cms.pod around line 457: Expected text after =item, not a number > cms.pod around line 461: Expected text after =item, not a number > cms.pod around line 465: Expected text after =item, not a number > cms.pod around line 470: Expected text after =item, not a number > cms.pod around line 474: Expected text after =item, not a number > > POD document had syntax errors at /usr/bin/pod2man5.18 line 72. > > make: *** [install_docs] Error 255 > > ### execution of /tmp/fink.u2mYI failed, exit code 2 > ### execution of /tmp/fink.mdZVk failed, exit code 2 > > Removing runtime build-lock... > Removing build-lock package... > > /sw/bin/dpkg-lockwait -r fink-buildlock-openssl100-dev-1.0.1e-3 Fink has openssl much newer than 1.0.1e for a while now in the standard package dist, but the bootstrap set is lagging. By eye, the 1.0.1h currently in the dist has changes in those vicinity to fix that sort of problem. I just sync'ed that into the boostrap set in master. Someone please test on 10.10 and sync to HalfDome if it's okay. 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
Re: [Fink-devel] Missing Depnds:perlXXX-core
On Mon, 4 Aug 2014 09:20:34 -0500, Hanspeter Niederstrasser wrote: On Sun, August 3, 2014 10:09 pm, Daniel Macks wrote: > > Should we make a validator test for if: > > Â Package:*-pm(\d+) > > then require: > > Â Depends:perl\1-core > > ? > > > > Should it be a .info test or a .dep test? > > > > I tried a few grep-based heuristics on dists/10.7/finkinfo and found 40-80 > > such missing. > > Probably doesn't hurt to have a val test. > > It should be a .info test, I think. If a deb is built w/ perlXXX-core > present, but used where absent, the runtime error is pretty obvious. But a > build w/out perl5.x.y around will fail. Added to git master (and also for python and ruby). I allowed a dependency on another package with matched variant as an alternative to a dependency on the language itself. That is, bar-pm5124:Depends:foo-pm5124 is sufficient as it inherits an indirect dep on perl5124-core via foo-pm5124 (which either has an explicit Depends:perl5124-core or else recurses down to other *-pm5124). It uncovered a handful of cases in 10.7/finkinfo, all fixed now. Please let me know if your build/run testing finds any others (== this new test is leaky) or other problems with it. dan -- Daniel Macks dma...@netspace.org -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ 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] trouble installing emacs24
On Mon, 23 Jun 2014 20:37:00 +0100, Derek Homeier wrote: On 23 Jun 2014, at 01:43 pm, Jesse Alama wrote: > > >> >> Emacs depends on the pkg 'passwd-games' so that user should > normally be set > >> up on the system. Try 'fink reinstall passwd-games' and select yes when > >> asked to install the user. > > > Thanks, that does seem to have made a difference. A fresh rebuild and > > reinstall of emacs24 does lead to some curiosities, though: > > emacs24-24.3-3 now seems to be missing a dependency on gnutls28-shlibs. And libmagickcore6.q16.2-shlibs libmagickwand6.q16.2-shlibs dan -- Daniel Macks dma...@netspace.org -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ 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] Circular dependency for python27 on Darwin13
On Wed, 11 Jun 2014 12:56:11 -0400, Daniel Macks wrote: On Wed, 11 Jun 2014 18:48:20 +0200, Martin Costabel > wrote: > On 11/06/14 15:41, TheSin wrote: > > > aren’t these BDO? how can you dep on them then? And since you > > can’t dep on them how can you have a circ dep with them? > > > --- > > > TS > > > http://www.southofheaven.org/ > > > Life begins and ends with chaos, live between the chaos! > > > > > > On Jun 11, 2014, at 1:19 AM, Martin Costabel wrote: > > > > > >> pkgconfig->glib2-dev > > > > These are build deps. Nothing illegal, just fatal (and IMHO > bloated: > pkgconfig is a dep or bdep for hundreds of packages. It is > just a > simple reader for *.pc files and should probably come with > xcode or > at least with X11, but it now requires glib2, gtk-doc, > docbook, > openjade, and so on). pkg-config is indeed a bit of bloat > itself. The alternative for *its* dependencies is to build its own > internal glib2 from source (note: the previous versions of pkg-config > didn't have the glib2 dep because they built their own internal glib1 > from source). The major dep bloat (setting aside pkg-config's choice > of implementation) is the glib2->gtk-doc build dep, which IIRC is > only needed because of a bug in the glib2 dist tarball. Newer glib2 > will presumably not need that hack. The glib2->gtk-doc dependency is now severed. I don't see any other dependency loops anywhere on my 10.8 fink machine except when building in -m (maintainer) mode. I'll try to switch pkgconfig back to using internal glib2 snapshot once I finish working on glib2 itself (no sense splitting/duplicating time). pkgconfig itself is GPL, so I suspect Apple would not want to include it. But cleanroom implementations under other licenses are possible (*assuming* they're really compatible). dan -- Daniel Macks dma...@netspace.org -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ 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] Circular dependency for python27 on Darwin13
On Wed, 11 Jun 2014 18:48:20 +0200, Martin Costabel wrote: On 11/06/14 15:41, TheSin wrote: > > aren’t these BDO? how can you dep on them then? And since you > can’t dep on them how can you have a circ dep with them? > > --- > > TS > > http://www.southofheaven.org/ > > Life begins and ends with chaos, live between the chaos! > > > > On Jun 11, 2014, at 1:19 AM, Martin Costabel wrote: > > > >> pkgconfig->glib2-dev > > These are build deps. Nothing illegal, just fatal (and IMHO bloated: > pkgconfig is a dep or bdep for hundreds of packages. It is just a > simple reader for *.pc files and should probably come with xcode or > at least with X11, but it now requires glib2, gtk-doc, docbook, > openjade, and so on). pkg-config is indeed a bit of bloat itself. The alternative for *its* dependencies is to build its own internal glib2 from source (note: the previous versions of pkg-config didn't have the glib2 dep because they built their own internal glib1 from source). The major dep bloat (setting aside pkg-config's choice of implementation) is the glib2->gtk-doc build dep, which IIRC is only needed because of a bug in the glib2 dist tarball. Newer glib2 will presumably not need that hack. Packages that need the functionality of pkg-config but want a lighter-weight implementation are welcome to use pykg-config (see .'fink info pkkg-config' for compatibility and migration details). dan -- Daniel Macks dma...@netspace.org -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ 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] Circular dependency for python27 on Darwin13
On Wed, 11 Jun 2014 12:25:15 +0200, Frava wrote: Ok, thank you for the replies, and sorry for having posted here. I will now wait for a fix. > > PS: Where do I have to report this kind of inconsistency in the > Fink's repository ? Many thanks for reporting these sorts of problems! Sometimes a maintainer might not realize that a small change to his own package creates problems for another (or that lots of seemingly okay changes conspire to create a special problem that is only seen in some situations. This mailing list is a fine place. dan -- Daniel Macks dma...@netspace.org -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ 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] Fwd: libgdbm4 title referencs libgdbm3
I fixed the package description. dan On Fri, 6 Jun 2014 13:08:28 -0400, Bill Waggoner wrote: I tried to send this note to the listed maintainer for gdbm4-shlibs > but my message got returned with: > > Technical details of temporary failure: > The recipient server did not accept our requests to connect. Learn > more at http://support.google.com/mail/bin/answer.py?answer=7720 > [(10) mail.finkproject.org. [213.84.134.226]:25: Connection refused] > > Thought you might like to know. > > Bill Waggoner > > > -- Forwarded message -- > From: Bill Waggoner > Date: Thu, Jun 5, 2014 at 11:41 AM > Subject: libgdbm4 title referencs libgdbm3 > To: Dave Morrison > > > Something I noticed quite incidentally today: libgdbm4-shlibs refers > to libgdbm3 in the title > > > `--> fink list gdbm > Information about 9743 packages read in 1 seconds. > i gdbm3 1.8.3-4 GNU dbm library > i gdbm3-shlibs 1.8.3-4 Shared libraries > for gdbm3 package > gdbm4 1.9.1-1 GNU dbm library > gdbm4-shlibs 1.9.1-1 Shared libraries > for gdbm3 package > gdbmexport 1.9.1-1 GNU dbm data > exporter/updater > > > No big deal but I thought you would like to know. > > Bill Waggoner > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > ___ > 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 > > -- Daniel Macks dma...@netspace.org -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ 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] Warning: Description of "ghc-zlib" exceeds 45characters. (ghc-zlib.info)
That sounds pretty intentional. The action of "update-all" is "check what's already installed, make sure it's the latest available", so it would have no reason so look at .info for packages that are not installed at all. dan On Sun, 1 Jun 2014 08:28:52 -0400, Jack Howarth wrote: Alexander, I see the difference now. It appears that 'fink -m update-all' only checks individual info files for validation errors if one of packages generated by the info file is already installed. Is that the intended behavior or a glitch? > Jack > > On Sun, Jun 1, 2014 at 8:24 AM, Jack Howarth > wrote: > > Brendan, Can you fix ghc-zlib.info so that it passes validation? > > Alexander, > Have you ever noticed that 'fink -m update-all' seems > non-deterministic? On some machines, the error in ghc-zlib.info is > detected but on other machines it is silently ignored. If this > issue were fixed in fink, it would be nice to have a cron job set up > do run 'fink -d -m update-all' weekly and automatically email the > maintainers on validation errors in their info files. > Jack > > - > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet - > > ___ > 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 > -- Daniel Macks dma...@netspace.org -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ 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] update libjson
Makes sense. As long as it's done at the same time as a change of
install_name is happening for other reasons (new libversion), moving
the existing one to a subdir also will not be disruptive.
Unrelated new detail...your libjson.patch alters a makefile
-install_name flag and then libjson.info does install_name_tool to
change install_name again. Can the makefile just do it correctly right
away?
dan
On Sun, 18 May 2014 17:28:44 -0400, Jack Howarth
wrote:
Daniel, FYI, the json-c package could stand an update as well
since it is behind by three releases…
>
> https://github.com/json-c/json-c/wiki
>
> so both packages could have their shared libs buried in
> subdirectories. As for the static lib,
> I built it as the the build is pretty quick.
> Jack
>
> On Sat, May 17, 2014 at 1:57 PM, Daniel Macks wrote:
>
> On Sat, 17 May 2014 13:07:14 -0400, Jack Howarth
> wrote:
> Sjors,
>
> The attached packaging updates the libjson to the
> latest 7.6.1 release and patches the makefile so that the fink build
> produces both the static and shared libs with the latter residing in
> a new libjson-shlibs split-off. This upgrade to the newer libjson
> release allows the package to be built against clang++ instead of
> llvm-gcc++ which doesn't exist on 10.9. Build-fails for me on 10.8.
> But succeeded if I re-added UseMaxBuildJobs:false that is present in
> the current .info. Is there value in still having the static lib now
> that there is a shared one?
>
> There are two "libjson" library packages (this one and "json-c"), and
> now both will have shared (they should probabaly Conflicts/Replaces
> not just Conflicts). They also use the same install_name root
> ("libjson"). For now, they have different library-versioning
> (libjson.0.dylib bs libjson.7.dylib), but they are two independent
> projects. I wonder if one (I guess this new one, since it doesn't
> already exist in fink) should be pushed into a subdir to avoid any
> future collisions of the runtime files?
>
> dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
> -
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs -
>
> ___
> 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
>
--
Daniel Macks
dma...@netspace.org
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
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] update libjson
On Sat, 17 May 2014 13:07:14 -0400, Jack Howarth
wrote:
Sjors,
> The attached packaging updates the libjson to the latest
> 7.6.1 release and patches the makefile so that the fink build
> produces both the static and shared libs with the latter residing in
> a new libjson-shlibs split-off. This upgrade to the newer libjson
> release allows the package to be built against clang++ instead of
> llvm-gcc++ which doesn't exist on 10.9.
Build-fails for me on 10.8. But succeeded if I re-added
UseMaxBuildJobs:false that is present in the current .info.
Is there value in still having the static lib now that there is a shared one?
There are two "libjson" library packages (this one and "json-c"), and
now both will have shared (they should probabaly Conflicts/Replaces not
just Conflicts). They also use the same install_name root ("libjson").
For now, they have different library-versioning (libjson.0.dylib bs
libjson.7.dylib), but they are two independent projects. I wonder if
one (I guess this new one, since it doesn't already exist in fink)
should be pushed into a subdir to avoid any future collisions of the
runtime files?
dan
--
Daniel Macks
dma...@netspace.org
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
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] purging r-cran-* files from 10.7
On Wed, 14 May 2014 09:22:49 -0400, Jack Howarth wrote: I would like to purge the legacy r-cran-* files (which preceded the switch to revision variant-based cran-*-r files). What is best practices for this these days? My inclination is to use the full C/R/P… C/R/P is not functionally equivalent to the effects of C/R and P together...the triplet has a specific different meaning than its components suggest. And it's technically completely broken to use the triplet when the package-name was ever actually a real package. P is also functionally broken as a substitute for a real package when any other package anywhere ever had a versioned dependency on it. This sounds like the exact situation for which fink-obsolete-packages is documented to be used. dan -- Daniel Macks dma...@netspace.org -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ 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] camlp5 dependency problem
I just tried to build camlp5 on 10.7. But... Can't resolve dependency "ocaml (<= 3.13.0)" for package "camlp5-6.02.3-1" (no matching packages/versions found) Sure enough, we have ocaml, but it's 4.01.0-1 dan -- Daniel Macks dma...@netspace.org -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ 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] GTK 2.20?
On Sun, 4 May 2014 12:46:58 -0400, Kevin Horton wrote: > I’d like to update my bluefish package, but all versions newer > than the one currently in fink require at least GTK 2.20 or GTK 3. > Is a GTK update on the horizon at all, or should I give up this > dream? Last I checked (last summer), newer glib2, the lowest level of the gnome stack, had problems on OS X. I've been tracking its new stable releases for a few years...there were still "new" bugs/test-fails in old APIs as well as fails in the newly added ones (the "reason" other parts of the stack need the newer glib2), so I wasn't motivated to really get it all solved (seemed poor to break what works in order to get new things that also might not be working). I had toyed with simply scrapping the new interfaces and working on getting the old ones fixed (so things that say they need new just because "new is better" would be happy, and only have symptoms for things that already weren't doable), but seemed like a lot of work for not really fixing the whole problem. This summer I'm going to try again to get the whole thing working (I've heard that at least some of the test fails are side-effects of how fink's build system is running them). dan -- Daniel Macks dma...@netspace.org -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ 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] r-base215. r-base-30 and r-base31
Why would they want a bug report against such an old version? Are newer
versions not-broken? I'm pretty sure I already mentioned exactly what
change they made in newer versions to avoid trying to access the
internals of the external libpcre.
dan
On Tue, 29 Apr 2014 13:44:34 -0400, Jack Howarth
wrote:
Okay, I now see that disables the use of pcre. Guess someone should
open a PR upstream, no? Do we really gain anything of use by having
R-base build against pcre?
>
> On Tuesday, April 29, 2014, Jack Howarth wrote:
>
> Well, empirically it fixed the r-base214 build on 10.8 for me
> by just changing --with-system-pcre to --with-pcre=%p. It would be
> highly irregular for the --with-system-pcre option not to be pushing
> the headers in /usr/include to be used.
>
> On Tuesday, April 29, 2014, Daniel Macks wrote:
>
>(sorry if this email goes out twice!)
>
> I don't think that's the meaning of "system". R appears to have
> optional onboard/internal sources of various dependencies as an
> alternative to using ones existing "on the system". *Where* on the
> system is a different issue. You can probably check the .d files to
> see exactly which headers are being loaded to see if it's matched. dan
>
> On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth
> wrote:
> Isn't this just a header mismatch? We have both a build depends on
> libpcre1 and --with-system-pcre which is illogical. I am testing with
> --with-system-pcre changed to --with-pcre=%p. FYI, macports doesn't
> pass either flag and incorrectly ignores pcre. On Tuesday, April 29,
> 2014, Daniel Macks wrote:
>
> Using (apparently-)undocumented, internal implementation
> details that are known to change in different versions is *always* a
> problem. Any solution that doesn't involve actually not-doing-that is
> merely deferring the same failure from occurring again in the future
> when those details change again. dan
>
> On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth
> wrote:
> Daniel, Isn't the real problem that r-base in fink is being
> built with --with-system-pcre but the fink lib pcre.1.dylib ends up
> linked into libR. I assume we need a BuildConflicts on libpcre1 in
> order to have the system pcre used.
> Jack
>
> On Tuesday, April 29, 2014, Daniel Macks wrote:
>
> On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks
> wrote:
> On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth
>
> wrote:
> > The r-base214 packaging seems to have test suite issues when built
> > against Xcode 5.1 on darwin12…
> >
> > Testing examples for package ‘utils’
> > /sw/src/fink.build/r-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60:
> > 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} >
> ${R_BATCH_OPTIONS} > ${out} 2>&1
> > Error: testing 'utils' failed
> > Execution halted
>
> The failure appears to be due to an unresolved __pcre_valid_utf (or
> similarly named) symbol in libR.dylib. The R library is trying to
> use a private symbol in libpcre by guessing what it's called (and
> what its parameters are) in various different libpcre versions, but
> our most recent libpcre dropped that symbol altogether. Obviously a
> fragile situation to rely on undocumented non-public content. One
> useful change we can make is to patch out the "-undefined
> dynamic_lookup" from the configure script. That flag causes
> undefined symbols to be ignored by the linker, leaving them to
> cause problems at runtime. By removing the flag, the linking itself
> fails right away rather than leaving a possibly mis-built library.
> ..which reveals that util.dylib is missing -llzma in even in r-base30
> and r-base31 (ones that do not have the pcre problem). dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
> -
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing
> platform available. Simple to use. Nothing to install. Get started
> now for free."
> http://p.sf.net/sfu/SauceLabs -
>
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription mana
Re: [Fink-devel] r-base215. r-base-30 and r-base31
(sorry if this email goes out twice!)
I don't think that's the meaning of "system". R appears to have
optional onboard/internal sources of various dependencies as an
alternative to using ones existing "on the system". *Where* on the
system is a different issue. You can probably check the .d files to see
exactly which headers are being loaded to see if it's matched.
dan
On Tue, 29 Apr 2014 13:21:08 -0400, Jack Howarth
wrote:
Isn't this just a header mismatch? We have both a build depends on
libpcre1 and --with-system-pcre which is illogical. I am testing with
--with-system-pcre changed to --with-pcre=%p. FYI, macports doesn't
pass either flag and incorrectly ignores pcre.
>
> On Tuesday, April 29, 2014, Daniel Macks wrote:
>
>Using (apparently-)undocumented, internal implementation
> details that are known to change in different versions is *always* a
> problem. Any solution that doesn't involve actually not-doing-that is
> merely deferring the same failure from occurring again in the future
> when those details change again. dan
>
> On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth
> wrote:
> Daniel, Isn't the real problem that r-base in fink is being
> built with --with-system-pcre but the fink lib pcre.1.dylib ends up
> linked into libR. I assume we need a BuildConflicts on libpcre1 in
> order to have the system pcre used.
> Jack
>
> On Tuesday, April 29, 2014, Daniel Macks wrote:
>
> On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks
> wrote:
> On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth
>
> wrote:
> > The r-base214 packaging seems to have test suite issues when built
> > against Xcode 5.1 on darwin12…
> >
> > Testing examples for package ‘utils’
> > /sw/src/fink.build/r-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60:
> > 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} >
> ${R_BATCH_OPTIONS} > ${out} 2>&1
> > Error: testing 'utils' failed
> > Execution halted
>
> The failure appears to be due to an unresolved __pcre_valid_utf (or
> similarly named) symbol in libR.dylib. The R library is trying to
> use a private symbol in libpcre by guessing what it's called (and
> what its parameters are) in various different libpcre versions, but
> our most recent libpcre dropped that symbol altogether. Obviously a
> fragile situation to rely on undocumented non-public content. One
> useful change we can make is to patch out the "-undefined
> dynamic_lookup" from the configure script. That flag causes
> undefined symbols to be ignored by the linker, leaving them to
> cause problems at runtime. By removing the flag, the linking itself
> fails right away rather than leaving a possibly mis-built library.
> ..which reveals that util.dylib is missing -llzma in even in r-base30
> and r-base31 (ones that do not have the pcre problem). dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
> -
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing
> platform available. Simple to use. Nothing to install. Get started
> now for free."
> http://p.sf.net/sfu/SauceLabs -----
>
> ___
> 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
>
> --
> Daniel Macks
> dma...@netspace.org
>
> -
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform
> available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs -
>
> ___
> 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
>
--
Daniel Macks
dma...@netspace.org
--
"Accelerate Dev
Re: [Fink-devel] r-base215. r-base-30 and r-base31
Using (apparently-)undocumented, internal implementation details that
are known to change in different versions is *always* a problem. Any
solution that doesn't involve actually not-doing-that is merely
deferring the same failure from occurring again in the future when
those details change again.
dan
On Tue, 29 Apr 2014 13:12:14 -0400, Jack Howarth
wrote:
Daniel, Isn't the real problem that r-base in fink is being
built with --with-system-pcre but the fink lib pcre.1.dylib ends up
linked into libR. I assume we need a BuildConflicts on libpcre1 in
order to have the system pcre used.
> Jack
>
> On Tuesday, April 29, 2014, Daniel Macks wrote:
>
>On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks
> wrote:
> On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth
>
> wrote:
> > The r-base214 packaging seems to have test suite issues when built
> > against Xcode 5.1 on darwin12…
> >
> > Testing examples for package ‘utils’
> > /sw/src/fink.build/r-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60:
> > 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} >
> ${R_BATCH_OPTIONS} > ${out} 2>&1
> > Error: testing 'utils' failed
> > Execution halted
>
> The failure appears to be due to an unresolved __pcre_valid_utf (or
> similarly named) symbol in libR.dylib. The R library is trying to
> use a private symbol in libpcre by guessing what it's called (and
> what its parameters are) in various different libpcre versions, but
> our most recent libpcre dropped that symbol altogether. Obviously a
> fragile situation to rely on undocumented non-public content. One
> useful change we can make is to patch out the "-undefined
> dynamic_lookup" from the configure script. That flag causes
> undefined symbols to be ignored by the linker, leaving them to
> cause problems at runtime. By removing the flag, the linking itself
> fails right away rather than leaving a possibly mis-built library.
> ..which reveals that util.dylib is missing -llzma in even in r-base30
> and r-base31 (ones that do not have the pcre problem). dan
>
> --
> Daniel Macks
> dma...@netspace.org
>
> -
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform
> available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs -
>
> ___
> 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
>
--
Daniel Macks
dma...@netspace.org
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
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] r-base215. r-base-30 and r-base31
On Mon, 28 Apr 2014 22:38:02 -0400, Daniel Macks wrote:
On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth
> wrote:
> > The r-base214 packaging seems to have test suite issues when built
> > against Xcode 5.1 on darwin12…
> >
> > Testing examples for package ‘utils’
> > /sw/src/fink.build/r-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60:
> > 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts} >
> ${R_BATCH_OPTIONS} > ${out} 2>&1
> > Error: testing 'utils' failed
> > Execution halted
>
> The failure appears to be due to an unresolved __pcre_valid_utf (or
> similarly named) symbol in libR.dylib. The R library is trying to
> use a private symbol in libpcre by guessing what it's called (and
> what its parameters are) in various different libpcre versions, but
> our most recent libpcre dropped that symbol altogether. Obviously a
> fragile situation to rely on undocumented non-public content. One
> useful change we can make is to patch out the "-undefined
> dynamic_lookup" from the configure script. That flag causes undefined
> symbols to be ignored by the linker, leaving them to cause problems
> at runtime. By removing the flag, the linking itself fails right
> away rather than leaving a possibly mis-built library.
..which reveals that util.dylib is missing -llzma in even in r-base30
and r-base31 (ones that do not have the pcre problem).
dan
--
Daniel Macks
dma...@netspace.org
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
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] r-base215. r-base-30 and r-base31
On Mon, 28 Apr 2014 20:55:18 -0400, Jack Howarth
wrote:
> The r-base214 packaging seems to have test suite issues when built
> against Xcode 5.1 on darwin12…
>
> Testing examples for package ‘utils’
> /sw/src/fink.build/r-base214-2.14.2-9/R-2.14.2/bin/BATCH: line 60:
> 34097 Trace/BPT trap: 5 ${R_HOME}/bin/R -f ${in} ${opts}
> ${R_BATCH_OPTIONS} > ${out} 2>&1
> Error: testing 'utils' failed
> Execution halted
The failure appears to be due to an unresolved __pcre_valid_utf (or
similarly named) symbol in libR.dylib. The R library is trying to use
a private symbol in libpcre by guessing what it's called (and what its
parameters are) in various different libpcre versions, but our most
recent libpcre dropped that symbol altogether. Obviously a fragile
situation to rely on undocumented non-public content.
One useful change we can make is to patch out the "-undefined
dynamic_lookup" from the configure script. That flag causes undefined
symbols to be ignored by the linker, leaving them to cause problems at
runtime. By removing the flag, the linking itself fails right away
rather than leaving a possibly mis-built library.
> There are quite a few differences between the r-base214 and r-base215
> info files so I am not sure what is the exact cause of the build
> issue. However, since upstream no longer lists the 2.14.x series as
> supported on their home page, we should just drop that package like
> we did with r-base213.
Looks like R now (as of 215) contains the actual internal pcre code it
wants (copied from pcre's sources), so it becomes insensitive to
changes in libpcre's internals. compare src/main/util.c around line
2159, and see the new valid_utf.h file added to support it.
dan
--
Daniel Macks
dma...@netspace.org
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
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] proj-4.8.0-3 broken with latest toolchain
On Sun, 13 Apr 2014 14:33:55 +0200, Andreas Bießmann
wrote:
Dear Kurt Schwehr,
>
> I noticed that proj-4.8.0-3's info file contains the entry 'SetLDFLAGS:
> -no-undefined'. Unfortunately this is the root cause for not compiling
> that package on my box.
>
> ---8<---
> configure:2850: gcc -I/sw/include -no-undefined -L/sw/lib conftest.c >&5
> clang: error: unknown argument: '-no-undefined'
> [-Wunused-command-line-argument-hard-error-in-future]
> clang: note: this will be a hard error (cannot be downgraded to a
> warning) in the future
> configure:2853: $? = 1
> configure:2891: result:
> configure: failed program was:
> | /* confdefs.h. */
> | #define PACKAGE_NAME "PROJ.4 Projections"
> | #define PACKAGE_TARNAME "proj"
> | #define PACKAGE_VERSION "4.7.0"
> | #define PACKAGE_STRING "PROJ.4 Projections 4.7.0"
> | #define PACKAGE_BUGREPORT "warmer...@pobox.com"
> | #define PACKAGE "proj"
> | #define VERSION "4.7.0"
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }
> configure:2898: error: C compiler cannot create executables
> See `config.log' for more details.
> --->8---
>
> ---8<---
> % gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
> Target: x86_64-apple-darwin13.1.0
> Thread model: posix
> --->8---
>
> Commenting that line makes it compile for me.
The makefiles now do include that flag where it's useful and
syntactically viable to do so, so there's no need to pass it manually.
In the build log using the older compiler that doesn't reject this
flag, it is currently passed *twice* in the places needed (libtool
--mode=link of a library; once due to makefile, once due to .info
field) and also once in the linking of executables (where it has no
effect; solely due to .info field). I suspect there are some other
no-longer-needed packaging work-arounds in the .info as well. Let me
know if I should commit this limited xcode5.1 fix and/or other cleanups.
dan
--
Daniel Macks
dma...@netspace.org
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
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] dateutil-py tests require *six*-py to run
On Sun, 6 Apr 2014 21:39:46 +0200, Derek Homeier wrote: > On 06.04.2014, at 9:33PM, Derek Homeier > wrote: > > On 06.04.2014, at 5:58PM, Daniel Macks wrote: > >>> >>> found there is a missing > >>> >>> TestDepends: six-py%type_pkg[python] > >>> >>> in dateutil-py-2.2-1. >> >> Fixed (sip-pyXXX not six-pyXXX). > > > hmm, I had gotten this error: > > > sudo -u fink-bld [ENV] sh -c /tmp/fink.67Gmy > > /tmp/fink.3vLAc > > #!/bin/bash -ev > > # -B prevents the test run from generating __pycache__ .pyc files. > > /sw/bin/python2.7 -B test.py || exit 2 > > Traceback (most recent call last): > > File "test.py", line 5, in > >from six import StringIO, BytesIO, PY3 > > ImportError: No module named six > > Oh, but I should check my own subject line. I did get confused with > the sip-pyXXX-bin > update problems… heh no worries:) It actually looks like a runtime dependency (six is imported by various installed components not just by the test script), so I added it to Depends. 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
Re: [Fink-devel] dateutil-py tests require sip-py to run
On Sat, 5 Apr 2014 20:54:18 +0200, Derek Homeier wrote: Hi, > > found there is a missing > >TestDepends: six-py%type_pkg[python] > > in dateutil-py-2.2-1. Fixed (sip-pyXXX not six-pyXXX). 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
Re: [Fink-devel] Time for 10.6 to go EOL
On Fri, 28 Mar 2014 17:48:52 -0700, Alexander Hansen wrote: We've reached the point where it appears that most maintainers don't > have access to 10.6, and we're getting divergences between the trees. > I've also found some packages that won't build as 32-bit. > > Also, most of our efforts probably need to be concentrated on fixing > the Xcode 5.1 build failures on 10.8 and 10.9. > > I propose ending official project support for 10.6 at the end of > April. There are a couple of options: > > 1) Move all of the package descriptions into a 10.6-EOL structure. > 2) Do nothing and just not update any of the base packages in the 10.4 tree. > > If somebody has an interest in keeping 10.6 going unofficially, they > are certainly welcome to do that. I support EOLing 10.6, and don't see a need to do the technical "mv to 10.6-EOL subdir". 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] Oh Whacking Day! (was Re: Killing python26)
[snip discussion of killing python] python26 (and db48*) are now no-longer-present on 10.7+ > It's also reasonable to kill 3.1 as it's now unsupported upstream. 3.3 and the just released 3.4 will stay of course, but we might also consider killing 3.2 even though it still gets patches. 3.3 introduced better backward compatibility with 2.7 to ease porting to 3.x and vastly improved unicode string handling. I have no objection to killing 3.1 or 3.2, but would first need to make sure all their modules get added variants for newer (or formally decide not to do so). For example, a quick heuristic check of the diff between 'fink list 31' and 'fink list 33' finds (ironically) there 33 has 31 that 33 does not have. dan -- Daniel Macks dma...@netspace.org -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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] Killing python26
We've been dragging python26 along for years, since back when it was the latest thing. It's not. Python27 has been available in fink for many years, and even in the past several OS X versions. Upstream says "Python itself has jumped to the 3.x series in 2008, with some major changes that may make upgrading non-trivial in some cases, so it makes sense to keep "some" python2.x in fink (OS X still has python27 and maybe older also). Upstream plans to keep 27 in maintenance mode for at least a while longer but gave up on even security patches for 26 as I understand it. As of yesterday, the only dependencies on python26 are the -py26 suite of modules--there does not appear to be anything outside of this self-contained tree. Is it time to chop down that tree? There are no -py26 modules that do not have a parallel -py27 variant. Ordinarily, I'd not object to keeping ancient versions of things around and just stop bringing them forward when we roll the next Distribution, but python26 is also the only package still using db48, another ancient version. I'd love to stop having to support ancient versions of things that are not even getting security-support upstream altogether. dan -- Daniel Macks dma...@netspace.org -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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] strange .tgz file doesn't pass gnutar heuristics, but can be extracted with gunzip and tar
On Sun, 19 Jan 2014 10:39:56 -0500, Charles Lepple wrote: On Jan 16, 2014, at 11:20 PM, Charles Lepple wrote: > > The cgi-formbuilder-pm.info file passes validation, but if any Perl > experts want to glance at it (I'm used to packaging Python and C > stuff), it's in a temporary branch here before I commit everything to > CVS: > > https://github.com/clepple/fink-dists/commit/18712affa0b2784f8ef033cd5222d72406d42963 Looks like a good package. Some technical improvements... License could be expanded to be Artistic/GPL (per statement in README and INSTALL). Instead of creating %i/lib/perl5/%type_raw[perl]/man/ and then moving just the man/man3/ subdir into it, you can just move the whole man/ (%i/lib/perl5/%type_raw[perl]/ already exists, so that saves a step and also avoids leaving a stray empty man/ dir). Makefile.PL has some checks for optional modules that fink does supply via other packages. You could Recommends: them. But the test suite also uses them, so they would also be good InfoTest:TestDepends: entries. If they themselves don't have large dep trees and/or the features they are common and useful, I tend to just Depends: them so that other users don't have to figure out fink's package-naming to find them. dan -- Daniel Macks dma...@netspace.org -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ 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] strange .tgz file doesn't pass gnutar heuristics, but can be extracted with gunzip and tar
On Thu, 16 Jan 2014 07:04:56 -0800, Alexander Hansen wrote: On 1/16/14 6:12 AM, Charles Lepple wrote: > > Just thought I'd throw this out there for the archives, or in case > anyone else has seen something similar. > > > > I'm attempting to package > http://search.cpan.org/~nwiger/CGI-FormBuilder-3.09/ and I get the > following at the unpack stage: > > > > env LANG=C LC_ALL=C /sw.lion/bin/tar --no-same-owner > --no-same-permissions -xvf > /Users/clepple/Downloads/CGI-FormBuilder-3.09.tgz > > /sw.lion/bin/tar: This does not look like a tar archive > > /sw.lion/bin/tar: Skipping to next header > > /sw.lion/bin/tar: Exiting with failure status due to previous errors > > ### execution of env failed, exit code 2 > > > > But if I manually gunzip the archive, and feed that to tar: > > > > $ /sw/bin/gnutar tvf ~/Downloads/CGI-FormBuilder-3.09.tar > > /sw/bin/gnutar: Ignoring unknown extended header keyword `SCHILY.dev' > > /sw/bin/gnutar: Ignoring unknown extended header keyword `SCHILY.ino' > > /sw/bin/gnutar: Ignoring unknown extended header keyword `SCHILY.nlink' > > drwxr-xr-x nateware/wheel0 2013-11-29 22:06 CGI-FormBuilder-3.09/ > > /sw/bin/gnutar: Ignoring unknown extended header keyword `SCHILY.dev' > > /sw/bin/gnutar: Ignoring unknown extended header keyword `SCHILY.ino' > > /sw/bin/gnutar: Ignoring unknown extended header keyword `SCHILY.nlink' > > -rw-r--r-- nateware/wheel 17748 2013-11-29 22:06 > CGI-FormBuilder-3.09/Changes > > > > (etc.) > > > > $ ls -l /sw/bin/tar > > lrwxr-xr-x 1 root admin 4 Nov 17 11:56 /sw/bin/tar@ -> gtar > > $ ls -l /sw/bin/gnutar > > lrwxr-xr-x 1 root admin 4 Nov 17 11:56 /sw/bin/gnutar@ -> gtar > > > > It looks like the GNU tar heuristics get confused by the extended > headers when presented with the .tgz. > > > > In the short term, I think I'll just try the Debian .orig.tar.gz, > but has anyone run across this before? (I'm assuming this is from > Schily's S tar, or something similar.) > > > > $ fink --version > > Package manager version: 0.36.3.1 > > Distribution version: selfupdate-cvs Thu Jan 16 08:54:42 2014, 10.7, x86_64 > > Trees: local/main stable/main > > > > TarFilesRename uses the older method of using the uncompressor first > and then pipes the result out, although to pax rather than tar. A > combination of TarFilesRename and SourceRename might well do the > trick here. > > Another option would be to recompress it and have the new tarball > uploaded to Fink's repository on Sourceforge. .tgz is not non-standard (per spec) and not uncommon in the world, I don't think "we should rehost it" is a good general solution. dan -- Daniel Macks dma...@netspace.org -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ 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] new version of m4 available: 1.4.17
On Tue, 31 Dec 2013 06:51:21 +0100, Jesse Alama wrote: > The current version of m4 in Fink is 1.4.16; looks like 1.4.17 is > available upstream. Jack, this passes self-tests on my 10.8 without gl_cv_func_printf_directive_a=no (documented as being needed on darwin>=12, cf. my darwin-12.5.0). Could you verify that the bug you found is fixed? Please let me know (and obviously also if anything else/new is broken). But don't commit...there are some other packaging changes needed (including one that's pretty important). dan -- Daniel Macks dma...@netspace.org -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ 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] Mass migration of python setuptools/distribute
At various times, we've have setuptools-pyXX and distribute-pyXX forking and developing and re-merging and whatnot. It all settled down a few months ago, with the single modern setuptools-tng-pyXX package. It also supplies (via a SplitOff wrapper packages tagged as fink-obsolete-packages and a Provides thereof) the old-named ones, and many other -pyXX packages still use those. But the f-o-p triggers a warning (or error in -m mode). The old-named packages really don't "exist" except as a fink packaging game for other packages' dependencies. Unless I hear any objections, tomorrow I plan to mass migrate all packages to use the new dependency. dan -- Daniel Macks dma...@netspace.org -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ 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] perl5162-core build/install problem on case-sensitiveFS
On Mon, 18 Nov 2013 18:11:50 +0100, Derek Homeier wrote: It seems I am running into troubles with my fink installation on a case-sensitive volume again, > > dpkg-deb -c > /sw/fink/dists/stable/main/binary-darwin-x86_64/languages/perl5162-core_5.16.2-102_darwin-x86_64.deb|grep > -i version/ >drwxr-xr-x root/admin0 2013-11-12 16:02 > ./sw/lib/perl5-core/5.16.2/Version/ > -r--r--r-- root/admin14605 2013-11-12 16:02 > ./sw/lib/perl5-core/5.16.2/Version/Requirements.pm > drwxr-xr-x root/admin0 2013-11-12 16:02 > ./sw/lib/perl5-core/5.16.2/version/ > -r--r--r-- root/admin25001 2013-11-12 16:02 > ./sw/lib/perl5-core/5.16.2/version/Internals.pod > > Building the package in maintainer mode however results in an error > in the validation phase: > > Validating .deb dir > /Volumes/Oberon/scratch.noindex/fink.build/root-perl5162-core-5.16.2-102... > Error: Pathname collision on case-insensitive filesystems > Offending file: /sw/lib/perl5-core/5.16.2/version/ > > It would seem, since the .deb contains both the lower- and uppercase > version dirs with their content, > it should install just fine on a case-sensitive filesystem, but > apparently dpkg-deb is still refusing to > install it (even in non-maintainer mode), because the package would > be broken on a case-insensitive fs. > > I suppose the proper fix would be to manually rename either "version" > or "Version" before/during/after > the build process to have Requirements.pm and Internals.pod coexist > in the same subdir? It's broken in several ways, including .deb portability and (in this case) perl functionality relating to filename<->namespace mapping. Perl has fought with this issue for years, and even this specific instance of it. Apparently the .pod is the remnant documentation regarding the actual perl-module fix (maybe there had been a version/Internals.pm that was renamed). See: http://www.nntp.perl.org/group/perl.perl5.porters/2011/06/msg173951.html that mentions the idea of moving the contents of the .pod into the documentation for another module. That thread talks about it being finally fixed by perl5.18ish, I wonder if perl more recent than 5.16.2 has any improvements in this regard. dan -- Daniel Macks dma...@netspace.org -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ 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] dpkg on 10.9
On Mon, 04 Nov 2013 06:53:55 -0800, Alexander Hansen wrote: On 11/4/13 6:29 AM, TheSin wrote: > > great thanks for testing I'll be sure to add this patch to my > dpkg/tar maybe someone could get the current versions? > > --- > > TS > > http://www.southofheaven.org/ > > Life begins and ends with chaos, live between the chaos! > > > > On 2013-11-04, at 2:59 AM, Martin Costabel wrote: > > > > Sounds good. I was holding off to make sure we had a solution that > folks were happy with. :-) > > It's probably worth freshening tar to the latest upstream while we're at it. I'm seeing some serious-sounding bug on bug-tar in tar-1.27. Might want to let that version shake out a bit unless there's something critical in it we need "now". dan -- Daniel Macks dma...@netspace.org -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ 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] librasterlite2
On Mon, 21 Oct 2013 03:03:05 -0400, Daniel Macks wrote: On Sun, 20 Oct 2013 11:45:21 -0400, Jack Howarth > > wrote: > Baba, > >There are few issues which should be addressed in > > librasterlite2.info. While you are upgrading dependencies, please fix > the following mistakes: > > SetCPPFLAGS: -I%i/include > > is clearly wrong. That means you are virtually guaranteed to get the > wrong headers if testing alternate build options in succession. The > "current" build will see the "previous" one's InstallScript results > in preference to the current one. And: > > SetCPPFLAGS: -I%p/include > > is already automatically passed there as the default. No need to pass > it twice. This package also fails Shlibs Policy. You're not allowed > to list a file in the Shlibs field if that filename does not actually > exist in the package. So: > > Shlibs: !%p/lib/librasterlite.2.dylib > > in %N when %p/lib/librasterlite.2.dylib is in %N-shlibs is not right. I just noticed that this even trips a validator warning on the .deb. Definitely a bad idea to commit a package that does not pass validator without getting a second opinion on whether it is a package mistake or a validator mistake. > You even already list the file in the Shlibs entry of %N-shlibs. And > that entry: > > Shlibs: %p/lib/librasterlite.2.dylib 3.0.0 %n (>= 1.1g-1) 32 > > looks suspicious. 'lipo -info' says the file is actually 64-bit not > 32-bit (and it should have semed *really* weird to claim a 32-bit > library in a 64-bit distro anyway). Is the install_name_tool trick > really needed? During the compile phase, I see: > > libtool: link: gcc -dynamiclib -o .libs/librasterlite.2.dylib > .libs/rasterlite_io.o .libs/rasterlite_image.o .libs/rasterlite_aux.o > .libs/rasterlite_quantize.o .libs/rasterlite_gif.o > .libs/rasterlite_png.o .libs/rasterlite_jpeg.o > .libs/rasterlite_tiff.o .libs/rasterlite_version.o > .libs/rasterlite.o -L/sw/lib /sw/lib/libsqlite3.dylib -lm > /sw/lib/libpng15.dylib /sw/lib/libspatialite.dylib > /sw/lib/libgeotiff.dylib /sw/lib/libproj.dylib /sw/lib/libtiff.dylib > /sw/lib/libjpeg.dylib -lz -O2 -pthread -install_name > /sw/lib/librasterlite.2.dylib -compatibility_version 3 > -current_version 3.0 -Wl,-single_module > > so install_name is already being correctly set. If something is > breaking or resetting it later, please document it so others will not > be confused (and maybe even know how to fix it). dan -- Daniel Macks dma...@netspace.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ 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] librasterlite2
On Sun, 20 Oct 2013 11:45:21 -0400, Jack Howarth wrote: Baba, >There are few issues which should be addressed in > librasterlite2.info. While you are upgrading dependencies, please fix the following mistakes: SetCPPFLAGS: -I%i/include is clearly wrong. That means you are virtually guaranteed to get the wrong headers if testing alternate build options in succession. The "current" build will see the "previous" one's InstallScript results in preference to the current one. And: SetCPPFLAGS: -I%p/include is already automatically passed there as the default. No need to pass it twice. This package also fails Shlibs Policy. You're not allowed to list a file in the Shlibs field if that filename does not actually exist in the package. So: Shlibs: !%p/lib/librasterlite.2.dylib in %N when %p/lib/librasterlite.2.dylib is in %N-shlibs is not right. You even already list the file in the Shlibs entry of %N-shlibs. And that entry: Shlibs: %p/lib/librasterlite.2.dylib 3.0.0 %n (>= 1.1g-1) 32 looks suspicious. 'lipo -info' says the file is actually 64-bit not 32-bit (and it should have semed *really* weird to claim a 32-bit library in a 64-bit distro anyway). Is the install_name_tool trick really needed? During the compile phase, I see: libtool: link: gcc -dynamiclib -o .libs/librasterlite.2.dylib .libs/rasterlite_io.o .libs/rasterlite_image.o .libs/rasterlite_aux.o .libs/rasterlite_quantize.o .libs/rasterlite_gif.o .libs/rasterlite_png.o .libs/rasterlite_jpeg.o .libs/rasterlite_tiff.o .libs/rasterlite_version.o .libs/rasterlite.o -L/sw/lib /sw/lib/libsqlite3.dylib -lm /sw/lib/libpng15.dylib /sw/lib/libspatialite.dylib /sw/lib/libgeotiff.dylib /sw/lib/libproj.dylib /sw/lib/libtiff.dylib /sw/lib/libjpeg.dylib -lz -O2 -pthread -install_name /sw/lib/librasterlite.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module so install_name is already being correctly set. If something is breaking or resetting it later, please document it so others will not be confused (and maybe even know how to fix it). dan -- Daniel Macks dma...@netspace.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ 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] xmkmf broken on clean install of Xcode 5
On Thu, 26 Sep 2013 12:07:28 -0700, Alexander Hansen wrote: > The symptom is as below: > > Original Message > Subject: [Fink-beginners] installing octave > Date: Wed, 25 Sep 2013 02:04:32 +0200 > From: Werner Bäni > To: fink-beginn...@lists.sourceforge.net > CC: d...@fincproject.org > > Hello > > When trying to install octave I get the following error message: > > imake -DUseInstalled -I/sw/lib/X11/config > imake: No such file or directory > imake: Cannot exec /usr/bin/llvm-cpp-4.2. >Stop. > imake: Exit code 1. >Stop. > > --- > > This is fixed in the 10.9 packaging for xmkmf (since that also uses > Xcode 5), via the use of a Fink package for Apple's llvm-gcc-4.2 in > the guise of the "llvm-gcc42" package. Currently this is currently > only available for Xcode >= 4.7, but in the interests of not making > xmkmf support any more complicated than necessary I'd propose > widening the availability of llvm-gcc42 to include earlier Xcodes so > that we can build that on 10.7, and then we can use the same xmkmf > packaging for 10.7-10.9. Can we *please* just kill off xmkmf? :) Okay, seriously, I'm not sure how it "hardcodes" this path/compiler, but seems like it could be patched to use something more generic, or a special wrapper that is more generic. dan -- Daniel Macks dma...@netspace.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ 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] Obsolete module-load-pm dependency inextutils-helper-pm
On Sun, 22 Sep 2013 13:46:22 -0700, Alexander Hansen wrote: (from an attempt at fink cleanup --obsolete): > > dpkg: dependency problems prevent removal of module-load-pm: > extutils-helpers-pm depends on module-load-pm. > /sw/bin/dpkg: error processing module-load-pm (--purge): module-load-pm became varianted (otherwise one may get an older perl-core version of it), but extuitls-helpers-pm is not, so it can't have that dep updated directly:( dan -- Daniel Macks dma...@netspace.org -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk ___ 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] xpwn and libpng16
I had mentioned https://github.com/planetbeing/xpwn/pull/1 to him in-channel earlier this week. dan On Sun, 11 Aug 2013 10:47:03 -0400, Hanspeter Niederstrasser wrote: Matthias, > > The attached .patch file for xpwn fixes the build to work with > libpng16. This allows xpwn to build and link against it successfully. > The CMakeLists.txt chunk is the existing patch. > > Hanspeter > > -- Hanspeter Niederstrasser > hanspeter AT snaggledworks DOT com > > - > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > - > > ___ > 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 > -- Daniel Macks dma...@netspace.org -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ 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] sorry about the mistaken commit
And your reversions broke everything even more. You're not allowed to rev-down in an existing version (can't strand users at a higher revision, especially if the actual maintainer were to rev-up for a bugfix). I re-raised the revs and now I think everything is back to sanity. dan On Fri, 19 Jul 2013 22:40:52 -0700 (PDT), Hisashi T Fujinaka wrote: I was trying to commit something locally. I guess I was in the wrong > directory. I'm reverting everything right now. > > -- Hisashi T Fujinaka - ht...@twofifty.com > BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte > > -- > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ___ > 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 > > -- Daniel Macks dma...@netspace.org -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ 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] readline5 and libgettext3
We've had some good times, and your continued existence has allowed us to migrate gradually to newer versions as time has permitted. But now, all of 10.7+ has migrated to readline6 and libgettext8, so it's time for you to die. I'll allow friends and wellwishers the next hour or so work through their grief... dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] fvp changes
Global $config is fine in this situation (UseFinkModules compartmentalizes the handling of some initialization, and it does export some Fink::Services functions into the main namespace). Is --apt ode fixed for this new more-detailed output in standalone mode (when /sw/lib/perl5 (or in whatever @BASEPATH@ is defined) doesn't exist? I have fink in /sw, and the finkaptstatus data looks unchanged by this patch when I move aside my /sw/lib/perl5...still has the old format not the extra fields you are adding. dan On Sat, 22 Jun 2013 19:36:40 -0600, TheSin wrote: Okay now it works, standalone, --apt and --dpkg all tested, hopefully declaring $config as a global isn't bad ;) > > - > > --- > TS > http://www.southofheaven.org/ > Life begins and ends with chaos, live between the chaos! > > On 2013-06-22, at 7:30 PM, TheSin wrote: > > > I take it back it only worked with out --apt :\ > > > Fetched 1072 kB in 4s (222 kB/s)> Can't locate > Fink/Config.pm in @INC (@INC contains: /Library/Perl/5.12/darwin-th > > > I'll keep working on this :\ > > --- > > TS > > http://www.southofheaven.org/ > > Life begins and ends with chaos, live between the chaos! > > > On 2013-06-22, at 7:27 PM, TheSin wrote: > > >> okay now that I have inet back and hopefully stable, I fixed it > so that I get the right arch now. > >> >> Package: 64bit-cpu > >> Status: install ok installed > >> Priority: optional > >> Architecture: darwin-x86_64 > >> Version: 0-1 > >> Maintainer: Fink Devel > >> Description: [virtual package representing the 64bit capability of > the CPU] > >> The presence of the 64bit-cpu package indicates that the CPU on which we > >> are running is 64bit capable. >> . >> Web site: > http://www.finkproject.org/faq/usage-general.php#virtpackage > >> . >> Maintainer: Fink Devel > >> >> >> >> Here is the new patch, hopefully I did it right I > couldn't figure out what or why UseFinkModules() was for or did since > it returns and exports nothing. If this is wrong please let me know. > >> > >> >> --- > >> TS > >> http://www.southofheaven.org/ > >> Life begins and ends with chaos, live between the chaos! > >> >> On 2013-06-21, at 11:56 PM, Daniel Macks wrote: > >> >>> On Thu, 20 Jun 2013 22:11:20 -0600, TheSin > wrote: > >>> The new apt is much more strict on the fields in status files, to > get >>> it to work I need to make a few minor changes to f-v-p, I > spent lots of >>> time working on apt 0.9.82 trying to figure out why > girts weren't >>> working and it turns out the parser was considering > them invalid due to >>> missing fields like arch and priority. So I > made a quick patch which >>> is in my pull request and i'll attach it > here as well. I'd add it >>> myself but I'm not sure which branch > and if it'll affect anything else >>> that uses f-v-p > >>>> >>>> the current output looks like > >>>> >>>> Package: 64bit-cpu > >>>> Status: install ok installed > >>>> Version: 0-1 > >>>> description: [virtual package representing the 64bit capability > of the CPU] > >>>> >>>> I'd like to change it to look like > >>>> >>>> Package: 64bit-cpu > >>>> Status: install ok installed > >>>> Priority: optional > >>>> Architecture: all > >>>> Version: 0-1 > >>>> Maintainer: Fink Devel > >>>> Description: [virtual package representing the 64bit capability > of the CPU] > >>>> The presence of the 64bit-cpu package indicates that the CPU on which we > >>>> are running is 64bit capable. >>>> . >>>> Web site: > http://www.finkproject.org/faq/usage-general.php#virtpackage > >>>> . >>>> Maintainer: Fink Devel > >>> >>> This change to --apt output looks reasonable to me. I talked > to TheSin >>> in #fink yesterday, who confirmed that old apt would > also accept it, so >>> I don't see harm in sending this to master now > (rather than later as >>> part of the large apt upgrade work) (would > also benefit anyone who's >>> experimenting with new debian tools of > any sort). >>> >>> Technical q
Re: [Fink-devel] fvp changes
On Thu, 20 Jun 2013 22:11:20 -0600, TheSin wrote: The new apt is much more strict on the fields in status files, to get it to work I need to make a few minor changes to f-v-p, I spent lots of time working on apt 0.9.82 trying to figure out why girts weren't working and it turns out the parser was considering them invalid due to missing fields like arch and priority. So I made a quick patch which is in my pull request and i'll attach it here as well. I'd add it myself but I'm not sure which branch and if it'll affect anything else that uses f-v-p > > the current output looks like > > Package: 64bit-cpu > Status: install ok installed > Version: 0-1 > description: [virtual package representing the 64bit capability of the CPU] > > I'd like to change it to look like > > Package: 64bit-cpu > Status: install ok installed > Priority: optional > Architecture: all > Version: 0-1 > Maintainer: Fink Devel > Description: [virtual package representing the 64bit capability of the CPU] > The presence of the 64bit-cpu package indicates that the CPU on which we > are running is 64bit capable. > . > Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage > . > Maintainer: Fink Devel This change to --apt output looks reasonable to me. I talked to TheSin in #fink yesterday, who confirmed that old apt would also accept it, so I don't see harm in sending this to master now (rather than later as part of the large apt upgrade work) (would also benefit anyone who's experimenting with new debian tools of any sort). Technical question: Is this really Architecture:all, given that it's generated by a fink that is single-arch? dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] EOL for 10.5 and 10.6
On Thu, 20 Jun 2013 01:52:10 -0700, David Lowe
wrote:
> On Jun 19, 2013, at 8:02 PM, Alexander Hansen wrote:
>
> > In view of simplifying our lives we've got a few options here:
> > > 1) EOL 10.5, and defer 10.6 for a while. This could be done >
> essentially immediately, with all of the 10.5 packages being stashed
> in > a 10.5-EOL directory similarly to we do for 10.4.
> > > 2) EOL 10.5 and 10.6/i386, keeping 10.6/x86_64 around for a
> while > longer. This will take additional tweaks to fink but I don't
> know of a > reason at this point that precludes this.
> > > 3) EOL 10.5 and 10.6. This is probably the simplest option,
> because it > just requires people to stop committing to the 10.4/
> tree, and a new > fink release which is set only to acknowledge 10.7
> and later.
> > > Anyway, feedback would be appreciated.
>
> For my own selfish reasons, i prefer #1. I have several working
> machines that aren't acceptable to 10.7 or newer, and frankly i've
> come to loath Lion on the one that is. I have no intention of moving
> to 10.8 as it seems to be moving further in the wrong direction, and
> will probably end up reinstalling 10.6 when support for 10.7 is
> dropped. Sébastien rightfully mentions the tradition of supporting
> only two recent versions of the OS. Well, yeah, Apple used to only
> support two recent versions. It is, however, *still* providing
> updates to Snow Leopard. I don't have any numbers, but browsing web
> forums leads me to believe that masses of Macs are stuck at 10.6.
10.6 was the last system to support Rosetta (thanks for the reminder,
cirdan), and I know a bunch of sites are keeping some machines at 10.6
because they still need that. I can't think of a reason to keep
10.6/i386 though. Now that we've moved so many years in the x86_64
world, is there anything in active development that is not in the new
arch? Would be good to check and see is there are any things we missed
though. And 10.6/i386 is harder to support (requires actual
test-building and sometimes arch-specific tweaks) than 10.6/x86_64
because it's not the native arch for the machine (whereas "it works on
10.{>6}/x86_64 therefore it'll probably be okay as-is on 10.6/x86_64"
is usually true). So I lean towards #2, with #3 my second choice
(because it really is easy and we really are over-extended with what we
can actually support by a lot).
dan
(and try migrating it to as many new platforms
use special-purpose software that needs that feature.
need for that feature.
>
> Now that i've said my piece, is there anything i can do to assist?
>
> Sent from Darlene-Lowes-Mac-mini
>
> River Tam: "Also? I can kill you with my brain."
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______
> 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
>
>
--
Daniel Macks
dma...@netspace.org
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
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] not quite there yet with gdal 1.10.0
On Sun, 16 Jun 2013 22:13:49 -0700, Kurt Schwehr wrote: having trouble getting gdal 1.10.0 to build with any of the 3 libspatialite versions. if any one has ideas, I'd appreciate any help. > > I've updated a few of the libraries and will add pcre once > spatialite/rasterlite work > > https://gist.github.com/schwehr/5794715 I left a mile of comments on gist (lots of misc cleanups, but also solving this linking problem). dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] tcltk threading
On Thu, 13 Jun 2013 15:46:34 -0700, Kurt Schwehr wrote: Any chance that you'd be okay with adding threading to the tcltk client? I've got a bug in displaying images in PIL/ImageTk.py that goes away if tcltk is build with --enable-threads? > > -kurt > (goatbar) > > RCS file: > /cvsroot/fink/dists/10.7/stable/main/finkinfo/languages/tcltk-x86_64.info,v > retrieving revision 1.9 > diff -r1.9 tcltk-x86_64.info > 4c4 > < Revision: 1 > --- > > Revision: 2 > 30c30 > < ConfigureParams: --enable-shared --disable-corefoundation > --exec-prefix=%p --mandir=%p/share/man > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib > tcl_cv_type_64bit="long long" > --- > > ConfigureParams: --enable-shared --enable-threads > --disable-corefoundation --exec-prefix=%p --mandir=%p/share/man > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib > tcl_cv_type_64bit="long long" I have no objections. Sounds like a good idea because "someone wants it", and I don't know anything about it to have an opinion either way. dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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] htmldoc-1.8.27 misbuilding
On Sun, 24 Feb 2013 10:42:12 -0700, Alexander Hansen wrote: On 2/24/13 10:11 AM, Sjors Gielen wrote: > > Op 24-02-13 17:36, Alexander Hansen schreef: > >> and the build process continues, leading to a misbuilt package. > > > IIRC I took over maintenance of the htmldoc package when I needed > > it as a dependency, but I have no clue what it does or (without > > investigating) what could cause this. The package is not in 10.8 > > anymore. I could move it to 10.8 and fix it there, then hope the > > same fixes apply for 10.6. However, if anyone else wants to have a > > go, that's as good a try as mine. > > > Sjors > > I'd advocate trying to fix it for 10.8 AND getting rid of it on 10.6 > until that happens. I took a look at it yesterday. I converted the separate htmldoc and htmldoc-nox to a varianted package freshened up the dependencies, and patched the makefiles so it won't misbuild (it will either succeed fully or fail early, rather than rolling a broken .deb). I was not able to fix htmldoc to be able to compile, though, so I turned off that variant, and synced it all on 10.[56] vs 10.[78] distros (only tested on 10.6). dan -- Daniel Macks dma...@netspace.org -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ 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] perl5.12.4 variants
I'm adding pm5124 variants to all 10.[78] packages that only had 5123 (no other changes being made unless there are variant-swapping splitoffs). Testing is limited to "does it build with -m and has nobody told me not to?". So if you'd like me not to touch your stuff or you know of ones that should not be done, speak up now. dan -- Daniel Macks dma...@netspace.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ 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 is ignoring my already downloaded tarball
On Wed, 12 Dec 2012 07:15:08 -0800, David Lowe wrote: > OK, I'll ask you some questions and update the configuration file in > '/sw/etc/fink.conf'. > > > In what additional directory should Fink look for downloaded > tarballs? [~/Downloads] By the time fink is handling tarballs, it's several sudo's away from "you" and has likely has way of knowing which user's homedir you mean. dan -- Daniel Macks dma...@netspace.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ 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] MIA for a while
On Tue, 30 Oct 2012 17:43:20 -0400, Daniel Johnson wrote: If anyone is looking for me, I got a bit disrupted by hurricane Sandy > here in Jersey. I'm safe and my house is undamaged but I won't have > power for a while. They're saying 8-15 days. :( Glad you're safe! We'll leave the light on here for you... dan -- Daniel Macks dma...@netspace.org -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ 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's cgal4 fails to build
On Sat, 20 Oct 2012 19:40:58 -0400, Hanspeter Niederstrasser wrote: Will, > > Your package cgal4 fails to build with this error: > > Boost version: 1.35.0 > Boost include path: /sw/include/boost-1_35 > The following Boost libraries could not be found: >boost_thread > > > 'fink list -i boost' says that I have boost1.35.python25, > boost1.35.python25-shlibs, and boost1.35.python26-shlibs installed, > none of which have the boost_thread library, but are listed as > permitted under cgal4's (Build)Depends field. > > Manually installing boost1.35.nopython-shlibs allows the build to > finish. The (Build)Depends fields need to be fixed to point to a > single package that actually provides the boost_thread library. > Assuming cgal4 actually works with them, boost1.41.cmake-shlibs or > boost1.46.cmake-shlibs could also be used. Also, all the runtime dependencies on the gmp and mpfr1 -shlibs need to go in the -shlibs splitoff (they are required by the cgal4-shlibs, not by the headers in cgal4 itself). dan -- Daniel Macks dma...@netspace.org -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ 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] [cvs] dists/10.7/stable/main/finkinfo/libsboost1.35..info, 1.3, 1.4 poppler4-glib.info, 1.1, 1.2
On Fri, 14 Sep 2012 16:03:37 +0200, Martin Costabel
wrote:
On 14/09/12 15:01, Hanspeter Niederstrasser wrote:
> >> diff -u -d -r1.1 -r1.2
> >> --- poppler4-glib.info 8 Aug 2011 01:07:36 - 1.1
> >> +++ poppler4-glib.info 14 Sep 2012 08:00:47 - 1.2
> >> @@ -1,7 +1,7 @@
> >> Package: poppler4-glib
> >> # NOTE: Must keep %v in sync among all poppler4* packages!
> >> -Version: 0.10.7
> >> -Revision: 4
> >> +Version: 0.12.4
> >> +Revision: 1
> >> Description: PDF rendering library (GLIB Interface)
> >> License: GPL
> >> Maintainer: Benjamin Reed fink.racoonfink.com>
> >> @@ -27,7 +27,7 @@
> >>pango1-xft2-ft219-dev (>= 1.24.5-4),
> >>pixman (>= 0.16.0-1),
> >>pkgconfig (>= 0.23),
> >> - poppler4 (>= %v-2),
> >> + poppler5 (>= %v-1),
> >
> > Martin,
> >
> > This update to poppler4-glib fails since there is no package poppler5 in
> > the 10.7 or 10.4 trees. I have a poppler8-0.15.0 in my experimental,
> > but that's clearly not what you were aiming for.
>
> I have no idea what this poppler stuff is. Must have been some
> leftover from an old test I have forgotten. Indeed I see
> poppler5.{info,patch} here. But I certainly didn't intend to check it
> into cvs. (forgotten space on the command line, it seems; lucky it
> didn't check in much more garbage). I'll remove it immediately. Since
> you say it doesn't build, it won't have caused a lot of damage yet.
I have some experience with poppler (and the problem thereof), I may
have even been surrogate parent of the v0.10.x package set and can take
a look at updating if someone wants newer stuff. There are some messy
update issues related to synchronizing various .pc files and the
resulting inherited BuildDepends:(
dan
--
Daniel Macks
dma...@netspace.org
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
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] automake1.12-1.12.3-1 fails tests on 10.7 (and10.6/*)
On Wed, 05 Sep 2012 08:55:24 -0400, Hanspeter Niederstrasser wrote: > As a user, I would be annoyed if all those TestDepends were added > (most especially coreutils-default) since they take over system > provided programs. For the specific case of "coreutils-default", which fills /sw/bin, one can instead depend on "coreutils", which has everything buried /sw/lib/coreutils/bin that can be prepended to PATH to make visible for the tests. dan -- Daniel Macks dma...@netspace.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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] automake1.12-1.12.3-1 fails tests on 10.7 (and10.6/*)
On Tue, 04 Sep 2012 16:31:00 -0400, Hanspeter Niederstrasser wrote: > install-info > --info-dir='/sw/build.build/automake1.12-1.12.3-1/automake-1.12.3/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/_inst/blah/blah/foobar' > --remove > '/sw/build.build/automake1.12-1.12.3-1/automake-1.12.3/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/_inst/blah/blah/foobar/main.info' > install-info(/sw/build.build/automake1.12-1.12.3-1/automake-1.12.3/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/_inst/blah/blah/foobar/main.info): > no entry for file > `main'. > cp: /sw/share/info/dir.bak: Permission denied > install-info(/sw/build.build/automake1.12-1.12.3-1/automake-1.12.3/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/_inst/blah/blah/foobar/main.info): > couldn't backup > /sw/build.build/automake1.12-1.12.3-1/automake-1.12.3/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/_inst/blah/blah/foobar/dir > in /sw/share/info/dir.bak: Inappropriate ioctl for > device > > Again, an info/dir problem. This might be a bug in install-info. Looks like it's hardcoding /sw/share/info as the dir.bak location even for dir files in other locations--a shared central backup location that overwrites (and possibly races) for all --info-dir locations rather than "adjacent to the dir file being backed up". dan -- Daniel Macks dma...@netspace.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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] updating pmw-py to latest 1.3.3
On Sat, 25 Aug 2012 11:37:16 -0400, Hanspeter Niederstrasser wrote: Is there any reason to not update pmw-py to version 1.3.3 that is from > this decade and not 5 years old like our current 1.3.2 is? I tested > it against pymol on 10.7 and noticed no obvious failures. Sounds like a good idea. dan -- Daniel Macks dma...@netspace.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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
