Re: fontforge - port installation
Thanks It is unclear where to get more detailed and specific info for the variants, so I guess I will go with the default. Will it matter if I fail to uninstall any of the dependencies for the the current (non-working) pkg version of fontforge? -A -Original Message- From: Ryan Schmidt ryandes...@macports.org To: uga...@talktalk.net CC: Jeremy Lavergne jer...@lavergne.gotdns.org; MacPorts Users macports-users@lists.macosforge.org Sent: Mon, 4 Nov 2013 21:23 Subject: Re: fontforge - port installation On Nov 4, 2013, at 09:40, uga...@talktalk.net wrote: I think it was a misguided example, sudo port install fontforge will do? If you do not want any of the offered variants, then yes, that will do. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: fontforge - port installation
It is unclear where to get more detailed and specific info for the variants, so I guess I will go with the default. port variants fontforge smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: fontforge - port installation
Yes fontforge has the variants: freetype_bytecode: Enable support for bytecode interpreter python26: Enable Python support (Python 2.6) * conflicts with python27 python27: Enable Python support (Python 2.7) * conflicts with python26 universal: Build for multiple architectures with_freetype_bytecode: Legacy compatibility variant * requires freetype_bytecode The above was included in an earlier post. I guess I may or may not find out, if I fail first to uninstall any of the dependencies for the the current (non-working) pkg version of fontforge. -A -Original Message- From: Chris Jones jon...@hep.phy.cam.ac.uk To: MacPorts Users macports-users@lists.macosforge.org Sent: Tue, 5 Nov 2013 13:11 Subject: Re: fontforge - port installation It is unclear where to get more detailed and specific info for the variants, so I guess I will go with the default. port variants fontforge ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: changing default perl
I would say we should even go further, and get rid of all of the p5-* ports. Instead, we should install perl5 as the latest stable perl, and include our own 'cpanm' program (like how perlbrew has it's own) which would download/build/(test)/install modules (probably into a DESTROOT to allow MacPorts to do the actual install and to take advantage of Macports being able to do unininstall). We could add a new dependency type (and associated functionality) to allow ports to still depend on perl modules, and the perl5 port could uninstall/reinstall all of the installed perl modules when upgraded (or actually, on post-activate). Of course, that's considerably more work (and requires changes to base/ that others may or may not be willing to accept into base/). We should at least just switch to one stable perl5, though. On Nov 4, 2013, at 7:05 PM, Mark Anderson e...@emer.net wrote: I'm with you there. 5.8 and 5.10 are long out of support. The Perl community also strongly advises moving to the latest version as soon as it is marked stable, that's why they make you do things like: use 5.018; to get new features that can break old ones. Which is why I'm leaning more and more toward nuking all but the latest perl and away from port select. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: fontforge - port installation
On Nov 5, 2013, at 06:03, uga...@talktalk.net wrote: It is unclear where to get more detailed and specific info for the variants, so I guess I will go with the default. fontforge has the variants: freetype_bytecode: Enable support for bytecode interpreter fontforge uses the freetype library. The freetype library has a feature called the bytecode interpreter which lets it display glyphs more accurately, but the method it uses to do so was covered by an Apple Inc patent, so the freetype project was not legally allowed to use that method. The freetype port had variant allowing users (in regions of the world not covered by that patent) to use the feature anyway. The patent expired in 2010 so everybody may now legally use it. The freetype port now always uses the bytecode interpreter; the variant has been deleted. The fontforge port has not had a maintainer since 2006 (r18094) so I guess nobody has noticed that fontforge still has this variant. Perhaps we should remove the variant from fontforge and always enable the feature there too. It’s also possible that the changes in freetype to always enable this feature will make fontforge unable to use this feature. The developers of fontforge appear not to have noticed the expiration of this patent either, since the latest code in their repository still refers users to Apple to get a license for the expired patent. I will attempt to report that problem to the developers of fontforge. If you’re interested, this page shows the difference using the bytecode interpreter makes: http://www.ludd.luth.se/~staham/linux/bci.shtml python26: Enable Python support (Python 2.6) * conflicts with python27 python27: Enable Python support (Python 2.7) * conflicts with python26 Select one of these variants if you want python support in fontforge. I don’t know what that entails. In fact the port seems to be somewhat confused: it looks like the port actually includes python27 support, even if you don’t select either of these variants. This is a bug in the port that should be fixed. universal: Build for multiple architectures Instead of building for only your machine’s normal architecture, the universal variant builds a port for multiple architectures. Most ports have universal variants, but most users don’t usually need it. It’s needed if you want to build a port on one computer and then run it on a second computer that has a different processor. Perhaps you want to build a standalone installer package for this port that you can distribute to other users. MacPorts will automatically select the universal variant if it’s needed. For example, if you are using a 64-bit Mac, and the port you’re trying to install is only available 32-bit, but has dependencies on other ports that can be built 64-bit, then MacPorts will install those dependencies with the universal variant in order to build them for both 32-bit and 64-bit. with_freetype_bytecode: Legacy compatibility variant * requires freetype_bytecode Legacy compatibility variants are not of interest to new users. We keep these around for a year or so to help users who already installed a previous version of the port upgrade to a new version. Since this variant had already been around for 2 years, I have now deleted it. Will it matter if I fail to uninstall any of the dependencies for the the current (non-working) pkg version of fontforge? I don’t know where your previous non-MacPorts fontforge installed its files. If, for example, it installed files, especially libraries, into /usr/local, then yes, that could be a problem. You should uninstall it, but most Mac software packages do not come with an uninstallation program, so you’ll have to check the web site where you got that installer package to see if they have any uninstallation instructions. Or you can re-download their installer, open it, don’t install it, but instead use the Show Files command in the Installer's File menu to see what it would install, then manually find those files on your drive and delete them. Ease of uninstallation is one of the reasons why installing software with MacPorts is so much more convenient… ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
octave-communications 1.1.1
Hi all, Could someone check in the patch for the octave-communications Portfile? See https://trac.macports.org/attachment/ticket/37746/patch-Portfile I just installed this using my local tree. It's only been sitting there for three months... -- Marius Schamschula ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Is there an iStumbler equilivant for iPhone/iPad
I routinely use the Mac Port version of iStumbler on my iMac and have lately had a desire to be able to use it on either my iPhone or iPad (air). Is there an equivalent (or a version of) ? Apple seems to have removed the ability to browse anything but Hot New and Editor's Choices from iTunes 11 (Mavericks).. Similarly, the Search function is singularly unhelpful. T.T.F.N. William H. Magill # iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.9 # Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.8.5 mag...@icloud.com mag...@mac.com whmag...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Is there an iStumbler equilivant for iPhone/iPad
in the app store that is This is OT though isn't it??? Oops, I guess not if you are trying to install from macports, but their isn't going to be a macports app for an iOS app anyway. -wes On Tue, Nov 5, 2013 at 2:53 PM, Wes James compte...@gmail.com wrote: These might be some options from a google search: http://forums.macrumors.com/showthread.php?t=527922 I also just typed in wifi on the ipad and several options showed up -wes On Tue, Nov 5, 2013 at 2:49 PM, William H. Magill mag...@mac.com wrote: I routinely use the Mac Port version of iStumbler on my iMac and have lately had a desire to be able to use it on either my iPhone or iPad (air). Is there an equivalent (or a version of) ? Apple seems to have removed the ability to browse anything but Hot New and Editor's Choices from iTunes 11 (Mavericks).. Similarly, the Search function is singularly unhelpful. T.T.F.N. William H. Magill # iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.9 # Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.8.5 mag...@icloud.com mag...@mac.com whmag...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: changing default perl
Actually, I kinda like that idea. It will be a lot of work, though. But it would keep me from having to mix CPAN and p5-* which I know is not recommended, but I still do. —Mark ___ Mark E. Anderson e...@emer.net On Tue, Nov 5, 2013 at 9:46 AM, Daniel J. Luke dl...@geeklair.net wrote: I would say we should even go further, and get rid of all of the p5-* ports. Instead, we should install perl5 as the latest stable perl, and include our own 'cpanm' program (like how perlbrew has it's own) which would download/build/(test)/install modules (probably into a DESTROOT to allow MacPorts to do the actual install and to take advantage of Macports being able to do unininstall). We could add a new dependency type (and associated functionality) to allow ports to still depend on perl modules, and the perl5 port could uninstall/reinstall all of the installed perl modules when upgraded (or actually, on post-activate). Of course, that's considerably more work (and requires changes to base/ that others may or may not be willing to accept into base/). We should at least just switch to one stable perl5, though. On Nov 4, 2013, at 7:05 PM, Mark Anderson e...@emer.net wrote: I'm with you there. 5.8 and 5.10 are long out of support. The Perl community also strongly advises moving to the latest version as soon as it is marked stable, that's why they make you do things like: use 5.018; to get new features that can break old ones. Which is why I'm leaning more and more toward nuking all but the latest perl and away from port select. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
