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 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 wrote: > > On Jun 12, 2013, at 11:15 AM, Kurt Schwehr > 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
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 >>> wrote: >>> On Jun 12, 2013, at 11:15 AM, Kurt Schwehr 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] 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
[Fink-devel] readline5 and libgettext3
We've had some good times, and your continued existence has allowed us to migrate gradually to newer versions as time has permitted. But now, all of 10.7+ has migrated to readline6 and libgettext8, so it's time for you to die. I'll allow friends and wellwishers the next hour or so work through their grief... dan -- Daniel Macks dma...@netspace.org -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] 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 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/ 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] 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 i"m 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 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 wrote: > Okay now it works, standalone, --apt and --dpkg all tested, hopefully > declaring $config as a global isn't bad ;) >> >> - >> >> --- >> TS >> http://www.southofheaven.org/ >> Life begins and ends with chaos, live between the chaos! >> >> On 2013-06-22, at 7:30 PM, TheSin wrote: >> >>> I take it back it only worked with out --apt :\ Fetched 1072 kB in 4s (222 kB/s)> Can't locate >> Fink/Config.pm in @INC (@INC contains: /Library/Perl/5.12/darwin-th I'll keep working on this :\ >>> --- >>> TS >>> http://www.southofheaven.org/ >>> Life begins and ends with chaos, live between the chaos! On 2013-06-22, at 7:27 PM, TheSin wrote: > okay now that I have inet back and hopefully stable, I fixed it >> so that I get the right arch now. >> Package: 64bit-cpu Status: install ok installed Priority: optional Architecture: darwin-x86_64 Version: 0-1 Maintainer: Fink Devel Description: [virtual package representing the 64bit capability of >> the CPU] The presence of the 64bit-cpu package indicates that the CPU on which we are running is 64bit capable. >> . >> Web site: >> http://www.finkproject.org/faq/usage-general.php#virtpackage . >> Maintainer: Fink Devel >> Here is the new patch, hopefully I did it right I >> couldn't figure out what or why UseFinkModules() was for or did since >> it returns and exports nothing. If this is wrong please let me know. >> --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! >> On 2013-06-21, at 11:56 PM, Daniel Macks wrote: >>> On Thu, 20 Jun 2013 22:11:20 -0600, TheSin >> wrote: > The new apt is much more strict on the fields in status files, to >> get >>> it to work I need to make a few minor changes to f-v-p, I >> spent lots of >>> time working on apt 0.9.82 trying to figure out why >> girts weren't >>> working and it turns out the parser was considering >> them invalid due to >>> missing fields like arch and priority. So I >> made a quick patch which >>> is in my pull request and i'll attach it >> here as well. I'd add it >>> myself but I'm not sure which branch >> and if it'll affect anything else >>> that uses f-v-p >> the current output looks like >> Package: 64bit-cpu >> Status: install ok installed >> Version: 0-1 >> description: [virtual package representing the 64bit capability >> of the CPU] >> I'd like to change it to look like >> Package: 64bit-cpu >> Status: install ok installed >> Priority: optional >> Architecture: all >> Version: 0-1 >> Maintainer: Fink Devel >> Description: [virtual package representing the 64bit capability >> of the CPU] >> The presence of the 64bit-cpu package indicates that the CPU on which we >> are running is 64bit capable. . Web site: >> http://www.finkproject.org/faq/usage-general.php#virtpackage >> . Maintainer: Fink Devel This change to --apt output looks reasonable to me. I talked >> to TheSin >>> in #fink yesterday, who confirmed that old apt would >> also accept it, so >>> I don't see harm in sending this to master now >> (rather than later as >>> part of the large apt upgrade work) (would >> also benefit anyone who's >>> experimenting with new debian tools of >> any sort). >>> >>> Technical 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/g
