Re: [Fink-devel] fvp changes
Global $config is fine in this situation (UseFinkModules compartmentalizes the handling of some initialization, and it does export some Fink::Services functions into the main namespace). Is --apt ode fixed for this new more-detailed output in standalone mode (when /sw/lib/perl5 (or in whatever @BASEPATH@ is defined) doesn't exist? I have fink in /sw, and the finkaptstatus data looks unchanged by this patch when I move aside my /sw/lib/perl5...still has the old format not the extra fields you are adding. dan On Sat, 22 Jun 2013 19:36:40 -0600, TheSin the...@southofheaven.org wrote: Okay now it works, standalone, --apt and --dpkg all tested, hopefully declaring $config as a global isn't bad ;) - --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-22, at 7:30 PM, TheSin the...@southofheaven.org wrote: I take it back it only worked with out --apt :\ Fetched 1072 kB in 4s (222 kB/s) Can't locate Fink/Config.pm in @INC (@INC contains: /Library/Perl/5.12/darwin-th I'll keep working on this :\ --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-22, at 7:27 PM, TheSin the...@southofheaven.org wrote: okay now that I have inet back and hopefully stable, I fixed it so that I get the right arch now. Package: 64bit-cpu Status: install ok installed Priority: optional Architecture: darwin-x86_64 Version: 0-1 Maintainer: Fink Devel fink-devel@lists.sourceforge.net Description: [virtual package representing the 64bit capability of the CPU] The presence of the 64bit-cpu package indicates that the CPU on which we are running is 64bit capable. . Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage . Maintainer: Fink Devel fink-devel@lists.sourceforge.net Here is the new patch, hopefully I did it right I couldn't figure out what or why UseFinkModules() was for or did since it returns and exports nothing. If this is wrong please let me know. fvp.patch --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-21, at 11:56 PM, Daniel Macks dma...@netspace.org wrote: On Thu, 20 Jun 2013 22:11:20 -0600, TheSin the...@southofheaven.org wrote: The new apt is much more strict on the fields in status files, to get it to work I need to make a few minor changes to f-v-p, I spent lots of time working on apt 0.9.82 trying to figure out why girts weren't working and it turns out the parser was considering them invalid due to missing fields like arch and priority. So I made a quick patch which is in my pull request and i'll attach it here as well. I'd add it myself but I'm not sure which branch and if it'll affect anything else that uses f-v-p the current output looks like Package: 64bit-cpu Status: install ok installed Version: 0-1 description: [virtual package representing the 64bit capability of the CPU] I'd like to change it to look like Package: 64bit-cpu Status: install ok installed Priority: optional Architecture: all Version: 0-1 Maintainer: Fink Devel fink-devel@lists.sourceforge.net Description: [virtual package representing the 64bit capability of the CPU] The presence of the 64bit-cpu package indicates that the CPU on which we are running is 64bit capable. . Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage . Maintainer: Fink Devel fink-devel@lists.sourceforge.net This change to --apt output looks reasonable to me. I talked to TheSin in #fink yesterday, who confirmed that old apt would also accept it, so I don't see harm in sending this to master now (rather than later as part of the large apt upgrade work) (would also benefit anyone who's experimenting with new debian tools of any sort). Technical question: Is this really Architecture:all, given that it's generated by a fink that is single-arch? dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel - -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev - ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive:
Re: [Fink-devel] fvp changes
I don't believe I messed with the standalone version, though it could easily be added, my only focus was the --apt output. Since im not sure what relies on the standalone I couldn't test if it would break anything. --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-24, at 12:05 AM, Daniel Macks dma...@netspace.org wrote: Global $config is fine in this situation (UseFinkModules compartmentalizes the handling of some initialization, and it does export some Fink::Services functions into the main namespace). Is --apt ode fixed for this new more-detailed output in standalone mode (when /sw/lib/perl5 (or in whatever @BASEPATH@ is defined) doesn't exist? I have fink in /sw, and the finkaptstatus data looks unchanged by this patch when I move aside my /sw/lib/perl5...still has the old format not the extra fields you are adding. dan On Sat, 22 Jun 2013 19:36:40 -0600, TheSin the...@southofheaven.org wrote: Okay now it works, standalone, --apt and --dpkg all tested, hopefully declaring $config as a global isn't bad ;) - --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-22, at 7:30 PM, TheSin the...@southofheaven.org wrote: I take it back it only worked with out --apt :\ Fetched 1072 kB in 4s (222 kB/s) Can't locate Fink/Config.pm in @INC (@INC contains: /Library/Perl/5.12/darwin-th I'll keep working on this :\ --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-22, at 7:27 PM, TheSin the...@southofheaven.org wrote: okay now that I have inet back and hopefully stable, I fixed it so that I get the right arch now. Package: 64bit-cpu Status: install ok installed Priority: optional Architecture: darwin-x86_64 Version: 0-1 Maintainer: Fink Devel fink-devel@lists.sourceforge.net Description: [virtual package representing the 64bit capability of the CPU] The presence of the 64bit-cpu package indicates that the CPU on which we are running is 64bit capable. . Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage . Maintainer: Fink Devel fink-devel@lists.sourceforge.net Here is the new patch, hopefully I did it right I couldn't figure out what or why UseFinkModules() was for or did since it returns and exports nothing. If this is wrong please let me know. fvp.patch --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2013-06-21, at 11:56 PM, Daniel Macks dma...@netspace.org wrote: On Thu, 20 Jun 2013 22:11:20 -0600, TheSin the...@southofheaven.org wrote: The new apt is much more strict on the fields in status files, to get it to work I need to make a few minor changes to f-v-p, I spent lots of time working on apt 0.9.82 trying to figure out why girts weren't working and it turns out the parser was considering them invalid due to missing fields like arch and priority. So I made a quick patch which is in my pull request and i'll attach it here as well. I'd add it myself but I'm not sure which branch and if it'll affect anything else that uses f-v-p the current output looks like Package: 64bit-cpu Status: install ok installed Version: 0-1 description: [virtual package representing the 64bit capability of the CPU] I'd like to change it to look like Package: 64bit-cpu Status: install ok installed Priority: optional Architecture: all Version: 0-1 Maintainer: Fink Devel fink-devel@lists.sourceforge.net Description: [virtual package representing the 64bit capability of the CPU] The presence of the 64bit-cpu package indicates that the CPU on which we are running is 64bit capable. . Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage . Maintainer: Fink Devel fink-devel@lists.sourceforge.net This change to --apt output looks reasonable to me. I talked to TheSin in #fink yesterday, who confirmed that old apt would also accept it, so I don't see harm in sending this to master now (rather than later as part of the large apt upgrade work) (would also benefit anyone who's experimenting with new debian tools of any sort). Technical question: Is this really Architecture:all, given that it's generated by a fink that is single-arch? dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel -
Re: [Fink-devel] Fink's a2ps-4.14-2 fails deb validation
Hi Hanspeter: I have only the dimmest recollection of inheriting this package. In any case, uncommenting the first line of the patch script solves this problem. I have to confess I had no idea what an elc file even was (being a vi guy). I did however find out it has a missing dependency on emacs or emacs-nox, so I need to put that in first before committing. I just realized I never replied to your other email about boost/cmake/rdkit. Your changes work fine, so feel free to go ahead with it. Bill On Jun 23, 2013, at 3:51 AM, Hanspeter Niederstrasser f...@snaggledworks.com wrote: a2ps-4.14-2 on 10.7 fails validation with this error: Validating .deb dir /sw/build.build/root-a2ps-4.14-2... Error: Compiled .elc file installed. Package should install .el files, and provide a /sw/lib/emacsen-common/packages/install/package script that byte compiles them for each installed Emacs flavour. Offending file: /sw/share/emacs/site-lisp/a2ps-print.elc Offending file: /sw/share/emacs/site-lisp/a2ps.elc Hanspeter -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] readline5 and libgettext3
On 6/24/13 7:18 PM, Daniel Macks wrote: We've had some good times, and your continued existence has allowed us to migrate gradually to newer versions as time has permitted. But now, all of 10.7+ has migrated to readline6 and libgettext8, so it's time for you to die. I'll allow friends and wellwishers the next hour or so work through their grief... dan -- Daniel Macks dma...@netspace.org *SNIFF* OK, that's done. :-) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python packagers - please switch from using distribute back to setuptools
On Jun 13, 2013, at 10:09 PM, Alexander Hansen wrote: On 6/12/13 6:27 PM, Alexander Hansen wrote: On 6/12/13 6:19 PM, Kurt Schwehr wrote: Yup. Suggestions on a solution? On Jun 12, 2013, at 6:13 PM, Daniel Johnson daniel.johnso...@gmail.com wrote: On Jun 12, 2013, at 11:15 AM, Kurt Schwehr kurtschw...@yahoo.com wrote: The author of distribute merged distribute back into setuptools 0.7 and took over as lead of setuptools. Please convert python packages that use distribute back to setuptools. Just committed setuptools 0.7.2 to 10.[78] and 10.[56]. https://pypi.python.org/pypi/setuptools/0.7.2#id3 https://bitbucket.org/pypa/setuptools/src/tip/docs/merge.txt This is causing a bit of a dependency problem. Some packages Depend on distribute-py rather than just BuildDepend, such as my modernize-py. Since setuptools and distribute are mutually exclusive, I now can't install setuptools at all without removing modernize first. I can update modernize to use setuptools but the already-installed version prevents the update from happening since distribute has to be uninstalled first, which causes a dependency loop. Daniel If the new setuptools is drop-in compatible with our current distribute, then how about making a dummy upgrade distribute which Depends on setuptools (= 0.7.2)? I found something which looks like it works. The gist is: 1) Make distribute a real package again but have it really be setuptools-0.7.2. This has the following: Conflicts: setuptools-py%type_pkg[python] ( 0.7.2-3) Replaces: setuptools-py%type_pkg[python] Provides: setuptools-py%type_pkg[python] The unversioned Replaces: will allow it to replace setuptools (= 0.7.2-3) without removing the package entry, and the Provides: keeps current users of setuptools (via the prior Provides from the old distribute) happy. 2) Do the following in setuptools: Conflicts: distribute-py%type_pkg[python] ( 0.7.2-3) Replaces: distribute-py%type_pkg[python] Provides: distribute-py%type_pkg[python] This allows folks who update distribute automatically to get setuptools (under the distribute label) without any nasty dependency hell. Then, if setuptools is updated and installed, it overwrites the overlapping files from distribute with identical ones, but does _not_ remove the distribute package (since there is no Conflict), so packages with dependencies on it are happy. It's not a complete solution, probably, but at least we can tell users to update distribute first. .infos attached. This has been sitting on my TODO list, but now it looks like there is a setuptools-tng-py*? I can hold off on upgrading my .info files if this is still being worked out, but if not... Kurt: looks like nose-py is still depending on the non-tng setuptools in the 10.7 tree. (I was being lazy and trying a 'fink remove setuptools-py*' to see what dependencies broke. Haven't checked for others.) -- Charles Lepple clepple@gmail -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] python packagers - please switch from using distribute back to setuptools
nose-py.info in 10.[78] now depends on setuptools-tng. -kurt On Jun 24, 2013, at 10:25 PM, Charles Lepple clep...@gmail.com wrote: On Jun 13, 2013, at 10:09 PM, Alexander Hansen wrote: On 6/12/13 6:27 PM, Alexander Hansen wrote: On 6/12/13 6:19 PM, Kurt Schwehr wrote: Yup. Suggestions on a solution? On Jun 12, 2013, at 6:13 PM, Daniel Johnson daniel.johnso...@gmail.com wrote: On Jun 12, 2013, at 11:15 AM, Kurt Schwehr kurtschw...@yahoo.com wrote: The author of distribute merged distribute back into setuptools 0.7 and took over as lead of setuptools. Please convert python packages that use distribute back to setuptools. Just committed setuptools 0.7.2 to 10.[78] and 10.[56]. https://pypi.python.org/pypi/setuptools/0.7.2#id3 https://bitbucket.org/pypa/setuptools/src/tip/docs/merge.txt This is causing a bit of a dependency problem. Some packages Depend on distribute-py rather than just BuildDepend, such as my modernize-py. Since setuptools and distribute are mutually exclusive, I now can't install setuptools at all without removing modernize first. I can update modernize to use setuptools but the already-installed version prevents the update from happening since distribute has to be uninstalled first, which causes a dependency loop. Daniel If the new setuptools is drop-in compatible with our current distribute, then how about making a dummy upgrade distribute which Depends on setuptools (= 0.7.2)? I found something which looks like it works. The gist is: 1) Make distribute a real package again but have it really be setuptools-0.7.2. This has the following: Conflicts: setuptools-py%type_pkg[python] ( 0.7.2-3) Replaces: setuptools-py%type_pkg[python] Provides: setuptools-py%type_pkg[python] The unversioned Replaces: will allow it to replace setuptools (= 0.7.2-3) without removing the package entry, and the Provides: keeps current users of setuptools (via the prior Provides from the old distribute) happy. 2) Do the following in setuptools: Conflicts: distribute-py%type_pkg[python] ( 0.7.2-3) Replaces: distribute-py%type_pkg[python] Provides: distribute-py%type_pkg[python] This allows folks who update distribute automatically to get setuptools (under the distribute label) without any nasty dependency hell. Then, if setuptools is updated and installed, it overwrites the overlapping files from distribute with identical ones, but does _not_ remove the distribute package (since there is no Conflict), so packages with dependencies on it are happy. It's not a complete solution, probably, but at least we can tell users to update distribute first. .infos attached. This has been sitting on my TODO list, but now it looks like there is a setuptools-tng-py*? I can hold off on upgrading my .info files if this is still being worked out, but if not... Kurt: looks like nose-py is still depending on the non-tng setuptools in the 10.7 tree. (I was being lazy and trying a 'fink remove setuptools-py*' to see what dependencies broke. Haven't checked for others.) -- Charles Lepple clepple@gmail -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
