Re: [Fink-devel] Fixed Apple_Terminal.src
On Sunday, April 6, 2003, at 07:09 PM, Max Horn wrote: OK, I'll stop flooding the list after this one: I was wrong. Emacs is still screwed. BUT: I think emacs is doing something evil. If I take the vt100 terminfo file, then replace vt100 by Apple_Terminal (read: everything else is unchanged), then emacs still won't work properly! So maybe for some reasons it's not finding this in ~/.terminfo? I don't know :-( Max Your Apple_Terminal.src doesn't seem to support bold or invisible text. I've been setting TERM to xterm-xfree86 for a while now and it supports those as well as everything else your file does. It may not be technically correct, but it supports all of the features that Terminal provides. I've tried it out with the test programs in the ncurses 5.3 src tarball. Thanks for all the great work on fink! -- Daniel Johnson [EMAIL PROTECTED] --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Library prebinding
I've been playing around with packages which don't currently build prebound libraries and found that in the majority of cases where libtool is used, calling libtool with -no-undefined will work--provided the dependencies are prebound, of course. This can usually be achieved by adding SetLDFLAGS: -no-undefined to the info file, although a few are a bit trickier. I've emailed the maintainers for the packages I've tested, but perhaps it would be a good idea for the documentation to encourage maintainers to try -no-undefined when their packages don't prebind. There isn't much documentation around about prebinding as it is, so I learned what I know about it through trial and error; a little something on the subject in Fink's docs would be helpful to maintainers. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/graphics pfaedit.info,NONE,1.1
On Mar 3, 2004, at 4:51 AM, Daniel Macks wrote: [EMAIL PROTECTED] committed: Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/graphics Added Files: pfaedit.info Log Message: Added pfaedit from tracker item 902269 --- NEW FILE: pfaedit.info --- Package: pfaedit [...] InstallScript: make install prefix=%i rm %i/lib/%n/libgdraw.la %i/lib/%n/libgdraw.dylib %i/lib/%n/libgunicode.la %i/lib/%n/libgunicode.dylib Shlibs: %p/lib/%n/libgdraw.1.dylib 2.0.0 %n (= 040301-1) %p/lib/%n/libgunicode.2.dylib 3.0.0 %n (= 040301-1) This looks out-of-compliance with the shared library policy. I see from the tracker what's going on, but it seems like this solution aims at contradictory purposes. Shifting .dylib files into lib/%n and not putting them into a -shlibs SplitOff isn't a bad solution for private shared libraries that aren't for public use (have no headers or published interface). But in that case, I don't think there should be a Shlibs field. But really, the package appears to use libtool (that's why there are .la) via a GNU configure script, so can't you just pass --enable-static=yes --enable-shared=no and get only static libs? That way they aren't needed at run-time and can be omitted from the fink package. dan Ack! This package wasn't ready to be released into the wild! I was waiting for more feedback on the shlibs issue, but I guess I didn't make that clear in the tracker. Besides, the upstream version has been renamed to FontForge, and it seemed pointless to release anything until the new version is readily available. I'd appreciate it if someone could remove this package until I can make an updated info file. I'll also try to eliminate the shlibs altogether. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] gconf-editor-2.6.2-7, gconf2-2.6.3-8, gstreamer-0.8.3-8
gconf-editor and gconf2 install man pages into /sw/man instead of /sw/share/man. Also, gstreamer is missing a BuildDepends on bison. Panther's bison is too old. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Patching popt.info
On Jul 4, 2004, at 6:29 PM, Blair Zajac wrote: Anybody mind if I patch popt.info to add this BuildDepends? RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/libs/popt.info,v retrieving revision 1.1 diff -u -r1.1 popt.info --- libs/popt.info 17 Jun 2004 00:41:09 - 1.1 +++ libs/popt.info 4 Jul 2004 22:27:38 - @@ -1,12 +1,12 @@ Package: popt Version: 1.7 -Revision: 2 +Revision: 3 BuildDependsOnly: true Maintainer: Matt Stephenson [EMAIL PROTECTED] Source: ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/%n-%v.tar.gz Source-MD5: 5988e7aeb0ae4dac8d83561265984cc9 Depends: %N-shlibs (= %v-%r) -BuildDepends: gettext-dev, gettext-bin +BuildDepends: gettext-dev, gettext-bin, libiconv-dev SetLDFLAGS: -lintl PatchScript: perl -pi -e 's,\-all\-static,,g' Makefile.in ConfigureParams: --mandir=%p/share/man This module is owned by Matt Stephenson [EMAIL PROTECTED] who hasn't been around. Blair If you also change SetLDFLAGS: -lintl to SetLDFLAGS: -no-undefined -lintl this package will build prebound. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Patching popt.info
On Jul 5, 2004, at 5:30 PM, Blair Zajac wrote: Blair Zajac wrote: Daniel Johnson wrote: If you also change SetLDFLAGS: -lintl to SetLDFLAGS: -no-undefined -lintl this package will build prebound. Thanks for the tip. My CVS commit contained this change. One question. I looked in the gcc.info and ld.info files for documentation on -no-undefined and couldn't find any. Is there a good link that discusses this? -no-undefined is a GNU libtool option which tells libtool to build libraries that don't have any undefined symbols. info libtool documents it. On Mac OS X this means that libraries are built without the -flat_namespace -undefined suppress flags that libtool uses by default. Libraries have to meet several requirements to be prebound: * all dependencies must be prebound * must use two-level namespace * can't have undefined symbols Fink's prebinding support fortunately does all the hard work, maintainers just have to meet the above requirements. Simply setting SetLDFLAGS: -no-undefined will allow many libtool based packages to be prebound, but it doesn't always work. Sometimes there really are undefined symbols that can't be avoided or the two-level namespace causes conflicts with another library. Sometimes it's necessary to manually patch configure and/or Makefiles (check the patch file for my libuninameslist1 package) because LDFLAGS isn't handled correctly. And if libtool isn't used you could have to do a lot more patching. Several more questions: And why don't we do this for all libraries? It doesn't work for all libraries, unfortunately. Also, I don't think many maintainers understand prebinding very well as it's not well documented by Apple, and I don't think the Fink docs discuss it at all. What I know I've learned through trial and error, dissecting libtool, and going over Apple's rather obtuse documentation. But it's a good idea to try the -no-undefined trick with any library since it has a good chance of working. Does this work for .info files in 10.2-gcc3 also? Yes, it should. Fink supports prebinding in the 10.2-gcc3 tree. Hope that helps. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] openssl097-dev conflicts with system man pages
I just noticed that openssl097-dev installs /sw/share/man/man3/err.3 (describing OpenSSL error codes) which conflicts with /usr/share/man/man3/err.3 (describing the BSD err function and friends). This makes it impossible to access the system manpage directly. Apple avoids this by installing the OpenSSL manpages as *.3ssl and I'd recommend that the fink package do likewise. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] Re: openssl097-dev conflicts with system man pages
On Sep 5, 2004, at 3:05 PM, Daniel Johnson wrote: I just noticed that openssl097-dev installs /sw/share/man/man3/err.3 (describing OpenSSL error codes) which conflicts with /usr/share/man/man3/err.3 (describing the BSD err function and friends). This makes it impossible to access the system manpage directly. Apple avoids this by installing the OpenSSL manpages as *.3ssl and I'd recommend that the fink package do likewise. Ugh, never mind. It doesn't help and even without /sw/share/man/man3/err.3, /usr/share/man/man3/err.3ssl still blocks err.3. Why did the OpenSSL folks have to use err.3 as a manpage? It doesn't even have and err function in it. Sigh. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] Perl 584 and DB_File
I just noticed that perl584 5.8.4-3 now builds DB_File support where it never did before. This breaks my db-file-pm581 package since they both try to install a DB_File.3pm man file and I'm not sure of the best way to approach it. Should I rename the man file or drop it? I don't want to drop the package completely since it's a newer version of DB_File and links with db42 instead of the ancient db lib that Apple provides. For the moment I'm deleting the man file since it's impossible to update perl if db-file-pm581 is installed. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] Abandoned cyrus-sasl2?
It appears that the cyrus-sasl2 maintainer has been missing for some time. I want an updated version because I'm building a Postfix package that uses it, and was wondering if it would be OK to take it over. I have an updated package that I've been using. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] FINK 0.7.1 freetype2 package is missing the freetype2.pc file
On Dec 18, 2004, at 11:19 PM, Dave Andruczyk wrote:
Fink 0.7.1 on os-x 10.3.6
I noticed that the freetype2-dev or freetype2-shlibs packages seem to
be
missing the freetype2.pc file that should be installed into
/sw/lib/pkgconfig
Can some developer please fix this? Users of my software can't
install it
because the freetype test fails because of the missing file from that
package... I've had to manually walk the users through creating the
freetype2.pc file from scratch and puting it in /sw/lib/pkgconfig
The file(/sw/lib/freetype2/pc) should look something like this:
prefix=/sw
exec_prefix=${prefix}
libdir=/sw/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.4.3
Requires:
Libs: -L${libdir} -lfreetype -lz
Cflags: -I${includedir}/freetype2
=
Dave J. Andruczyk
From 'fink info freetype2':
The freetype2 package now exists only for compatibility with older Fink
packages. Developers should use the freetype that is part of XFree86
for new packages.
For packages that need freetype2 version 2.1.3 or newer, there is now
a freetype2-dev splitoff. For this to work, you need to make sure that
configure finds the freetype-config script in %p/lib/freetype2/bin
So you should be using the freetype2 that comes with X11 (wether
Apple's, XFree, or Xorg) and not Fink's obsolete freetype2. But as far
as I can tell, none of these freetypes create a freetype2.pc file.
Instead they have the freetype-config script to get build info. It is
in /usr/X11R6/bin for X11's version and /sw/lib/freetype2/bin for
Fink's. If you're using Apple's X11, you have to have the X11SDK.pkg
installed as well, most likely.
--
Daniel Johnson
[EMAIL PROTECTED]
PGP public key: http://homepage.mac.com/danielj7/publickey.txt
PGP.sig
Description: This is a digitally signed message part
Re: [Fink-devel] wxWidgets vs. wxMac
On Feb 19, 2005, at 4:54 PM, Trevor Harmon wrote: Okay, makes sense. Currently the wxmac/wxgtk packages Conflict/Replace each other, but they don't Provide anything. As a test, I modified the wxmac package so that it Provides wxwidgets, rebuilt it, and indeed a wxwidgets virtual package showed up in Fink Commander. Interestingly, however, Fink Commander reported the version of this package as 2.5.2.8-2, even though the providing package (wxmac) was 2.5.3. Somehow the virtual wxwidgets package inherited the version from wxgtk instead, even though I never touched it and it doesn't Provide anything. Anybody know why? FinkCommander's handling of provided virtual packages is completely broken. Among other things, it doesn't clear the variable that holds the version when a provided package is processed, which causes it to list the version of the last real package that preceded it. Poor FinkCommander needs a lot of work. :) -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] Text encoding for .info files?
Is there a policy about what encoding to use for .info files? The fink tool (or specifically perl 5.8.x) and online package database seem to expect Unicode while FinkCommander assumes MacRoman. There are two files, gtktalog.info and recode.info, that use MacRoman in the Maintainer field. Thus they show correctly in FinkCommander but not anywhere else. If I change those files to UTF-8, fink info gives the correct result. Of course, then FinkCommander is wrong. :) I came across this issue because I'm working on a Cocoa program that reads package info from fink, and since Cocoa assumes text is in Unicode, Bad Things were happening with those two files. As in crashing. I had to explicitly convert the text from MacRoman first, like FinkCommander does. I couldn't find anything in the Packaging Manual about this. Perhaps a good policy would be to require all .info files to use UTF-8 and document this? -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Text encoding for .info files?
On Feb 25, 2005, at 10:15 AM, Daniel Macks wrote: On Fri, Feb 25, 2005 at 08:33:04AM -0500, Daniel Johnson wrote: Is there a policy about what encoding to use for .info files? They are supposed to be plain text files in the traditional Unix sense. As such, I don't think there's is any issue about encoding. The validator emits a warning if a .info file contains characters not part of the POSIX :ascii: class. The fink tool (or specifically perl 5.8.x) and online package database seem to expect Unicode while FinkCommander assumes MacRoman. There are two files, gtktalog.info and recode.info that use MacRoman in the Maintainer field. Yup, 'fink validate' on those files gives: Warning: maintainer contains non-standard characters. (gtktalog.info) Warning: maintainer contains non-standard characters. (recode.info) Heh. I didn't think to try 'fink validate'. Duh. Thus they show correctly in FinkCommander but not anywhere else. If I change those files to UTF-8, fink info gives the correct result. Of course, then FinkCommander is wrong. :) I came across this issue because I'm working on a Cocoa program that reads package info from fink, and since Cocoa assumes text is in Unicode, Bad Things were happening with those two files. As in crashing. I had to explicitly convert the text from MacRoman first, like FinkCommander does. ...and that kind of how do I encode this portably? weirdness is one of the reasons we want everything in plain-text ASCII. So the proper solution is to not use non-ASCII chars:) I just patched those two .info files in 10.3/unstable. dan Plain ASCII works for me. But unless I missed it (which isn't outside the realm of possibility), it's not documented anywhere and probably should be. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] New freetype2 packages
On Feb 28, 2005, at 10:01 AM, Martin Costabel wrote: After some quick tests, I have now committed these packages for freetype versions 2.1.4 and 2.1.9 to CVS 10.3/unstable: freetype2, freetype2-dev, freetype2-shlibs freetype2-hinting, freetype2-hinting-dev, freetype2-hinting-shlibs freetype219 freetype219-shlibs Just a bit of positive feedback; I upgraded my fontforge package to use freetype219 and it seems to work just fine. It did require some Makefile hacking since fontforge kept insisting on searching /usr/X11R6/lib first. :P -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] building cyrus21-imapd fails
On Mar 4, 2005, at 3:50 AM, Jean-Michel besnard wrote: Hi, 'fink build cyrus21-imapd' fails with the following messages in STDERR: -- STDERR- - Information about 4719 packages read in 4 seconds. /sw/bin/tar: Read 512 bytes from - configure: warning: Parts of com_err distribuion were found, but not compile_et. configure: warning: Will build com_err from included sources. sieve-lex.l: In function `yylex': sieve-lex.l:118: warning: label `find_rule' defined but not used /usr/include/stdio.h: At top level: sieve-lex.l:999: warning: `yy_flex_realloc' defined but not used mkchartable: expanding unicode mappings... mkchartable: expanding unicode mappings... mkchartable: expanding unicode mappings... mkchartable: building expansion table... mkchartable: mapping unicode... mkchartable: mapping UTF-8... mkchartable: mapping UTF-7... mkchartable: mapping ./charset/big5.t... mkchartable: mapping ./charset/gb2312.t... mkchartable: mapping ./charset/iso-2022-jp.t... mkchartable: mapping ./charset/iso-2022-kr.t... mkchartable: mapping ./charset/iso-8859-1.t... mkchartable: mapping ./charset/iso-8859-15.t... mkchartable: mapping ./charset/iso-8859-2.t... mkchartable: mapping ./charset/iso-8859-3.t... mkchartable: mapping ./charset/iso-8859-4.t... mkchartable: mapping ./charset/iso-8859-5.t... mkchartable: mapping ./charset/iso-8859-6.t... mkchartable: mapping ./charset/iso-8859-7.t... mkchartable: mapping ./charset/iso-8859-8.t... mkchartable: mapping ./charset/iso-8859-9.t... mkchartable: mapping ./charset/koi8-r.t... mkchartable: mapping ./charset/us-ascii.t... mkchartable: mapping ./charset/windows-1252.t... imapd.c: In function `printstring': imapd.c:7043: warning: unsigned int format, long unsigned int arg (arg 3) imapd.c: In function `printastring': imapd.c:7073: warning: unsigned int format, long unsigned int arg (arg 3) tls.c: In function `tls_init_serverengine': tls.c:628: warning: assignment from incompatible pointer type message.c: In function `message_write_nstring': message.c:2067: warning: unsigned int format, long unsigned int arg (arg 4) annotate.c: In function `fetch_cb': annotate.c:267: warning: unsigned int format, long unsigned int arg (arg 4) annotate.c:283: warning: unsigned int format, long unsigned int arg (arg 4) annotate.c: In function `annotatemore_fetch': annotate.c:383: warning: unsigned int format, long unsigned int arg (arg 4) annotate.c:404: warning: unsigned int format, long unsigned int arg (arg 4) fud.c:101:1: warning: MAXLOGNAME redefined In file included from /usr/include/netdb.h:84, from ../config.h:299, from fud.c:43: /usr/include/sys/param.h:92:1: warning: this is the location of the previous def inition proxyd.c: In function `printstring': proxyd.c:4706: warning: unsigned int format, long unsigned int arg (arg 3) proxyd.c: In function `printastring': proxyd.c:4734: warning: unsigned int format, long unsigned int arg (arg 3) imtest.c: In function `tls_init_clientengine': imtest.c:457: warning: assignment from incompatible pointer type mv: /sw/src/root-cyrus21-2.1.13-11/sw/share/include/cyrus: No such file or direc tory install: doc/CVS: Inappropriate file type or format mv: rename /sw/src/root-cyrus21-2.1.13-11/sw/bin/cyradm to /sw/src/root-cyrus21-admin-2.1.13-11/sw/bin/cyradm: No such file or directory Fink's cyrus21 package is very old and no longer has a maintainer so it's not too surprising that it doesn't work anymore. I've been experimenting with packaging cyrus 2.2.10 on and off, but I've been busy with other things lately and never finished it. Maybe I'll give it another try--no promises though! :) It does build successfully, but I remember having some packaging issues that I wasn't happy with. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] openjade-1.3.2-28
On Apr 23, 2005, at 2:41 AM, Daniel Czarnecki wrote: Hi Everybody, I am trying to compile openjade 1.3.2-28 on OSX 10.3.9 however I am getting the following error: mv -f .libs/LocNode.lo LocNode.lo /bin/sh /sw/src/openjade-1.3.2-28/openjade-1.3.2/libtool -- mode=link g++-3.3 --tag=CXX -allow-undefined -o libogrove.la Node.lo LocNode.lo \ -rpath /sw/lib -version-info 0:1:0 -lm libtool: link: `-allow-undefined' is deprecated because it is the default rm -fr .libs/libogrove.la .libs/libogrove.* .libs/libogrove.* -dynamiclib -undefined suppress -flat_namespace -o .libs/libogrove. 0.0.1.dylib -lm Node.lo LocNode.lo -lm -lc -install_name /sw/ lib/libogrove.0.dylib -compatibility_version 1 -current_version 1.1 /sw/src/openjade-1.3.2-28/openjade-1.3.2/libtool: line 1: - dynamiclib: command not found make[2]: *** [libogrove.la] Error 127 make[1]: *** [grove] Error 2 make: *** [all] Error 2 ### execution of /var/tmp/tmp.1.71udyZ failed, exit code 2 Removing build lock... dpkg -r fink-buildlock-openjade-1.3.2-28 (Reading database ... 25629 files and directories currently installed.) Removing fink-buildlock-openjade-1.3.2-28 ... Failed: phase compiling: openjade-1.3.2-28 failed It appears that I am missing libogrove. Which pakacge provides this? There was a bug in the openjade package. fink selfupdate should fix it. Daniel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] prevent Spotlight indexing of /sw/src subdirectories in 10.4
On May 12, 2005, at 11:57 PM, Dave Vasilevsky wrote: On May 12, 2005, at 11:31 PM, Daniel Johnson wrote: I've written an info file mdimporter. It doesn't use fink or perl at all; Yeah, dmacks showed this to me a bit ago. It's very nice. But I guess I just think it would be nicer to have the mdimporter actually use Fink. This would be good for packages that use name- munging (ie: variants), and also because of the potential for background Fink indexing. The version I linked to is newer than the one I originally emailed - seed about. It now lists some metadata in Finder preview panes. Unfortunately, Spotlight only understands files, so just extracting info from fink won't work. That's why iCal has to create a folder full of files, one for each event, so Spotlight can index them even though iCal actually uses a database. Besides, running fink (which would also bring in perl) would likely slow down indexing a lot. I looked at doing an importer for deb files, but it's complicated because you need un-ar, un-gzip, AND un-tar (as far as I can tell) to get at the metadata. mdimporters need to be small and fast; all that overhead could be an issue. I didn't try it, so maybe it's not that bad--I'm just guessing. Er, it's best if you can just use dpkg-deb. Perhaps an executable could be included using some install_name_tool magic (or a static executable). You're still running an external tool and it still needs to do those steps. I'm worried it would really slow down Spotlight; importers have to be very lightweight. Maybe I'll try to do one and see what happens. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] freetype219 to stable in 10.3
Can freetype219 be moved to stable in 10.3? It was moved in 10.4- transitional but not 10.3 apparently. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] XCode Legacy Tools on ADC
An XCode Legacy Tools package is now available on ADC which provides, among other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger user installs this, fink will want to install it's gcc3.1 package since it's version number is higher than the virtual gcc3.1 package. This is likely not the desired behavior. :) I haven't actually installed this package, but I remember what happened when I had a leftover Panther gcc3.1 on my system after upgrading to 10.4. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] libbonoboui2-2.10.0-1 upstream file has different md5 sum
curl -f -L -O ftp://ftp.gnome.org/pub/GNOME/sources/libbonoboui/2.10/ libbonoboui-2.10.0.tar.bz2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 778k 100 778k0 0 63246 0 0:00:12 0:00:12 --:--:-- 100k The checksum of the file is incorrect. The most likely cause for this is a corrupted or incomplete download Expected: e83516b3ec07fab22d008e528ef2402e Actual: bd4fb92f993b7fb7e660bb999465ef3b Downloading the file libbonoboui-2.10.0.tar.bz2 failed. Looks like the upstream file has changed? The file on finkmirrors has the correct checksum. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: libdv4-0.104-1 failure
On Oct 18, 2005, at 3:14 PM, TheSin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 it seems xcode 2.2 is causing issues, I haven't installed it yet though, but this is the third report of one of my packages and all with 2.2. - --- TS http://southofheaven.org/ Chaos is the beginning and end, try dealing with the rest. On 18-Oct-05, at 4:09 AM, Stanton McCandlish wrote: /bin/sh ../libtool --silent --mode=link --tag=CC gcc -g -O2 -Wall -g -o dvconnect dvconnect.o -lpthread -lpopt -lm -L/sw/lib /usr/bin/ld: warning multiple definitions of symbol _locale_charset /sw/lib/libintl.dylib(localcharset.lo) definition of _locale_charset /sw/lib/libiconv.dylib(localcharset.o) definition of _locale_charset /usr/bin/ld: Undefined symbols: _sched_setscheduler collect2: ld returned 1 exit status make[2]: *** [dvconnect] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ### execution of make failed, exit code 2 Removing build lock... /sw/bin/dpkg-lockwait -r fink-buildlock-libdv4-0.104-1 (Reading database ... 112727 files and directories currently installed.) Removing fink-buildlock-libdv4-0.104-1 ... Failed: phase compiling: libdv4-0.104-1 failed Before reporting any errors, please run fink selfupdate and try again. If you continue to have issues, please check to see if the FAQ on fink's website solves the problem. If not, ask on the fink- users or fink-beginners mailing lists. As a last resort, you can try e- mailing the maintainer directly: Justin F. Hallett [EMAIL PROTECTED] -- Package manager version: 0.24.10 Distribution version: 0.7.2.rsync Mac OS X version: 10.4.2 Xcode version: 2.2 gcc version: 4.0.0 (Apple Computer, Inc. build 5026) make version: 3.80 Feedback Courtesy of FinkCommander I just built libdv4-0.104-2 with Xcode 2.2 Preview 3 without a problem. There are two problems that I see here. The user is running 10.4.2 but has Distribution version: 0.7.2.rsync which is wrong; it should be 0.8.0.rsync. So he's building the 10.3 libdv4-0.104-1 instead of 10.4's libdv4-0.104-2. Secondly, if he's got Xcode 2.2 installed, something else is very wrong since 2.2 has gcc 4.0.1. gcc 4.0.0 build 5026 is from Xcode 2.1. From personal experience, it is necessary to run /Developer/Tools/uninstall-devtools.pl BEFORE installing Xcode 2.2, otherwise you're likely to have some things not update properly thanks to the genius of Installer.app. :) If you have a fink installed xorg or xfree86, you'll probably also need to reinstall it since uninstall-devtools.pl will nuke it. (Also from personal experience.) -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] update script ready for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 25, 2006, at 7:27 PM, Brendan Cully wrote: On Wednesday, 14 June 2006 at 16:15, David R. Morrison wrote: There is now a script available which will attempt to update a 10.4- transitional (or 10.3) fink installation to the 10.4 tree. The script comes in a tarball which also contains basic deb files for a 10.4 installation (and hence is nearly 12 MB). I'll announce this script generally in a day or so, but in the meantime, if anybody would like to test it under real-world circumstances, I would like to hear how it went. The tarball containing the script is available at http://prdownloads.sourceforge.net/fink/scripts-10.4- update-0.1.tar.gz?download I tried version 0.3 of the script on a box I haven't updated in some time. It's still going, but the first apt-update (I had todai enabled) generated this error and stopped soon after: Preparing to replace cyrus-sasl2-dev 2.1.21-3 (using .../cyrus- sasl2-dev_2.1.21-1015_darwin-powerpc.deb) ... Unpacking replacement cyrus-sasl2-dev ... /sw/bin/dpkg: error processing /sw/var/cache/apt/archives/cyrus- sasl2-dev_2.1.21-1015_darwin-powerpc.deb (--unpack): trying to overwrite `/sw/lib/sasl2/libanonymous.so', which is also in package cyrus-sasl2 Preparing to replace cyrus-sasl2 2.1.21-3 (using .../cyrus- sasl2_2.1.21-1015_darwin-powerpc.deb) ... Unpacking replacement cyrus-sasl2 ... ... Unpacking replacement apr-ssl-common ... Errors were encountered while processing: /sw/var/cache/apt/archives/cyrus-sasl2-dev_2.1.21-1015_darwin- powerpc.deb E: Sub-process /sw/bin/dpkg returned an error code (1) ### execution of apt-get failed, exit code 100 fink update-all Older versions of cyrus-sasl2 had some files in the wrong splitoffs. Since those files have moved around, you can have this problem particularly during update-all. Reissuing the command should work properly. Sorry for the inconvenience, but there was no completely seamless way to fix the package. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFEn0XG4sDFGYouOqARAj8JAJ9bm5ubHQBkVkCZ4lXfZi6vaf1ZQACeOqdB aNeEKGCHr8FIXpKXAs8B0aI= =osFy -END PGP SIGNATURE- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] update script ready for testing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 26, 2006, at 2:19 PM, Daniel Macks wrote:
On Sun, Jun 25, 2006 at 10:26:13PM -0400, Daniel Johnson wrote:
On Jun 25, 2006, at 7:27 PM, Brendan Cully wrote:
Preparing to replace cyrus-sasl2-dev 2.1.21-3 (using .../cyrus-
sasl2-dev_2.1.21-1015_darwin-powerpc.deb) ...
Unpacking replacement cyrus-sasl2-dev ...
/sw/bin/dpkg: error processing /sw/var/cache/apt/archives/cyrus-
sasl2-dev_2.1.21-1015_darwin-powerpc.deb (--unpack):
trying to overwrite `/sw/lib/sasl2/libanonymous.so', which is also
in package cyrus-sasl2
Preparing to replace cyrus-sasl2 2.1.21-3 (using .../cyrus-
sasl2_2.1.21-1015_darwin-powerpc.deb) ...
Unpacking replacement cyrus-sasl2 ...
...
Unpacking replacement apr-ssl-common ...
Errors were encountered while processing:
/sw/var/cache/apt/archives/cyrus-sasl2-dev_2.1.21-1015_darwin-
powerpc.deb
E: Sub-process /sw/bin/dpkg returned an error code (1)
### execution of apt-get failed, exit code 100
fink update-all
Older versions of cyrus-sasl2 had some files in the wrong splitoffs.
Since those files have moved around, you can have this problem
particularly during update-all. Reissuing the command should work
properly. Sorry for the inconvenience, but there was no completely
seamless way to fix the package.
Often, one can use the Replaces field to smooth the upgrade when a
file jumps from one package to another. If files moved from foo to
foo-dev starting in {foo,foo-dev}-2.1.1-1, having foo-dev:
Replaces: foo ( 2.1.1-1)
should allow the foo-dev with the new layout to be installed when one
has the foo from the old layout installed.
dan
Oh, I see what I did. I should have just Replaced not Conflict/
Replace. Duh. I've now fixed it in all trees, for what it's worth.
Thanks.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)
Comment: http://homepage.mac.com/danielj7/publickey.txt
iD8DBQFEoHTt4sDFGYouOqARAq3xAKCSj+Z+2CQoQ/IhD2av8OE+9Tq4vwCfaz2O
lDH1X4EaW9qg3+lfZFhCfCQ=
=rMLG
-END PGP SIGNATURE-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Take over pcre?
Is it safe to assume that Christian Swinehart is MIA? I've seen discussion of this before and my own emails to him from a year ago have never been answered. I'd like to update pcre since fink's version (4.5) is pretty ancient and I've been using the latest version (6.4) for a few months now with no issues. Note that pcre now includes a C++ wrapper lib, libpcrecpp, so it would have to have a GCC field. I've compiled it with both g++ 3.3 and 4.0.1 successfully for what it's worth, and noted so in the info file. Any objections if I take it over? -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Take over pcre?
On Jan 16, 2006, at 7:32 PM, TheSin wrote: just make sure it doesn't break apache2 please or php4/5 since I know the pcre stuff is odd in those. --- TS http://southofheaven.org/ Chaos is the beginning and end, try dealing with the rest. On 16-Jan-06, at 5:07 PM, Daniel Johnson wrote: Is it safe to assume that Christian Swinehart is MIA? I've seen discussion of this before and my own emails to him from a year ago have never been answered. I'd like to update pcre since fink's version (4.5) is pretty ancient and I've been using the latest version (6.4) for a few months now with no issues. Note that pcre now includes a C++ wrapper lib, libpcrecpp, so it would have to have a GCC field. I've compiled it with both g++ 3.3 and 4.0.1 successfully for what it's worth, and noted so in the info file. Any objections if I take it over? Is there any reasonably simple way I can test this? I have very little experience with Apache or PHP. I do know that postfix works with the new version, even if built with the old pcre. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Take over pcre?
On Jan 16, 2006, at 9:47 PM, Daniel E. Macks wrote: Daniel Johnson [EMAIL PROTECTED] said: On Jan 16, 2006, at 7:32 PM, TheSin wrote: On 16-Jan-06, at 5:07 PM, Daniel Johnson wrote: Is it safe to assume that Christian Swinehart is MIA? Yes. I'd like to update pcre since fink's version (4.5) is pretty ancient and I've been using the latest version (6.4) for a few months now with no issues. [...] pcre appears to follow the freetype model of binary compatibility. Freetype? Ick! It burns! Maybe if I back away slowly and don't make eye contact... Bleh. I didn't realize that. Scratch that idea. Compared to 4.5, 6.4 adds new things to the public API/ABI (new functions, new elements in structs, new #defines and wider datatypes for other #defines). However, it appears to use the same install_name and does not appear to increment the compatibility_version. Granted, they don't change existing prototypes, and they add to the end of structs, so things compiled against old would work with new and things compiled against new would work with old (as long as they don't use any new stuff). But we're just askin' for user-land breakage unless compat is incremented or a different install_name is used. Is there any reasonably simple way I can test this? I think your email to -devel just did:) So if I do this, it should be a new package with a different install_name, compat version, and a subdir of lib, right? Like (shudder) freetype219? Maybe it's not worth it... -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Take over pcre?
OK, I've put together a preliminary libpcre64 package, in which headers and libraries and such live in %p/lib/libpcre64. The install_name is adjusted accordingly. The info file is here: http:// www.mac.com/danielj7/libpcre64.info I didn't want to commit it soliciting opinions. Speaking of which, how the heck do I submit a new item to the tracker? I can edit existing items fine, but I searched the page repeatedly and can't find an add new item or some-such button. I've done it before, so maybe I'm just losing my mind. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: Take over pcre?
On Jan 18, 2006, at 11:48 PM, Charles Lepple wrote: On 1/18/06, Daniel Johnson [EMAIL PROTECTED] wrote: I didn't want to commit it soliciting opinions. Speaking of which, how the heck do I submit a new item to the tracker? I can edit existing items fine, but I searched the page repeatedly and can't find an add new item or some-such button. I've done it before, so maybe I'm just losing my mind. on this page: https://sourceforge.net/tracker/?atid=371315group_id=17203 (the same link as from fink.sourceforge.net) search for Submit new. Make sure you are logged in. OK, I am losing my mind. Not that that's necessarily a bad thing. I guess I was trying to find a button, not a link. I really _have_ done this before, honest! :) Muchly appreciated. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Take over pcre?
On Jan 19, 2006, at 2:38 PM, Patrick Näf wrote: version (6.4) for a few months now with no issues. Note that pcre now includes a C++ wrapper lib, libpcrecpp, so it would have to have a Hm, in this case the new pcre package would obsolete the existing pcre++ package, wouldn't it? A C++ wrapper is now included with pcre, though I couldn't guarantee that it's a drop-in replacement. I would be glad if I could get rid of pcre++, since I'm not actively maintaining the package anymore. Also, I haven't ever heard of anybody who uses it... I just checked, and there aren't any packages that depend on pcre++. If nobody disagrees - how do I go about removing it? Should I submit an item to the package requests tracker? If you want, I'll delete it when I add the new package. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] mac-growl-pm586: fix it or I'll kill it
On Jan 18, 2006, at 5:36 PM, Koen van der Drift wrote: On Jan 18, 2006, at 3:28 PM, TheSin wrote: hmm that is odd if it's the case, can other confirm this? I only have one Mac and it is building after turning off Growl in the pref pane as I reported earlier. I tried turning Growl on and rebuild mac-growl-pm586 to see if I could reproduce the old error, but it still builds fine. Regarding you earlier question, that returns: [EMAIL PROTECTED]:~] $ locate glues/GrowlHelperApp /sw/lib/perl5/5.8.6/Mac/Glue/glues/GrowlHelperApp /sw/lib/perl5/5.8.6/Mac/Glue/glues/GrowlHelperApp.pod /System/Library/Perl/Extras/5.8.6/Mac/Glue/glues/GrowlHelperApp /System/Library/Perl/Extras/5.8.6/Mac/Glue/glues/GrowlHelperApp.pod - Koen. If someone is still investigating this, I just did a fresh fink bootstrap of the 10.4 tree and had the same mac-growl-pm586 failure. Turning off Growl in the preference pane allowed the build to complete successfully and, as above, once it's been built the first time, further rebuilds also succeed. Note that I don't have a GrowlHelperApp glue in /System, only in /sw. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] package ordering problem
On Feb 12, 2006, at 7:01 PM, William Scott wrote: That's great. It works, and is so simple it hurts. Thanks! On Sun, 12 Feb 2006, Charles Lepple wrote: On 2/12/06, William Scott [EMAIL PROTECTED] wrote: dpkg --compare-versions 0.1.0-pre-1 gt 0.1.0 echo true true How about 0.1.0.0-1 ? While this works, it does contaminate the version number. Another approach is to encode the pre in the revision: 0.1.0-0.pre1.1 or some such. Increment the last .1 for a new revision. This way you can keep the version pure while still showing the pre status and being able to upgrade to the final version. But that's just a matter of taste. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] 10.4 bindist URL?
On Feb 19, 2006, at 5:25 PM, Koen van der Drift wrote: On Feb 19, 2006, at 5:20 PM, David R. Morrison wrote: In fact, this is why the installation instructions in RangerRick's blog (pointed to from the wiki page I gave yesterday) suggest that you should answer no to the question try to use binary? during bootstrap or configuration. Ah, I missed that part :-| Fixed now in my fink.conf file, sorry for the noise. - Koen. I also found it useful to comment out the lines deb http://bindist.finkmirrors.net/bindist 10.4/release main crypto and deb http://bindist.finkmirrors.net/bindist 10.4/current main crypto in /sw/etc/apt/sources.list to avoid errors from apt-get update. Especially if you use fink HEAD and the cool new AutoScanpackages feature. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] /var/lib/dpkg
On Feb 19, 2006, at 12:48 PM, William Scott wrote: Mine's got loads of stuff in it. I wonder if this was due to the fact that I went directly from injecting to building ca. 200 packages, possibly forgetting to source /sw/bin/init.sh before I started installing stuff? On Sun, 19 Feb 2006, [ISO-8859-1] Jean-François Mertens wrote: On 19 Feb 2006, at 18:01, Jean-François Mertens wrote: # dpkg -S /var/lib aptitude: /var/lib The dir is empty, so easy to fix at the end of the InstallScript JF Mertens Adding --enable-package-state-loc=%p/var/lib/aptitude to aptitude's ConfigureParams should fix this. Of course, any stuff in /var/lib/ aptitude would have to be manually moved to /sw/var/lib/aptitude after this or else you'll have to start over since that's where aptitude keeps package state information. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] /var/lib/dpkg
On Feb 19, 2006, at 6:11 PM, Daniel Johnson wrote: On Feb 19, 2006, at 12:48 PM, William Scott wrote: Mine's got loads of stuff in it. I wonder if this was due to the fact that I went directly from injecting to building ca. 200 packages, possibly forgetting to source /sw/bin/init.sh before I started installing stuff? On Sun, 19 Feb 2006, [ISO-8859-1] Jean-François Mertens wrote: On 19 Feb 2006, at 18:01, Jean-François Mertens wrote: # dpkg -S /var/lib aptitude: /var/lib The dir is empty, so easy to fix at the end of the InstallScript JF Mertens Adding --enable-package-state-loc=%p/var/lib/aptitude to aptitude's ConfigureParams should fix this. Of course, any stuff in /var/lib/aptitude would have to be manually moved to /sw/var/lib/ aptitude after this or else you'll have to start over since that's where aptitude keeps package state information. Of course, the original question was about /var/lib/dpkg not /var/lib/ aptitude. :P Got a little sidetracked there... I have no /var/lib/dpkg on my 10.4 tree system, nor have I found what creates it. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] Spotlight importer universal binary
I've built my Fink info file Spotlight importer as a universal binary. MacBook's coming this week. :) http://homepage.mac.com/danielj7/FinkInfoFile.zip Source code is included. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] some gtk+2 issues
While building abiword-2.2.7-1003 on Intel, I discovered some issues with gtk+2-2.6.10-1001. Abiword would crash on launch with warnings about Cannot open pixbuf loader module file '/sw/etc/gtk-2.0/gdk- pixbuf.loaders': No such file or directory. Indeed no such file exists in any gtk+2 splitoffs, but if I run /sw/sbin/update-gdk- pixbuf-loaders from gtk+2 that file is created and abiword works. I think update-gdk-pixbuf-loaders needs to be run during the gtk+2 build. Also, gtk+2 must be installed at runtime in addition to gtk+2- shlibs or abiword crashes anyway. Abiword also crashes when quitting, but that's not terribly important and I didn't look into it very closely. I'm going to be building a bunch more packages, and I'm willing to take requests for testing things on Intel. I can't promise to build EVERYTHING of course, but I think I might try KDE next. :) This thing is blazing fast at compiling. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] some gtk+2 issues
/ImageIO.framework/Versions/A/ImageIO 0x91929000 - 0x919dbfff libcrypto.0.9.7.dylib /usr/lib/libcrypto. 0.9.7.dylib 0x91a21000 - 0x91a37fff libcups.2.dylib /usr/lib/libcups.2.dylib 0x91a3c000 - 0x91a58fff libJPEG.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libJPEG.dylib 0x91a5d000 - 0x91abbfff libJP2.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libJP2.dylib 0x91acb000 - 0x91ac libGIF.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libGIF.dylib 0x91ad1000 - 0x91b1afff libRaw.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libRaw.dylib 0x91b1d000 - 0x91b5afff libTIFF.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libTIFF.dylib 0x91b6 - 0x91b7afff libPng.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libPng.dylib 0x91b7f000 - 0x91b81fff libRadiance.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libRadiance.dylib 0x91b83000 - 0x91b83fff com.apple.Accelerate 1.2.1 (Accelerate 1.2.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/ Accelerate 0x91b85000 - 0x91c0bfff com.apple.vImage 2.2 /System/Library/ Frameworks/Accelerate.framework/Versions/A/Frameworks/ vImage.framework/Versions/A/vImage 0x91c12000 - 0x91c12fff com.apple.Accelerate.vecLib 3.2.1 (vecLib 3.2.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/ Frameworks/vecLib.framework/Versions/A/vecLib 0x91c14000 - 0x91c59fff libvMisc.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libvMisc.dylib 0x91c61000 - 0x91c86fff libvDSP.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libvDSP.dylib 0x91c8d000 - 0x92210fff libBLAS.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libBLAS.dylib 0x9224d000 - 0x925f libLAPACK.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libLAPACK.dylib 0x9a5f7000 - 0x9a606fff libICE.6.dylib /usr/X11R6/lib/libICE.6.dylib 0x9a60b000 - 0x9a60 libSM.6.dylib /usr/X11R6/lib/libSM.6.dylib 0x9a673000 - 0x9a6b3fff libfreetype.6.dylib /usr/X11R6/lib/ libfreetype.6.dylib 0x9a6c - 0x9a6dcfff libexpat.0.dylib /usr/X11R6/lib/libexpat. 0.dylib 0x9a6e1000 - 0x9a6f8fff libfontconfig.1.dylib /usr/X11R6/lib/ libfontconfig.1.dylib 0x9c034000 - 0x9c03cfff libXext.6.dylib /usr/X11R6/lib/libXext.6.dylib 0x9c041000 - 0x9c0fefff libX11.6.dylib /usr/X11R6/lib/libX11.6.dylib 0x9c3be000 - 0x9c3c3fff libXcursor.1.dylib /usr/X11R6/lib/libXcursor. 1.dylib 0x9c3c6000 - 0x9c3cafff libXrender.1.dylib /usr/X11R6/lib/libXrender. 1.dylib 0x9c3da000 - 0x9c3e6fff libXft.2.dylib /usr/X11R6/lib/libXft.2.dylib 0x9c3f2000 - 0x9c3f2fff libXinerama.1.dylib /usr/X11R6/lib/ libXinerama.1.dylib 0x9c421000 - 0x9c422fff libXrandr.2.dylib /usr/X11R6/lib/libXrandr. 2.dylib -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] libgnomeprint2.2-2.12.1-1001
It's me again. And no I'm not looking to take over Gnome. :-) Anyway, the brand new libgnomeprint2.2-2.12.1-1001 package requires a BuildDepends on bison. It fails to build with the system's version. I assume the same is also true in the other trees. What's the correct procedure for these things? If a package has a real maintainer I'll email them, obviously. But for a package like this, should I just go ahead and make the change? What's the best way to be useful? Aside from assuming the role of fink-gnome-core of course. ;-) I've also got gnumeric building with gcc 4 and emailed the maintainer with the instructions. Thanks. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] Some observations on Gnome on Intel Macs
I've successfully built all of bundle-gnome on Intel and most things even work! I also tried some other gnome-using programs like gnumeric, abiword, conglomerate, and bluefish-gnome2 successfully. There are two issues I've encountered. Mozilla and firefox both crash on launch with backtraces like the following: Command: firefox-bin Path:/sw/lib/firefox/firefox-bin Parent: sh [466] Version: ??? (???) PID:471 Thread: 0 Exception: EXC_BAD_INSTRUCTION (0x0002) Code[0]:0x000d Code[1]:0x Thread 0 Crashed: 0 dyld0x8fe136e4 stub_binding_helper_interface + 18 1 0x 0 + 0 2 libxpconnect.dylib 0x02ca30fa NSGetModule + 28198 3 libxpconnect.dylib 0x02c9e96f NSGetModule + 9883 4 libxpcom.dylib 0x00255b4e XPTC_InvokeByIndex + 246 5 libxpcom.dylib 0x00255cb5 nsXPTCStubBase::Stub4() + 27 6 libxpconnect.dylib 0x02cb24a2 NSGetModule + 90574 7 libxpconnect.dylib 0x02cb2785 NSGetModule + 91313 8 libxpconnect.dylib 0x02cb057f NSGetModule + 82603 9 libxpcom.dylib 0x0023635e nsComponentManagerImpl::AutoRegisterNonNativeComponents(nsIFile*) + 270 10 libxpcom.dylib 0x00236eec nsComponentManagerImpl::AutoRegisterImpl(int, nsIFile*, int) + 780 11 libxpcom.dylib 0x0023708f nsComponentManagerImpl::AutoRegister(nsIFile*) + 137 12 libxpcom.dylib 0x00207ad9 NS_InitXPCOM2 + 1165 13 firefox-bin 0x24a5 ScopedXPCOMStartup::Initialize() + 43 14 firefox-bin 0x486f ScopedXPCOMStartup::SetWindowCreator(nsINativeAppSupport*) + 2811 15 firefox-bin 0x5873 xre_main(int, char**, nsXREAppData const*) + 2245 16 firefox-bin 0x22de main + 40 17 firefox-bin 0x225e start + 270 18 firefox-bin 0x2179 start + 41 So it's failing to load external modules, apparently. I haven't look at this too closely yet. Of course, anything using either of these, like yelp and the gnome help system, won't work. The other issue is with control-center2 and gnome-panel. Control center is crashing because it can't find any of the preference programs, although those programs exist and can be run manually. Gnome panel can't load applets or find any applications; the applications menu is empty. They're asking gnome-vfs2 how to find these resources, but gnome-vfs2 doesn't know what they're talking about. And now I know why. From the gnome-vfs2 ChangeLog: 2004-11-16 Mark McLoughlin [EMAIL PROTECTED] Remove the vfolder and cdemenu methods - the panel and control-center now use libgnome-menu for accessing the menus. The issue is that gnome-vfs2 2.10.x is too new for control-center2 and gnome-panel which are both 2.6.x. The methods they rely on no longer exist. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] ESP Ghostscript
On Feb 26, 2006, at 12:41 PM, Tomoaki Okayama wrote: Hello, I made a finkinfo of ESP Ghostscript which contains powerful CJK support and cups support. It's now in the experimental tree, experimental/todai/ecc/main/finkinfo/text/ghostscript-esp.info. I'd like to commit it to unstable but there is a problem. For adding files to system's cups, it is necessary to handle system's directory(out of /sw). Symbolic links must be created at least. That handlings in PostInstScript and PreRmScript are commented out now, but would it be possible to uncomment them and commit to unstable? If it is ok, lots of cups users will be happy. Thanks, -- Tomoaki Okayama / Todai Fink Team The problem with installing things outside of /sw is that it can surprise the user. For example, I have a later version of ESP GhostScript (8.15.1) that I manually built, along with HPIJS, so I could use some printers that don't have other drivers available. If I installed this package, either directly or as a dependency, my current system would get overwritten and I could lose the ability to print. Furthermore, removing this package would not restore my system to the way it was before. That would not make me happy. :) At the very least, this needs to backup any existing files and restore them at package removal. A better solution is to include a script with the package which does the actual installation into /usr and handles restoration at removal. This way the user must explicitly choose to do this rather than being surprised by simply installing a package. The package's PreRm should also call this script to ensure that the package will clean up after itself. The postfix package does something like this with its mta-switch script. Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] The continuing adventures of the Intel build
In this next episode, we completed building kdelibs3-unified. The only necessary fix was to remove a -mtune=G4 from qt3.patch which caused gcc on Intel to freak out. Maintainer notified. Next we embark on the quest for kdebase3-unified. Scary! -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] The continuing adventures of the Intel build
On Feb 26, 2006, at 3:24 PM, Daniel Johnson wrote: In this next episode, we completed building kdelibs3-unified. The only necessary fix was to remove a -mtune=G4 from qt3.patch which caused gcc on Intel to freak out. Maintainer notified. Next we embark on the quest for kdebase3-unified. Scary! To continue... kdebase3, kdeadmin3, kdeartwork3, and kdetoys3 have built and I'm now compiling kdeedu3. I figured I had enough built to fire up kde and try it out. It works! And quite speedy too. kdeaccessibility3 won't build because gst-plugins is only powerpc at the moment and so is koffice. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
[Fink-devel] KDE builds on Intel! (mostly)
Just to let everyone know, I've built all of bundle-kde on Intel, except for kdeaccessibility3 and koffice. Along the way I've fixed Intel building of some dependecies and emailed maintainers about some others. The blocker for kdeaccessibility3 is gstreamer (at least) which uses assembly language files for it's x86 build. Unfortunately, Apple's assembler appears to use a different syntax than the Gnu assembler and dies horribly when trying to parse the files. It's possible to use the generic C code instead, but it won't be simple to decouple the assembly code from the rest of the x86isms. This could turn out to be a problem with other assembly-using packages. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] KDE builds on Intel! (mostly)
On Feb 28, 2006, at 12:15 AM, Dave Vasilevsky wrote: On Feb 27, 2006, at 9:57 PM, Daniel Johnson wrote: The blocker for kdeaccessibility3 is gstreamer (at least) which uses assembly language files for it's x86 build. Unfortunately, Apple's assembler appears to use a different syntax than the Gnu assembler and dies horribly when trying to parse the files. It's possible to use the generic C code instead, but it won't be simple to decouple the assembly code from the rest of the x86isms. This could turn out to be a problem with other assembly-using packages. Which version of gstreamer fails, and what's the error? I think the gstreamer folks removed most of their assembly code lately. Dave That would be gstreamer-0.8.12-1021 from 10.4/unstable. I'm trying gstreamer-0.10 now, but the older one is required by some dependency of kdeaccessibility3. I see what needs to be done to get 0.8.12 to build, but it requires a lot of patching which I don't really feel like doing right now. :) Of course, if the dependency can be safely changed to gstreamer-0.10, that would also work. And gstreamer-0.10 just built. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: ppc unix binaries on Macintel?
On Feb 28, 2006, at 7:15 PM, Jack Howarth wrote: Chris, I had been hoping that X11.app and Rosetta would have been designed such that the X11 libs would be present in both binary formats (intel and ppc) so that pre-existing X11 ppc binaries could be run through Rosetta. That would have really smoothed the transition. Jack For what it's worth, I just checked on my MacBook and all the libraries and executables in Apple's X11 are universal binaries. Since X Windows uses a client/server architecture and, in fact, you can run a client program on one machine with a server on another machine with a different processor, it SEEMS like this should work. Of course, all libraries a ppc program links to must also be ppc or universal, which is true of all system-provided libraries. I haven't actually tried this though since I have no ppc-only X clients around. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] KDE builds on Intel! (mostly)
On Feb 28, 2006, at 8:34 PM, Benjamin Reed wrote: Daniel Johnson wrote: I see what needs to be done to get 0.8.12 to build, but it requires a lot of patching which I don't really feel like doing right now. :) Of course, if the dependency can be safely changed to gstreamer-0.10, that would also work. And gstreamer-0.10 just built. The API changed rather drastically between 0.8 and 0.10, it's extremely unlikely you can just switch the dep and have it work, you'll have to port the software, or wait for the software to be ported to the 0.10 framework. Also be aware that the osx audio and video plugins for gstreamer haven't been ported to 0.10 yet, so you'll have to go through esound or something else if there is something, to get audio at all from gstreamer 0.10. Oh well, back to 0.8.12. Heh, that was a lot easier then I thought! Here's the patch to enable building on Intel: gstreamer.patch Description: Binary data This won't effect ppc building at all, and since it never built on Intel you shouldn't need to rev-up. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] SDL-mixer patch for fink
On Mar 10, 2006, at 10:57 AM, Keith Conger wrote: Hi Max, A couple packages of mine depend on SDL_mixer so I decided to try to fix on 10.4 intel. Looks like the fixes were in SDL_mixer cvs already. So I've include a patch and update info file until there is a new upstream release. Thanks, Keith I tested this and it works. Committed to 10.4/unstable. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] dpkg bug (new dpkg apt need testing)
On Mar 14, 2006, at 5:54 PM, Benjamin Reed wrote: Martin Costabel wrote: $ for GCC in gcc2 gcc3 gcc-3.3 gcc-3.3.3 gcc-3.4.1 gcc-4.0 i686-apple-darwin8-gcc-4.0.1 ; do echo $GCC : `$GCC - dumpmachine` ;done gcc2 : ppc-darwin gcc3 : ppc-darwin gcc-3.3 : ppc-darwin gcc-3.3.3 : powerpc-apple-darwin7.4.0 gcc-3.4.1 : powerpc-apple-darwin7.4.0 gcc-4.0 : powerpc-apple-darwin8 i686-apple-darwin8-gcc-4.0.1 : i686-apple-darwin8 Nobody seems to have told debian about this. well, we're using a rather old version of dpkg... I've got updated dpkg and apt packages in my experimental that appear to do better on intel: ---(snip!)--- $ dpkg-architecture DEB_BUILD_ARCH=darwin-i386 DEB_BUILD_ARCH_OS=darwin DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=darwin DEB_BUILD_GNU_TYPE=i486-darwin DEB_HOST_ARCH=darwin-i386 DEB_HOST_ARCH_OS=darwin DEB_HOST_ARCH_CPU=i386 DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=darwin DEB_HOST_GNU_TYPE=i486-darwin ---(snip!)--- Not sure why they want to make it i486 for the GNU stuff, but hey, it works, at least. :) A lot of packages try to detect which ix86 processor a machine has so that they can tune gcc to match. Because of the proliferation of ix86 processors, such code quickly becomes outdated. :) Unfortunately, since the Core Duo is so new, most packages don't correctly identify it and often fall back to i386 or i486. Which can degrade performance since Apple's gcc is already properly tuned by default. I'd appreciate some testers, it would be nice to have a modern dpkg and apt in Fink again. I'll try it out. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] dpkg bug (new dpkg apt need testing)
On Mar 14, 2006, at 8:13 PM, Daniel Johnson wrote: On Mar 14, 2006, at 5:54 PM, Benjamin Reed wrote: Martin Costabel wrote: $ for GCC in gcc2 gcc3 gcc-3.3 gcc-3.3.3 gcc-3.4.1 gcc-4.0 i686-apple-darwin8-gcc-4.0.1 ; do echo $GCC : `$GCC - dumpmachine` ;done gcc2 : ppc-darwin gcc3 : ppc-darwin gcc-3.3 : ppc-darwin gcc-3.3.3 : powerpc-apple-darwin7.4.0 gcc-3.4.1 : powerpc-apple-darwin7.4.0 gcc-4.0 : powerpc-apple-darwin8 i686-apple-darwin8-gcc-4.0.1 : i686-apple-darwin8 Nobody seems to have told debian about this. well, we're using a rather old version of dpkg... I've got updated dpkg and apt packages in my experimental that appear to do better on intel: ---(snip!)--- $ dpkg-architecture DEB_BUILD_ARCH=darwin-i386 DEB_BUILD_ARCH_OS=darwin DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=darwin DEB_BUILD_GNU_TYPE=i486-darwin DEB_HOST_ARCH=darwin-i386 DEB_HOST_ARCH_OS=darwin DEB_HOST_ARCH_CPU=i386 DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=darwin DEB_HOST_GNU_TYPE=i486-darwin ---(snip!)--- Not sure why they want to make it i486 for the GNU stuff, but hey, it works, at least. :) A lot of packages try to detect which ix86 processor a machine has so that they can tune gcc to match. Because of the proliferation of ix86 processors, such code quickly becomes outdated. :) Unfortunately, since the Core Duo is so new, most packages don't correctly identify it and often fall back to i386 or i486. Which can degrade performance since Apple's gcc is already properly tuned by default. I'd appreciate some testers, it would be nice to have a modern dpkg and apt in Fink again. I'll try it out. OK, I built apt 0.6.43.3-1022 and dpkg 1.13.16-1022 from your experimental/10.4 and now apt-ftparchive crashes with: dyld: Library not loaded: /sw/lib/libapt-inst.1.dylib Referenced from: /sw/bin/apt-ftparchive Reason: image not found Trace/BPT trap $ otool -L /sw/bin/apt-ftparchive /sw/bin/apt-ftparchive: /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation (compatibility version 150.0.0, current version 368.26.0) /sw/lib/libapt-pkg.3.dylib (compatibility version 3.0.0, current version 3.11.0) /sw/lib/libapt-inst.1.dylib (compatibility version 1.0.0, current version 1.1.0) /sw/lib/libintl.1.dylib (compatibility version 2.0.0, current version 2.1.0) /sw/lib/libftw.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) $ otool -L /sw/lib/libapt-inst.1.dylib otool: can't open file: /sw/lib/libapt-inst.1.dylib (No such file or directory) $ otool -L /sw/lib/libapt-inst.1.0.dylib /sw/lib/libapt-inst.1.0.dylib: /sw/lib/libapt-inst.1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libapt-pkg.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation (compatibility version 150.0.0, current version 368.26.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) and /sw/lib/libapt-inst* only exists in the apt 0.5.4 packages, not the 0.6.43.3 ones. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Re: New Build Results
On Mar 27, 2006, at 5:25 PM, Jordan Mantha wrote: devhelp - no change, but failure due to desktop-file-utils, so it should work, unless something else is not good Builds but doesn't run because of a problem with mozilla (and firefox) on Intels. I reported a bug (1459616) https:// sourceforge.net/tracker/index.php? func=detailaid=1459616group_id=17203atid=117203 I commented on the bug, but I'll also do so here: This is a known problem in all currently released versions of mozilla and firefox. It's supposed to be fixed by the not yet released firefox 1.5.0.2. I doubt that 1.0.7 will ever be fixed. See http:// wiki.mozilla.org/Mac:Intel for more info. See also the firefox 1.5 package submission https://sourceforge.net/tracker/? func=detailatid=414256aid=1370163group_id=17203 (and if someone could test the new firefox on a ppc machine, it would be helpful; I had trouble building yelp against it, but that might just be because it doesn't build right on Intel). -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Could pcre be updated?
On Sep 12, 2006, at 9:36 AM, Michèle Garoche wrote:Le 12 sept. 2006 à 14:32, Benjamin Reed a écrit :Michèle Garoche wrote: Hello,Could pcre be updated to at least version 6.4, better to version 6.7?It has new unicode properties needed for medit I plan to package, if I succeed. It will take some work, I think; last I saw pcre broke binary compatibility without changing the library version, and no one's looked into updating it since.Oh, I have not even tried to compile it myself. There are too many things in the info file I don't understand.I don't know if it breaks binary compatibility, but there is at least a change in version number in the configure. I played with updating pcre a while ago, but stopped after the binary compatibility issues were revealed.I have a working pcre 6.4 package here: http://homepage.mac.com/danielj7/libpcre64.info if that is of use. -- Daniel Johnson[EMAIL PROTECTED] PGP.sig Description: This is a digitally signed message part - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Updating pcre revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A while ago I had suggested updating pcre to something not so prehistoric, but at the time concerns were raised about library compatibility. Recently. I looked closely at the current version, 7.0, and compared it to Fink's 4.5. I can't find any reason why we couldn't update the package to the latest version. Yes, there are 4 new functions added to the library, but adding functions doesn't break backward compatibility. If that were the case then anything built on Panther shouldn't work on Tiger. :) There are a couple of new fields added to the end of two structs, but again the developers designed this with backward compatibility in mind by requiring flags to be passed in to enable those fields. While upstream hasn't rigorously followed libtool versioning guidelines, even if they had, the install_name would still not have changed since 4.5 since CURRENT and AGE would still be the same. I've done some testing and encountered no issues, but I'd appreciate it if others could test as well. I can confirm, for example, that bluefish built against pcre 4.5 works fine with pcre 7.0. Postfix and nmap also seem to work. I've put the info file in my experimental directory at danielj/10.4/ pcre.info for anyone who would like to try it. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFFvRtl4sDFGYouOqARAu5ZAKCQHGVrhtY8r9gaGJmdDFqyTBAzKQCgj4N7 f3lgHUUn6LUKx9NKP+X5a6Y= =zH8R -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc42 mixed result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 28, 2007, at 4:12 PM, Jack Howarth wrote: It would appear that using tar 1.16 in fink is a really bad idea... http://www.mail-archive.com/amanda-users@amanda.org/msg37008.html I would also note that Fedora development is still using 1.15.1 for tar. Jack A possible workaround for now is to make sure that /usr/bin/tar comes before /sw/bin/tar in PATH. I did a ln -s /usr/bin/tar ~/bin/tar and then make sure I export PATH=~/bin:$PATH. I do this since I prefer Apple's tar which understands extended attributes and I've never had an issue with the file changed as we read it error. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFFvR6z4sDFGYouOqARAu2AAKCESiXVhFVlyU1u9TAeyINYaCPBXwCglCSp 0YUO/r/l/mdM6Vvf7ayS/6Q= =2Fsk -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] postgis82-1.2.1-1024
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 16, 2007, at 5:06 PM, Robert T Wyatt wrote: Robert T Wyatt wrote: Howdy, Postgis82 (10.4-unstable tree) built for me, but it won't install (on two different machines I have the same error): Setting up postgis82 (1.2.1-1024) ... mv: cannot stat `/etc/alternatives/createdb.postgis.dpkg-tmp': No such file or directory update-alternatives: unable to install /etc/alternatives/createdb.postgis.dpkg-tmp as /etc/alternatives/createdb.postgis: No such file or directory /sw/bin/dpkg: error processing postgis82 (--install): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: postgis82 ### execution of /sw/bin/dpkg-lockwait failed, exit code 1 Failed: can't install package postgis82-1.2.1-1024 Downgrading dpkg from RR's experimental tree to the one in unstable resolved this. RR: Note that I was using dpkg_1.13.25-1021 which may not have been your most recent. You can also manually edit /sw/sbin/update-alternatives and change $altdir= '/etc/alternatives'; to $altdir= '/sw/etc/alternatives'; until this is fixed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFF1krp4sDFGYouOqARAot8AJ41EXeXTddziYJzZFArZgsMYnzXlwCfeyfw OgfUhj69lK0SyuBfyRaS9g0= =pE4L -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc42 O0g.gch: file changed as we read it (again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 26, 2007, at 10:52 PM, Jean-François Mertens wrote: On 27 Feb 2007, at 03:17, Jack Howarth wrote: Frankly it is insane that tar hasn't been epoched and regressed back to 1.15.1. No other software distro would allow a single critical package like this to be left broken for so long. If we can rationalize leaving our dpkg at such an old version certainly we can also justify leaving tar at 1.15.1. Jack We still don't know whether it is tar which is broken (which I doubt..), or whether there is something else going on on _ a couple of, or: many ? _ machines.. I have built those pkgs as many times as anybody else, on several machines, (and am building about as much as anybody else, with ~ 600K files and directories installed), and have never seen this problem. (Waiting desperately to see it once _ to be able to do immediately a stat on the files involved, and ps -lxaww, etc...) A problem should first be understood, and the clues to its source can only come from those who suffer from it... I don't know exactly why it's happening, but I have figured out some things. The file changed as we read it warning does occur sometimes with tar 1.15.1, but it always returned an exit code of 0 in such cases. It would return 1 if a fatal error occurred. Starting with 1.16, tar now returns 0 for success, 1 for non-fatal errors (like the file changed one) and 2 for fatal errors. The problem is that dpkg- deb fails if tar returns a non-zero exit code. Now dpkg-deb could be patched, but since you'd still want it to fail for truly fatal errors and the fatal error code changed from 1 to 2, it needs to know which version of tar it's using or Bad Things could happen. Another bit of information is that the code in tar that checks if a file changed as we read it changed after 1.15.1. Previously, the warning occurred if a file's ctime changed during archiving; now it will also occur if the file's size increases. I don't know why either of these situations is happening though. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFF5G324sDFGYouOqARAgajAJ0Vv7lnObPFvk9Ia9lPvB17uzRjOwCfVEU+ Tb8tohjC0QGQuCKXQz2GXKY= =62gL -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc42 O0g.gch: file changed as we read it (again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 1, 2007, at 10:20 PM, Jean-François Mertens wrote: On 27 Feb 2007, at 18:44, Daniel Johnson wrote: I don't know exactly why it's happening, but I have figured out some things. The file changed as we read it warning does occur sometimes with tar 1.15.1, but it always returned an exit code of 0 in such cases. It would return 1 if a fatal error occurred. Starting with 1.16, tar now returns 0 for success, 1 for non-fatal errors (like the file changed one) and 2 for fatal errors. The problem is that dpkg- deb fails if tar returns a non-zero exit code. Now dpkg-deb could be patched, but since you'd still want it to fail for truly fatal errors and the fatal error code changed from 1 to 2, it needs to know which version of tar it's using or Bad Things could happen. Daniel, For the moment, the major problem seems to be in 10.4/unstable, where we know the version of tar. So why don't you go ahead and commit your patch to dpkg there _ (with if you want a versioned dep on tar). I've no idea about the bootstrap process (just know it is not starting with just symlinks in %p pointing to corresponding things in /usr, and then building in strict build-order with '%i' silently substituted by '%p' until dpkg is installed). But I can't see how such a patch _ sorry: much better, correction _ of dpkg in that tree could have any negative impact, even on the bootstrap process (and even if it was as I would have thought). So please commit your correction to dpkg, unless someone screams with good arguments in the next couple of hours ... Another bit of information is that the code in tar that checks if a file changed as we read it changed after 1.15.1. Previously, the warning occurred if a file's ctime changed during archiving; now it will also occur if the file's size increases. I don't know why either of these situations is happening though. I too would have by far preferred to understand this before; but 'unstable' is not 'experimental', and we shouldn't hold up a fix that's anyway needed _ for consistency between the 2 pkgs _, just in order to pursue an experiment... (I would bet rather on the ctime than on the size _ which looks to me as an almost redundant test _, but evidence for that will disappear after your patch .. (sigh) ) Well since I'm not a core developer, I don't think it would be appropriate for me to patch core packages. :) What I recommend for now is this: perl -pi -e 's,tar,/usr/bin/tar,g' dpkg-deb/build.c That will force dpkg-deb to use the system's tar instead of fink's and would have the least side effects. Patching around the new tar's behavior would require significant changes to dpkg's logic. The function checksubprocerr is ultimately responsible for checking the exit code of subprocesses and it's designed to simply check for zero or non-zero status. There's no easy way to make it know that it needs to handle tar's exit code differently than for other processes. Another possibility, suggested by Dave Morrison, is a wrapper script for tar, which would massage the exit code into something dpkg-deb can handle, depending on the version of tar installed. Or tar can be epoched. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD4DBQFF562l4sDFGYouOqARAsL1AJikmjsmlG3iBR5UvaaEwDqW0miWAJ91ZyS5 nueiaMGV60nRWKupfqoC7A== =7q4W -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Help with debugging mysterious tar error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 3, 2007, at 3:52 AM, Martin Costabel wrote: Could those of you who have or had the dpkg-deb failure caused by tar-1.16.1 claiming file changed as we read it please help with debugging this? Based on the outcome of these tests, we should be able to decide whether we need to patch tar or dpkg, or whether we need to dig further down. I have made a special version of the tar executable that prints some more information if this error appears. It prints the old/new ctimes and the old/new file sizes. The special version is a universal binary (so it should work on both ppc and intel) and is available at http://perso.orange.fr/costabel/tar.gz A possible test procedure to follow would be: 1. Download the new tar: curl -O http://perso.orange.fr/costabel/tar.gz gunzip tar.gz chmod +x tar mv tar /var/tmp/ 2. Replace (temporarily) Fink's tar by the new one sudo ln -sf /var/tmp/tar /sw/bin/tar 3. Build one of the packages that give you the tar error (mysql, gcc42, gnumeric were among those where the error was reported). Cross your fingers that the error will happen again ;-) 4. Report to the list the part of the error message that is printed after the file changed as we read it line. 5. Put Fink's tar back to where it was before sudo ln -sf gtar /sw/bin/tar I just got synaptic to fail with your tar: dpkg-deb -b root-synaptic-0.57.2-2012 /sw/fink/10.4/unstable/main/ binary-darwin-i386/utils dpkg-deb: building package `synaptic' in `/sw/fink/10.4/unstable/main/ binary-darwin-i386/utils/synaptic_0.57.2-2012_darwin-i386.deb'. tar: ./sw/sbin/synaptic: file changed as we read it = Old ctime: 1172946146 New ctime: 1172946150 Old size : 14130940 New size : 14130940 = /sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1 ### execution of dpkg-deb failed, exit code 2 Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFF6b6I4sDFGYouOqARAinjAJ9ttimRePg946/7uO9thcdsxZEkmwCdGcg/ +0g2Y91bH0sSg/bWuwoqJbM= =okQd -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] License question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 4, 2007, at 1:09 PM, Tristan Thiede wrote: I'd like to package the appscript-py python mod, but it comes with the following license: -- Copyright (C) 2006 HAS Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. -- This looks like a very open license, yet it seems to be hand-rolled as it were, and so doesn't fit into any of the categories listed in Fink's packaging policy. What's the right thing to do here? This is essentially the MIT/BSD license, so BSD should be fine. You could also use OSI-Approved, which is a catch-all for non-restrictive licenses. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFF6w7z4sDFGYouOqARAkjFAKCK6xD8lYWjOAO8+Uw1zhfpbaRbVQCfZ1QW ohgyYkKfDGPkjubulOm8lTA= =6gHy -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] validation question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 28, 2007, at 5:12 PM, Benjamin Reed wrote:
David R. Morrison wrote:
I guess you are using fink from CVS HEAD?
There are some extensions to the validator which check on the
validitiy
of the Shlibs fields and dependencies in fink packages. These
extensions are still under construction, so error messages might be
misleading.
Ben, care to comment?
hard to say without digging in a little more, I'll see if I can take a
look at it
I see the problem. It only happens when the deb gets validated during
building. In PkgVersion::phase_build the validation occurs here:
if (Fink::Config::get_option(validate)) {
my %saved_options = map { $_ = Fink::Config::get_option($_) }
qw/
verbosity Pedantic /;
Fink::Config::set_options( {
'verbosity' = 3,
'Pedantic' = 1
} );
if(!Fink::Validation::validate_dpkg_unpacked($ddir)) {
if(Fink::Config::get_option(validate) eq on) {
die Please correct the above problems and try
again!\n;
} else {
warn Validation of .deb failed.\n;
}
}
Fink::Config::set_options(\%saved_options);
}
validate_dpkg_unpacked($ddir) is using $ddir which is equal to
basename $destdir and so the prefix gets dropped. Use $destdir
instead and it works.
Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: http://homepage.mac.com/danielj7/publickey.txt
iD8DBQFGNKf24sDFGYouOqARAhC7AJ9JhNKhHvenZaA+IKykrUq6C82ORwCaA8zs
dK9dKB7fuhv42tMSLGHd8vE=
=QQBX
-END PGP SIGNATURE-
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Deborphan fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 12, 2007, at 5:27 PM, Jean-François Mertens wrote: On 12 May 2007, at 12:16, Remko Tronçon wrote: Since deborphan is (ironically) an orphan, i'm posting this to fink- devel. Deborphan's 'orphaner' script needs 'dialog' or 'whiptail', yet it only searches for both binaries in /usr/bin and /usr/local/bin. The quick fix attached adds /sw/bin to those paths. Maybe a dependency on dialog or whiptail should be added, although deborphan itself does not depend on either. Updated deborphan. Could you check whether everything works well now ? Just a note that I've patched deborphan to now work with debfoster. In brief testing it seems to work fine, both with and without debfoster installed. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: http://homepage.mac.com/danielj7/publickey.txt iD8DBQFGR1r64sDFGYouOqARAh5oAJ0ZmmCmVFaFYhfTrRg0V8Lpb+/D2ACePywZ kjugPolOv8Pj7s0RiJgS0Q4= =fXUT -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] %p in patch file?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 20, 2007, at 7:54 AM, Koen van der Drift wrote:
I see it :-)
[]
Patch: %n.patch
[]
D'oh! thanks,
- Koen.
You should also use the newer PatchFile field instead of just Patch.
You then have to use a PatchFile-MD5 field which allows Fink to
ensure that the correct patch is being used. That'll catch mistakes
like forgetting to commit an updated patch file, which I've done
before. :) You can then also use %{PatchFile} instead of %a/%
{ni}.patch in the PatchScript. See http://www.finkproject.org/doc/
packaging/reference.php?phpLang=en#fields under PatchFile for details.
Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: http://homepage.mac.com/danielj7/publickey.txt
iD8DBQFG8mz24sDFGYouOqARAllrAJ9w7tyuOhyLR19NgmByz4vXs8qqpQCfVBeF
Aj6ESZ5+GgJFM4pQ2RD0NkI=
=IhwF
-END PGP SIGNATURE-
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] -dead_strip_dylibs
On Nov 11, 2007, at 8:12 PM, Jean-François Mertens wrote: I see in an excerpt of 'man ld' for 10.5 that ld now has an option '-dead_strip_dylibs'. I would strongly favour adding this as a default LDFLAG (conditional to 10.5). It does have the potential, when used systematically, to substantially reduce our deps ... Interesting! I'm testing this with some of my packages and it seems to work well. For instance, curl went from $ otool -L /sw/bin/curl /sw/bin/curl: /sw/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.1.0) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 19.0.0) /sw/lib/libssh2.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) to this $ otool -L /sw/bin/curl /sw/bin/curl: /sw/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.1.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) Only libcurl links to the other libraries. I did this by adding SetLDFLAGS: -Wl,-dead_strip_dylibs to the info file. I think it's necessary to use the -Wl, construction with libtool, though I didn't try without. I don't think it's a good idea to make this a default though. There are too many chances for surprises. Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Leopard, various porting-issues
On Nov 17, 2007, at 9:44 AM, Alexey Zakhlestin [EMAIL PROTECTED] wrote: On 11/17/07, Martin Costabel [EMAIL PROTECTED] wrote: As pogma explained in the thread [Fink-devel] I need help with a2ps 6 days ago, using a very recent autoconf should solve this problem. The latest we have in fink is 2.60 and it is not new enough Leopard comes with autoconf 2.61 which is the latest version. Try calling /usr/bin/autoconf instead of just autoconf. Leopard's automake is newer also, so you might want to use that as well. Daniel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] tcltk 8.4.16-1
On Dec 7, 2007, at 8:55 AM, Alexander K. Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Murali Vadivelu wrote: I have installed the latest update package from http://trac.macosforge.org/projects/xquartz and that seems to be the problem. Who's fault is it? Fink's or XQuartz's. snip Both. They changed the version in XQuartz from 7.2 to 1.3 and fink hasn't been updated to cope with that. Actually, there's something else wrong here. I have the latest Xquartz too, but fink correctly finds the (incorrect) version: $ fink list system-xfree86 Information about 6203 packages read in 3 seconds. i system-xfree86 2:1.3-2 [placeholder for user installed x11] i system-xfree86-dev 2:1.3-2 [placeholder for user installed x11 development tools] i system-xfree86-manu 2:1.3-2 Manually installed X11 components i system-xfree86-shli 2:1.3-2 [placeholder for user installed x11 shared libraries] What version of fink do you have, and what version of Xquartz? $ /usr/X11/bin/Xquartz -version -iokit X11.app starting: Xquartz server based on X.org Release 1.3, built on 20071201 The only package that is currently broken by the version change is fontconfig2-shlibs which is looking for system-xfree86-dev and -shlibs (= 2:7.2-1). Removing the (= 2:7.2-1) and rebuilding fixes that. Daniel smime.p7s Description: S/MIME cryptographic signature - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Xquartz version change?
On Dec 7, 2007, at 6:44 PM, Jeremy Huddleston wrote: I don't see why fink binaries won't work right. They should work fine since we symlink /usr/X11R6 to /usr/X11... the problem is in compiling them, right? So compile them on Tiger for now and distribute them as they'll work on Leopard... then as the packages get updated to use pkg-config instead of grep-hacks, things should start to work right on Leopard. That is infeasible. My impression is that most Fink users (well, at least me) compile from source, because the pre-built binaries available are sometimes rather out of date, or simply nonexistent. I don't have the inclination or the disk space to maintain a Tiger install just to build Fink... Sorry, I was under the impression it was mainly compile-from- source. I'm glad to see that's not the case. Fink does both compile-from-source and download-and-install-binaries. Unfortunately, building the binaries is very time consuming and is only done occasionally. Note: I don't use Fink, so I don't have a fine understanding of their build process. Well, maybe you should start, because a rather large fraction of the X11 users on the Mac will likely rely on Fink working nicely with X11 changes you make. :- Yes, I'm sure they will. Personally, I use MacPorts instead of fink. So far, I've noticed a few problems where it pulls in a macports package for a library instead of using the one in /usr/X11 (which is the case regardless of which version of Leopard X11 is installed), and if MacPorts devs don't get them fixed in a few weeks, I'll probably devote some cycles to fixing them up... Fink is very strict about dependencies and ensuring that packages always build the same on every system. This is necessary for binary packages to work since if a dependency was present on the build machine but not on the user's machine, well, that would be bad. :) The package manager generates a number of virtual packages that represent things provided by the system to support the dependency system. It also needs to provide version information for those packages. Fink has always provided virtual packages for X11 called system-xfree86-dev and system-xfree86-shlibs which had version 4.4 on Tiger and 7.2 on Leopard. Now they went to 1.3 and currently 0.0, since fink can no longer figure out the version. Now there is currently only one package that explictly depends on system-xfree86- shlibs =7.2 and that can easily be changed to an unversioned dependency since it's a Leopard-only package anyway. The big problem is that the package manager itself is failing since it can't figure out any version information so it thinks the system is corrupted. I agree that depending on individual X11 components is probably the right way to go, but the problem is that hundreds of packages in Fink currently depend on system-xfree86-* and changing that would require forcing users to rebuild every package that uses X11 since the dependency information is part of the package. Users will find this...annoying. Honestly, this problem comes from years of fink having to use ugly grep hacks to figure out version numbers for X11, and there is finally a *real* way for them to check it now. It's sad that they did not get this working right during the Leopard beta, but I'm confident that it will be working soon. As someone else mentioned, most other *nixes went through this hell a few years ago, and it's finally OSX's turn to bite the bullet. This means people relying on X11 support for mission critical needs will need to stick with Tiger or use Tiger's X11 on Leopard for the near future. In the end, however, this will be much more smoother. Well, this was never an issue with the Leopard seeds since the version checking code still worked. :) And, in fact, still works on the Leopard GM X11. I'm not a core Fink dev, just a package maintainer, but my suggestion would be to create a new virtual package, maybe xorg-server, and set its version from xorg-server.pc. We wouldn't want to make pkg-config a core dependency, but parsing the version from the .pc file is easy. Then if that package exists, assume that we're using xorg 7.2 and set system-xfree86-* to version 7.2. That way existing packages will continue to work and new packages can migrate to the new virtual package(s). I think I'll suggest that and cross-post this to fink-devel. In the mean time, I'm volunteering my time to help get this working as quick as possible. --Jeremy And your work is much appreciated! Daniel smime.p7s Description: S/MIME cryptographic signature - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source.
Re: [Fink-devel] when Xcode 3.0 gcc 4.2 arrives...
On Dec 11, 2007, at 9:56 AM, Benjamin Reed wrote: Jack Howarth wrote: Alexey, What I had in mind was to default fink to use the gcc-4.2 and g++-4.2 compilers if present on a system but to allow both the ability to override this behavior on an info file basis as well as system-wide through an optional entry in fink.conf. We already have the provision to do this, through the GCC: field, so in theory we should be in good shape. (I presume the ABI changed again between apple's 4.0 and 4.2?) No, fortunately, the ABI didn't change. 4.2.1 should be a drop-in replacement, assuming that stricter error checking and/or bugs don't cause problems. Of course, we all know what happens when we assume... :) Daniel smime.p7s Description: S/MIME cryptographic signature - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] when Xcode 3.0 gcc 4.2 arrives...
On Dec 11, 2007, at 2:27 PM, Jack Howarth wrote: Benjamin, That sounds great, but we should still provide a way for an info file to force gcc-4.0 and g++-4.0 to be used even in the presence of gcc-4.2 and g++-4.2. It would also be nice to provide a fink.conf option to do the same globally. That should prevent anyone from complaining about being forced to use Apple's GCC 4.2. Jack In most cases, a SetCC: and/or SetCXX: field should do the trick for individual info files. Allowing users to change which compiler is used globally could be problematic. Technically, it would violate Fink policy since debs would be built differently. But more to the point, some packages might build with one compiler but not the other. It could cause support headaches for maintainers. Then again, maybe it'll work fine. I guess the first thing to do is to try building with the new compiler and see what happens. Daniel smime.p7s Description: S/MIME cryptographic signature - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] validation question
On Jan 13, 2008, at 6:27 PM, Koen van der Drift wrote: On Jan 13, 2008, at 6:15 PM, Jean-François Mertens wrote: But as coded e.g. in octave.info it does pass validation with fink (= 0.27.99) Just figured out that it only works when there are no trailing spaces before the exclamation mark. So we should not use indentation in a multiple line shlibs field. Aha! Yes, you're right. The offending regex in Validation.pm is /^\! \s*(.*?)\s*$/ so it should probably be /^\s*\!\s*(.*?)\s*$/ instead. But why does it work in octave which only BuildDepends on fink = 0.27.9, instead of fink = 0.27.99. Since now I get the following error: Error: private-library entry in Shlibs requires declaring a BuildDepends on fink (= 0.27.99) or higher. It only works if you change it to 0.27.99 or later, but since no such version has been released you can't actually use it in a public info file. Daniel smime.p7s Description: S/MIME cryptographic signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] validation question
On Jan 13, 2008, at 7:09 PM, Koen van der Drift wrote: On Jan 13, 2008, at 6:59 PM, Daniel Johnson wrote: But why does it work in octave which only BuildDepends on fink = 0.27.9, instead of fink = 0.27.99. Since now I get the following error: Error: private-library entry in Shlibs requires declaring a BuildDepends on fink (= 0.27.99) or higher. It only works if you change it to 0.27.99 or later, but since no such version has been released you can't actually use it in a public info file. Now I'm confused, since octave.info has BuildDepends: fink (= 0.27.9), not BuildDepends: fink (= 0.27.99). Ah, never mind, it still fails the validation ;-) - Koen. Yeah, like I said, octave.info CAN'T use 0.27.99 since no such fink version has been released. :) If it did, only people using fink HEAD could build octave. But I'm still having a problem: Validating .deb dir /sw/src/fink.build/root-fontforge-20080110-101... Error: package contains a dylib with no corresponding Shlibs entry (/ sw/lib/fontforge/libfontforge.1.0.0.dylib - /sw/lib/fontforge/ libfontforge.1.dylib 2.0.0) If this is a private library, add '!/sw/lib/fontforge/ libfontforge.1.0.0.dylib' to the Shlibs field. Error: package contains a dylib with no corresponding Shlibs entry (/ sw/lib/fontforge/libgdraw.3.0.0.dylib - /sw/lib/fontforge/libgdraw. 3.dylib 4.0.0) If this is a private library, add '!/sw/lib/fontforge/libgdraw. 3.0.0.dylib' to the Shlibs field. Error: package contains a dylib with no corresponding Shlibs entry (/ sw/lib/fontforge/libgunicode.3.0.0.dylib - /sw/lib/fontforge/ libgunicode.3.dylib 4.0.0) If this is a private library, add '!/sw/lib/fontforge/ libgunicode.3.0.0.dylib' to the Shlibs field. Error: package contains a dylib with no corresponding Shlibs entry (/ sw/lib/fontforge/libgutils.1.0.0.dylib - /sw/lib/fontforge/libgutils. 1.dylib 2.0.0) If this is a private library, add '!/sw/lib/fontforge/ libgutils.1.0.0.dylib' to the Shlibs field. This is even after adding those lines (with no whitespace in front) so I'm still missing something. Guess I need to dig into the validator more. Daniel smime.p7s Description: S/MIME cryptographic signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] validation question
On Jan 13, 2008, at 7:30 PM, Daniel Johnson wrote:
On Jan 13, 2008, at 7:09 PM, Koen van der Drift wrote:
On Jan 13, 2008, at 6:59 PM, Daniel Johnson wrote:
But why does it work in octave which only BuildDepends on fink =
0.27.9, instead of fink = 0.27.99. Since now I get the following
error:
Error: private-library entry in Shlibs requires declaring a
BuildDepends on fink (= 0.27.99) or higher.
It only works if you change it to 0.27.99 or later, but since no
such version has been released you can't actually use it in a
public info file.
Now I'm confused, since octave.info has BuildDepends: fink (=
0.27.9), not BuildDepends: fink (= 0.27.99).
Ah, never mind, it still fails the validation ;-)
- Koen.
Yeah, like I said, octave.info CAN'T use 0.27.99 since no such fink
version has been released. :) If it did, only people using fink HEAD
could build octave.
But I'm still having a problem:
Validating .deb dir /sw/src/fink.build/root-fontforge-20080110-101...
Error: package contains a dylib with no corresponding Shlibs entry (/
sw/lib/fontforge/libfontforge.1.0.0.dylib - /sw/lib/fontforge/
libfontforge.1.dylib 2.0.0)
If this is a private library, add '!/sw/lib/fontforge/
libfontforge.1.0.0.dylib' to the Shlibs field.
Error: package contains a dylib with no corresponding Shlibs entry (/
sw/lib/fontforge/libgdraw.3.0.0.dylib - /sw/lib/fontforge/libgdraw.
3.dylib 4.0.0)
If this is a private library, add '!/sw/lib/fontforge/libgdraw.
3.0.0.dylib' to the Shlibs field.
Error: package contains a dylib with no corresponding Shlibs entry (/
sw/lib/fontforge/libgunicode.3.0.0.dylib - /sw/lib/fontforge/
libgunicode.3.dylib 4.0.0)
If this is a private library, add '!/sw/lib/fontforge/
libgunicode.3.0.0.dylib' to the Shlibs field.
Error: package contains a dylib with no corresponding Shlibs entry (/
sw/lib/fontforge/libgutils.1.0.0.dylib - /sw/lib/fontforge/
libgutils.1.dylib 2.0.0)
If this is a private library, add '!/sw/lib/fontforge/
libgutils.1.0.0.dylib' to the Shlibs field.
This is even after adding those lines (with no whitespace in front)
so I'm still missing something. Guess I need to dig into the
validator more.
OK, the validator is buggy. This is the code that prints the error:
for my $dylib (@installed_dylibs) {
next if (-l $destdir . $dylib);
if (defined $otool) {
my $dylib_temp = resolve_rooted_symlink($destdir,
$dylib);
if (not defined $dylib_temp) {
print Warning: unable to resolve symlink for
$dylib.\n;
} else {
$dylib_temp =~ s/\'/\\\'/gs;
if (open (OTOOL, $otool -L '$dylib_temp' |)) {
OTOOL; # skip first line
my ($libname, $compat_version) = OTOOL =~ /^\s*(\S+)\s*\
(compatibility version ([\d\.]+)/;
close (OTOOL);
if (not exists $deb_shlibs-{$libname})
{
print Error: package contains a dylib with no corresponding
Shlibs entry ($dylib - $libname $compat_version)\n;
printIf this is a private library, add '!$dylib' to the
Shlibs field.\n;
$looks_good = 0;
}
}
}
}
}
It doesn't actually check if private libraries are specified. So
that's two private-shlibs bugs. :)
Daniel
smime.p7s
Description: S/MIME cryptographic signature
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] validation question
On Jan 13, 2008, at 8:09 PM, Daniel Johnson wrote:
It doesn't actually check if private libraries are specified. So
that's two private-shlibs bugs. :)
The whitespace bug is fixed in HEAD now, but the deb file validator is
still having problems. I think this patch might fix it:
Index: perlmod/Fink/Validation.pm
===
RCS file: /cvsroot/fink/fink/perlmod/Fink/Validation.pm,v
retrieving revision 1.277
diff -u -r1.277 Validation.pm
--- perlmod/Fink/Validation.pm 14 Jan 2008 06:02:23 - 1.277
+++ perlmod/Fink/Validation.pm 14 Jan 2008 14:52:41 -
@@ -1905,7 +1905,7 @@
my ($libname, $compat_version) = OTOOL =~ /^\s*(\S+)\s*\
(compatibility version ([\d\.]+)/;
close (OTOOL);
- if (not exists $deb_shlibs-{$libname})
{
+ if (not exists $deb_shlibs-{$libname} || not $deb_shlibs-
{$dylib}-{'is_private'}) {
print Error: package contains a dylib with no corresponding
Shlibs entry ($dylib - $libname $compat_version)\n;
printIf this is a private library, add '!$dylib' to
the Shlibs field.\n;
$looks_good = 0;
Daniel
smime.p7s
Description: S/MIME cryptographic signature
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fontforge-20080203-1 failed
On Feb 7, 2008, at 9:01 PM, Pierre-Henri Lavigne wrote: Oucha, my mistake. Everything fine now. I removed the libungif deprecated package, re- performed a fink update-all command and it seems ok about fontforge. Thanks for your suggestions, I updated the package to no longer depend on libungif. There's no reason to not use giflib now anyway. Inertia is a powerful force. ;) Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] Anyone built curl 7.18.0-1 on Tiger?
Has anyone built curl 7.18.0-1 on Tiger? I have a user whose build is failing in an odd way and I can't duplicate it on Leopard. The build progresses normally and no warnings or errors are reported, but then it just stops in the middle with 'execution of make failed, exit code 2' but no indication of why make failed. This is with both /usr/bin/ make and /sw/bin/make. Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] ghostscript 8.61-3 oddities
On Mar 21, 2008, at 6:25 PM, Jens Noeckel wrote: On Mar 21, 2008, at 3:17 PM, Alexander Hansen wrote: On Mar 21, 2008, at 5:31 PM, Jack Howarth wrote: Does anyone know why when installing ghostscript 8.61-3 in fink 10.5 unstable, the following dpkg warnings appear? Preparing to replace ghostscript 8.61-3 (using .../ ghostscript_8.61-4_darwin-i386.deb) ... Unpacking replacement ghostscript ... dpkg: warning - unable to delete old file `/usr/share/cups/model': Directory not empty dpkg: warning - unable to delete old file `/usr/share/cups': Directory not empty dpkg: warning - unable to delete old file `/usr/share': Directory not empty dpkg: warning - unable to delete old file `/usr/libexec/cups/ filter': Directory not empty dpkg: warning - unable to delete old file `/usr/libexec/cups': Directory not empty dpkg: warning - unable to delete old file `/usr/libexec': Directory not empty dpkg: warning - unable to delete old file `/usr': Directory not empty dpkg: warning - unable to delete old file `/private/etc/cups': Directory not empty dpkg: warning - unable to delete old file `/private/etc': Directory not empty dpkg: warning - unable to delete old file `/private': Directory not empty I don't recall ever seeing anything like that before. Jack Actually this is from installing 8.61-4 over in place of 8.61-3. 8.61-3 installed files outside of the Fink tree--though I would have thought the validator would have caught that: $ dpkg -L ghostscript | grep -v \/sw\/ /. /private /private/etc /private/etc/cups /private/etc/cups/pstoraster.convs /sw /usr /usr/libexec /usr/libexec/cups /usr/libexec/cups/filter /usr/libexec/cups/filter/pstopxl /usr/libexec/cups/filter/pstoraster /usr/share /usr/share/cups /usr/share/cups/model /usr/share/cups/model/pxlcolor.ppd /usr/share/cups/model/pxlmono.ppd 8.61-4 disables cups support so as not to install these files, and dpkg is just warning you that it isn't going to delete files and directories that aren't empty because you have stuff there. Hi, sorry about that - it's a side effect of a mistake I made in the previous revisions of ghostscript 8.61, where a few (trivial) files slipped through and got installed outside of /sw, exactly in the directories you list: /private/etc/cups /usr/libexec/cups/filter /usr/share/cups/model These are now being removed when ghostscript is updated. Ghostscript thinks it needs to install these files in order to tie itself into the CUPS printing system. This capability didn't exist in earlier versions, and I overlooked that this new feature had been made the default in version 8.61, and required a configure flag to _disable_ it. That was the mistake I'm reverting in this revision 8.61-4. If there's another way of doing this without causing those warning messages, that would be great - I don't want to cause alarm, but the fact is that I let this slip through and thought this is the best way to fix the fink policy violation. So with this revision, CUPS printing is disabled, as it has been for all previous versions all along. In a future version, one could instead enable CUPS printing with a post-install script that the user could run by hand. Or maybe the devels could give me permission to write files into those CUPS directories so that I don't have to make it so complicated to install CUPS support? I don't feel strongly either way, but do apologize if this hickup is causing trouble. Jens Take a look at the ghostcript-esp package. ESP GhostScript's CUPS support was rolled into standard GS so perhaps you can adopt the same solution. It uses a custom tool called 'finkcups' which users can run to install the files into /usr. Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Fink not understanding private Shlib declaration
On Apr 7, 2008, at 7:16 PM, Trevor Harmon wrote: I'm testing a new version of the lpsolve-java package, but it's not validating because it includes a private library without a Shlibs declaration. Obviously, the fix is to add the Shlib declaration, but for some reason it's not working. What I've added looks like this: Shlibs: !%p/lib/liblpsolve55j.jnilib But I still get this error with -m --build-as-nobody: Error: package contains a dylib with no corresponding Shlibs entry (/ sw/lib/liblpsolve55j.jnilib - liblpsolve55j.jnilib 5.5.0) If this is a private library, add '!/sw/lib/ liblpsolve55j.jnilib' to the Shlibs field. I don't see anything wrong with the Shlibs field I added. Have I discovered a bug in Fink? It is indeed a bug, which I've previously reported. The problem is that the validator is checking the library's install_name but telling you to use the actual pathname in the error message. These are not necessarily the same thing. So basically, fink is telling you to do one thing, but actually wants something else and you have to read its mind (or source code) to know that. :) Do an 'otool -L /sw/lib/liblpsolve55j.jnilib' to get the install_name (the first listed pathname) and use that for the Shlibs field. Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Fink not understanding private Shlib declaration
On Apr 8, 2008, at 12:03 AM, Daniel Macks wrote: On Mon, Apr 07, 2008 at 08:15:35PM -0400, Daniel Johnson wrote: On Apr 7, 2008, at 7:16 PM, Trevor Harmon wrote: I'm testing a new version of the lpsolve-java package, but it's not validating because it includes a private library without a Shlibs declaration. Obviously, the fix is to add the Shlib declaration, but for some reason it's not working. What I've added looks like this: Shlibs: !%p/lib/liblpsolve55j.jnilib But I still get this error with -m --build-as-nobody: Error: package contains a dylib with no corresponding Shlibs entry (/ sw/lib/liblpsolve55j.jnilib - liblpsolve55j.jnilib 5.5.0) If this is a private library, add '!/sw/lib/ liblpsolve55j.jnilib' to the Shlibs field. I don't see anything wrong with the Shlibs field I added. Have I discovered a bug in Fink? It is indeed a bug, which I've previously reported. The problem is that the validator is checking the library's install_name but telling you to use the actual pathname in the error message. These are not necessarily the same thing. So basically, fink is telling you to do one thing, but actually wants something else and you have to read its mind (or source code) to know that. :) I think I fixed this bug in fink CVS HEAD a few weeks ago. I mean, I know I *tried* to fix it, I *think* I succeeded. Oooh, yes, this seems fixed in CVS. I missed that. We could use a new fink release, especially since I don't think the current version recognizes the latest kernel version. Thanks. Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Install GNUPLOT, Mac OSX 10.5.2 PowerPC
On May 30, 2008, at 10:49 AM, Alexander Hansen wrote: On May 29, 2008, at 11:41 AM, Raeanne Napoleon wrote: Received the following error when installing gnuplot on MAC OSX 10.5.2 Power PC: Making all in tutorial dyld: Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /sw/lib/libgd.2.dylib Reason: Incompatible library version: libgd.2.dylib requires version 27.0.0 or later, but libpng12.0.dylib provides version 25.0.0 /bin/sh: line 1: 97908 Trace/BPT trap ../src/gnuplot eg1.plt make[2]: *** [eg1.tex] Error 133 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ### execution of make failed, exit code 2 Removing runtime build-lock... Removing build-lock package... /sw/bin/dpkg-lockwait -r fink-buildlock-gnuplot-4.0.0-1005 (Reading database ... 40461 files and directories currently installed.) Removing fink-buildlock-gnuplot-4.0.0-1005 ... Failed: phase compiling: gnuplot-4.0.0-1005 failed Ran fink selfupdate, and then fink update-all and received same error. I have no idea what to do next. Thanks for any suggestions. Following up: I got bit by a version of this bug today. I'm not 100% sure, but it looks like one of the X11 updates downgraded the compatibility version of libpng12.0.dylib (which is generally not a good thing ever to do). You're going to want to rebuild gd2-shlibs. The latest X11 package from macosforge has libpng version 27.0.0 but 10.5.3 has 25.0.0. So if you previously installed the macosforge package and then updated to 10.5.3, libpng (and other things) will get downgraded. You must reinstall X11-2.2.1.pkg after updating. In fact, once you've installed X11 from macosforge, you should always reinstall it after any system upgrade since the version Apple includes is not quite the latest. One of the penalties of using the latest and greatest. :) Daniel smime.p7s Description: S/MIME cryptographic signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
On Jun 24, 2008, at 4:50 AM, Martin Costabel wrote: Max Horn wrote: [] So, the missing symlink is indeed back (i.e. Apple has fixed the bug on its part), but libtool is translating a -lXrandr to an explicit /usr/X11/lib/libXrandr.2.0.0.dylib. I have not yet discovered why it does that, though *sigh*. Usually libtool takes what it finds in the corresponding *.la file. That was always the origin of the problem, that libXrandr.la had a last entry in its library_names line (which is what libtool uses) which did not correspond to the really existing files or symlinks. I have the suspicion that someone at Apple's is doing these symlinks in /usr/X11/lib by hand. Pogma says they are created by Apple's in-house version of gnu libtool, but they are so weird and useless - except for causing occasional linker crashes - that I find it hard to believe that they are created by an automatic and deterministic tool. I just checked the 10.5.3 combo updater and while it installs new libxrandr.2.1.0.dylib and libxrandr.2.dylib, it does NOT install a new libxrandr.la file. So the .la file still points to libxrandr. 2.0.0.dylib. Now the update SHOULDN'T delete libxrandr.2.0.0.dylib (I still have mine) but apparently Max's went away somewhere. As long as that file is still there, things will (accidentally) work. But that .la file really SHOULD be updated, and it's a bug that it isn't. If you install the X11 package from macosforge, it does update it to use 2.1.0. The simplest fix is to recreate the libxrandr.2.0.0.dylib symlink to point to libxrandr.2.dylib. Incidentally, it's a feature that libtool uses /usr/X11/lib/libXrandr. 2.0.0.dylib explicitly, not a bug. Each .la file belongs to a specific library version, so that multiple versions can coexist on the system. Apple just neglected to update the file when they updated the library. Daniel smime.p7s Description: S/MIME cryptographic signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] pangocairo: Error building gtk+2-2.12.10-1
On Jun 24, 2008, at 12:55 PM, Martin Costabel wrote: Daniel Johnson wrote: [] I just checked the 10.5.3 combo updater and while it installs new libxrandr.2.1.0.dylib and libxrandr.2.dylib, it does NOT install a new libxrandr.la file. So the .la file still points to libxrandr. 2.0.0.dylib. Now the update SHOULDN'T delete libxrandr.2.0.0.dylib (I still have mine) but apparently Max's went away No, the problem is with machines that came with 10.5.2 preinstalled. They don't have the 2.0.0 symlink. I can no longer verify this, because on the only machine I have that came with 10.5.2 preinstalled I did various xquartz updates thatt change these files too. Ah yes, I hadn't taken into account that pre-installed 10.5.2 did this. So, even more of a bug on Apple's part since X11 is very broken on such systems and upgrading to 10.5.3 won't help. Apple's really screwed up X11 on Leopard. :( The only way to be sure you have a complete X11 is to install the macosforge package, which causes other issues. somewhere. As long as that file is still there, things will (accidentally) work. But that .la file really SHOULD be updated, and it's a bug that it isn't. If you install the X11 package from macosforge, it does update it to use 2.1.0. The simplest fix is to recreate the libxrandr.2.0.0.dylib symlink to point to libxrandr.2.dylib. Incidentally, it's a feature that libtool uses /usr/X11/lib/ libXrandr.2.0.0.dylib explicitly, not a bug. Each .la file belongs to a specific library version, so that multiple versions can coexist on the system. Apple just neglected to update the file when they updated the library. That's exactly what Apple got backwards. They put the real file into libXrandr.2.dylib, whatever its minor version, and they create symlinks (often several of them) with fake minor version numbers that all point to the same file. This does not make sense. No argument. Anyway, multiple coexisting versions of a dylib only make sense if they have different install_names, otherwise they won't be found by their respective executables. And this is never the case, neither with Apple's variant nor with the standard gnu libtool variant of the symlinking game. The only thing that you can have with the gnu libtool variant is several different coexisting compatibility_versions of the same dylib with the same install_name. With Apple's variant you can't even have this. Apple's way: - install_name=libfoo.X.dylib, - real file libfoo.X.dylib, - symlinks libfoo.X.y.z.dylib and libfoo.X.a.b.dylib, - both pointing to libfoo.X.dylib Gnu libtool's way: - install_name=libfoo.X.dylib, - real files libfoo.X.y.z.dylib and libfoo.X.a.b.dylib, - one symlink either pointing to libfoo.X.y.z.dylib or to libfoo.X.a.b.dylib. In addition, both have the compile-time symlink libfoo.dylib that points to the install_name. And that's what IMHO libtool should use in any case. Yes, it's backwards, but libtool is still doing what it thinks is right. I believe that the X.y.z naming convention is a holdover from Linux, which doesn't have the concept of compatibility_version. Libtool 2 simplifies lib naming on OS X but isn't widely adopted yet. In any case, libtool can't know that the system is being abused. Despite its complexity, libtool has not yet achieved sentience. :) I wonder if it's actually the xorg build system that is at fault here rather than Apple. The macosforge package does the same thing. Of course, if Apple had just included the updated .la file this wouldn't be an issue. In any case, the results are headaches for Fink users/ maintainers. Thanks Apple! Daniel smime.p7s Description: S/MIME cryptographic signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] svn 1.5.0 packages
I have a set of svn 1.5.0 packages available for testing in my experimental cvs directory (experimental/danielj/svn). They validate, build, and pass their self tests with the exception of one test in svn- javahl that fails when built as root. I've only used svn-client, which seems to work fine. One dylib in svn-shlibs has changed its name from libsvn_ra_dav-1.0.0.0.dylib to libsvn_ra_neon-1.0.0.0.dylib. I think it's only used internally, but if some other package links to it we'll need a new package with a separate lib dir. So that's why this is experimental. :) I'd appreciate any feedback. Daniel smime.p7s Description: S/MIME cryptographic signature - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] libcurl4.info needs a BuildDepends: libiconv-dev
On Sep 20, 2008, at 10:35 AM, James Bunton wrote: Subject says it all. libiconv-dev seems to be needed for libcurl4 to build. I'll add libiconv-dev to BuildDepends. Are you using 10.4 by any chance? Daniel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Shlibs validation failures with new ode package
On Jan 24, 2009, at 4:29 PM, Trevor Harmon wrote: Hi, I'm the maintainer of the ode package, which has had a history of problems related to shlibs [1]. Luckily, ode now uses libtool, and it also fixes a problem that was preventing successful builds on Leopard, so I thought I'd hit two birds with one stone and upgrade Fink's package for ode to the latest upstream. I've now got a version that's mostly working, but it gives me validation errors related to shlibs, and I'm not sure how to fix them. Validating ode-shlibs gives: Error: Shlibs field specifies file '/sw/lib/libode.1.dylib', but it does not exist! And validating ode gives: Error: package contains the shared library /sw/lib/libode.1.0.0.dylib but the corresponding install_name and compatibility_version %p/lib/libode.1.dylib 2.0.0 are not listed in the Shlibs field. See the packaging manual. On a manual installation of ode, running otool -L on the dylib gives: /opt/ode/lib/libode.dylib: /opt/ode/lib/libode.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Everything looks right in my .info, so I don't know how to fix these errors. I've attached the .info I've created, so maybe somebody can spot my mistake. Thanks, Trevor There are a couple of problems here. You have too many packages. There only needs to be a -dev and a -shlibs package. The unnecessary ode package only contains 2 files: libode.1.0.0.dylib, which needs to be in ode-shlibs and libode.la, which needs to go in ode-dev. It's because libode.1.0.0.dylib isn't in ode-shlibs that you're getting that validator error, since it's the actual shared lib: libode.1.dylib is just a symlink to it. Daniel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Shlibs validation failures with new ode package
On Jan 24, 2009, at 7:33 PM, Trevor Harmon wrote: On Jan 24, 2009, at 5:54 PM, Daniel Johnson wrote: There are a couple of problems here. You have too many packages. There only needs to be a -dev and a -shlibs package. The unnecessary ode package only contains 2 files: libode.1.0.0.dylib, which needs to be in ode-shlibs and libode.la, which needs to go in ode-dev. It's because libode.1.0.0.dylib isn't in ode-shlibs that you're getting that validator error, since it's the actual shared lib: libode.1.dylib is just a symlink to it. Okay, I was able to get the packages to validate. However, I had to remove libode.dylib from the shlibs because I was getting a validation error: Error: Files with names less specifically versioned than ones in public Shlibs entries do not belong in this package Offending file: /sw/lib/libode.dylib I simply removed libode.dylib from the shlibs split off, but I don't think that's right because now there's only libode.1.0.0.dylib and libode.1.dylib. Shouldn't there be a libode.dylib somewhere as well? Also, regarding the unnecessary ode package... How do I address this? I don't know how to remove it without also removing the split offs. Thanks, Trevor libode.dylib needs to go in the dev package, not shlibs. It appears that nothing currently depends on ode, yes? If so, I'd suggest removing the ode-dev splitoff entirely, leaving all the dev files in the main ode package. Make it BuildDependsOnly: true and leave the ode- shlibs package as is and everything should work. Generally fink packages use the libfoo, libfoo-shlibs nomenclature. You only create a libfoo-dev splitoff if the main package contains user binaries. Daniel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] svn / ssl problem
On Mar 6, 2009, at 10:38 AM, Damian Dimmich wrote: Hi, The latest subversion seems to be suffering from a library mismatch issue wrt ssl: svn up throws the following when trying to update over webdav/https. SSL negotiation failed: SSL disabled due to library version mismatch I've read that this can be an issue when neon is compiled against a different ssl library than svn. Having removed a stale neon26-shlibs, and rebuilt the neon27 and neon27-shlibs package(s) I spotted that neon27 used the system ssl libraries. From the compile flags it looks like subversion is also using ssl from /sw, although: otool -L /sw/bin/svn /sw/bin/svn: /sw/lib/svn15/libsvn_client-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/svn15/libsvn_wc-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/svn15/libsvn_ra-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/svn15/libsvn_diff-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/svn15/libsvn_delta-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/svn15/libsvn_subr-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libapr.0.dylib (compatibility version 4.0.0, current version 4.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) /sw/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) doesn't really say much :/ otool -L /sw/lib/libneon.27.dylib /sw/lib/libneon.27.dylib: /sw/lib/libneon.27.dylib (compatibility version 29.0.0, current version 29.4.0) /sw/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) /sw/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /sw/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 25.0.2) /sw/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.32.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) shows that the libraries from /sw/lib are being used. Have rebuilt/reinstalled both packages with no joy. Any suggestions? This is fixed in neon27 0.28.4-2. Daniel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-beginners] Pine-ssl
On Apr 20, 2009, at 1:53 PM, Alexander Hansen wrote: Herb Wright wrote: Im trying to install pine-ssl and am getting the following errors: The LDAP library ldap/libraries/libldap.a is missing. ### execution of /var/tmp/tmp.2.iXzwoI failed, exit code 30 Removing runtime build-lock... Removing build-lock package... /sw/bin/dpkg-lockwait -r fink-buildlock-pine-ssl-4.64-1003 (Reading database ... 132167 files and directories currently installed.) Removing fink-buildlock-pine-ssl-4.64-1003 ... Failed: phase compiling: pine-ssl-4.64-1003 failed Thanks, Herb Wright Contractor Desktop Group NCBI/NLM/NIH wrigh...@ncbi.nlm.nih.gov Let's not crosspost: one Fink list per thread is sufficient. It's usually helpful to provide some context before the error: ... make args are CC=cc 'SSLCERTS=/sw/etc/ssl' 'SSLINCLUDE=/sw/include/openssl' 'SSLLIB=/sw/lib' 'EXTRACFLAGS=-I/sw/include' 'EXTRALDFLAGS=-L/sw/lib' 'DEBUG=-g -O2 -DDEBUG' 'LDAPLIBS=../ldap/libraries/libldap.a ../ldap/libraries/liblber.a -L/sw/lib -lsasl2' osx The LDAP library ldap/libraries/libldap.a is missing. ... And, indeed there isn't any reference to ldap in the pine tarball other than contrib/ldap-setup You might try alpine (available through Fink), which is the successor to pine. It doesn't look like pine is buildable anymore. It does depend on openldap23, but it tries to link to static libs instead of shared libs and openldap* no longer builds static libs. Its build system is bizarre and complex so I'm not sure how to tell it to use the shared libs instead. Using alpine would make more sense than trying to fix pine. Daniel smime.p7s Description: S/MIME cryptographic signature -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] perltidy and perl-tidy-pm conflict
On May 10, 2009, at 2:18 PM, Matthew Berginski wrote: The perltidy package the perl module as well as the stand alone script, so the entries do appear to cover the same material. I don't see any reason why they can't be merged and the lines suggested added to perltidy.info. Matt On Sun, May 10, 2009 at 9:12 AM, Steve Huff sh...@vecna.org wrote: hello folks! as best i can tell, these two modules are duplicates. if i'm missing something obvious, please let me know :) the only package i've found that depends on perl-tidy-pm is perl- critic-pm*, and i've been able to work around the problem by adding Provides: perl-tidy-pm Conflicts: perl-tidy-pm Obsoletes: perl-tidy-pm Replaces: perl-tidy-pm to perltidy.info. Yeah, this makes sense since perltidy is newer than perl-tidy-pm. I updated perl-critic-pm to use perltidy and added the conflicts/ replaces of the two perl tidys to allow for the change. Daniel smime.p7s Description: S/MIME cryptographic signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Fetching fink binaries from different architectures
On Jun 14, 2009, at 10:45 AM, Ebrahim Mayat wrote: On Sunday, June 14, 2009, at 06:55AM, Monic Polynomial moni...@gmx.com wrote: I'm clueless about building universal libraries. That said, the following describes how to obtain and extract binary packages. You may download Fink's binary packages for 10.5 stable from http://bindist.finkmirrors.net/bindist/dists/10.5/ You may extract the contents of a .deb file with dpkg-deb: dpkg-deb --extract package.deb destinationdirectory Warning: the instructions below use *unofficial* binary distributions that are not supported by the Fink project itself. Todai's binary packages for 10.5 i386 unstable are available in http://fink.sodan.ecc.u-tokyo.ac.jp/apt/10.5/dists/unstable/main/binary-darwin-i386/ Todai doesn't build x86_64 binary packages yet. Scott does but his selection of binary packages are mostly for scientific computing and he hasn't provided a libsndfile1-shlibs binary package. Warning: the instructions above use *unofficial* binary distributions that are not supported by the Fink project itself. Many thanks Monic for the URLs. For building universal binaries of command-line programs you could try using CFLAGS= -arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk --host=i386-apple-darwinx.x.x --disable-dependency- tracking You also need to set LDFLAGS=-arch ppc -arch i386 -Wl,syslibroot,/ Developer/SDKs/MacOSX10.4u.sdk Note that this will work for most autotools-using packages, but not all. If a package doesn't use autotools, all bets are off. Daniel smime.p7s Description: S/MIME cryptographic signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] graphviz-nox prospects
On Jun 22, 2009, at 4:36 AM, Daniel Macks wrote: On Sun, Jun 21, 2009 at 04:58:56PM -0400, David Fang wrote: Hi all, After sensing a disturbance in the Source (reading my emails), I've gathered that several people (myself included) find the current graphviz package a little dependence-heavy. I'm considering writing a Type: -nox variant, which I might need a little guidance with. I'm armed with the packaging manual and some examples (emacs22.info, vim.info). I need a little advice on which dependencies I can drop for -nox. For example, can I remove all of the gnome, gtk, pango, cairo deps? Many of the upper-level gnome dependencies can probably be removed, period, even in a fully-gui-enabled package. They appear to be unused by graphviz itself, and were probably only needed via inheritance from older versions of some dependency. By setting the current (unstable) versions of the dependencies, you can eliminate all the packages related to avahi, bonobo, bonoboui, gnome-vfs, gnome-keyring, libgnome, libgnomecanvas, libgnomeui, libart2, popt. You can also simplify the ConfigureParams: don't need any FREETYPE2_*, and don't need the pango-ft219 or freetype219 components in PKG_CONFIG_PATH. Unrelated dependency bug: configure autodetects the gts/gts-shlibs and lasi-dev/lasi-shlibs packages, so need to add dependencies on them or force them to be ignored. Also detection of ghostscript (iapi.h and -lgs) and DevIL fail because those libs aren't in fink *right now*, but for sanity should still disable detection in case they ever do get into fink. Actually, libdevil1 is in fink unstable. Daniel smime.p7s Description: S/MIME cryptographic signature -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] openssl dependencies?
On Jul 20, 2009, at 4:39 PM, Robert Wyatt wrote: Daniel Macks wrote: On Mon, Jul 20, 2009 at 12:28:30PM -0500, Robert Wyatt wrote: Robert T Wyatt wrote: In trying to install pine-ssl in unstable: I'm not sure what's going on, but I think it might have to do with what seems to me like a catch-22: openssl097: Depends: openssl (= 0.9.7m-5) openssl conflicts with openssl097, but openssl097 is installed Now that I've gotten some sleep and some coffee, it occurs to me that I have a vague recollection that pine-ssl is not necessary. So while this discussion may be moot, it may time to remove pine-ssl from the PDB (if anyone has a better memory about this, please feel free to chime in). I'll have to dig around and see if I can find the relevant correspondence from I don't know how long ago. pine was superceded by alpine upstream. Maybe time to replace pine and pine-ssl (both presently unmaintaind) with pointers to alpine (which is maintained)? The *pine builds are scary-nonstandard...no reason to keep obsolete stuff that is difficult to understand and build. dan Thanks Dan, for what it's worth I just built and installed alpine with practically no problems on a Quad PPC and on an i386 MacBookPro (both running 10.5.7). They are both working like a charm! I'll try with a 10.4 machine this evening. On the PPC, I did have to fink remove libgettext3-dev (a build conflict) because there are no .debs to restore from and then used sudo apt-get install alpine=2.00-1 to resolve the inconsistent dependency. Besides this, both installations are functioning very well. Just for reference, the reason pine-ssl doesn't build is that its bizarre build system is hard-coded to link to libldap.a instead of - lldap for some inexplicable reason. openldap23 hasn't built a static library for some time and therefore pine-ssl won't build without extensive patching. It should definitely be removed. Daniel smime.p7s Description: S/MIME cryptographic signature -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] mirrors
On Jul 25, 2009, at 9:51 AM, Robert Wyatt wrote: The auto-logs are showing that no cvs changes after moose was submitted have been picked up, so changes to kdesvn-kde4 (-mac and -x11), scilab, libtelepathy and telepathy-missioncontrol are not reflected on the mirrors. - fetching files for moose-pm.info (10.4/unstable) - Moose-0.88.tar.gz... /var/www/distfiles/md5/a9842e4bdf2ffceef7990d1edf14d033/ Moose-0.88.tar.gz does not exist, downloading downloading I don't think the problem is with moose.info, but I don't know where the problem lies. From the cvs changes for moose: Source: mirror:cpan:authors/id/D/DR/DROLSKY/Moose-%v.tar.gz -Source-MD5: 4cb9069378a8a7cece7960953ec37ccb +Source-MD5: a9842e4bdf2ffceef7990d1edf14d033 MD5 (/Users/robertwyatt/Downloads/Moose-0.88.tar.gz) = a9842e4bdf2ffceef7990d1edf14d033 Here's where the source lives: http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Moose-0.88.tar.gz which apparently redirects to: http://www.perl.com/CPAN/authors/id/D/DR/DROLSKY/Moose-0.88.tar.gz I think the issue is that Moose hasn't propagated to all the CPAN mirrors yet, and Fink's mirroring script is hanging when it tries to download from a not-updated mirror. Daniel smime.p7s Description: S/MIME cryptographic signature -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] nuking .la once and for all?
On Aug 30, 2009, at 6:20 PM, David R. Morrison wrote: On Aug 31, 2009, at 6:22 AM, Martin Costabel wrote: Jack Howarth wrote: Considering that Apple's X11 developers are recommending that we tell user to nuke their installations and rebuild everything from scratch under Snow Leopard as well as never install .la files, why don't we take this opportunity to do just that. It may cause some minor breakage in fink unstable (which should be easily fixable), but we could modify fink to automatically purge any *.la files from the packaged files in the debs created. Sure we will need to correct some info file to remove the *.la from the file list but that will be trivial. We really should embrace this opportunity to purge out *.la files from 10.6 and later releases. Is anyone aware of a large-scale test of what happens if we indeed let libtool build all those *.la files and then simply remove them, despite each one of them screaming # Please DO NOT delete this file! # It is necessary for linking the library. ? Are there situations where they are really useful or perhaps even needed? I think we could cope without .la files if we had to, provided that they were all gone. But I don't see any good reason for following those apple developer's suggestion in this case. What we might consider doing, though, is this: removing any references to non-fink-created .la files from fink-created .la files. I haven't really thought through how hard it would be, but there may be some nice incantation we could put at the end of install scripts which would do it. I've been cleaning the .la files in my library packages for a while now. I use perl -pi -e s/dependency_libs=.*$/dependency_libs=''/ %i/ lib/*.la in InstallScript, which just clears dependency_libs altogether. This is almost always safe, as long as you DON'T build static libraries. When linking to static libraries, dependency_libs is necessary since static libs don't encode where to resolve external symbols. Shared libraries DO encode this, so they don't need to link to indirect libraries. As a side benefit, You no longer need to BuildDepend on indirect dependencies, which makes it much easier when some dependency down the chain changes. So, for example, you can depend on libcurl4 or svn15 and not have to care about their dependencies. I can change (and have done so) their dependencies without breaking anything. Do note that you also need to check foo-config and/or libfoo.pc files for such dependencies too, and that can't easily be automated. Oh, and sometimes with libtool2 generated .la files you have to clean inherited_linker_flags too. Daniel smime.p7s Description: S/MIME cryptographic signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] nuking .la once and for all?
On Aug 30, 2009, at 7:23 PM, Jack Howarth wrote: On Sun, Aug 30, 2009 at 06:50:42PM -0400, Daniel Johnson wrote: I've been cleaning the .la files in my library packages for a while now. I use perl -pi -e s/dependency_libs=.*$/dependency_libs=''/ %i/ lib/*.la in InstallScript, which just clears dependency_libs altogether. This is almost always safe, as long as you DON'T build static libraries. When linking to static libraries, dependency_libs is necessary since static libs don't encode where to resolve external symbols. Shared libraries DO encode this, so they don't need to link to indirect libraries. As a side benefit, You no longer need to BuildDepend on indirect dependencies, which makes it much easier when some dependency down the chain changes. So, for example, you can depend on libcurl4 or svn15 and not have to care about their dependencies. I can change (and have done so) their dependencies without breaking anything. Do note that you also need to check foo-config and/or libfoo.pc files for such dependencies too, and that can't easily be automated. Oh, and sometimes with libtool2 generated .la files you have to clean inherited_linker_flags too. Daniel Would we really be able to survive entirely without static libraries? I would assume somethings in fink assume their presence to build. We will likely get some complaints if we remove them as I had to add them over the years to satisfy various users who wanted to create statically linked binaries via fink for redistribution. Jack Fink itself should almost never need static libs since the linker always uses a shared lib when it's available. It's actually impossible to make a truly static binary with OS X. And OS X usually works better with shared libraries since the OS can manage memory better and only load libs as they are needed, hence the shared part. Also, we can't even consider getting rid of .la files as long as we keep static libs around because libtool NEEDS that dependency info to resolve external symbols in static libs. Fink isn't designed for people to use parts of it outside of the Fink environment. If we can make that happen, fine, but we can't let that interfere with Fink itself. Just my opinion. Daniel smime.p7s Description: S/MIME cryptographic signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Fink-devel mailing list Fink-devel@lists.sourceforge.net 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.4/unstable/main/finkinfo/base zip.info, 1.1, 1.2
On Aug 30, 2009, at 9:22 PM, Daniel Macks wrote: Jack Howarth committed: Log Message: non-maintainer update to zip 3.0-1 RCS file: /cvsroot/fink/dists/10.4/unstable/main/finkinfo/base/ zip.info,v --- zip.info20 Jan 2006 20:19:36 - 1.1 +++ zip.info30 Aug 2009 22:51:58 - 1.2 -Version: 2.31 +Version: 3.0 [...] +BuildConflicts: bzip2-dev Why did you even bother asking others' opinions if you were going to ignore my explicit response to you *not* to do it that way? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks Why would it be a big deal to just depend on Fink's bzip2? It's already an Essential package so everyone will have it built anyway. BuildConflicts cause more trouble than they're worth usually, especially for something as basic as bzip2-dev. Daniel smime.p7s Description: S/MIME cryptographic signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100
On Sep 3, 2009, at 10:43 AM, Koen van der Drift wrote: A few days a go I updated module-build-pm with a new upstream version. I'd appreciate it if any of you can have another look at the package and make sure all issues have been resolved. Also, I am using a PPC and will be on 10.5, so I have no idea if there any issues on SL. Feel free to fix those if there are any. Thanks, - Koen. I was able to install module-build-pm588, module-build-pm5100 and module-build-pm on 10.6/x86_64 without issue. Daniel smime.p7s Description: S/MIME cryptographic signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libgettext package layout
On Oct 30, 2009, at 10:25 AM, Daniel Macks wrote: With a new libgettext suite in the works, I'm wondering about getting a saner package layout for this lib suite. Here's (1) the current breakdown (gettext3; older gettext appears same): gettext-doc html-format documentation about library and runtime programs gettext-bin runtime programs man-format documentation about library and runtime programs* libgettext3-dev library developer files The * is the crazy part. If we have a separate -doc component, that's where the docs should be. If we have separate library and runtime components, docs specifically for one should not be in the other. So (2) should all doc formats be in the -doc component, or (3) should the -doc component be abolished and the docs placed in the actual component (-bin or -dev) to which they relate? I think the -doc (even with added material from -bin) is on the order of 100K. Is that large enough (or docs useless enough:) that it should be offloaded from the main packages rather than being installed automatically (idea 2)? Since the lib has different versions and the major-version of -bin need not match that of the -dev installed, is it needlessly confusing to have an additional -doc that tries to unify the docs for two separate pkgs (the docs one reads may not apply to the target presently installed)? I'm thinking separate docs for independent items, and so abolishing the -dev (idea 3). Or are we best just ignoring this since inertia of things that aren't badly/visibly broken avoids having to play any games with upgrade routes, Replaces, etc. (idea 1)? I think (3) makes the most sense, but I'm fine with inertia as an excuse. :) I doubt anyone actually uses the docs. Daniel smime.p7s Description: S/MIME cryptographic signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] missing svn-dev-1.6.6?
On Nov 19, 2009, at 11:26 AM, Steve Huff wrote: On Nov 19, 2009, at 10:30 AM, Alexander Hansen wrote: Try building a package that actually exists :-) I think you mean svn-swig-pm5100. yes, that would do it facepalm anyway, i am now at last able to find the real error: ... cd subversion/bindings/swig/perl/libsvn_swig_perl /bin/sh /sw/src/fink.build/svn-swig-pm5100-1.6.6-1/subversion-1.6.6/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -L/sw/lib/system-openssl/lib -L/sw/lib-L/sw/lib -L/sw/lib -L/sw/lib -rpath /sw/lib/perl5/5.10.0/lib -o libsvn_swig_perl-1.la swigutil_pl.lo -lsvn_delta-1 -lsvn_subr-1 /sw/lib/libaprutil.la /sw/lib/libapr.la -lpthread -lintl -framework Security -framework CoreFoundation -framework CoreServices cd subversion/bindings/swig/perl/native ARCHFLAGS= /sw/bin/perl5.10.0 Makefile.PL PERL=/sw/bin/perl5.10.0 PREFIX=/sw INSTALLPRIVLIB=/sw/lib/perl5/5.10.0 INSTALLARCHLIB=/sw/lib/perl5/5.10.0/darwin-thread-multi-2level INSTALLSITELIB=/sw/lib/perl5/5.10.0 INSTALLSITEARCH=/sw/lib/perl5/5.10.0/darwin-thread-multi-2level INSTALLMAN1DIR=/sw/share/man/man1 INSTALLMAN3DIR=/sw/share/man/man3 INSTALLSITEMAN1DIR=/sw/share/man/man1 INSTALLSITEMAN3DIR=/sw/share/man/man3 INSTALLBIN=/sw/bin INSTALLSITEBIN=/sw/bin INSTALLSCRIPT=/sw/bin Writing Makefile for SVN::_Core Writing Makefile.client for SVN::_Client Writing Makefile.delta for SVN::_Delta Writing Makefile.fs for SVN::_Fs Writing Makefile.ra for SVN::_Ra Writing Makefile.repos for SVN::_Repos Writing Makefile.wc for SVN::_Wc make PERL=$PERL FULLPERL=$PERL ABSPERL=$PERL arch: Unknown architecture: powerpc make: *** [blib/lib/SVN/.exists] Error 1 ... You must be using 10.5/ppc? Yeah, it wouldn't build there. Sorry, I never tested that combination. I just committed a fix. Try again. Daniel smime.p7s Description: S/MIME cryptographic signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] build failure for libsndfile, preventing libsamplerate from working
On Nov 23, 2009, at 10:09 AM, monipol moni...@gmx.com wrote: I have been able to reproduce this build error on 10.5/x86_64, stable (version 1.0.15-1). The unstable version, 1.0.20-1, builds fine, though. Daniel: Do you think stable libsndfile1 could be updated? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] build failure for libsndfile, preventing libsamplerate from working
On Nov 23, 2009, at 10:09 AM, monipol moni...@gmx.com wrote: I have been able to reproduce this build error on 10.5/x86_64, stable (version 1.0.15-1). The unstable version, 1.0.20-1, builds fine, though. Daniel: Do you think stable libsndfile1 could be updated? Grr, sorry, I hit send too soon. I have no objection to moving this to stable. I can't do it until this evening (EST) so if someone wants to do it now, I'm fine with it. Daniel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] build failure for libsndfile, preventing libsamplerate from working
On Nov 23, 2009, at 11:36 AM, Richard Kettlewell wrote: monipol wrote: I have been able to reproduce this build error on 10.5/x86_64, stable (version 1.0.15-1). The unstable version, 1.0.20-1, builds fine, though. Daniel: Do you think stable libsndfile1 could be updated? libsndfile1 1.0.20-1 is now in stable. Daniel smime.p7s Description: S/MIME cryptographic signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
