Re: [Fink-devel] automake1.12-1.12.3-1 fails tests on 10.7 (and 10.6/*)
On 9/4/2012 11:09 PM, Max Horn wrote: Hi again, On 04.09.2012, at 14:31, Hanspeter Niederstrasser wrote: [...] From the link in the original report, the python failure seems to be a race issue: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12210 This is an 8 core MBP, while the 10.6 system only has 4 cores. For the record, I am on an 8 core MBP (well 4 core, times 2 for hyper threading), running 10.7. But I guess I am simply always lucky :). Anyway, so that one can be dealt with using the patch included in that bug report. But the vast number of differences in test results are due to differences in what packages we have installed. For example, I don't have tex installed via Fink (rather, I use MacTeX 2012). Hence for me, the txinfo tests get skipped, and thus I don't see those failures. In addition, I have GNU make, grep, sed, gawk, bash, coreutils-default installed, all of which get picked up by the testsuite; on the other hand, you seem to have flex or flex-devel and bison or byacc installed (and also texlive of tetex), which I don't have. This all leads to differences. The difference in what tests are run I don't think matters, unless a test is known to fail, and the txinfo tests fit that. As dmacks pointed out, it seems to be that they're hardcoding /sw/share/info/dir.bak, which is fragile when not-root. Now I am pondering whether to add any of these to the dependencies of the InfoTest... hrm. Anyway, now that I know why those tests don't fail for me (they get skipped), I can look into resolving all this. 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 packages that have such large test suites, I think common practice is to only TestDepend on packages that are fully needed for the suite, rather than including all the ones for every single individual test (see gettex-tools and git). In closing, it could be helpful if you could also upload the fink build log somewhere, as the test log generated by automake is incomplete (it does not reliably cover all tests). http://snaggledworks.com/fink/logs/fink-build-log_automake1.12_1.12.3-1_2012.09.04-14.29.14 Hanspeter -- 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 Wed, 05 Sep 2012 08:55:24 -0400, Hanspeter Niederstrasser f...@snaggledworks.com 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
[Fink-devel] avoiding linking system's python
Hi folks: Despite my best attempts, I cannot seem to persuade the coot package I am maintaining from linking to /System/Library/Frameworks/Python.framework/Versions/2.7/Python Is there a way to keep it out of there? I have in the package NoSetCPPFLAGS: true NoSetLDFLAGS: true and alias python=%p/bin/python2.7 export PYTHON=%p/bin/python2.7 export python=%p/bin/python2.7 CPPFLAGS=-I%p/include/python2.7 LDFLAGS=-Wl,-dylib_file,%p/lib/python2.7/config/libpython2.7.dylib but I still get the binary linking to the framework python. Any advice? Thanks. Bill -- 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] avoiding linking system's python
On 9/5/12 5:17 PM, William G. Scott wrote: Hi folks: Despite my best attempts, I cannot seem to persuade the coot package I am maintaining from linking to /System/Library/Frameworks/Python.framework/Versions/2.7/Python Is there a way to keep it out of there? I have in the package NoSetCPPFLAGS: true NoSetLDFLAGS: true and alias python=%p/bin/python2.7 export PYTHON=%p/bin/python2.7 export python=%p/bin/python2.7 CPPFLAGS=-I%p/include/python2.7 LDFLAGS=-Wl,-dylib_file,%p/lib/python2.7/config/libpython2.7.dylib but I still get the binary linking to the framework python. Any advice? Thanks. Bill It looks like coot has a --with-python option for its configure script: --with-python=PFX Prefix where PYTHON has been installed That's probably worth a try. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- 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
[Fink-devel] install_name issues on 10.8
I am trying to figure out a problem with shared library install_name for package I created for nfft3. Since updating to OS X 10.8 the install_name points to the fink.build directory where the package was create instead of where the package gets installed, as can be seen by the output of otool -L $ otool -L /sw/lib/libnfft3.1.dylib /sw/lib/libnfft3.1.dylib: /sw/src/fink.build/root-nfft3-3.2.1-2/sw/lib/libnfft3.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0) OS X 10.8 does not like this. I can manually change this with install_name_tool, to the correct settings $ otool -L /sw/lib/libnfft3.1.dylib /sw/lib/libnfft3.1.dylib: /sw/lib/libnfft3.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0) I've read through the documentation at http://www.finkproject.org/doc/packaging/index.php, but have been unable to figure out what I need to change to get fink to automatically set the install_name correctly. I am probably missing something obvious and am hoping someone with more packaging experience can point out my mistake in the nfft3.info file below. Package: nfft3 Version: 3.2.1 Revision: 2 Maintainer: Martyn Klassen lmklas...@gmail.com Source: http://www-user.tu-chemnitz.de/~potts/nfft/download/nfft-%v.tar.gz Source-MD5: a15c0c4375bef51bc8b37ca74cea8339 BuildDepends: fink (= 0.24.12-1) Depends: %N-shlibs (= %v-%r), fftw3 BuildDependsOnly: True PatchFile: %n.patch PatchFile-MD5: 45f6fb9b57a508203d17b87072190bda License: GPL ConfigureParams: --with-fftw3='%p' --prefix='%i' CompileScript: ./configure %c make InstallScript: make install prefix=%i SplitOff: Package: %N-shlibs Files: lib/libnfft3.*.dylib Shlibs: %p/lib/libnfft3.1.dylib 2.0.0 %n (= 3.2.1-1) DocFiles: AUTHORS COPYING INSTALL NEWS README DocFiles: AUTHORS COPYING INSTALL NEWS README #InfoDocs: nfft3.info Description: Non-uniform Fourier Transform Lib (Ver 3) DescDetail: NFFT is non-uniform Fast Fourier transform library DescUsage: DescPackaging: Homepage: http://www-user.tu-chemnitz.de/~potts/nfft -- L. Martyn Klassen, PhD Research Scientist Centre for Functional and Metabolic Mapping Robarts Research Institute Schulich School of Medicine Dentistry Western University 100 Perth Drive London, ON N6A 5K8 Tel: (519) 663-5777 ext. 24145 Fax: (519) 931-5260 -- 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] install_name issues on 10.8
On 9/5/12 7:31 PM, Martyn Klassen wrote: I am trying to figure out a problem with shared library install_name for package I created for nfft3. Since updating to OS X 10.8 the install_name points to the fink.build directory where the package was create instead of where the package gets installed, as can be seen by the output of otool -L $ otool -L /sw/lib/libnfft3.1.dylib /sw/lib/libnfft3.1.dylib: /sw/src/fink.build/root-nfft3-3.2.1-2/sw/lib/libnfft3.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0) OS X 10.8 does not like this. I can manually change this with install_name_tool, to the correct settings $ otool -L /sw/lib/libnfft3.1.dylib /sw/lib/libnfft3.1.dylib: /sw/lib/libnfft3.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0) I've read through the documentation at http://www.finkproject.org/doc/packaging/index.php, but have been unable to figure out what I need to change to get fink to automatically set the install_name correctly. I am probably missing something obvious and am hoping someone with more packaging experience can point out my mistake in the nfft3.info file below. Package: nfft3 Version: 3.2.1 Revision: 2 Maintainer: Martyn Klassen lmklas...@gmail.com Source: http://www-user.tu-chemnitz.de/~potts/nfft/download/nfft-%v.tar.gz Source-MD5: a15c0c4375bef51bc8b37ca74cea8339 BuildDepends: fink (= 0.24.12-1) Depends: %N-shlibs (= %v-%r), fftw3 BuildDependsOnly: True PatchFile: %n.patch PatchFile-MD5: 45f6fb9b57a508203d17b87072190bda License: GPL ConfigureParams: --with-fftw3='%p' --prefix='%i' CompileScript: ./configure %c make InstallScript: make install prefix=%i SplitOff: Package: %N-shlibs Files: lib/libnfft3.*.dylib Shlibs: %p/lib/libnfft3.1.dylib 2.0.0 %n (= 3.2.1-1) DocFiles: AUTHORS COPYING INSTALL NEWS README DocFiles: AUTHORS COPYING INSTALL NEWS README #InfoDocs: nfft3.info Description: Non-uniform Fourier Transform Lib (Ver 3) DescDetail: NFFT is non-uniform Fast Fourier transform library DescUsage: DescPackaging: Homepage: http://www-user.tu-chemnitz.de/~potts/nfft -- L. Martyn Klassen, PhD Research Scientist Centre for Functional and Metabolic Mapping Robarts Research Institute Schulich School of Medicine Dentistry Western University 100 Perth Drive London, ON N6A 5K8 Tel: (519) 663-5777 ext. 24145 Fax: (519) 931-5260 There's not a standard way to do it within Fink. One normally works with whatever the upstream build system wants, or patches Makefiles, or otherwise edits the install_name manually in the InstallScript. However, the --prefix='%i' option in your ConfigureParams is suspect. Most packages use --prefix=%p, which is a default option so you don't need to specify that. Also, if the package supports it, then make install DESTDIR=%d is usually preferable nowadays to make install prefix=%i (though the latter is still the default InstallScript). -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- 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 04.09.2012, at 14:43, Daniel Macks wrote: On Tue, 04 Sep 2012 16:31:00 -0400, Hanspeter Niederstrasser f...@snaggledworks.com 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. Yes, that's right. So we could adjust our dpkg.patch, changing +$backup='@PREFIX@/share/info/dir.bak'; to +$backup=$infodir/dir.bak; which would fix that particular error. However, this is *not* what is tripping up the automake tests. Rather, this is: ERROR: files left after uninstall: ./share/info/dir ./share/info/dir.old *sigh*. I don't have a good idea right now how to fix that, short of making major changes to our install-info (e.g. removing the dir file altogether...), or replacing it entirely with the one from texinfo. Huh, well, I guess I could insert a fake install-info into the PATH of the TestScript... But for now, I'll just disable those tests. Cheers, Max -- 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
