Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On Thu, 28 May 2015, Ryan Schmidt wrote: No; the MacPorts default build_arch is x86_64 on Yosemite, but the user can override it by changing build_arch to i386 in macports.conf. In this case, the user probably didn't meant to do that, he just imported a pre-Snow Leopard Intel MacPorts installation onto his Yosemite Mac, and should now fully follow the Migration instructions to set things right. Hmmm... I've never touched macports.conf in my life (because I won't know what I'm doing), but I see this: -rw-r--r-- 1 root admin 5787 Dec 1 2010 macports.conf -r--r--r-- 1 root admin 8248 Nov 22 2014 macports.conf.default The first would be the original Snow Leopard file, and the second would be Yosemite (with attendant differences in default build architectures). Am I in trouble? I've had no problems with ports. -- Dave Horsfall DTM (VK2KFU) Those who don't understand security will suffer. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
ok. so it works now. i did 2 things. first i set the universal to also include x86_64 tried again and no luck then i went through the entire migration steps and now i'm up and running. i hadn't installed macports in my last 2 os upgrades so i wasn't thinking i had to migrate. but i guess it was left over from very first os on the machine when i used it a bunch. so i thought it was gone but obviously it was not. thanks for all the help, sorry for not doing that step to begin with. thanks! -dan On Thu, May 28, 2015 at 2:26 PM, René J.V. rjvber...@gmail.com wrote: On Thursday May 28 2015 13:33:45 Lawrence Velázquez wrote: On May 28, 2015, at 1:01 PM, René J.V. Bertin rjvber...@gmail.com wrote: OP is on Yosemite. MacPorts defaults to x86_64 builds on Yosemite. even if build_arch is set to i386 only, as was the case for him? Isn't that a bug? R -- i'm leaving gmail in 2014, new email address is danjo.m...@runbox.com my cell phone has poor reception 617-504-9619 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: `port -pf upgrade outdated` is incredibly unsafe ??
On May 28, 2015, at 2:47 PM, René J.V. Bertin rjvber...@gmail.com wrote: It should be safe to build ports that do not depend directly on a failed port, but it seems not impossible that the ABI-changing effect of the update of an indirect dependency permeates to a direct dependency. I would consider this a bug in the dependent port. That indirect dependency should be a direct dependency. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: `port -pf upgrade outdated` is incredibly unsafe ??
End users probably don't read the man pages to even know these flags exist. We're left wondering how and why you're even using them. -p Despite any errors encountered, proceed to process multiple ports and com- mands. -f force mode (ignore state file) Do you run force mode on all your system commands and never check the result before the next one? That's an analogy here. MacPorts upgrades dependencies by default. The routine you employ here breaks that in the worst way possible: it ignores problems and safeties with prejudice. For what purpose are you using these flags? On May 28, 2015, at 1:09 PM, Kurt Pfeifle wrote: Ok then: which one of the two switches is the unsafe one? I guess the -f? Or has the combination of the two even more damage potential? I started to make it a habit using them, because so often the upgrade does not run through to continue with a few hundred other packages because of just one or two or three packages fail… And this requires me to restart the upgrade every so often, with a changed list of package names. If the -f (or the combo of -pf) is indeed so terribly unsafe as you say (I do not doubt your statement, even though I do not understand the reason for it), then there should be at least one of the following: • Add a warning (including the reason for it) to the port manpage. • Emit a warning on the command line, whenever this option is used. Currently none of the two is present. So do not wonder, if (some of the few) users who read man pages also make use of it :) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: `port -pf upgrade outdated` is incredibly unsafe ??
On Thursday May 28 2015 19:54:27 Kurt Pfeifle wrote: I've seen the upgrade of 200+ packages stopping just because one of the first five package upgrade fails. So have I, but I rarely if ever use even -p when I do launch a bunch of updates. I rather tend to isolate the ones I know will be time-consuming, and yes, I do use -n quite often nowadays in order to update ports without updating their dependencies (if I even updated their port directories). I would be nice however if there were a flag that works more like make's -k flag. It would do something like - keep working until an upgrade fails, building only ports that don't depend *) on a failed port - add the failed port to a list of ports that failed until now - skip to the next port that needs updating, and try to build it if it doesn't depend *) on a failed port - repeat *) with -k, this is a recursive depend; with -kf (or some other variation) this is a direct depend It should be safe to build ports that do not depend directly on a failed port, but it seems not impossible that the ABI-changing effect of the update of an indirect dependency permeates to a direct dependency. At (probably) worst that would mean that you have to rebuild some ports again after getting the failed port(s) to build, so I think it should be fine to allow a less strict skipping mechanism in case of upgrade failure. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: `port -pf upgrade outdated` is incredibly unsafe ??
On Thu, May 28, 2015 at 7:28 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: End users probably don't read the man pages to even know these flags exist. That's what I already hinted at in my last mail. We're left wondering how and why you're even using them. -p Despite any errors encountered, proceed to process multiple ports and com- mands. -f force mode (ignore state file) Do you run force mode on all your system commands Nope, I don't. and never check the result before the next one? I gave up to do this for MacPorts upgrades, because it is so time consuming. I do however always check *afterwards* what problems did occur. That's an analogy here. That sentence I do not understand. For what purpose are you using these flags? I outlined that already in my last mail. :-) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: `port -pf upgrade outdated` is incredibly unsafe ??
On May 28, 2015, at 1:09 PM, Kurt Pfeifle kurt.pfei...@googlemail.com wrote: Ok then: which one of the two switches is the unsafe one? I guess the -f? Or has the combination of the two even more damage potential? They're both unsafe. -f does different things depending on the build phase, but all of them amount to plowing through despite problems. For instance, activating a port usually fails if some of that port's files already exist. Force-activating just overwrites those files. -p tells MacPorts to continue processing ports and commands, even on failure. This can cause problems when upgrading a port and its dependencies, as MacPorts will blindly continue to upgrade ports despite their dependencies' builds failures. I started to make it a habit using them, because so often the upgrade does not run through to continue with a few hundred other packages because of just one or two or three packages fail… Ignoring errors is a bad way to handle this situation. You should upgrade more often or uninstall some ports. (And report build failures to us, naturally.) If the -f (or the combo of -pf) is indeed so terribly unsafe as you say (I do not doubt your statement, even though I do not understand the reason for it), then there should be at least one of the following: • Add a warning (including the reason for it) to the port manpage. • Emit a warning on the command line, whenever this option is used. Those are good ideas. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
`port -pf upgrade outdated` is incredibly unsafe ??
On Wed, May 27, 2015 at 11:54 PM, Lawrence Velázquez lar...@macports.org wrote: On May 27, 2015, at 4:37 PM, Kurt Pfeifle kurt.pfei...@googlemail.com wrote: [] girara was updated an hour ago. Please run a selfupdate and try upgrading again. Thanks, it works now. P.S. Unrelated: Stop using port -pf upgrade and never use it again. It's incredibly unsafe. Ok then: which one of the two switches is the unsafe one? I guess the -f? Or has the combination of the two even more damage potential? I started to make it a habit using them, because *so often* the upgrade does not run through to continue with a few hundred other packages because of just one or two or three packages fail… And this requires me to restart the upgrade every so often, with a changed list of package names. If the -f (or the combo of -pf) is indeed so terribly unsafe as you say (I do not doubt your statement, even though I do not understand the reason for it), then there should be at least one of the following: 1. Add a warning (including the reason for it) to the port manpage. 2. Emit a warning on the command line, whenever this option is used. Currently none of the two is present. So do not wonder, if (some of the few) users who read man pages also make use of it :) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On Thursday May 28 2015 13:33:45 Lawrence Velázquez wrote: On May 28, 2015, at 1:01 PM, René J.V. Bertin rjvber...@gmail.com wrote: OP is on Yosemite. MacPorts defaults to x86_64 builds on Yosemite. even if build_arch is set to i386 only, as was the case for him? Isn't that a bug? R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On May 28, 2015, at 1:01 PM, René J.V. Bertin rjvber...@gmail.com wrote: On Thursday May 28 2015 12:42:20 Lawrence Velázquez wrote: So the OP is trying to build ImageMagick x86_64. Are there ways to that other than requesting a +universal build of it, or of another port which has ImageMagick as its first dependency? OP is on Yosemite. MacPorts defaults to x86_64 builds on Yosemite. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: `port -pf upgrade outdated` is incredibly unsafe ??
I'm confused about the purpose of the thread. The documentation indicates why what you're doing is a bad thing. You should just run random commands without knowing what they do. To quote IRC: things break so often that i decided that the best course of action was to ignore the breakage It sounds like you don't actually want help. On May 28, 2015, at 1:34 PM, Kurt Pfeifle wrote: On Thu, May 28, 2015 at 7:28 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: End users probably don't read the man pages to even know these flags exist. That's what I already hinted at in my last mail. We're left wondering how and why you're even using them. -p Despite any errors encountered, proceed to process multiple ports and com- mands. -f force mode (ignore state file) Do you run force mode on all your system commands Nope, I don't. and never check the result before the next one? I gave up to do this for MacPorts upgrades, because it is so time consuming. I do however always check *afterwards* what problems did occur. That's an analogy here. That sentence I do not understand. For what purpose are you using these flags? I outlined that already in my last mail. :-) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: zlib acceleration?
On Thursday May 28 2015 00:14:14 Ryan Schmidt wrote: Instead of trying to add a patch for this to MacPorts, I would rather you work with the developers of zlib on including the changes into zlib itself When the Phoronix article was written, this was being discussed on the zlib ML and that's about 2 years ago. If no patches were included in that time, and even a 2nd party felt the need to develop their own, I think it'd be a waste of time to try that route. Not without some additional evidence that the patch works and has an interest without drawbacks, which could come from deploying it through MacPorts for a while. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Cleaning MacPorts from old (unused) ports versions
On May 28, 2015, at 12:36 AM, Mojca Miklavec wrote: On Thu, May 28, 2015 at 4:20 AM, Brandon Allbery wrote: On Wed, May 27, 2015 at 10:10 PM, Gustavo Seabra wrote: So, there were 4 (!) versions of grace installed! That should be remnants of old MacPorts installations. I suppose similar multiple versions must be present for a number of different ports. My question is: is there a way to hunt and remove those older versions of ports? (preferably, some automatic way to remove them all, from all programs?) Those are preserved old versions, from `port upgrade` --- so, if something is broken for you in the new version, you can easily roll back. `sudo port uninstall inactive` will clear them. If you decide you don't want to keep them at all, use `sudo port -u upgrade outdated`. This is true, but I agree that it would be great to have something like sudo port uninstall --all grace Otherwise one has to manually copy and paste every single version (if one wants to keep older versions for other ports except with the interactive version of the port command). You can do that already: sudo port uninstall installed and grace (uninstalls ports named grace that are installed) Or if you meant: uninstall only the inactive ones: sudo port uninstall grace and inactive (uninstalls ports named grace that are inactive) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: zlib acceleration?
On May 28, 2015, at 3:30 AM, René J.V. Bertin wrote: On Thursday May 28 2015 00:14:14 Ryan Schmidt wrote: Instead of trying to add a patch for this to MacPorts, I would rather you work with the developers of zlib on including the changes into zlib itself When the Phoronix article was written, this was being discussed on the zlib ML and that's about 2 years ago. If no patches were included in that time, and even a 2nd party felt the need to develop their own, I think it'd be a waste of time to try that route. That was kind of my point. Not without some additional evidence that the patch works and has an interest without drawbacks, which could come from deploying it through MacPorts for a while. I'm not comfortable with making MacPorts users involuntary testers for unofficial code in a fundamental library like zlib. Maybe you can include it in your own private copy of zlib, and based on your experiences running that, you can make recommendations to the developers. But if the developers don't believe it should be included, then I don't feel we should second-guess them. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
RE: Backing up MacPorts directories
-Original Message- From: Ryan Schmidt [mailto:ryandes...@macports.org] Sent: 26 May 2015 20:33 To: Larry Velázquez Cc: Steve Holden; MacPorts Users Subject: Re: Backing up MacPorts directories On May 26, 2015, at 12:11 PM, Lawrence Velázquez wrote: On May 26, 2015, at 7:11 AM, Steve Holden wrote: Is it recommended to omit any of the directories under ‘/opt/local/var/macports’ from backups (e.g. ‘distfiles’, ‘sources’)? https://guide.macports.org/#internals.hierarchy Whilst I’d like a fully-functioning MacPorts installation if I have to boot from or restore from a backup drive, I wondered whether any of its build directories could be safely omitted? Would their contents be re-downloaded or re-built automatically (or could they be manually)? You can probably omit these. - var/macports/build: A scratch directory for port builds. There shouldn't be anything in there, unless a build was interrupted and you didn't run `port clean` afterwards. - var/macports/distfiles: A cache for ports' source distributions. MacPorts will redownload anything it can't find here. - var/macports/logs: MacPorts' logs. - var/macports/sources: Contains the ports tree and MacPorts base source code. I believe `port selfupdate` repopulates this, so you need not back it up. While the contents of those directories can be safely deleted, MacPorts might expect the directories themselves to exist, with certain permissions and ownership. Not sure if they will be recreated automatically if you delete them (or exclude them from your backup, then restore them). Thanks, Ryan and Larry - I'll exclude the contents (but not the directories themselves) from my backup. Best wishes, Steve ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: zlib acceleration?
On Thursday May 28 2015 04:43:28 Ryan Schmidt wrote: I'm not comfortable with making MacPorts users involuntary testers for unofficial code in a fundamental library like zlib. Not on an obligatory basis, no, not until we can show that there are no drawbacks to it. I plan to add a variant to a personal version of port:zlib, and publish that via my repository. I see a few possible reasons why upstream hasn't included it: - there was an issue with the original patch, which caused them to hold off on incorporating it. That issue has been resolved. - they find the gains not worth the effort, leaving it up to those for whom a 10% speed increase is significant to build their own copy - zlib development has simply stalled for lack of whatever. Two years without even something as fashionable as a security patch feels like a sign on the wall ... BTW, can someone try the benchmark script I linked to on 10.10 and more recent hardware than mine (early 2011 MBP 13)? Building the CloudFare version with -march=native causes clang to fail in the assembly stage, which reeks of a clang bug I might have to report to Apple. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
hey all, i recently upgraded a late 2008 macbookpro to yosemite. with SSD it seems to work ok. when running macports to install software i get the following error quote Error: Cannot install ImageMagick for the arch(s) 'x86_64' because Error: its dependency libtool is only installed for the arch 'i386' Error: and the configured universal_archs 'i386 ppc' are not sufficient. Error: Unable to execute port: architecture mismatch /quote I found the macports.conf file and uncommented build_arch i386 and i cleaned all. but the error remains the same. this machine did not have macports on it last time around so i did not follow the whole list of migration commands. but should i? or what else am i missing? Thanks, danjo my machine is this one i think: MacBook Pro Core 2 Duo 2.66 17 (Unibody) http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-2-duo-2.66-aluminum-17-early-2009-unibody-specs.html 2.66 GHz Core 2 Duo (T9550) http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-2-duo-2.66-aluminum-17-early-2009-unibody-specs.html Intro. January 6, 2009 Disc. June 8, 2009 Order MB604LL/A Model A1297 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1297 (EMC 2272 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=2272) Family Early 2009 ID MacBookPro5,2 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBookPro5,2 RAM 4 GB VRAM 512 MB* Storage 320 GB (5400 RPM) Optical 8X DL SuperDrive Complete MacBook Pro Core 2 Duo 2.66 17 (Unibody) Specs http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-2-duo-2.66-aluminum-17-early-2009-unibody-specs.html ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On Thursday May 28 2015 09:16:46 ^. .^ wrote: i recently upgraded a late 2008 macbookpro to yosemite. with SSD it seems Does it have a 64bit processor? quote Error: Cannot install ImageMagick for the arch(s) 'x86_64' because Error: its dependency libtool is only installed for the arch 'i386' Error: and the configured universal_archs 'i386 ppc' are not sufficient. Error: Unable to execute port: architecture mismatch /quote I found the macports.conf file and uncommented build_arch i386 Apparently MacPorts was configured for 32bit only when you installed it, but somehow ImageMagick wants to be built for 64bit only. I don't see anything in the Portfile that causes that, so maybe it's ImageMagick itself that enforces that choice. You'd probably need to file a ticket on trac for that. have macports on it last time around so i did not follow the whole list of migration commands. but should i? No. Family Early 2009 ID MacBookPro5,2 Apple/About This Mac/More Information will give you the correct ID R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On Thursday May 28 2015 11:02:08 Lawrence Velázquez wrote: You may have to edit macports.conf again and set universal_archs x86_64 i386. Was he doing a universal build? ImageMagick doesn't have +universal as a default variant, so I don't see why one would need universal_archs if one just wants or needs to build the entire tree in 32bit mode ... R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On May 28, 2015, at 9:16 AM, ^. .^ sixmilliondollar...@gmail.com wrote: when running macports to install software i get the following error quote Error: Cannot install ImageMagick for the arch(s) 'x86_64' because Error: its dependency libtool is only installed for the arch 'i386' Error: and the configured universal_archs 'i386 ppc' are not sufficient. Error: Unable to execute port: architecture mismatch /quote I found the macports.conf file and uncommented build_arch i386 and i cleaned all. but the error remains the same. You may have to edit macports.conf again and set universal_archs x86_64 i386. this machine did not have macports on it last time around so i did not follow the whole list of migration commands. but should i? Was MacPorts present on the machine when you upgraded to Yosemite? If so, then you should follow the migration instructions. If not, you don't have to. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On 2015-05-28 15:16, ^. .^ wrote: i recently upgraded a late 2008 macbookpro to yosemite. with SSD it seems to work ok. Did you follow the migration procedure? http://trac.macports.org/wiki/Migration when running macports to install software i get the following error quote Error: Cannot install ImageMagick for the arch(s) 'x86_64' because Error: its dependency libtool is only installed for the arch 'i386' Error: and the configured universal_archs 'i386 ppc' are not sufficient. Error: Unable to execute port: architecture mismatch /quote I found the macports.conf file and uncommented build_arch i386 and i cleaned all. but the error remains the same. this machine did not have macports on it last time around so i did not follow the whole list of migration commands. but should i? or what else am i missing? You probably migrated this MacPorts installation from an older machine, which still used 32-bit as default build architecture. After reinstalling MacPorts as recommended by the migration procedure, please compare your macports.conf against the macports.conf.default. You will find both files in /opt/local/etc/macports/ after installing the latest MacPorts version. Most probably you even want to replace the macports.conf entirely with the default options unless you made any changes on purpose. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On May 28, 2015, at 11:22 AM, René J.V. Bertin rjvber...@gmail.com wrote: Was he doing a universal build? ImageMagick doesn't have +universal as a default variant, so I don't see why one would need universal_archs if one just wants or needs to build the entire tree in 32bit mode ... MacPorts tries to remedy architecture mismatches by building dependencies +universal. So the OP is trying to build ImageMagick x86_64. Its dependency libtool is already installed, but its architecture is unsatisfactory. MacPorts tries to fix this by rebuilding libtool +universal, but it notices that universal_archs doesn't contain x86_64 and bails out. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?
On Thursday May 28 2015 12:42:20 Lawrence Velázquez wrote: So the OP is trying to build ImageMagick x86_64. Are there ways to that other than requesting a +universal build of it, or of another port which has ImageMagick as its first dependency? I must have assumed that the OP would have found the universal_archs setting in macports.conf if he wanted to install a universal variant... R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
