Re: How to fix faulty symlink in XCode 3.2.6, issue 14018?
In article <28ecc888-1cf6-4306-bfce-b4713369e...@yahoo.com>, semaphor...@yahoo.com wrote: > Ned: what are you referring to here? > > But yeah, the problem in issue14018 does not apply to any MacPorts > > python port and shouldn't be an issue for any other port unless there is > > a bug in the port. Just agreeing with Ryan's comments. As far as I know, in general a MacPorts port should not be depending on anything in /Library/Frameworks; if the upstream build for a project does, the MacPort's portfile should have appropriately patched the upstream build to no longer do that and, instead, compile with and/or link to MacPort's installed frameworks or libraries, all of which would be under the MacPort's prefix, e.g. /opt/local. (For the record, I know nothing about gnuradio.) -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How to fix faulty symlink in XCode 3.2.6, issue 14018?
In article , Ryan Schmidt wrote: > On Jun 19, 2015, at 10:24 PM, semaphor...@yahoo.com wrote: > > I am trying to solve the issue described there > > http://bugs.python.org/issue14018, which prevents me from installing gqrx. [...] > I just installed a fresh copy of Xcode 3.2.6 on Snow Leopard, and can confirm > there is a problem with the Mac OS X 10.6 SDK's Frameworks, which is that > /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks is a directory, and it > contains a symlink Frameworks pointing to /Library/Frameworks. In other > words, /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks/Frameworks points to > /Library/Frameworks, when instead it is > /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks that should point to > /Library/Frameworks. If you look at the MacOSX10.5.sdk, it is already set up > that way. [...] As an aside to others following along: in more recent versions of Xcode for newer releases of OS X, the SDK no longer includes any symlinks (working or faulty) to the /Library on the root file system. If you need them, you'll need to explicitly create them in the desired SDK, which is now buried inside of an Xcode.app bundle. And that's really a better default: a main advantage of using an SDK is to isolate builds from variances among individual build machines. > The faulty Frameworks setup in Xcode 3.2.6's Mac OS X 10.6 SDK should not be > of any significance for MacPorts, because MacPorts ports don't typically use > anything in /Library/Frameworks, but I have not tested the gqrx port > specifically; perhaps it is an exception. I'll try to install it now. But yeah, the problem in issue14018 does not apply to any MacPorts python port and shouldn't be an issue for any other port unless there is a bug in the port. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: something you always ...... about the X11 clipboard(s)
In article <1979918.mOAS13Diux@portia.local>, Rene J.V. Bertin wrote: > One reason I use xterms for so much of my command line tinkering is how > double clicking selection works (full paths, for instance) and copies the > selected content at once to a clipboard or cutbuffer (CLIPBOARD?). Just FYI: iTerm.app, a native OS X replacement for Apple's Terminal.app (and available via "port install iTerm2"), supports auto-copying of double-clicked selections to the OS X clipboard and has many other useful power features and doesn't use X. Of course, if one *prefers* to run under X ... (but if one does, why use OS X on the desktop in the first place?). http://iterm2.com -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /Library/Frameworks no longer a default location?
In article <203747044.N0Q8luCIT7@portia.local>, Rene J.V. Bertin wrote: > Not really MacPorts-related, but is it true that /Library/Frameworks is no > longer searched automatically by the compiler and linker, as suggested by > https://codereview.qt-project.org/108400 ? The use of /Library/Frameworks in the default search path at link time is documented in "man 1 ld". The use of /Library/Frameworks in the default fallback search path at execution time is documented in "man 1 dyld". -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: CD creation/burning: [MacPorts] #46840: new port submission: xcdroast
In article <1815194.9uG6SLK7dp@portia.local>, Rene J.V. Bertin wrote: > Yes, I'm aware of those settings; they have been in existence for as long as > I can remember. There's no option however to ignore data CDs or DVDs, and I'm > not sure if ignoring the injection of a music CD (i.e. not launch an app) > will prevent it from being mounted by the Finder, which prevents access by > other applications. One can unmount it (=/= eject), but it will be remounted > as soon as you access the drive. Apparently that still generates events that > the Finder reacts to. You may be able to prevent automounting of optical media by adding appropriate entries in /etc/fstab; that certainly worked for disk partitions in older versions of OS X (I haven't tried it recently). Even if does get automounted, you should be able to use the various options in hdiutil to unmount and/or attach the device without mounting file systems and/or making the mounts visible to the Finder. hdiutil has a boatload of options. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: CD creation/burning: [MacPorts] #46840: new port submission: xcdroast
In article <4372684.aLdx8UTxBz@patux>, Rene J.V. Bertin wrote: > Back in 10.3 (and maybe 10.4) days, xcdroast gave itself a chance to access > newly inserted optical disks (= preventing the Finder from auto-mounting > them) by killing the autodiskmount daemon. That no longer works, but there > must surely be another way. System Preferences -> CDs & DVDs -> When you insert a blank CD -> Ignore Also see "man drutil" and "man hdiutil". -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Virtual machines and OS X
In article <6d5f317f-1f1d-4864-b6c0-1efc50eae...@tigger.ws>, James Linder wrote: > Actually it is messier yet. You cannot install xcode on Snow Leopard any > longer. Since this is a foobar of great magnitude (and exists because the > certificate Apple uses to install xcode has expired) one can hope that they > will fix the error. MEANWHILE unless you have a working development system > you can’t get one (at lease for snow leopard and when I tried to install > snowleopard from the supplied DVDs) Which Xcode and how are you trying to install it? I just successfully reinstalled a downloaded Xcode 3.2.6 on a 10.6 system several weeks ago. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: upgrading XCode on 10.9
In article <1977346.HivKc7Tkja@portia.local>, > I've seen lots of talk about XCode 6 lately. When I had my 10.9.4 VM running > the last few days, I did get an update for the dev. command line tools (to > 5.1 IIRC), but no sign of an update to the IDE. Would that require upgrading > to 10.9.5 first? The Xcode entry in the Mac App store claims that 10.9.4 or later is required for the current Xcode 6.1. You may need to login in the App Store app to "buy" it (for free) if you haven't already or to ensure your account is registered on your system if you have. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Case-sensitive file system
In article <8d2d8233-983b-4edf-bcbb-23431d7f2...@macports.org>, Vincent Habchi wrote: > Le 6 nov. 2014 à 21:20, Dave Horsfall a écrit : > > There was a discussion here on the Mac's case-sensitive-but-not-quite file > > system, and I was convinced to leave it the way it is (it breaks something > > in MacPorts or something). Well, I've just been convinced otherwise… > I’ve been running MacPorts on a case-sensitive HFS+ disk for years now, and > it works like a charm. Don’t let you gull by the grapevine! So have I: since OS X 10.5, in fact. I don't recall ever encountering a MacPorts-related problem with using case-sensitive HFS. In the past, I ran into a few problems with older (non-MacPorts) third-party Mac applications that did not work properly on case-sensitive HFS+, usually because of some silly mistyped mixed-case file name inside of the app bundle. Some discussion of a few recent apps here: http://apple.stackexchange.com/questions/46322/what-programs-have-trouble -with-case-sensitive-hfsx-filesystems-and-how-to-fi That said, I haven't noticed a problem in years and I use case-sensitive HFS as the root file systems on all of my primary systems. I also use default, case-insensitive HFS on other test systems. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Yosemite, XCode 6.1?
In article <05649a1b-10b7-442e-8944-687575f33...@mac.com>, "William H. Magill" wrote: > The truly annoying thing is that 6.0.1 was released along with 10.10 -- and a > comment > that it "supported" 10.10. > Where the definition of "supported" means -- will run under 10.10; but does > NOT > provide 10.10 tools! 6.0.1 was released in mid-September, long before 10.10 was released. It works just fine on 10.10, except for the lack of a 10.10 SDK which, most of the time, you don't really need anyway if you have installed the Command Line tools and headers. Unfortunately, the build processes for some ports really do depend on using an SDK and/or xcodebuild, which is why MacPorts requires that you install both Xcode and the Command Line Tools. Back in the day before the CLTs were broken out as a convenient separate item, it really didn't matter as you always had to install Xcode. These days it would be nice if all ports could be built with just the CLT. But that's not the job of the MacPorts folks to do, that's an upstream issue for each project. In any case, in 24 hours this should all be a moot point as the expected official release of Xcode 6.1 will have both an 10.10 and 10.9 SDK and 6.0.1 will become obsolete. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Yosemite, XCode 6.1?
In article , Chris Jones wrote: > Its quite simple, you need the OSX 10.10 SDK, which is only available in > Xcode 6.1, which for whatever reason is not released yet. You need to wait > for it The reason, I think, is that Xcode 6.0.x was released to support iOS 8 when iOS 8 was released so it does not include an OS X 10.10 SDK since 10.10 wasn't released at that point yet. Xcode 6.1 will support iOS 8.1 which apparently is anticipated to release on Monday 10/20 US time so I would expect to see Xcode 6.1 released via the Mac App Store then as well. Apparently, Apple decided (somewhat understandably) that it wasn't worth the effort to rev bump Xcode 6.0.x just to include a 10.10 SDK just for the four days between the release of 10.10 and the release of 8.1 and they didn't want to publicly pre-release an 8.1 SDK. Thus we're in this weird limbo state - unless you are a member of one of the (paid) Apple Developer programs that give non-disclosure access to pre-releases. Why Apple chose to not release 10.10 and 8.1 simultaneously may never be known but it could just be they didn't want to overload the Interwebz and/or their support organizations. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: End of Python 2.4-2.6 and 3.1-3.3 support
In article , Alex Tomkins wrote: > However could the 3.2 and 3.3 ports be reconsidered? > > 3.2 is supported until February 2016 - > http://legacy.python.org/dev/peps/pep-0392/ > 3.3 is supported until September 2017 - > http://legacy.python.org/dev/peps/pep-0398/ For some value of supported: both 3.2.x and 3.3.x are now in upstream's security-fix-only mode which means they only receive fixes that fix "issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch." In particular, 3.2.x and 3.3.x are not tested or updated upstream (e.g. by python-dev) to support new operating system releases or any other kind of bugs other than those that meet the security criteria above. Downstream distributors like MacPorts are, of course, free to provide whatever level of additional support they deem fit, like backporting fixes but, especially for Python 3, there are lots of good reasons to use the most recent release. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: selfupdate is not working
In article , Brandon Allbery wrote: > On Tue, Sep 30, 2014 at 4:09 PM, Ned Deily wrote: > > http://support.apple.com/kb/HT6495 > sigh. > > Yes, I know about the patches. And I know why they didn't do the switch, > especially considering that it's normally too large a change to consider > without a major release as opposed to a patch... but IMO bash as /bin/sh is > so boneheaded as to be worth an exception. (Yes, I feel this way about > Linux as well. I was fully supportive when Debian switched its /bin/sh to > dash.) You know and I know that ain't gonna happen. On the other hand, I believe it is true that OS X systems are, in general, less likely to be vulnerable to bash security issues in that (1) bash is likely less used for system daemons et al, in part thanks to launchd and (2) most OS X users don't (know to) open up their systems (and their network firewalls) to potentially dangerous network services. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: selfupdate is not working
In article <12845854.HUSkGzuWFH@portia.local>, Rene J.V. Bertin wrote: > On Tuesday September 30 2014 11:29:55 Brandon Allbery wrote: > > (In fact, I was kinda hoping that Apple was being slow about patching > > because they were regression-testing ash as /bin/sh... sigh.) > No, probably more because the bug has so many faces that they preferred to > wait a bit rather than send out multiple updates. http://support.apple.com/kb/HT6495 (They don't seem to have been pushed out yet through the normal Software Update mechanism but you can install them manually.) -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Idle (Python) on OS X Mavericks
In article <53854428.7000...@macports.org>, Joshua Root wrote: > > Ok, I’ve got python2.7 and 3.4 from Macports installed. I’m trying to use > > idle but the error printed is: > > > > ** IDLE can’t import Tkinter. Your Python may not be configured for tk ** > > > > I also installed the py34-tkinter port as I believe this port contains the > > required libraries for Idle. The same error is printed. > > > > Could it be a $PATH issue or missing libraries issue or both? > > > > PATH is currently set to: > > > > /Users/jamie/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/Users/jamie > > /bin:/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bi > > n:/usr/texbin > > > > Some repetition of directories but that shouldn’t cause a problem (I don’t > > think) > > > > Would anyone be able to offer some advice/info? > > How are you starting IDLE? I just installed python34 and py34-tkinter > and double-clicking on /Applications/MacPorts/Python 3.4/IDLE.app works > fine. (If you want to run /Applications/MacPorts/Python 2.7/IDLE.app > then of course you would need py27-tkinter.) Also what port variant of tk are you using? The quartz variant has open issues for 10.9.x and Xcode 5.1: https://trac.macports.org/ticket/42850 (ping!) -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Problem pyton PIL
On Apr 15, 2014, at 12:36 , Ryan Schmidt wrote: > On Apr 15, 2014, at 14:00, Ned Deily wrote: > > Ryan Schmidt wrote: > > > Where did /Library/Frameworks/Python.framework come from? It?s not > > > provided > > > by Apple, nor any MacPorts port, and will likely interfere with things > > > you > > > want to install using MacPorts. I recommend you remove it > > /Library/Frameworks/Python.framework is the installation location for > > the Pythons provided by python.org binary installers. They will happily > > co-exist with MacPorts- and Apple-provided Pythons. > Anything installed in /Library/Frameworks can potentially cause problems for > MacPorts-installed software, as it might inadvertently find dependencies in > /Library/Frameworks instead of the MacPorts-provided version thereof. This is > similar to the /usr/local problem. I don't think that is very likely to be a problem with Pythons. And, if one pops up, it will likely be pointing out a port that is already broken. Python framework installations are somewhat odd ducks (and were implemented with some unfortunate choices). One might think that there is a risk that a port trying to link with a Python shared framework library might get the wrong library. But because there is a /System/Library/Python.framework (Apple-supplied) and the header and the default link search order include both /Library/Frameworks and /System/Library/Frameworks, ports need to be careful to use the MacPorts locations regardless of whether a /Library/Frameworks/Python.framework exists, e.g. otherwise they'll always incorrectly build/link against either the python.org or the Apple-supplied one. Secondly, using -framework Python as arguments to compile or link is almost always problematic because Python "abuses" the use of framework versions. Currently, all Python versions (2.x and 3.x) are installed to the same framework which, AFAICT, makes it nearly impossible to use -framework Python if you want to build or link against a specific Python version, which you almost always want to do. Instead, build scripts need to use pythonx.y-configure commands to find the proper --includes, --libs, etc, which also work in a platform-independent manner. Upstream packages that don't do so are broken and probably do not link correctly without portfile patching already. -- Ned Deily n...@acm.org -- [] -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Problem pyton PIL
In article , Ryan Schmidt wrote: > On Apr 15, 2014, at 08:00, Spinxer wrote: > > But when I do: > > > > $ python > > Python 2.7 (r27:82508, Jul 3 2010, 21:12:11) > > [GCC 4.0.1 (Apple Inc. build 5493)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > > >>> from PIL import Image > > > > I get this error message: > > > > Traceback (most recent call last): > > File "", line 1, in > > File > > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa > > ges/PIL/Image.py", line 53, in > >from PIL import _imaging as core > > ImportError: > > dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site- > > packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart > > Referenced from: > > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packag > > es/PIL/_imaging.so > > Expected in: dynamic lookup > > Where did /Library/Frameworks/Python.framework come from? It¹s not provided > by Apple, nor any MacPorts port, and will likely interfere with things you > want to install using MacPorts. I recommend you remove it. /Library/Frameworks/Python.framework is the installation location for the Pythons provided by python.org binary installers. They will happily co-exist with MacPorts- and Apple-provided Pythons. That said, 2.7.0 is quite old, so consider upgrading it or deleting it if you are now just going to be using a MacPorts-based Python 2.7. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenSSL
In article <1496567.dPnP996dF6@patux>, Rene J.V. Bertin wrote: > On Monday April 07 2014 23:58:37 Ned Deily wrote: > > Don't even think of that! First, as you may know, most Apple-supplied > > programs don't use OpenSSL anyway (at least since 10.7 when it was > > This I didn't know ... Because they use Apple's own security frameworks (remember the recent GOTO fail?). > > officially deprecated). Second, the Heartbleed bug only applies to > > OpenSSL 1.0.1 through 1.0.1f. Apple has never shipped a version of > > OpenSSL later than 0.9.8. > > And this ... hardly surprises me... An independent software developer wrote a blog post a while back with his explanation of why Apple deprecated use of OpenSSL in favor of its own security frameworks. It wasn't an arbitrary decision. http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-techno te-about-openssl-on-os-x -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenSSL
In article <2628775.Ob0fHhrzob@patux>, René J.V. Bertin wrote: > I wonder, how feasible would it be to replace the system OpenSSL with the one > from MacPorts? If security updates are pushed this quickly it would make > sense for just about any OS X version, but even more so for those of us still > running 10.6 ... Don't even think of that! First, as you may know, most Apple-supplied programs don't use OpenSSL anyway (at least since 10.7 when it was officially deprecated). Second, the Heartbleed bug only applies to OpenSSL 1.0.1 through 1.0.1f. Apple has never shipped a version of OpenSSL later than 0.9.8. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Error setting python34 to python
In article , Ned Deily wrote: > The vestigial "pythonw" symlink synonyms for "python" have been removed > upstream in python3.4. It looks like "port select" needs to be changed > to accommodate that. I've opened MacPorts ticket #42746 for this ... > You should also be careful about setting "python" to a Python 3 variant. > That's not recommended as many Python packages still assume that > "python" refers to a Python 2 variant. "port select" should provide a > "python3" name as well and, ideally, for future compatibility, a > "python2" one as well so that someday "python" can mean "python3", all > as recommended in Python PEP 394. ... and #42747 for this. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Error setting python34 to python
In article , Thad Humphries wrote: > Ticket #41146 (https://trac.macports.org/ticket/41146) says this is fixed, > that that has not been my experience today. As you can see from the > terminal clips below, I cannot set python34 to python. I am running MacOS > 10.9.2. > > > $ sudo port install python34 > ---> Computing dependencies for python34 > ---> Fetching archive for python34 > ---> Attempting to fetch python34-3.4.0rc2_0.darwin_13.x86_64.tbz2 from > http://packages.macports.org/python34 > ---> Attempting to fetch python34-3.4.0rc2_0.darwin_13.x86_64.tbz2.rmd160 > from http://packages.macports.org/python34 > ---> Installing python34 @3.4.0rc2_0 > ---> Activating python34 @3.4.0rc2_0 > > To make python 3.4 the default (i.e. the version you get when you run > 'python'), > please run: > > sudo port select --set python python34 > > ---> Cleaning python34 > ---> Updating database of binaries: 100.0% > ---> Scanning binaries for linking errors: 100.0% > ---> No broken files found. > > $ sudo port select --set python python34 > Selecting 'python34' for 'python' failed: could not create new link > "/opt/local/bin/pythonw": target "/opt/local/bin/pythonw3.4" doesn't exist > > $ port -v installed python34 > The following ports are currently installed: > python34 @3.4.0rc2_0 (active) platform='darwin 13' archs='x86_64' The vestigial "pythonw" symlink synonyms for "python" have been removed upstream in python3.4. It looks like "port select" needs to be changed to accommodate that. You should also be careful about setting "python" to a Python 3 variant. That's not recommended as many Python packages still assume that "python" refers to a Python 2 variant. "port select" should provide a "python3" name as well and, ideally, for future compatibility, a "python2" one as well so that someday "python" can mean "python3", all as recommended in Python PEP 394. http://legacy.python.org/dev/peps/pep-0394/ -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: maxima+xmaxima: can't type into Console
In article , Ned Deily wrote: > In article <0fee59a6-86ed-4335-80d7-d2f954c21...@gmail.com>, > Murray Eisenberg wrote: > > How do I tell which Tk is being used?? > > $ port info tk > tk @8.6.1 (x11) > Variants: [+]quartz, (+)universal, (-)x11 > > In this case, the quartz (native) variant is selected, not the x11 one. > > > As to the Tk patch referenced in the cited ticket, how does one use it? > > Ideally, the MacPorts maintainer for Tk should create an appropriate patch > and > update the port file. Update: I see that the Tk port has just been updated with the patch for the Mavericks refresh problem. sudo port selfupdate sudo port upgrade tk Thanks, Ryan! -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: maxima+xmaxima: can't type into Console
In article <0fee59a6-86ed-4335-80d7-d2f954c21...@gmail.com>, Murray Eisenberg wrote: > How do I tell which Tk is being used?? $ port info tk tk @8.6.1 (x11) Variants: [+]quartz, (+)universal, (-)x11 In this case, the quartz (native) variant is selected, not the x11 one. > As to the Tk patch referenced in the cited ticket, how does one use it? Ideally, the MacPorts maintainer for Tk should create an appropriate patch and update the port file. > (I¹ve installed XQuartz just updated to 2.7.5. Is that relevant?) Only if you are using the x11 variant of tk in which case the patch isn't going to help. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: maxima+xmaxima: can't type into Console
In article , Murray Eisenberg wrote: > OS is Mavericks. > > Will try wxMaxima. > > On Nov 13, 2013, at 4:07 PM, mk-macpo...@techno.ms wrote: > > > Hi Murray, > > > > On Nov 13, 2013, at 4:11 PM, Murray Eisenberg wrote: > >> I installed maxima @5.30.0_0+xmaxima. By itself, the command-line maxima > >> works (so far) as expected. > > good. > > > >> When, instead, I start xmaxima from the command-line, I get two windows > >> Xmaxima: browser and Xmaxima: console. If I double-click one of the > >> highlighted lines in the Xmaxima: browser window, then the output appears > >> in the Xmaxima:browser window, and both the input and corresponding output > >> appear in the Xmaxima:console window as well. > > Yes, that's intentional. > > The browser just shows you a section from the manual, which you're advised > > to click through to show off some of maxima's and xmaxima's features. > > > >> But I cannot type any input directly into the Xmaxima: console window. > >> Shouldn¹t I be able to do so? And, if not, how can one enter input of > >> one¹s own (instead of just evaluate what¹s in the prepared html page > >> showing in the Xmaxima:browser window? > > You should be able to enter your own lines in the console. > > If not, which Mac OS version are you using? > > Here on my SL it works seamlessly. > > > > Greets, > > Marko > > > > P.S.: Perhaps you would like to install wxMaxima and try that too. If the problem is seen using the quartz (native) Tk on Mavericks, it's very likely you are running into a critical Tk problem on Mavericks. There is a simple patch available that fixes the problem. https://trac.macports.org/ticket/41278 -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
In article , Samuel Halliday wrote: > On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: > >> what command line arguments do I use to get universal builds in my own > >> projects? > > > > add all the -arch flags (e.g. "-arch x86_64 -arch i386 -arch ppc64 -arch > > ppc") > > > I'm guessing these instructions are for the apple gcc? Because doing this > with the gcc / gfortran that I've been installing with macports gives > > gcc-mp-4.8: error: unrecognized command line option '-arch' > > and trying to compile C code on Mountain Lion with the apple gcc gives > > llvm-gcc-4.2: error trying to exec > '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: > No such file or directory > llvm-gcc-4.2: error trying to exec > '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: > No such file or directory > > > So I'm concluding it is impossible to build universal fortran apps since the > apple gcc doesn't come with gfortran. My only hope would be to build separate > binaries for each architecture by: > > 1. access to old OS X machines (+ macports) > 2. cross compile > > I don't have access to old machines (and it would be incredibly inconvenient > in any case), and I'm guessing macports doesn't supply cross compilers for > older OS X architectures. You *might* be able to build for all four architectures on Mountain LIon if you can successfully install a version of Xcode 3 (like 3.2.6) as a secondary Xcode and use the build tools and 10.5 SDK it provides. xcrun can help with this but I don't think MacPorts supports building with a non-installed SDK so you'd still be on your own. Another, more reliable option to consider is running an older version of OS X, like 10.5 server, as a virtual machine in VMware Fusion or similar. Be aware that the software license of 10.5 (non-server) prohibited use as a virtual client and Fusion does enforce that but the Interwebs tell of ways to get around that when running on a Mac host. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: py33-pyqt4 32 or 64 bit???
In article <5eec34c5-6900-47c4-b651-8252ed869...@macports.org>, Lawrence Velazquez wrote: > Install it universal and use arch(1) or ARCHPREFERENCES to select the desired > architecture for your Python. > > % sudo port install python33 +universal > % man arch Or, instead of "arch", use the command name "python3.3-32" instead of "python3.3". With 3.3, this has the advantage over "arch" by helping to ensure that any subprocesses are also launched in 32-bit mode. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts wants to install apple-gcc42 on 10.6 all of a sudden?
In article <0307d314-6374-4fbb-ac6d-7e229a5ba...@gmail.com>, "Rene J.V. Bertin" wrote: > On Apr 22, 2013, at 21:23, Ned Deily wrote: > > That's correct. xcode-select sets the defaults that are used by several > > other build tools, primarily xcodebuild and xcrun but it has no effect > > on what is installed in system locations. If you allowed the Xcode 4.2 > Yes. xcode-select is just a very basic script that updates a file, from which > in turn other scripts read the prefix to prepend to /usr/bin (etc) when > invoking the necessary commands. Just an extra indirection. I'm not sure I understand what you are saying there but, in general, the whole point of using xcode-select and its related tools is to avoid having to install anything in /usr/bin et al. They provide a mechanism to use the Xcode-supplied build tools, like clang or gcc-4.2, from an Xcode-specific location, either in the equivalent of /Developer (or wherever one has installed the instance of Xcode) or from within the Xcode.app bundle (for current Xcode 4's on 10.7+). xcrun and friends allow you to create a build process (Makefile or script) that has no dependencies on anything being installed outside of Xcode. I'm not aware of any third-party Makefiles that take direct advantage of that (I'm sure there are some) but, in many cases, it isn't *too* difficult to modify an autoconf-based build process to use it. But, unless one has some need to support multiple Xcode tools chains simultaneously on the same machine, it's much simpler to also have Xcode install the build tools in their customary system locations (/usr/bin). For current versions of Xcode, that option is not on by default, as Xcode.app itself does not need them to be installed when building Xcode-based projects. The defaults are such that Apple is assuming that developers are going to be building code primarily within Xcode, not by calling compilers directly. > > Installer to install the command tools package (I'm not sure what the > > package name is for Xcode 4.2), you would need to re-install the 3.2.6 > > UNIX Development package using the Xcode 3.2.6 Installer to get the > > proper executables and header files installed in /usr/bin, /usr/include, > > /System/Frameworks, et al. First, though, you should uninstall the 4.2 > > command tools by using the uninstaller script from the Xcode 4.2 > > /Developer directory: > > I think this applies only if you installed 4.2 to its default location. I > haven't had to do any of this - my Unix toolchain still uses the 3.2.6 > executables if I refer to the default tools, but Xcode 4.2 uses its own > versions from within its IDE. Exactly as I had hoped. It doesn't matter where Xcode itself is located since, essentially, Xcode.app does not depend on installing anything into system locations like /usr. What matters is whether a particular Xcode's command line tools package has been installed which makes the Xcode-provided build tools available from the command line in the system locations. Since each command line tools package installs to fixed locations (e.g. /usr/bin/cc etc), only one command line tools package can be installed at one time, and a given command line tool pacakge can only be installed on a specific OS X release. In other words, you could install Xcode 3.2.6 on OS X 10.8 along with Xcode 4.6.2 but, the command line tools package for 3.2.6 can only be installed on OS X 10.6. To use the 3.2.6 compilers from the command line on 10.8, you would need to use xcrun or construct its equivalent. > I must admit I hadn't thought about universal build implications of choosing > a non-Apple compiler. Curiously, the first port of which I installed a > universal variant was ffmpeg, and that package cannot (easily) be built as > universal by simply specifying the desired architectures. I've presumed that > Macports followed the same approach as Xcode, i.e. build each architecture in > parallel and then pull in (lipo) the resulting binaries. More cumbersome, but > if the build engine allows to do this it does have advantages (finer control > over compiler options). And of course it works with any compiler that > supports the desired architectures! Many third-party packages can be build universal out-of-the-box or with trivial modifications just by adding -arch arguments, thanks to the integration of the whole multiple builds and lipo process under the covers in the Apple-supplied compiler drivers. One has to be careful of autoconf-based builds that make decisions based on ./configure time tests that are run only in the default architecture. Those kinds of problems can be difficult to foresee. It can be safer to run the whole process build process in parallel, rather
Re: MacPorts wants to install apple-gcc42 on 10.6 all of a sudden?
In article ,
Lawrence Velázquez wrote:
> On Apr 22, 2013, at 10:16 AM, René J.V. Bertin wrote:
> > On Apr 22, 2013, at 15:12, Clemens Lang wrote:
> >> While it is uncommon to have multiple Xcode versions I guess if you have
> >> a patch to fix this we'd be happy to apply it.
> > As I said, I executed xcode-select /Developer to make Xcode 3.2 the default
> > again. Not sure what I should patch nor how for an automated fix.
> Note that (as far as I know) xcode-select does not swap out the tools
> installed to /usr/bin (the Command Line / UNIX Development tools), which are
> the tools that MacPorts generally uses for building.
That's correct. xcode-select sets the defaults that are used by several
other build tools, primarily xcodebuild and xcrun but it has no effect
on what is installed in system locations. If you allowed the Xcode 4.2
Installer to install the command tools package (I'm not sure what the
package name is for Xcode 4.2), you would need to re-install the 3.2.6
UNIX Development package using the Xcode 3.2.6 Installer to get the
proper executables and header files installed in /usr/bin, /usr/include,
/System/Frameworks, et al. First, though, you should uninstall the 4.2
command tools by using the uninstaller script from the Xcode 4.2
/Developer directory:
sudo /Library/uninstall-devtools --mode=unixdev
sudo /Library/uninstall-devtools --mode=systemsupport
That will leave the files in the Xcode 4.2 directory unchanged so it is
still possible to use the compilers and SDKs there using xcrun and
xcodebuild. To remove all of Xcode 4.2:
sudo /Library/uninstall-devtools --mode=all
Then run the 3.2.6 installer and customize to ensure that the "UNIX
Development" package is selected.
FTR, current versions of Xcode 4.x on 10.7 and 10.8 have moved the
management of the command line tools ("UNIX Development") to within the
expanded Xcode.app and do not use /Developer dirs.
--
Ned Deily,
n...@acm.org
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Python pip issue
In article , Ned Deily wrote: > cd ./ib/python2.6/site-packages/ cd ./lib/python2.6/site-packages/ -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Python pip issue
In article <77d0858c-1c68-4628-a4f4-5db5c7b0f...@alum.mit.edu>,
"Adam Dershowitz Ph.D., P.E." wrote:
> On Apr 2, 2013, at 7:10 PM, Brandon Allbery wrote:
> > On Tue, Apr 2, 2013 at 9:27 PM, Adam Dershowitz Ph.D., P.E.
> > wrote:
> > I have pip-2.6 installed, and I have used port select to make sure that
> > macport python26 is active. If I then do:
> >
> > This only works as expected if /opt/local/bin precedes /usr/bin in your
> > $PATH; you might want to doublecheck that.
> Thanks. I just checked and it is.
Also make sure you don't have a permissions problem. If you did a "sudo
pip install", the created directories and files may not be world
readable and executable. Check and, if necessary, alter the
permissions of the packages you installed:
sudo bash
cd /opt/local/Library/Frameworks/Python.framework/Versions/2.6
cd ./ib/python2.6/site-packages/
ls -ltr
Directories should be something like:
drwxr-xr-x 6 root wheel...
Files:
-rw-r--r-- 1 root wheel...
If not:
chmod -R o+rX ...
replacing ... with the directory and file names
--
Ned Deily,
n...@acm.org
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Looping on Python 2.7.3_1
In article <7108a9c5-5b17-4393-ac49-6631397e0...@macports.org>, Ryan Schmidt wrote: > On Nov 16, 2012, at 14:40, Alejandro Imass wrote: > > > When I do port install dosbox it tries to re-install Python 2.7.3_1 > > > > sudo port install dosbox > > ---> Computing dependencies for python27 > > ---> Staging python27 into destroot > > > > But Python is already installed: > > > > port installed python27 > > The following ports are currently installed: > > python27 @2.7.3_1 (active) > > python27 is installed non-universal (for x86_64 only). dosbox only builds > 32-bit. Therefore MacPorts is trying to rebuild python27 universal (for > x86_64 and i386). > > > > Also, the Python27 build fails because it can't find some shared > > objects (shoudl these be dylibs instead??). Here are some relevant > > parts of the main.log file: > > > > :info:destroot ImportError: > > dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pytho > > n2.7/site-packages/_xmlplus/parsers/pyexpat.so, > > 2): no suitable image found. Did find: > > :info:destroot > > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/si > > te-packages/_xmlplus/parsers/pyexpat.so: > > mach-o, but wrong architecture > > :info:destroot make[1]: *** [install_BuildApplet] Error 1 > > Could you file a bug report for that? This appears to be yet another instance of the problem reported in https://trac.macports.org/ticket/32090, At some point port py27-xml was installed. That port is now obsolete and has been deleted. You need to uninstall it and get rid of the conflicting pyexpat.so. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: readline + python + vi-editing-mode
In article <1350591062071-197263.p...@n4.nabble.com>,
laurence wrote:
> I'm trying to enable vi editing mode in readline in Python. Here's what I'm
> doing in an interactive Python session:
>
> >>> import readline
> >>> import rlcompleter
> >>> readline.parse_and_bind ("bind ^I rl_complete")
> >>> readline.parse_and_bind("tab: complete")
> >>> readline.parse_and_bind('set editing-mode vi')
>
> To test if it's working, I type a few words, and then tap ESC and 'b' a few
> times. That should take me back word-by word. On my Linux box this works as
> expected, but on my Mac with MacPorts it doesn't, and I don't understand
> why. Tapping b repeatedly moves me back one word, but then starts inserting
> b's, so it seems to be still in emacs mode.
>
> I thought I might have accidentally run the Apple build of Python (I know it
> has... issues with readline due to GPL), but it looks like I'm using the
> MacPorts version:
>
> >>> rlcompleter.__file__
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/rlc
> ompleter.pyc'
> >>> readline.__file__
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib
> -dynload/readline.so'
>
> Any ideas?
Did you install the py27-readline port? If not, modern Pythons on OS X
will link with the Apple-supplied BSD libedit which has a different
syntax for its bind commands. py27-readline replaces the Python
readline with one linked with the GNU libreadline. Some more info here:
http://stackoverflow.com/questions/7116038/python-tab-completion-mac-osx-
10-7-lion/7116997#7116997
--
Ned Deily,
n...@acm.org
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Django & virtualenv
In article <50376297.8090...@gmail.com>, Phil Dobbin wrote: > That did the trick. Now running: > > `$ django-admin.py` > > gets the desired result. Don't know if this mentioned anywhere in the > docs but if it isn't, maybe it should be. Probably at the tail end of > the install perhaps. Macports installs many Python scripts into /opt/local/bin but with a version suffix. For the Python 2.7 version of django, you should see: django-admin-2.7.py Also, there is no reason to be manually setting PTYHONPATH to the framework site-packages directory. That is normally always searched unless you are in a virtualenv and explicitly created it with --no-site-packages. Setting PYTHONPATH should be a rare event; there should almost always be a better way. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Mercurial
In article <501df382.4060...@gmail.com>, Phil Dobbin wrote: > I've just run selfupdate & got, amongst other things: > > `mercurial 2.2.3_0 < 2.3_0` > > so I ran upgrade outdated but now when I cd into my hg vim repo & run > `hg pull` it throws the error: > > `$ hg pull > abort: No module named repo!` hg 2.3 is working fine for me. Check your ~/.hgrc file and any repo-specific .hg/hgrc files for the stray use of the word "repo", for example in the [extensions] section. And make sure you don't have any PYTHON* environment variables set (like PYTHONPATH) that might be causing a problem. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: What has MacPorts Installed for py27-iPython?
In article <20120707183738.gb6...@macmini.kode5.net>, Jamie Paul Griffin wrote: > On Sat, Jul 07, 2012 at 10:19:28AM -0400, Arno Hautala wrote: > > On Sat, Jul 7, 2012 at 9:57 AM, Jamie Paul Griffin > > wrote: > > > > > > I experienced a similar issue when I installed pyzor (not from Macports > > > but build manually using the Macports installed python2.7) and the > > > binary pyzord was installed in: > > > > > > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pyzord > > > > > > You can just use a symlink to the binary into a directory in your path; > > > /opt/local/bin for example. > > > > It's probably not a good idea to put anything in /opt/local/bin > > If you link it as bin/pyzord, for example, and that port later starts > > linking into bin on it's own, you'll receive an activation error, and > > you'll most likely have forgotten that you linked it yourself and not > > understand the error. (apologies for any assumptions about your > > technical memory skills) > > > > It might be better to link into ~/local/bin or somewhere else that's > > completely under your control. > > It wasn't a port though, I built pyzor from source only I used the port > built python2.7 to build it so I can't forsee any issues there but it's a > good point > to remember none the less. Maybe i'm wrong, though? Another solution is to add the framework bin directory to your PATH: export PATH=\ /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin:$PATH or, possibly, to use the default MacPorts python: export PATH=\ /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:$PATH -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: progress on tickets?
In article <1cb3873b-a43c-4165-947e-99b2a929d...@macports.org>, Daniel Ericsson wrote: > On 16 jun 2012, at 16:20, Andrew Long wrote: > > > Just wondering if there was any progress on the following tickets:- > > > > 34742 - py27-sip > > I could reproduce this on a 10.7.4 Mac Pro with Xcode 4.3.2 last weekend and > the patch I attached to the ticked made it install. But I can't reproduce it > now on a 10.7.4 Macbook Pro with Xcode 4.3.3. Weird? > > The buildbot seems to have been able to make a binary archive since then as > well... > > $ sudo port -s -d -v install py27-sip > > DEBUG: Executing command line: cd > "/opt/local/var/macports/build/_Users_deric_Projects_macports-trunk_dports_pyt > hon_py-sip/py27-sip/work/sip-4.13.2" && > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 > configure.py -d > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 -e > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 > -v /opt/local/share/sip -p macx-g++ --bindir=/opt/local/bin > --destdir=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyth > on2.7/site-packages > --incdir=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/p > ython2.7 --sipdir=/opt/local/share/py27-sip > --sdk=/Applications/Xcode.app/Contents/Developer/SDKs/MacOSX10.7.sdk > LFLAGS="-F/opt/local/Library/Frameworks -L/opt/local/ > lib" > > > $ ls /Applications/Xcode.app/Contents/Developer > Documentation Headers Library Makefiles Platforms > ToolchainsTools usr In Xcode 4.3, the SDKs are located further down in platform-specific subtrees of Xcode.app. Although it's not very obvious from the man pages, it turns out there are canonical ways to find an SDK location with Xcode >=3: $ xcodebuild -version -sdk macosx Path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve loper/SDKs/MacOSX10.7.sdk $ xcodebuild -version -sdk macosx Path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve loper/SDKs/MacOSX10.7.sdk $ xcodebuild -version -sdk macosx10.6 Path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve loper/SDKs/MacOSX10.6.sdk $ xcodebuild -version -sdk macosx10.7 Path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve loper/SDKs/MacOSX10.7.sdk $ xcodebuild -version -sdk macosx10.5 Path xcodebuild: error: SDK "macosx10.5" cannot be located. $ DEVELOPER_DIR=/Devel_326 xcodebuild -version -sdk macosx Path /Devel_326/SDKs/MacOSX10.6.sdk $ DEVELOPER_DIR=/Devel_326 xcodebuild -version -sdk macosx10.5 Path /Devel_326/SDKs/MacOSX10.5.sdk etc. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Using MacPorts Python packages in different Python
In article <71147bab-dd71-4110-91d9-e7bb11370...@fusion.gat.com>,
Sterling Smith wrote:
> I do not use the Enthought python distribution, but in other python
> distributions the path that is searched for modules is affected by the
> PYTHONPATH environment variable, and is also accessible/editable in the
> python interpreter by
>
> import sys
> sys.path.append('/path/to/add/')
Something like that would likely work for pure Python modules. The
sticky problem is with C extension modules. To be able to reliably
share them between Python instances, you need to ensure that the two
Pythons were configured and built compatibly, i.e. same arch selections,
compatible ABIs (deployment target settings), same internal Unicode
settings (UCS-2 vs UCS-4), etc. Without auditing the code in the
extension module, it's nearly impossible to know ahead of time whether
there will be problems are not. An extension module might not be
importable without an exception (good) but (bad) it might work for days
until you hit some other path in your code. Most people decide it's not
worth the risk. If you need to use more than one Python instance,
install everything you need in each of them.
--
Ned Deily,
n...@acm.org
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Which version of "Wine", or am I on the wrong track?
In article , Bradley Giesbrecht wrote: > On Apr 15, 2012, at 10:56 AM, Michael_google gmail_Gersten wrote: > > I am not sure which version of Wine to install from Macports (there > > are three), or if this is even the right approach for what I want to > > do. > > > > The goal: Edit a "movie" (screen recording), from the view that 80-90% > > of what I recorded will be tossed. > > iMovie is a failure (as far as I can tell) as selecting sections and > > removing them. > > Pretty sure you can cut frames with iMovie. > > > This means I'm going to use VirtualDub (only program I've found so far > > that is good at selecting lots of specific frame ranges and tossing > > them). > > There are going to be better options for video editing on the Mac then > running a Windows program. > > Quicktime Pro Player has been able to cut video many years. The pro version > used to cost $35. > > Have you looked at the MacPorts ports for Avidemux and Kdenlive. Or the free app MPEG Streamclip? "You can use MPEG Streamclip to: open most movie formats including MPEG files or transport streams; play them at full screen; edit them with Cut, Copy, Paste, and Trim; set In/Out points and convert them into muxed or demuxed files, or export them to QuickTime, AVI, DV and MPEG-4 files" http://www.squared5.com/svideo/mpeg-streamclip-mac.html -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: spe for Python 2.7? -> getting closure on a patch
In article , Dave Curtis wrote: > Unfortunately, my 'invoke Python via arch i386' patch will break on PPC. > Ryan suggests below that one way to fix this is to turn off the universal > variant. That seems to me to be the best solution -- are there large numbers > of people that will care about having an i386/ppc universal build of SPE? > I'm guessing not. On 10.4 through 10.6 systems (I believe - tested for sure on 10.5), the arch command takes multiple arch values and uses the first applicable one. So "arch -i386 -ppc /path/to/exectable" may do what you want. The 10.7 version of arch also accepts multiple archs but it emits the message "warning: unsupported architecture: ppc". OTOH, the 10.7 arch has "-32" and "-64" arguments which work as expected. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: python 2.7, import wx says "wrong architecture"
In article , Ryan Schmidt wrote: > On Mar 22, 2012, at 10:51, Dave Curtis wrote: > > > Idle is an IDE, done using Python's TK interface components. It is the > > default IDE for Python that is more-or-less guaranteed to be present with > > Python. > > > > I'm not familiar with the guts of it, but I presume it is picking up a > > Python through whatever pointer mechanism python-select uses -- again I'm > > not expert in the mechanics of that either. I'll have to go research idle > > configuration settings. > > Hopefully idle does *not* pick up python via the version that the user > selected; if it did, that would be a bug in the port that we would want to > fix. idle should use the specific version of python that it is designed to > work with. idle is just a small shebang script copied from the version-specific shebang script, i.e. idle2.7, idle3.2, et al. The appropriate specific interpreter shebang path is built into the version-specific idle script and "port select python" symlinks "idle" to the selected "idlem.n" script. So it appears to be doing the right thing. One could quibble about creating separate "python" and "python3" select groups, including separate "idle" and "idle3" symlinks and including a "python2" symlink, as recommended in the recent PEP 394 (http://www.python.org/dev/peps/pep-0394/). The issue here, though, is simply that, although universal builds of Python 2.7+ and 3.2+ support arch selection with /usr/bin/arch, Python does not ensure that any subprocesses with a Python interpreter that are launched are forced to be the same execution arch as the main interpreter. One such case is here when IDLE launches a subprocess; it just defaults to the system-preferred arch (usually x86_64 on 10.6+). There may be other cases of this. I have a note to myself to track them down and possibly fix it upstream. But I don't think it's a major issue. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What provides xcodebuild?
In article , Brandon Allbery wrote: > haral:6722 Z$ pkgutil --file-info =xcodebuild | grep pkgid > pkgid: com.apple.pkg.DeveloperToolsSystemSupportLeo > pkgid: com.apple.pkg.update.os.10.7.3.11D50b.combo > > The former is part of Xcode, the latter would be best obtained by > downloading the latest combo updater from Apple. (Is it me or did Apple > confuse things rather badly by doing that?) I think the idea is that xcodebuild et al are supposed to be independent of the release of Xcode; they act as a wrapper and pointer to the various Xcode versions since it is supported to have multiple versions of Xcode installed on the same system (although only one version of the command line tools active in /usr/bin at one time). So rather than having each version of Xcode supply duplicate copies of xcodebuild, it's supplied with OS X itself; that also means those commands are available to query even if no Xcode is installed. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: python 2.7, import wx says "wrong architecture"
In article , Dave Curtis wrote: > arch -i386 idle2.7 > > now works! But it appears to start a 64 bit version of Python in a 32 bit > IDE, because when I > > import wx > > it gives me the "wrong arch" message. > How do I force 32 bit idle2.7 to start 32 bit python? > Or for that matter, shouldn't I be able to get 64 bit idle to start 32 bit > python? That probably makes a little more sense. The easiest way is to tell IDLE to run without a subprocess using its -n argument: $ arch -i386 idle2.7 -n OTOH, I'm not sure that running wx applications under IDLE (a Tk application) is a good idea. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What/where Xcode 4.0.2 for Macports install in Snow Leopard?
In article , Dominik Reichardt wrote: > Ok, on the SL machine with my App Store account with which I bought Xcode 4.0 > back then on SL: > > In the purchased list I see two Xcode apps to install: > - Xcode (which is the one you can find in the store through searching and > which will not even download on SL because it is for Lion only) > - Xcode for Snow Leopard > > Clicking on the icon for Xcode for snow Leopard will produce an error that > the App Store can't finish the request (since there is no actual application > page for that). > Clicking on install will download it correctly and looking at the content it > is indeed Xcode 4.2, so it is safe to assume that whoever purchased Xcode 4.0 > will always be up to date with the Xcode 4.x that Apple offers in the > developer members area. > However I did *not* install it since I want to keep that SL machine in a > default user condition without any developer stuff so I can be assured that > apps built on my development machine do actually run on a default machine :) Thanks very much, Dom, for investigating! Your findings are what I thought would be the most likely case, under the circumstances. Unfortunately, that means those of us supporting open-source projects do need to worry about both Xcode 3.2 and 4.2 on Snow Leopard as well as 4.2 on Lion. Apple certainly has made life *interesting*. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What/where Xcode 4.0.2 for Macports install in Snow Leopard?
In article <4ed29c1c.2010...@gmail.com>, Murray Eisenberg wrote: > But I _did_ install Xcode 4.0.2. I can run it! OK, so getting back to your original question: > I'm running Xcode 4.0.2 under OS X 10.6.8. Tried to install from > MacPorts-2.0.3.pkg. Get error message > "Xcode is not installed, or was installed with UNIX > Development (10.5+) or > Command Line Support (10.4) deselected. at what point in the MacPorts installation process do you get the error message? And, just to make sure, what happens when you type: /usr/bin/gcc-4.2 --version -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What/where Xcode 4.0.2 for Macports install in Snow Leopard?
In article , Dominik Reichardt wrote: > Yes if you want to purchase it now you can't > BUT if you got it back then it still shows in the purchase tab of the app > store app as "Xcode for Snow Leopard". At least it does show for me and also > shows as updated, so I guess it's the same as the one you can get from the > developer page. Interesting! I didn't purchase Xcode 4 for Snow Leopard through the App Store when it was available so I haven't been able to verify this myself. I've seen conflicting reports from others who did. What I think everyone agrees on is that, if you did not purchase Xcode 4.0 for SL when it was available prior to the release of Lion, you can no longer purchase it through the Mac App Store - period. The open question - and one that I would love to get a definitive answer to - is, if you *did* purchase Xcode 4.0 for SL while it was for sale in the App Store *and* you are still running SL, what is now available to you for downloads for SL from the App Store? Is it: 1) still Xcode 4.0 for SL 2) Xcode 4.x for SL 3) Xcode 4.x for Lion 4) none of the above Can anyone else who is still running 10.6 SL and who purchased Xcode 4 through the App Store say what happens when they try to download Xcode 4 from the App Store now (or since Xcode 4.2 was released)? In any case, for most users, I would still recommend sticking with Xcode 3 for 10.6 SL. That's what 10.6 itself was built with. There are some specific use cases where you really need to use Xcode 3 on 10.6, for example, if you are trying to build something on 10.6 to run on 10.5 or older versions of OS X and need to support all machines (i.e. PPC-based ones). You can even get into trouble with things like installing C extension modules for the Apple-supplied system Python, because most system software on 10.6 includes PPC archs for compatibility. Yes, there are workarounds for many of these issues but, by using Xcode 3, you avoid the problems altogether. The other solution is to join Apple's paid Mac Developers program which I gather does make newer versions of Xcode available for 10.6. But not everyone is willing or able to do that. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What/where Xcode 4.0.2 for Macports install in Snow Leopard?
In article <4ed2858c.80...@gmail.com>, Murray Eisenberg wrote: > But the current Xcode 4.2.1 requires Lion (OS X 10.7) and, as I said, > I'm running Snow Leopard 10.6.8. Apple made a version of Xcode 4.0 available to the public through the Mac App Store for a period prior to the launch of Lion which requires Xcode 4. I believe their motive was to give people who were not part of the paid Mac Developer program to get a taste of what was coming with Xcode 4 in Lion (i.e. removing PPC support and older SDKs and moving from plain gcc to llvm-gcc and eventually clang). However, once Lion was released, they replaced Xcode 4.0 in the App Store with Xcode 4.1 which is only supported on Lion, leaving the adventurous Xcode 4.0 Snow Leopard users scratching their heads. Unless you really need something from Xcode 4.0, your best bet on Snow Leopard is to go back to Xcode 3, the standard for 10.6. Xcode 3.2.6 is available for free download from the Apple Developer Center website after free registration. At the ADC web site, click on the Resources link (http://developer.apple.com/resources/) and then on "Mac OS X Downloads" (which will require you to login). -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Forum?
In article <2eeae4b8-f2c2-4646-8b66-1f752fc78...@geeklair.net>, "Daniel J. Luke" wrote: > On Oct 11, 2011, at 12:47 PM, Andrew Todd wrote: > > On Tue, Oct 11, 2011 at 12:30 PM, Dominik Reichardt > > wrote: > >> Anyway, I'd prefer a forum, it probably could be done as the libSDL people > >> have done it, that the forum and ML go to the same address (ML posts go to > >> the forum, forum posts go to the ML). > > > > Honestly, I'd just like to see the ML configured so that the default > > reply-to address is the list email rather than the author's email. > and I want a pony ;-) > > reply-to munging comes up every once a a while, but there are various good > reasons for not doing it (google "reply to considered harmful" if you're > curious). > > Since MacPorts is an all volunteer project, there's nothing stopping anyone > from creating a web forum and having discussions there. > > It's just a matter of having enough interested people so that there's a group > willing to answer questions/give advice/whatever. > > I personally probably won't participate in a web forum, just like I don't > participate in the IRC channel - but that doesn't mean that places outside of > the mailing list(s) aren't useful places to go... Note that this mailing list, along with several other MacPorts lists, is two-way mirrored at gmane.org. That means you can read and post to the list via a conventional (NNTP) news reader or via a couple of different web formats. You can also read via RSS feeds. http://gmane.org/find.php?list=macports http://dir.gmane.org/gmane.os.apple.macports.user -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Installation of psycopg2
In article , Ryan Schmidt wrote: > On Oct 6, 2011, at 07:19, David Rippel wrote: > > (/Library/Frameworks/Python.framework/Versions/2.7/bin/python)? > That's actually the MacPorts python 2.7 right there, assuming your > frameworks_dir is set to its default value of /Library/Frameworks. No, that's another Python, possibly installed from python.org or built from source. The default location for the MacPorts Python frameworks is: /opt/local/Library/Frameworks/Python.framework ... And the Apple-supplied system Pythons are in: /System/Library/Frameworks/Python.framework .. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: python IDE?
In article , mark brethen wrote: > spyder and python toolkit (PTK) provide MATLAB-like features. I found on the > spyder web page a link to macports py26-spyder. Will py26 interfere with py27 > already installed under macports? You can have both installed but you'll need to install py26 versions of all the ports you need. Since it appears spyder is supported on Python 2.7, you could also file a MacPorts ticket to request a py27-spyder port. https://trac.macports.org/auth/login/?next=/newticket -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: python IDE?
In article <5855904b-5153-4d72-ba09-dc597aea6...@aim.com>, mark brethen wrote: > With all the python ports available (I've installed numpy, sympy and > matplotlib) are there any IDE ports? If not, what alternatives can you > recommend? IPython is closely associated with Numpy and scientific and numeric processing. http://ipython.org/ http://www.macports.org/ports.php?by=name&substr=ipython There is the venerable but still useful IDLE that is included with Python. You'll need to install the Tkinter port for the corresponding Python port: http://www.macports.org/ports.php?by=name&substr=tkinter (Also, currently the MacPorts Tk is an X11-based one. There are more native Tk ones available with other Python installations like the python.org OS X installers.) -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: py26-enchant missing lib '_md5'
In article , Philip Hudson wrote: > Titanium PowerBook G4, 1GHz, OS 10.5.8 > > > :info:destroot File "/opt/local/Library/Frameworks/ > > Python.framework/Versions/2.6/lib/python2.6/hashlib.py" > > , line 63, in __get_builtin_constructor > > :info:destroot import _md5 > > :info:destroot ImportError: No module named _md5 > > :info:destroot shell command " cd "/opt/local/var/macports/build/ > > _opt_local_var_macports_sources_rsync.macpo > > rts.org_release_ports_python_py26-enchant/work/pyenchant-1.6.5" && / > > opt/local/Library/Frameworks/Python.fram > > ework/Versions/2.6/bin/python2.6 setup.py --no-user-cfg install -- > > prefix=/opt/local/Library/Frameworks/Pytho > > n.framework/Versions/2.6 --root=/opt/local/var/macports/build/ > > _opt_local_var_macports_sources_rsync.macports > > .org_release_ports_python_py26-enchant/work/destroot " returned > > error 1 > > :error:destroot Target org.macports.destroot returned: shell command > > failed (see log for details) > > :debug:destroot Backtrace: shell command failed (see log for details) > > while executing > > "command_exec destroot" > > (procedure "portdestroot::destroot_main" line 2) > > invoked from within > > "$procedure $targetname" > > :info:destroot Warning: the following items did not execute (for > > py26-enchant): org.macports.activate org.ma > > cports.destroot org.macports.install > > :error:destroot Failed to install py26-enchant > > :notice:destroot Log for py26-enchant is at: /opt/local/var/macports/ > > logs/_opt_local_var_macports_sources_rs > > ync.macports.org_release_ports_python_py26-enchant/main.log > > Googled lots, going round in circles: hashlib, openssl, md5, _md5, > wtf... doesn't seem to make a difference whether OS X Python or > MacPorts Python is first on $PATH... IIRC, in Python 2.6, it was possible to get the building of hashlib confused when building Python. Basically, at build time, it tries to find openssl and build hashlib to link with it. If it can't find the openssl lib, it builds its own versions and that's what _md5 is supposed to be. But sometimes it could get it wrong but I don't remember the exact sequence. Possibly one way could have been a conflicting version of openssl in /usr/local/lib, However, you should be able to get it to build and work properly (among other platforms, I have it on a G4 running 10.5). I'd suggest the following steps: First, check to see that you don't have a version of openssl in /usr/local/bin. ls -l /usr/local/lib/libssl* If you do, figure out if you really need it and either delete it or rename it out of the way before going on to the next steps. sudo port selfupdate sudo port -f uninstall python26 sudo port -f uninstall openssl sudo port install openssl sudo port install python26 -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: py26-numpy is much slower than NumPy compiled for MacPython
In article , Konrad Hinsen wrote: > Somewhat by accident I noticed an enormous speed difference in basic NumPy > operations between my MacPorts installation (py26-numpy) and the NumPy 1.5.1 > binaries from the NumPy sourceforge site used with MacPython 2.6, also > downloaded as a binary. > > ~/projects/solar_system> /usr/local/bin/python bench2.py > CPU time: 16 s > ~/projects/solar_system> /opt/local/bin/python bench2.py > CPU time: 45 s > > The script bench2.py is attached. I wonder what could cause this big > difference. No BLAS operations are used, so the difference in BLAS > implementation should not matter. In fact, all that happens is allocation of > a big array and lots of float subtractions. > > Did anyone look into this already? Could it be 64-bit vs 32-bit? The python 2.6 from a python.org installer (I assume that's what you mean by MacPython) is built as 32-bit only. If you build python 2.6 with MacPorts it will likely be 64-bit by default on OS X 10.6. You might try asking on the numpy mailing list as people there are more likely to have experience with the performance trade-offs: http://dir.gmane.org/gmane.comp.python.numeric.general -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
