Re: Latest Wireshark crashes on startup
On Mar 11, 2015, at 5:02 AM, Mark Lucas mlli...@arc.co.uk wrote: The latest MacPorts upgrade to Wireshark 1.12.4, which updated without a problem, now reliably crashes when trying to start it up. Previous version worked fine. I have the Wireshark app 1.99.2 also installed which still works ok. When starting from the terminal MacPorts Wireshark crashes with;- Segmentation fault: 11 The start of the OS X crash log reports;- Process: wireshark [6175] Path:/opt/local/bin/wireshark Identifier: wireshark Version: 0 Code Type: X86-64 (Native) Parent Process: bash [6165] Responsible: Terminal [6161] User ID: 501 Date/Time: 2015-03-11 08:46:12.820 + OS Version: Mac OS X 10.9.5 (13F1066) Report Version: 11 Anonymous UUID: 0EA542C5-0225-B550-A26F-14062DC83078 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xd884e000 VM Regions Near 0xd884e000: -- shared memory 7ff83000-7ff84000 [4K] r-x/r-x SM=SHM Application Specific Information: wireshark 1.12.4 (Git Rev Unknown from unknown) Compiled (64-bit) with GTK+ 2.24.25, with Cairo 1.14.0, with Pango 1.36.8, with GLib 2.42.2, with libpcap, with libz 1.2.8, without POSIX capabilities, with SMI 0.4.8, without c-ares, with ADNS, with Lua 5.2, without Python, with GnuTLS 3.3.13, with Gcrypt 1.6.3, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Feb 8 2014 04:53:37), with AirPcap. Running on Mac OS X 10.9.5, build 13F1066 (Darwin 13.4.0), with locale en_GB.UTF-8, with libpcap version 1.6.2, with libz 1.2.8, GnuTLS 3.3.13, Gcrypt 1.6.3, without AirPcap. Intel(R) Xeon(R) CPU E5520 @ 2.27GHz Built using clang 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57). Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libgobject-2.0.0.dylib0x000110e1f855 g_type_check_instance_is_fundamentally_a + 11 1 libgobject-2.0.0.dylib0x000110e0a959 g_object_ref + 19 2 libglib-2.0.0.dylib 0x000110e70961 g_list_foreach + 34 3 libgtk-x11-2.0.0.dylib0x0001106ae560 gtk_window_set_icon_list + 95 4 wireshark 0x00010c41f09f window_icon_realize_cb + 190 5 libgobject-2.0.0.dylib0x000110e05b3a g_closure_invoke + 272 6 libgobject-2.0.0.dylib0x000110e18eee signal_emit_unlocked_R + 2135 7 libgobject-2.0.0.dylib0x000110e19af8 g_signal_emit_valist + 1948 8 libgobject-2.0.0.dylib0x000110e1a23a g_signal_emit + 134 9 libgtk-x11-2.0.0.dylib0x0001106a05ee gtk_widget_realize + 201 10 wireshark 0x00010c3de33f splash_new + 37 11 wireshark 0x00010c4259e0 main + 1046 12 libdyld.dylib 0x7fff8aa905fd start + 1 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0xd884e000 rcx: 0x0004 rdx: 0x rdi: 0xd884e000 rsi: 0x0050 rbp: 0x7fff538412c0 rsp: 0x7fff538412c0 r8: 0x r9: 0x7fff53840a00 r10: 0x0001108104c0 r11: 0x0001106ae501 r12: 0x7f9ada3004f0 r13: 0x7f9ad843b660 r14: 0x r15: 0x000110e0a946 rip: 0x000110e1f855 rfl: 0x00010286 cr2: 0xd884e000 Logical CPU: 6 Error Code: 0x0004 Trap Number: 14 Is anyone else seeing this? ___ Yes, I also did the update, but hadn’t tested it until I saw your email. Mine also won’t run at all and gives a segmentation fault 11. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Undo universal?
On Aug 20, 2014, at 1:22 PM, Joshua Root j...@macports.org wrote: I had OpenSceneGraph installed, but, for another application I was testing, I needed a universal version. So, I did sudo port install OpenSceneGraph +universal It then proceeded to upgrade MANY things to universal. I hadn’t realized how many dependencies there were. My question is, is there a way to undo that? If I am done with that testing, so I no longer need the universal version of OpenScenegraph (and then the many dependencies). If I just do: sudo port deactivate OpenSceneGraph +universal sudo port activate OpenSceneGraph sudo port uninstall OpenSceneGraph +universal I believe that it would remove that one thing. But, it won’t then follow all the dependencies. Is there any way to make all the dependencies that would no longer have to be universal be removed and just have the original versions made active? Essentially I am looking for a command: Make OpenSceneGraph and all dependents no longer universal What about: sudo port upgrade --enforce-variants OpenSceneGraph -universal - Josh I believe that would just change OpenSceneGraph, not the 35 or so dependents. Can anyone verify? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Undo universal?
I had OpenSceneGraph installed, but, for another application I was testing, I needed a universal version. So, I did sudo port install OpenSceneGraph +universal It then proceeded to upgrade MANY things to universal. I hadn’t realized how many dependencies there were. My question is, is there a way to undo that? If I am done with that testing, so I no longer need the universal version of OpenScenegraph (and then the many dependencies). If I just do: sudo port deactivate OpenSceneGraph +universal sudo port activate OpenSceneGraph sudo port uninstall OpenSceneGraph +universal I believe that it would remove that one thing. But, it won’t then follow all the dependencies. Is there any way to make all the dependencies that would no longer have to be universal be removed and just have the original versions made active? Essentially I am looking for a command: Make OpenSceneGraph and all dependents no longer universal --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Undo universal?
On Aug 19, 2014, at 3:05 PM, Ryan Schmidt ryandes...@macports.org wrote: On Aug 19, 2014, at 9:36 AM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: I had OpenSceneGraph installed, but, for another application I was testing, I needed a universal version. So, I did sudo port install OpenSceneGraph +universal It then proceeded to upgrade MANY things to universal. I hadn’t realized how many dependencies there were. My question is, is there a way to undo that? If I am done with that testing, so I no longer need the universal version of OpenScenegraph (and then the many dependencies). If I just do: sudo port deactivate OpenSceneGraph +universal sudo port activate OpenSceneGraph sudo port uninstall OpenSceneGraph +universal I believe that it would remove that one thing. But, it won’t then follow all the dependencies. That is correct. Is there any way to make all the dependencies that would no longer have to be universal be removed and just have the original versions made active? Essentially I am looking for a command: Make OpenSceneGraph and all dependents no longer universal There's not an automatic way to do that, no. If you still have the non-universal versions installed, you can just reactivate them. Otherwise you will have to reinstall them. It might be neat to have a script to automate this. It could notice if you have any universal ports installed that aren't required to be universal and offer to reinstall them non-universal. -- I do have them. But, it would be great to be able to use a script, as you suggested. Right now, I think the only way is make a note of everything that go switched to universal, by looking at the console output, and manually activating the other version. I guess it is just something else for the wish list. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: selfupdate fails trying to synch with openmodelica (!)
On Jul 10, 2014, at 1:41 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 9, 2014, at 11:01 PM, Adam Dershowitz de...@alum.mit.edu wrote: No. They do use existing standard ports. So openmodelica does require certain macporys dependencies, not its own separate copies. I don't know about Qt, and don't have access to check at the moment. But, my guess is that they are using the standard macport Qt, not a redundant one. I know that for a bunch of other things they just use the macport port so there is no redundancy. They have even worked on some ports to get them upgraded to get things to work together. The only reason that I could see any redundant versions is if they require some specific version that macports doesn't have. And doing that would be tricky to avoid any conflicting versions. I think that you have a bit of a misunderstanding. You could, for example create your own port file of something, and just keep that file locally (see the macport instructions). That port could then have other dependencies that are included with macports. All they have done is put their port file, instead, on their server, and you can then use it by adding it to your sources file. No redundant files involved, and no extra disk space. A port file is just a text file that explains where to find files, and how to build. Part of that how is what other ports are required to be installed. If someone were able to copy the current port file from their server to macports the build would be identical in size and dependents. My guess is that the reason they haven't done that is because the release version is a bit behind, and the develop version is changing every day. But I don't know for sure. Adam, Jerry is correct. The binary distribution provided on the openmodelica web site, though created with MacPorts, installs the MacPorts-provided dependencies into a separate prefix /opt/openmodelica, not the normal MacPorts prefix /opt/local. This is exactly as we at MacPorts would recommend for a third party wanting to distribute a standalone installer so that it will not conflict with an existing MacPorts installation. Jerry is correct that, would the openmodelica developers instead submit their portfile to be included in the standard MacPorts ports tree, then openmodelica could be installed by using existing MacPorts dependencies (in /opt/local or whatever the user's prefix is), and would not need separate copies thereof in /opt/openmodelica. The user can already accomplish this however by setting up a second sources entry in their sources.conf pointing to the openmodelica rsync server, which is in fact what Jerry had done and is what prompted him to begin this thread, when the openmodelica rsync server was temporarily offline. You can read more about all of this at: https://www.openmodelica.org/index.php/download/download-mac Perhaps we just were not communicating clearly. I was not talking about the binary, and I didn’t think that Jerry was either (perhaps I am mistaken). He was suggesting that they make an “official port file” and they already have one. They just keep it on their own server. The instructions on that page make it clear, as you said. The reason that I believe the binary had nothing to do with Jerry’s comments is because if he was using the binary he would not have run into the rsync problem when their server went down. That problem was purely from trying to download the source port file, which, as I have said, takes up the same amount of space whether on their server or the macports server. I did verify that their port does just use the existing qt4-mac port, for example, so their is no redundancy in Qt, as Jerry had suggested. But, I do understand that if someone installs the binary, then they are not using Macports for the install, and will be downloading a whole bunch of stuff that they might already have. The port file for openmodelica-devel changes many times a day. So, I assume that they have a script that auto generates it, on their server, for every change in their development branch. I have been using their development branch with macports, for a while now, and it has tended to work well. As it is devel, there are occasional problems, but they have always been very quick to fix them, and keep it building. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: selfupdate fails trying to synch with openmodelica (!)
On Jul 10, 2014, at 5:20 PM, Jerry lancebo...@qwest.net wrote: On Jul 10, 2014, at 6:08 AM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: On Jul 10, 2014, at 1:41 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 9, 2014, at 11:01 PM, Adam Dershowitz de...@alum.mit.edu wrote: No. They do use existing standard ports. So openmodelica does require certain macporys dependencies, not its own separate copies. I don't know about Qt, and don't have access to check at the moment. But, my guess is that they are using the standard macport Qt, not a redundant one. I know that for a bunch of other things they just use the macport port so there is no redundancy. They have even worked on some ports to get them upgraded to get things to work together. The only reason that I could see any redundant versions is if they require some specific version that macports doesn't have. And doing that would be tricky to avoid any conflicting versions. I think that you have a bit of a misunderstanding. You could, for example create your own port file of something, and just keep that file locally (see the macport instructions). That port could then have other dependencies that are included with macports. All they have done is put their port file, instead, on their server, and you can then use it by adding it to your sources file. No redundant files involved, and no extra disk space. A port file is just a text file that explains where to find files, and how to build. Part of that how is what other ports are required to be installed. If someone were able to copy the current port file from their server to macports the build would be identical in size and dependents. My guess is that the reason they haven't done that is because the release version is a bit behind, and the develop version is changing every day. But I don't know for sure. Adam, Jerry is correct. The binary distribution provided on the openmodelica web site, though created with MacPorts, installs the MacPorts-provided dependencies into a separate prefix /opt/openmodelica, not the normal MacPorts prefix /opt/local. This is exactly as we at MacPorts would recommend for a third party wanting to distribute a standalone installer so that it will not conflict with an existing MacPorts installation. Jerry is correct that, would the openmodelica developers instead submit their portfile to be included in the standard MacPorts ports tree, then openmodelica could be installed by using existing MacPorts dependencies (in /opt/local or whatever the user's prefix is), and would not need separate copies thereof in /opt/openmodelica. The user can already accomplish this however by setting up a second sources entry in their sources.conf pointing to the openmodelica rsync server, which is in fact what Jerry had done and is what prompted him to begin this thread, when the openmodelica rsync server was temporarily offline. You can read more about all of this at: https://www.openmodelica.org/index.php/download/download-mac Perhaps we just were not communicating clearly. I was not talking about the binary, and I didn’t think that Jerry was either (perhaps I am mistaken). He was suggesting that they make an “official port file” and they already have one. They just keep it on their own server. The instructions on that page make it clear, as you said. The reason that I believe the binary had nothing to do with Jerry’s comments is because if he was using the binary he would not have run into the rsync problem when their server went down. That problem was purely from trying to download the source port file, which, as I have said, takes up the same amount of space whether on their server or the macports server. I did verify that their port does just use the existing qt4-mac port, for example, so their is no redundancy in Qt, as Jerry had suggested. But, I do understand that if someone installs the binary, then they are not using Macports for the install, and will be downloading a whole bunch of stuff that they might already have. The port file for openmodelica-devel changes many times a day. So, I assume that they have a script that auto generates it, on their server, for every change in their development branch. I have been using their development branch with macports, for a while now, and it has tended to work well. As it is devel, there are occasional problems, but they have always been very quick to fix them, and keep it building. Well, let's all agree that I barely know what I'm talking about. My file at /opt/local/etc/macports/sources.conf contains two non-comment lines: rsync://rsync.macports.org/release/tarballs/ports.tar [default] rsync://build.openmodelica.org/macports/ I don't know how the second line appeared since I _think_ I have not messed with openmodelica since last installing MacPorts. Should
Re: conflict with macports
Just an update on this issue. It sounds like they are both responsive and making progress. Mark, you probably received the same email as I did: I've got good news. Currently it looks like I got it working from /opt/Z88Aurora by using MacPorts to install all relevant libs. There are just some icons missing and I'll have to clean the /opt/Z88Aurora folder from all unnecessary MacPorts files to get it down in size, but then we should be able to release a version which does not interfere with MacPorts. And a whole lot of testing has to be made as well :-( This will take its time. I'll get in touch with you when I'm finished. P.S. Another MacPorts user, with whom you are in contact through macports mailing list, also got this email. I just haven't found the time to search through these lists and create an account of my own, so please share this information if he does not. Kind regards from Bayreuth, --Adam On Jun 11, 2014, at 1:00 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: I just want to add, that I have now had a few emails with Z88 support as well. While it seems that he is not the primary developer, and English is not his native language (and I speak no German), he has been very understanding and supportive. I concur that they now do understand the problem and have said that they are going to fix it. Probably by moving all of their required libraries into the same directory structure as they have for their application, instead of having two different installers into two different locations (one of which is /opt/local). They do a bunch of testing of their functionality before they do releases, so it might be a little while before they get things fixed and released. But, I am looking forward to trying Z88 out. --Adam On Jun 11, 2014, at 11:12 AM, Brethen, Mark Douglas. (MSFC-ER41)[ESSSA] mark.bret...@nasa.gov wrote: Received another response from the z88 developer this morning, and it looks like they are going to resolve the problem one way, or another. I did follow up with his question in regard to running z88 without using their GTK+ package, and mentioned the outdated png library. There may be other issues as well, such as missing fonts and icons, etc. Thanks, Mark -Original Message- From: Z88Aurora Support [mailto:z88aur...@uni-bayreuth.de] Sent: Wednesday, June 11, 2014 8:06 AM To: Brethen, Mark Douglas. (MSFC-ER41)[ESSSA] Subject: AW: conflict with macports Dear Mr. Brethen, I just tried to install MacPorts and GTK+ after Z88Aurora, which resulted in overwriting most of the GTK+ 2.0 files used for Z88. But Z88Aurora still runs perfectly, just some icons are missing. Have you tried running Z88Aurora without using our GTK4Z88 package? Just install GTK2 via MacPorts and try for yourself, maybe it helps. Another issue regarding GTK3 exists, which results in Z88Aurora not working at all. So if you have GTK3 installed, it is not possible to run Z88Aurora without massive errors. Again, there is a much more simple approach to run Z88Aurora while not breaking MacPorts: use two /opt/local directories and just rename them before you run the software. For Z88Aurora, rename /opt/local to /opt/local_macports and /opt/local_Z88 to /opt/local (Or use aliases) For Macports vice versa...you just can't use macports and Z88Aurora the same time. We are looking into the problem and may be solving this issue with the next release, but this will take some months to become available to the public. I hope this was of some help to you. Kind regards from Germany, S. Hautsch Support Z88Aurora Lehrstuhl für Konstruktionslehre und CAD Universität Bayreuth Universitätsstraße 30 95447 Bayreuth E-Mail: z88aur...@uni-bayreuth.de Internet: www.z88.de -Ursprüngliche Nachricht- Von: Brethen, Mark Douglas. (MSFC-ER41)[ESSSA] [mailto:mark.bret...@nasa.gov] Gesendet: Dienstag, 10. Juni 2014 15:04 An: Z88Aurora Support Betreff: Re: conflict with macports Hello, Macports is a package manager similar to those used on linux systems. Mac users can install and maintain all sorts of open-source software. For instance, I have already used it to maintain a GTK+ package on my mac. Files written into the MacPorts prefix (/opt/local by default) by 3rd-party software leads to errors and could necessitate reinstalling macports. Please consider either to move the location of the libraries (e.g. /opt/z88), and require your own GTK+ package, or to use the newer versions of the libraries, so that a Macports install with up-to-date libraries would cover it. Then the extra install would be optional. Thanks, Mark -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ macports-users mailing list macports-users
Re: conflict with macports
On Jun 11, 2014, at 8:15 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 10, 2014, at 8:16 AM, Mark Brethen wrote: Response from z88 developers below. I followed up with the suggested fixes already mentioned in this group. Begin forwarded message: From: Z88Aurora Support z88aur...@uni-bayreuth.de Subject: AW: conflict with macports Date: June 10, 2014 at 2:32:41 AM CDT To: deleted Hello Mr. Brethen, unfortunately, it is not possible to simply change the location of the GTK+ files. Yes, it is possible for the people who packaged this Z88Aurora distribution to repackage it with files in a different location, and as we've discussed previously, that's what they must do to fix this conflict with MacPorts. To run Z88Aurora, you need the GTK+ package to be installed to /opt. I don’t know much about MacPorts, but how does the GTK+ package interfere with this? GTK+ will create the following folders/files: /opt/local [snip] Please ensure that this will not interfere with the existing MacPorts files in /opt and you will be fine. Installing files to /opt/local does interfere with MacPorts; they must not install files there. They are welcome to invent another prefix of their own choosing into which to put their files. Directories under /opt are a common choice. /opt/z88 or /opt/aurora for example would be fine choices. /opt/local is a poor choice because that has already been chosen by MacPorts. I also just received a response from the Z88 support. He explained that they do see the necessity to work on the problem, but that I will have to wait until the next release because he claims that they will have to make changes in their source code. I emphasized the significance of the dangers in their installation instructions, and suggested that they at least add a warning about installing with MacPorts until they get it fixed. So, it sounds like they are now aware of the problem and will try to fix it. I have no idea about a timeline. —Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: z88 Aurora
--Adam On Jun 8, 2014, at 9:29 PM, Mark Brethen mark.bret...@gmail.com wrote: On Jun 7, 2014, at 6:02 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 7, 2014, at 5:10 PM, Mark Brethen wrote: I don't know for certain that the developers used MacPorts, what gave you that impression? The fact that it installed files into /opt/local. The installation consists of two compressed files: gtk4z88.tar.gz z88aurorav2_en.tar.gz The first is a GTK+-package needed for execution of Z88Aurora. It contains an /opt/local directory tree, with files in /opt/local/etc and opt/local/lib. I compared the contents of /lib with my macports /lib directory and noticed only these files are missing: /opt/local/lib/libgdkglext-x11-1.0.0.dylib /opt/local/lib/libgtkglext-x11-1.0.0.dylib /opt/local/lib/libpangox-1.0.0.dylib /opt/local/lib/libpng12.0.dylib The second file contains the program, which can be launched from the terminal or with an accompanying app. You are instructed to uncompress it in your user directory. So It looks like he may have used macports to build the GTK+ package for his program. If one were to write a port file for this, could you just check for GTK and all its dependencies and then move the app into the macports applications directory? There are also some fonts in the /opt/local/etc/fonts directory which are not present in my macports install. I don't know the source of these fonts. I've emailed the developer and waiting for a response. Mark The above libraries are provided by gtkglext, pangox-compat and libpng. It appears that the developer used macports to build each of those, and then copied the files over. As, I have versions of each already installed from Macports, I figured I would attempt to just run the application with just the macport versions, without installing the versions that the developer provides. But, it didn’t work. I believe the problem is that z88 Aurora is trying to use an older version of libpng. Above wants 12, while I have 1.6.10 installed (libpng16.16.dylib). Tthe error that I get when I try to run it is: ./aurorastartv2 dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib Referenced from: /Users/adershowitz/z88aurorav2/bin/mac/./z88aurora Reason: no suitable image found. Did find: /usr/local/lib/libpng12.0.dylib: no matching architecture in universal wrapper ./aurorastartv2: line 5: 20411 Trace/BPT trap: 5 z88aurora Since I have libpng built as universal, I find this error surprising. Unless z88 is attempting to use the PPC version? So, it seems that the developer will have to fix z88 for it to be compatible with Macports. I hope that they are responsive to your email. —Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: z88 Aurora
On Jun 9, 2014, at 7:09 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Jun 9, 2014 at 7:06 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: /usr/local/lib/libpng12.0.dylib: no matching architecture in universal wrapper That's not from MacPorts. Where did you get it? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. I am not sure which install did that. But, it has been there for a long time. Since z88 is searching for 1.2 anyway could that make a difference? Might it find and use 1.6 if I dump that old libpng out?___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: z88 Aurora
On Jun 9, 2014, at 7:27 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: On Jun 9, 2014, at 7:09 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Jun 9, 2014 at 7:06 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: /usr/local/lib/libpng12.0.dylib: no matching architecture in universal wrapper That's not from MacPorts. Where did you get it? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. I am not sure which install did that. But, it has been there for a long time. Since z88 is searching for 1.2 anyway could that make a difference? Might it find and use 1.6 if I dump that old libpng out? -- As I suspected, dumping that just changed the error message: ./aurorastartv2 dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib Referenced from: /Users/adershowitz/z88aurorav2/bin/mac/./z88aurora Reason: image not found ./aurorastartv2: line 5: 20674 Trace/BPT trap: 5 z88aurora Seems that as built, Z88 was linked against libpng12 and not 16. So, it looks like the developers just used an older version of MacPorts to develop and release the library files, and then copied the key files over. A bit ironic that they use MacPorts, but then make an installer that is not compatible with it. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: z88 Aurora
On Jun 9, 2014, at 8:12 PM, Craig Treleaven ctrelea...@cogeco.ca wrote: At 7:37 PM -0400 6/9/14, Adam Dershowitz Ph.D., P.E. wrote: On Jun 9, 2014, at 7:27 PM, Adam Dershowitz Ph.D., P.E. mailto:de...@alum.mit.edude...@alum.mit.edu wrote: On Jun 9, 2014, at 7:09 PM, Brandon Allbery mailto:allber...@gmail.comallber...@gmail.com wrote: On Mon, Jun 9, 2014 at 7:06 PM, Adam Dershowitz Ph.D., P.E. mailto:de...@alum.mit.edude...@alum.mit.edu wrote: /usr/local/lib/libpng12.0.dylib: no matching architecture in universal wrapper That's not from MacPorts. Where did you get it? I am not sure which install did that. But, it has been there for a long time. Since z88 is searching for 1.2 anyway could that make a difference? Might it find and use 1.6 if I dump that old libpng out? As I suspected, dumping that just changed the error message: ./aurorastartv2 dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib Referenced from: /Users/adershowitz/z88aurorav2/bin/mac/./z88aurora Reason: image not found ./aurorastartv2: line 5: 20674 Trace/BPT trap: 5 z88aurora Seems that as built, Z88 was linked against libpng12 and not 16. So, it looks like the developers just used an older version of MacPorts to develop and release the library files, and then copied the key files over. A bit ironic that they use MacPorts, but then make an installer that is not compatible with it. I think you're missing the point. '/opt/local' is the default prefix for MacPorts--it _owns_ all the files under there. Your Z88 installer _should not_ be writing to /opt/local/... BAD things will happen if you keep mixing their broken installer with the default prefix. It is virtually certain that the developer of Z88 has a Portfile they use to build and package their Mac installer. Either: 1) get them to give you the Z88 portfile (and associated files directory, if any) and you can use MacPorts to build a current copy of Z88. Then you won't have a version mismatch on libpng. 2) get them to submit their Z88 portfile here and then everyone will be able to build an appropriate version of their software, OR 3) get them to reinstall their copy of MacPorts to any other prefix (say '/opt/z88') and create a new version of their installer. Then they won't stomp on stuff MacPorts owns. Craig -- -- Craig Treleaven, CA -- Clearview Consulting (905) 829-2054 ctrelea...@cogeco.ca Not at all. I think that you have made assumptions about the point, and haven’t really looked into what is going on. First off, I don’t have anything to do with Z88, other then it looking useful, so I thought that I would try it out. But, a few things to help explain this. 1) The application installer doesn’t install anything into /opt. It only installs into the user’s home directory. There is no reason that I have seen to think that they used Macports to build the application. 2) The application requires a few additional runtime dependencies. Apparently, these few libraries are built using Macports. They provide an additional download to install these. These are installed into /opt/local/lib and we agree that they should not be putting them there. I think that you are confusing the Z88 installer and the separate gtk installer that they provide. 3) If they linked against the current versions of these libraries, then just having the appropriate ports installed would not require this additional download. I believe that Mark has already reached out to the developer, and hopefully there will be a fix coming. It seems that the fix could be either to move the location of the libraries,and require the extra download, or to use the newer versions of the libraries, so that a Macports install with the correct libraries would cover it. Then the extra install would be optional. Also, to clarify it appears that Z88 is open source, while Z88 Aurora, the version that includes pre- and post- processors, is free, but not open source. I don’t see the source code on their web site, so I am not sure that we can build a port for it. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Server Issues?
I can’t seem to get most of my ports to upgrade. It seems that it is a server issue. Here is one example: --- Computing dependencies for ImageMagick --- Fetching archive for ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9_0+jbig+lqr+x11.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9_0+jbig+lqr+x11.darwin_13.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9_0+jbig+lqr+x11.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/ImageMagick --- Fetching distfiles for ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://sea.us.distfiles.macports.org/macports/distfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://www.imagemagick.org/download/ --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from ftp://ftp.u-aizu.ac.jp/pub/graphics/image/ImageMagick/imagemagick.org/ --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://cjj.kr.distfiles.macports.org/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from ftp://sunsite.icm.edu.pl/packages/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://mirror.checkdomain.de/imagemagick/ --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://nue.de.distfiles.macports.org/macports/distfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from ftp://ftp.sunet.se/pub/multimedia/graphics/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://jog.id.distfiles.macports.org/macports/mpdistfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://lil.fr.distfiles.macports.org/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://her.gr.distfiles.macports.org/mirrors/macports/mpdistfiles/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://distfiles.macports.org/ImageMagick --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://svn.macports.org/repository/macports/distfiles/ImageMagick Error: org.macports.fetch for port ImageMagick returned: fetch failed Please see the log file for port ImageMagick for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_ImageMagick/ImageMagick/main.log Error: Unable to upgrade port: 1 To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets But, I am seeing similar things for a number of ports. I did make sure to use a working DNS (8.8.8.8). If I try to upgrade with my usual DNS (internal office), I get a checksum mismatch. I know that this can be expected for some ports. But, my experience is that most ports typically do work, and now I am seeing it for ports that I know usually work fine with my internal office DNS. Is something up with Macports servers? Or is it something at my end? --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Server Issues?
Turns out it was a DNS issue. For some reason just using 8.8.8.8 was causing trouble, but putting in a backup, 8.8.4.4 has it working fine. --Adam On Mar 24, 2014, at 11:20 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: But this one isn’t a MacPorts server. Also, i was able to download it without error... On Mar 24, 2014, at 11:13, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: --- Attempting to fetch ImageMagick-6.8.8-9.tar.xz from http://www.imagemagick.org/download/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: jpilot
On Jan 16, 2014, at 9:52 AM, Lenore Horner lenorehor...@sbcglobal.net wrote: For obvious reasons, Palm has not been keeping its drivers up-to-date; http://kb.hpwebos.com/wps/portal/kb/common/article/33529_en.html#mac is still downloadable but I would be very very surprised if it worked on 10.9. I did find this: http://pccallup.sourceforge.net which may be a working replacement. (I don’t have one to test with, sorry.) The Palm software hasn’t worked since 10.7. That’s why I switched to Missing Sync. However it (and other companies) used iSync which Apple has removed from 10.9. I tried the pccallup and the site still exists but there are no files available. Can I copy a /dev/pilot air /dev/ttyUSB1 from a backup under an old operating system or are there going to be other pieces that go along with that that I’ll also be missing? Thanks, Lenore As was stated earlier, these aren’t files, so they can’t just be copied. These are essentially the inputs and output of device drivers. So, when the right drivers are installed, copying /dev/pilot will cause the driver to read data from the Palm, and output the results to another file. The device driver is code that reads (or writes) data from a piece of hardware and then outputs that data to /dev/pilot (or whatever). So, that another program can read from that as though it is a file. So /dev/pilot is really a virtual file, not a real file, and trying to copy it would not cause the driver to be copied, but instead would cause the device driver to try to read some data. —Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Distributions remaining
It seems that when I upgrade ports, whether I uninstall the old version or not, that the distribution files remain. I have installed with the “-u” and have also just unstalled the inactive ports, after an upgrade. Yet, I see all my old distribution files remaining in /opt/local/var/macports/distfiles/. Is this expected behavior? I don’t recall noticing this from prior to 10.9 and 2.2.1. Is there a way to get rid of the distribution files for ports that are no longer the installed versions? For example I tried to do a clean like this: sudo port clean --dist inactive But these remain: ls /opt/local//var/macports/distfiles/sqlite3 sqlite-autoconf-3071600.tar.gz sqlite-autoconf-3071602.tar.gz sqlite-autoconf-308.tar.gz sqlite-autoconf-3080100.tar.gz sqlite-autoconf-3071601.tar.gz sqlite-autoconf-3071700.tar.gz sqlite-autoconf-3080002.tar.gz I believe that the reason that the clean like that didn’t work is because I had removed my old versions of sqlite3, so they are not inactive. port installed sqlite3 The following ports are currently installed: sqlite3 @3.8.2_0+universal (active) So, I would like to be able to clean the distributions for all things that are not installed, but leave the distributions for anything that I have either active or inactive. Is there a way to do that? --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
10.9.1
This is mostly an FYI. I upgraded from 10.9 to 10.9.1 When I think upgraded a few ports, I started getting: Warning: Xcode does not appear to be installed; most ports will likely fail to build. Although it did appear to be working fine. I opened Xcode, and then closed it. And now when I do upgrades the warning no longer appears. So, it seems, as I was hoping, that with the upgrade macports “forgot” about Xcode, and just opening it acted as a “reminder” that it was still installed. --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
pkg-config issue
I am trying to upgrade webkit-gtk on a PPC G5 machine. I have seen a few tickets about this, and have been trying a few things. http://trac.macports.org/ticket/35989 http://trac.macports.org/ticket/37839 But, now, I seem to have a new issue. When I try to upgrade, during the configure stage, I get an error in my log that it can't find GLIB = 2.36.0. I confirmed that I have glib2 installed with macports, (2.36.3). I tried setting PKG_CONFIG_PATH and I also I verified that there isn't' an extra pkg-config as suggested in the closed ticket: http://trac.macports.org/ticket/36321 And I also saw this ticket: http://trac.macports.org/ticket/27392 I then did a force uninstall of glib2 and reinstalled it. But, webkit-gtk upgrade still fails at the glib configure check. So, I am not really sure if this is a glib2 issue, a webkit-gtk issue, a pkg-config or something else. Any suggestions for what might be going on? Thanks, --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Error in staging
I am trying to create a port for SUNDIALS
(http://computation.llnl.gov/casc/sundials/main.html), and I have two
questions. It follows ./configure make make install. So, I have a pretty
minimal Portfile. Using my local test portfile if I do sudo port install, it
builds, and I see the libraries get installed into /opt/local/lib
But, I also see these errors:
--- Staging sundials into destroot
Error: No files have been installed in the destroot directory!
Error: Please make sure that this software supports 'make install
DESTDIR=${destroot}' or implement an alternative destroot mechanism in the
Portfile.
Error: Files might have been installed directly into your system, check before
proceeding.
Error: org.macports.destroot for port sundials returned: Staging sundials into
destroot failed
Please see the log file for port sundials for details:
/opt/local/var/macports/logs/_Users_adershowitz_Programming_ports_math_sundials/sundials/main.log
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: Processing of port sundials failed
My portfile doesn't have anything in it about destroot, so it should use the
default, and seems to. Yet, I get that error. In my logfile I see some things
like this:
:info:destroot Install src/kinsol/fcmix...
:info:destroot --
:info:destroot make[1]: Entering directory
`/opt/local/var/macports/build/_Users_adershowitz_Programming_ports_math_sundials/sundials/work/sundials-2.5.0/src/kinsol/fcmix'
:info:destroot /bin/sh ./../../../config/mkinstalldirs /opt/local/lib
:info:destroot /bin/sh ../../..//libtool --mode=install /usr/bin/install -c
libsundials_fkinsol.la /opt/local/lib
:info:destroot /usr/bin/install -c .libs/libsundials_fkinsol.lai
/opt/local/lib/libsundials_fkinsol.la
:info:destroot /usr/bin/install -c .libs/libsundials_fkinsol.a
/opt/local/lib/libsundials_fkinsol.a
:info:destroot chmod 644 /opt/local/lib/libsundials_fkinsol.a
:info:destroot ranlib /opt/local/lib/libsundials_fkinsol.a
:info:destroot
--
:info:destroot Libraries have been installed in:
:info:destroot/opt/local/lib
:info:destroot
:info:destroot If you ever happen to want to link against installed libraries
:info:destroot in a given directory, LIBDIR, you must either use libtool, and
:info:destroot specify the full pathname of the library, or use the `-LLIBDIR'
:info:destroot flag during linking and do at least one of the following:
:info:destroot- add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable
:info:destroot during execution
:info:destroot
:info:destroot See any operating system documentation about shared libraries for
:info:destroot more information, such as the ld(1) and ld.so(8) manual pages.
:info:destroot
--
:info:destroot make[1]: Leaving directory
`/opt/local/var/macports/build/_Users_adershowitz_Programming_ports_math_sundials/sundials/work/sundials-2.5.0/src/kinsol/fcmix'
Is there something that has to be done to get the libraries to be in the right
place to be found? Or for macports not to complain about them?
Also, on a separate issue related to this port. The source is released under a
BSD license. But the web site requires that you put in a name and email
address to download the source. For now I have just followed the example of the
geoexpress-sdk port (which requires a manual download). But, is it possible to
put a mirror of the source on Macports so that it will support an automatic
download?
Thanks,
--Adam
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Perl upgrade issue
I have a fresh install of macports (new computer). I see that: perl5.12 5.12.4_1 5.12.4_2 I just tried to do an upgrade. But it fails with these errors at the end of the log file: :info:build /usr/bin/clang -L/opt/local/lib -arch x86_64 -arch i386 -fstack-protector -force_flat_namespace -o miniperl \ :info:build gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o \ :info:build miniperlmain.o opmini.o perlmini.o -ldl -lm -lutil -lc :info:build ld: in '/opt/local/lib/libstdc++.6.dylib', file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386 :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation) :info:build make: *** [miniperl] Error 1 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5.12/perl5.12/work/perl-5.12.4' :info:build Command failed: cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5.12/perl5.12/work/perl-5.12.4 /usr/bin/make -j8 -w all :info:build Exit code: 2 :error:build org.macports.build for port perl5.12 returned: command execution failed I believe that the reason for this error is that it seems that there is a mismatch between standard library not being universal and perl being universal: $port installed perl5.12 libstdcxx The following ports are currently installed: libstdcxx @4.8-20130411_0 (active) perl5.12 @5.12.4_1+universal (active) What I am trying to understand is how that can happen, and why an upgrade would make this problem show up. I don't believe that I have explicitly installed anything +universal. But, I understand that certain things require universal, so some installs (wine-devel?), would have caused dependents to be reinstalled as universal. So, I do have a bunch of things installed as universal. So, I assume that I could get the upgrade of perl5.12 to work but manually installing libstdcxx as universal. But, it seems that will cause many things to then be rebuilt, since many things depend on it. My main question is why this would have developed if all I did was install ports and upgraded periodically. --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Perl upgrade issue
On Apr 19, 2013, at 2:37 PM, Lawrence Velázquez lar...@macports.org wrote: On Apr 19, 2013, at 4:55 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: I just tried to do an upgrade. But it fails with these errors at the end of the log file: :info:build /usr/bin/clang -L/opt/local/lib -arch x86_64 -arch i386 -fstack-protector -force_flat_namespace -o miniperl \ :info:buildgv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o \ :info:build miniperlmain.o opmini.o perlmini.o -ldl -lm -lutil -lc :info:build ld: in '/opt/local/lib/libstdc++.6.dylib', file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386 :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation) Reported a couple of hours ago. https://trac.macports.org/ticket/38858 I did a search, but then didn't send my email until later, so missed it. And some of the duplicates were obviously related, until after digging into them. I believe that the reason for this error is that it seems that there is a mismatch between standard library not being universal and perl being universal: $port installed perl5.12 libstdcxx The following ports are currently installed: libstdcxx @4.8-20130411_0 (active) perl5.12 @5.12.4_1+universal (active) Strictly speaking yes, but the final Perl installation does not seem to use libstdc++. This particular clang invocation probably should not use -L/opt/local/lib. What I am trying to understand is how that can happen, and why an upgrade would make this problem show up. I don't believe that I have explicitly installed anything +universal. But, I understand that certain things require universal, so some installs (wine-devel?), would have caused dependents to be reinstalled as universal. So, I do have a bunch of things installed as universal. So, I assume that I could get the upgrade of perl5.12 to work but manually installing libstdcxx as universal. But, it seems that will cause many things to then be rebuilt, since many things depend on it. My main question is why this would have developed if all I did was install ports and upgraded periodically. I don't think perl5.12 has been changed materially for many months. I would guess that you simply did not have libstdcxx installed the last time you updated it. That is possible. I didn't explicitly install either perl or libstdcxx, but each was a dependent of other things, so I am not sure of the order they were installed in. Unless you're building perl5.12 with a MacPorts GCC, you should be able to work around this by force-deactivating libstdcxx for the duration of the update. sudo port -f deactivate libstdcxx sudo port upgrade perl5.12 sudo port activate libstdcxx That did the job. Thanks much. --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Python pip issue
On Apr 2, 2013, at 6:27 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu wrote: I am trying to install a package, and have run into a problem. I did make sure that I am running the correct python: I have pip-2.6 installed, and I have used port select to make sure that macport python26 is active. If I then do: sudo pip-2.6 install PyJSBSim I get progress and then I see: Successfully installed PyJSBSim If I do: pip-2.6 freeze, then I see it present: PyJSBSim==0.5.5 But if I then try to use it, from within python, it doesn't seem to be present. In python I get this: from PyJSBSim import FGFDMExec Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named PyJSBSim But, if I look in: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages I see these: PyJSBSim-0.5.5-py2.6.egg-info pyjsbsim I know that this worked for me a couple of months back with 10.6, but I recently upgrade to 10.8 and now it just doesn't seem to show up. Any suggestions? Does 10.8 handle search paths any differently? I did do a full fresh install of all ports. So the bottom line is that the port of pip-2.6 thinks it is installing something, but the selected python then doesn't actually see it. --Adam ___ Thanks for the help. It turns out that there was a problem with the install of that particular code, and the developer was able to fix it. So the pip script was not installing some files, and then, of course, the module wasn't working. --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Python pip issue
I am trying to install a package, and have run into a problem. I did make sure that I am running the correct python: I have pip-2.6 installed, and I have used port select to make sure that macport python26 is active. If I then do: sudo pip-2.6 install PyJSBSim I get progress and then I see: Successfully installed PyJSBSim If I do: pip-2.6 freeze, then I see it present: PyJSBSim==0.5.5 But if I then try to use it, from within python, it doesn't seem to be present. In python I get this: from PyJSBSim import FGFDMExec Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named PyJSBSim But, if I look in: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages I see these: PyJSBSim-0.5.5-py2.6.egg-info pyjsbsim I know that this worked for me a couple of months back with 10.6, but I recently upgrade to 10.8 and now it just doesn't seem to show up. Any suggestions? Does 10.8 handle search paths any differently? I did do a full fresh install of all ports. So the bottom line is that the port of pip-2.6 thinks it is installing something, but the selected python then doesn't actually see it. --Adam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Python pip issue
On Apr 2, 2013, at 7:10 PM, Brandon Allbery allber...@gmail.com wrote: On Tue, Apr 2, 2013 at 9:27 PM, Adam Dershowitz Ph.D., P.E. de...@alum.mit.edu 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. $ printenv PATH /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Tk Port Question
I have Tk 8.5.5 installed. I am trying to run an application (GRASS) and the new version (6.4 is the development version that will be released soon) requires the Aqua framework Tk, according to what I have learned. I tried rebuilding Tk with +quartz. But the binary application that I am trying to use is not finding the correct libraries, because it is looking for frameworks. The person who does the binaries suggested that I install the ActiveTcl distribution, but that seems silly, given that I already have the MacPorts TclTk installed. So, I am wondering if there is any way to make this installation work? Is there something that can be done with Tk to have it also build frameworks? There is a --enable-frameworks flag as part of TclTk, but I am not sure if that will work within MacPorts. Any ideas? Thanks, --Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
