[Fink-devel] Automatic build log
Todai Fink Team tried building all unstable packages automatically. You can check what package could not be built or installed here: http://fink.sodan.ecc.u-tokyo.ac.jp/build/2005-03-26/ Notes: * The most common error is insufficient BuildDepends. Especially libiconv-dev is very frequently forgot. * The list contains our experimental or private packages. Just ignore them. * Elisp packages cannot be installed because the emacs20 binary is broken. I reported it to the maintainer and am waiting for the response. --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: License for .info and .patch files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David R. Morrison wrote: | Yes, probably we should say that patches for open source projects | inherit the license. I'm kind of late into the fray here (had a short vacation), but would suggest that we notify submitters that we prefer .info and .patch files to be placed in the public domain, but that explicit licenses can be added to comments in the .info file, or the patch file, if required. The GPL is a dangerous default license, in my opinion, the default should be the easiest to copy while allowing people the option to make their files more restrictive. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQk1UA7iDAg3OZTLPAQIEbwQAp8uKLxZHNu/2enMlwhvtcGISWOfTTvdv M7R1T4QK6vgXne26Z0ixqweCGdgZYfn7BqEjzHkVRjT3PFkpzD5KDqPocVY/AoY/ F8eUkf9rc4pxSmZO0bgnYKm+oZFH7nW58ufAx5W7ZzXvGBl6ybLoRceWuKJsnIh4 ALlpZsww1cI= =pw2v -END PGP SIGNATURE- --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: License for .info and .patch files
Peter O'Gorman wrote: I'm kind of late into the fray here (had a short vacation), but would suggest that we notify submitters that we prefer .info and .patch files to be placed in the public domain, but that explicit licenses can be added to comments in the .info file, or the patch file, if required. The GPL is a dangerous default license, in my opinion, the default should be the easiest to copy while allowing people the option to make their files more restrictive. +1 I think public domain is a good idea for such things. --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] g++ ABI: new proposal
Peter O'Gorman wrote: [] I don't think that a new field is necessary, and do believe that the time available to implement any solution is very short, so I suggest that we start implementing this as soon as practical. I would like to have one point cleared up in my understanding. Let me first say that I know what the g++ ABIs mean. What I don't know is how you intend to enforce them. (I am also sorry that I will not be able to participate practically in this task for the next 4 weeks, due to circumstances out of my control - dead harddisk and travel to Australia). There is another transition for Tiger, namely from gcc-3.3 to gcc-4.0. Right now, for all existing packages, or at least those I have seen, there is a very simple equation: -fabi-version=1 == g++-3.3 -fabi-version=2 == g++-4.0 Please correct me if I am wrong. You have been enforcing g++-3.3 for a lot of packages in the 10.3 tree. Is this the way you are intending to enforce the ABI versions? So one could equate basically 10.4-transitional with g++-3.3 and 10.4 with g++-4.0? If this is the case, this would make the transition for package maintainers rather easy (or at least easy to describe): Make the package compile under gcc-4.0, using the libraries from the 10.4 tree, and they will be fit for the 10.4 tree. For the 10.4-transitional tree, one would have to enforce g++-3.3 even for those packages in the 10.3 tree (for example qt3 and scribus built with it) where the enforcement of gcc-3.3 has been removed in the meantime. Or do you have experience now with mixing packages and libraries compiled with g++-3.3 and g++-4.0 while enforcing ABI version 1 by some other means? And the same for ABI version 2? I haven't seen or tried packages compiled with g++-3.3 and -fabi-version=2 or with gcc-4.0 and -fabi-version=1. Are you sure there will be no other unpleasant surprises with these combinations? -- Martin --- 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] g++ ABI: new proposal
Martin and Jean-Francois: -fabi_version=2 is not available under gcc 3.3. What you get when you compile using gcc 4.0 and -fabi_version=1 is all of the new features of gcc 4.0 *except* the change in ABI. Libraries compiled with abi_version=1 are not compatible with libraries compiled with abi_version=2, and vice versa. The way I plan to enforce this is to have SetCXXFLAGS = -fabi_version=1 be default in the 10.3 and 10.4-transitional trees, and SetCXXFLAGS = -fabi_version=2 be default in the 10.4 tree. This will be done within PkgVersion.pm I've been testing this setup for weeks and it works well. You can mix libraries compiled under gcc 3.3 and gcc 4.0 without apparent problems, although there may be some cases in which symbols are getting mangled incorrectly. By the way, the reason the abi_version=0 is not a good idea is that then next time fsf releases a new version of gcc, the libraries become incompatible all over again. By setting abi_version=2, we control when the next upgrade is for fink packages. abi_version=0 is probably good for people testing things, but is not good for a distribution. -- Dave --- 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
