Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?
On 27.08.2016 07:41 PM, [ftp83plus] wrote: > So, after reinstalling Mac OS X as I did to get out of the startup crash as I > did, even if ports stayed in place, I should re-perform the > LibcxxOnOlderSystems steps? These instructions aren't meant to be static. Instead, they are getting updated by Jeremy pretty often and reliable whenever something changes in the toolchain. I guess it can be implied to check the page now and than to make sure the system still matches with what is being described on the wiki page and take necessary measures to sync it up - not necessarily by reinstalling everything blindly, but abstracting from the information presented. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?
On 27.08.2016 04:00 PM, [ftp83plus] wrote: > Crash log, approximately when gtk3 segfaulted: > > http://pastebin.com/bzuez8Xp In there, I see two things that look weird: - you're using ld64-136, although step 8 and 9 of the LibcxxOnOlderSystems guide explicitly says to switch to ld64-latest - ld64-136 was installed with +llvm37, although step 5 and 7 make sure that +llvm38 is used The second problem may be explicable by upgrading - earlier versions probably used llvm37 and the llvm38 change is relatively new. Still, your setup is broken/deviates from what is advertised to work on 10.6. That crash is probably a consequence of that. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: clang 3.4 can't be configured (part of a selfupdate)
On 26.07.2016 02:13 PM, [ftp83plus] wrote: > I am currently attempting a "port selfupdate" operation before installing two > ports I'd like to test. > > However, it fails for a reason I don't understand: > [...] Also interesting might be the output of `port installed 'ld64*' cctools` This problem might have been triggered by[0], although I have only seen proper linking failures on my system, not a segfaulting clang binary. Then again I'm natively on libc++ and a newer OS and Xcode version, so I can't rule out that clang might behave differently (or worse) on other systems. Regard this as additional information only though - a crashing clang binary should still be handled as well and reported upstream with the proper requested information. Mihai [0] https://trac.macports.org/ticket/51929 signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gimp-app Abort trap: 6
On 28.01.2016 07:24 PM, Mark Brethen wrote: > gimp-app fails to build on 10.11.3: > > :info:build sh: line 1: 55927 Abort trap: 6 /usr/bin/xcodebuild > -alltargets -configuration Deployment build OBJROOT=build/ SYMROOT=build/ > MACOSX_DEPLOYMENT_TARGET=10.11 ARCHS=x86_64 SDKROOT="" > GCC_VERSION=com.apple.compilers.llvm.clang.1_0 CLANG_CXX_LIBRARY="libc++" > :info:build Command failed: cd > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_gimp-app/gimp-app/work/GIMPskel/ScriptExecCocoa" > && /usr/bin/xcodebuild -alltargets -configuration Deployment build > OBJROOT=build/ SYMROOT=build/ MACOSX_DEPLOYMENT_TARGET=10.11 ARCHS=x86_64 > SDKROOT="" GCC_VERSION=com.apple.compilers.llvm.clang.1_0 > CLANG_CXX_LIBRARY="libc++" > :info:build Exit code: 134 > :error:build org.macports.build for port gimp-app returned: command execution > failed > :debug:build Error code: NONE > > I do not know what this means, but I did not find a ticket for this > particular failure. This sounds like either the issue described here, if you are using Xcode 7.2: https://trac.macports.org/wiki/ProblemHotlist#xcode7.2 If the workaround provided there didn't fix your problem, please read https://trac.macports.org/ticket/49101 carefully and follow the instructions given there - ADAPTING THE INSTRUCTIONS TO YOUR SYSTEM IF NECESSARY! Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: checksum errors and non accessible wiki
On 22.10.2015 10:17 AM, Dominik Reichardt wrote: > Thanks - gonna be patient and stopping myself from selfupdates whenever the > "bad checksum reports" arrive here ;) FWIW, these "bad checksum reports" seem to have been caused by SourceForge, in the sense that their mirrors sent out 404 not found error messages instead of the actual files, c.f. https://twitter.com/sfnet_ops/status/656886938113175552 MacPorts should currently be operating fine when it comes to distfiles. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gpsd checksum issue?
On 22.10.2015 07:49 PM, Ryan Schmidt wrote: > No need to clean all ports; only the gpsd port. To clean its distfiles too, > use "sudo port clean --all gpsd". > > Before you do that, you could save off the gpsd-3.14.tar.gz file you already > have, to see what's wrong with it. The root cause was most likely SourceForge serving a 404 error message webpage instead of the actual file, see my other message in the thread "checksum errors and non accessible wiki". Cleaning and retrying should work just fine now. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: checksum errors and non accessible wiki
On 22.10.2015 08:18 PM, Ryan Schmidt wrote: >> If SourceForge was sending a 404 Not Found HTTP status code, that would not >> be a problem for MacPorts. It's only a problem if SourceForge was sending a >> 200 OK HTTP status code but delivering an HTML file instead of the distfile >> we requested, and in that case, MacPorts would print a message stating that >> the file it got was an HTML file. That was not stated in the error shown >> above. > > Oh sorry, I was thinking of a different thread. That *was* stated in the > error above. But we haven't seen what the HTML file says... Yes. It looks like they sent "fake" 404 error messages as "real" webpages with status 200, confusing everybody. The original message in this thread has had a warning regarding this in its output, for the other thread we never saw how the distfile was fetched, so it stands to reason that the warning also came up there at fetch time. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Subversion Component Down
Dear Developers and Users The subversion server seems to eventually also be affected by recent server problems and is currently effectively down. This is a continuation of the general problems we have experienced with the rsync server and, to some extent, trac. For the time being, please stash your commits. I am sure portmgr will take appropriate measures to report the problem and work towards a resolution with the hosting provider. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: rsync server problems
On 13.10.2015 04:42 AM, Bill Christensen wrote: > $ sudo port sync > Password: > ---> Updating the ports tree > Error: Synchronization of the local ports tree failed doing rsync > port sync failed: Synchronization of 1 source(s) failed Can you re-run with -v? "sudo port -v sync" Also, this might be a network problem. Do you get a nice list of modules with "rsync rsync.macports.org::"? Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: PulseAudio with MacPorts
On 30.09.2015 08:43 PM, Erica Cooper wrote: > Hello, > > I am using Mac OS X 10.8.5 (Mountain Lion). I tried to install PulseAudio > using > MacPorts and the installation appeared to be successful, however when I tried > to > run it, I got the following error: > > [...] no hard error in there [...] > > Is PulseAudio currently supported for mac? Is there anything else that needs > to > be done after installing it from MacPorts to be able to use it? PA should be start up and run fine. Dave has added a line to the default.pa config file a few month ago that I "forgot" (actually, my patches do the wrong thing - record and playback should have been automatically enabled.) Can you please execute pulseaudio -? Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: unbound did not start automatically after reboot
On 08.09.2015 05:03 PM, FritzS - gmx wrote: > I use only one volume. My guess the startup of the ethernet port coming to > late or the application firewall Little Snitch unblocking the DNS ports to > late at startup. > > My suggestion - unbound should start after network connection is OK and > Little Snitch is running up. The ethernet device should be available right from the start. I doubt that's a problem. Deactivate Little Snitch to see whether this works or still fails? I've taken a look at unbound last week and didn't see anything obvious that would cause startup to fail. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Sophos Antivirus claims port 'zlib' ships a Virus/Spyware called "iPh/WireLurk-G"...
On 05.09.2015 12:18 AM, Marko Käning wrote: > today I got a warning from my "Sophos Antivirus" w.r.t. MacPorts!!! > > It claimed that zlib’s dylib file > > /opt/local/lib/libz.1.2.8.dylib > > carried a virus called > > iPh/WireLurk-G https://trac.macports.org/ticket/48756 (Trac is currently unreachable for me, but there's the same report.) Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: website problem
On 04.09.2015 11:21 PM, Lars Sonchocky-Helldorf wrote: > Meanwhile, the rest of the macport servers are now down too … Trac and everything was back up today (or yesterday) and suddenly went unreachable again. mtr report (60 seconds): Start: Sat Sep 5 00:17:59 2015 HOST: nopileos.local Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0%600.8 2.9 0.5 54.8 8.9 2.|-- 217.0.117.2270.0%60 26.1 25.6 19.2 139.6 21.8 3.|-- 217.237.155.74 0.0%60 19.9 26.6 19.6 127.6 17.4 4.|-- f-ee5-i.f.de.net.dtag.de (62.154.14.246) 0.0%60 26.8 30.4 24.6 142.1 20.8 5.|-- 62.157.250.700.0%60 35.5 40.2 35.4 130.6 14.9 6.|-- ae-2-70.edge1.sanjose2.level3.net (4.69.152.71) 5.0%60 191.1 194.5 186.4 313.1 27.2 7.|-- ae-2-70.edge1.sanjose2.level3.net (4.69.152.71) 3.3%60 186.9 191.9 186.3 237.3 11.9 8.|-- apple-compu.edge1.sanjose2.level3.net (4.28.172.82) 0.0%60 186.9 203.4 186.4 812.1 82.6 9.|-- ??? 100.0600.0 0.0 0.0 0.0 0.0 10.|-- ??? 100.0600.0 0.0 0.0 0.0 0.0 11.|-- ??? 100.0600.0 0.0 0.0 0.0 0.0 12.|-- trac.macports.org (17.251.224.215) 0.0%60 181.2 186.4 181.0 291.9 19.7 Looks like the connection drops at Apple's interface with L3. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: website problem
On 05.09.2015 12:29 AM, Daniel J. Luke wrote: > your mtr shows 0% loss for ‘trac.macports.org’ (so it’s just showing > no details for hops 9-11 which is probably due to the configuration > of apple’s internal network). It shows no loss, because I can reach it again. Sigh. Seems like I was too slow with creating the report. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Connectivity problems with master server (distfiles.macports.org/rsync.macports.org)
On 25.08.2015 09:35 PM, Mihai Moldovan wrote: As previously announced, here is the archive link to my former message: https://lists.macosforge.org/pipermail/macports-users/2015-August/039111.html This will hopefully ease information spread. And as Jeremy pointed out, it is easy to imagine that the mailing list infrastructure might fall victim to the same problem. Hence, here is a copy by archive.org: https://web.archive.org/web/20150825194048/https://lists.macosforge.org/pipermail/macports-users/2015-August/039111.html I hope that's redundant enough. Hopefully my last post on that matter for now. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Connectivity problems with master server (distfiles.macports.org/rsync.macports.org)
Hi As previously announced, here is the archive link to my former message: https://lists.macosforge.org/pipermail/macports-users/2015-August/039111.html This will hopefully ease information spread. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Connectivity problems with master server (distfiles.macports.org/rsync.macports.org)
Hi
For the last few days, I have increasingly seen reports of problems reaching the
master server (distfiles.macports.org/rsync.macports.org) with symptoms ranging
from low throughput (tens of KB/s with an otherwise idle connection on the
user's end), stalling of downloads with eventual disconnects or even being
unable to reach the machine at all.
To the best of my knowledge, at the time of writing, the problems seem to be
mostly isolated to the western part of the US (including Alaska.) I was not able
to reproduce these issues in Europe.
We do not know the source of these problems.
We cannot provide an ETA for the eventual resolution of these problems.
If you think you are affected (MacPorts installer hangs for a long time at about
80 to 90% with the message running post installation scripts or the like, sudo
port selfupdate or sudo port sync hanging, failures during the fetch phase while
installing ports), please select another *working* mirror close to your location
in this list: https://trac.macports.org/wiki/Mirrors
Afterwards,
- change the rsync_server setting in ${prefix}/etc/macports/macports.conf
(if you're using the default prefix, that is
/opt/local/etc/macports/macports.conf)
- add distfiles.macports.org to host_blacklist and make sure to uncomment
this option in the same file
- change ${prefix}/etc/macports/sources.conf (if using the default prefix,
that's /opt/local/etc/macports/sources.conf) in the same vein.
If necessary, you can switch back to the master server after the problems have
been resolved.
Once this post reaches the mailing list(s), I will make a follow-up post with
the archive link for easy linking.
Thank you for your understanding.
Mihai
signature.asc
Description: OpenPGP digital signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: org.macports.build for port kerberos5 returned: command execution failed
On 25.08.2015 02:22 AM, Brandon Allbery wrote: On Mon, Aug 24, 2015 at 8:17 PM, Ryan Schmidt ryandes...@macports.org mailto:ryandes...@macports.org wrote: I'm not having any trouble reaching trac.macports.org http://trac.macports.org or other MacPorts sites from Austin or Munich or right now, but of course network problems are often region-specific so there may be a network problem somewhere between you and Apple's data center in Cupertino. fwiw mtr was showing me sporadic failures at Level3 San Jose. And there have been at least 4 reports of sluggishness with download rates of a few KB/s with complete stalling and connection drops on IRC for master. There's definitely something going on currently. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Problem upgrading `tiff`
On 08.08.2015 11:43 AM, Kurt Pfeifle wrote:
But I have every package installed which has /jpeg/ in its name:
|$ port installed *jpeg* jpeg @9a_1+universal (active) jpeg2ps @1.9_0
(active)
jpegoptim @1.2.4_1 (active) libjpeg-turbo @1.3.1_0 libjpeg-turbo @1.4.0_0
libjpeg-turbo @1.4.0_1 (active) mozjpeg @3.0_1 mozjpeg @3.1_0 (active)
openjpeg
@2.1.0_0+universal (active) openjpeg15 @1.5.1_0+universal (active) |
Wow, this should be literally impossible.
You probably messed up your system pro-actively and are better off wiping
${prefix} (in this case /opt/local) and reinstalling everything, pretty much as
explained in https://trac.macports.org/wiki/Migration - just without the Xcode
steps and with moving the old /opt/local directory out of the way *after*
getting the installed port list.
Even then, you cannot just install from this installed list, because it's
broken and will need some manual care.
The ports jpeg, jpeg-turbo and mozjpeg conflict with each other. You should
*never*, *ever*, have more than one of them active. It looks like you
force-activated them, anyway, and that's the end result of these operations.
Maybe there is a problem with the |*jpeg*| files in |/opt/local/lib/*jpeg*| ?
|$ ls -l /opt/local/lib/*jpeg* -rwxr-xr-x 1 root admin 440372 25 Mai 14:18
/opt/local/lib/libjpeg.8.dylib -rwxr-xr-x 1 root admin 348908 25 Mai 14:16
/opt/local/lib/libjpeg.8.dylib.mp_1432586226 -rwxr-xr-x 1 root admin 423172 7
Mär 2014 /opt/local/lib/libjpeg.9.dylib -rw-r--r-- 1 root admin 554072 25 Mai
14:18 /opt/local/lib/libjpeg.a -rw-r--r-- 1 root admin 531808 7 Mär 2014
/opt/local/lib/libjpeg.a.mp_1432331338 -rw-r--r-- 1 root admin 455560 25 Mai
14:16 /opt/local/lib/libjpeg.a.mp_1432586226 lrwxr-xr-x 1 root admin 15 25 Mai
14:18 /opt/local/lib/libjpeg.dylib - libjpeg.8.dylib lrwxr-xr-x 1 root admin
15
7 Mär 2014 /opt/local/lib/libjpeg.dylib.mp_1432331338 - libjpeg.9.dylib
lrwxr-xr-x 1 root admin 15 25 Mai 14:16
/opt/local/lib/libjpeg.dylib.mp_1432586226 - libjpeg.8.dylib -rwxr-xr-x 1
root
admin 276756 26 Okt 2014 /opt/local/lib/libopenjpeg.1.dylib -rw-r--r-- 1 root
admin 347312 26 Okt 2014 /opt/local/lib/libopenjpeg.a lrwxr-xr-x 1 root admin
19
26 Okt 2014 /opt/local/lib/libopenjpeg.dylib - libopenjpeg.1.dylib
-rwxr-xr-x 1
root admin 480788 25 Mai 14:18 /opt/local/lib/libturbojpeg.0.dylib -rwxr-xr-x
1
root admin 385236 25 Mai 14:16
/opt/local/lib/libturbojpeg.0.dylib.mp_1432586226
-rw-r--r-- 1 root admin 609880 25 Mai 14:18 /opt/local/lib/libturbojpeg.a
-rw-r--r-- 1 root admin 511320 25 Mai 14:16
/opt/local/lib/libturbojpeg.a.mp_1432586226 lrwxr-xr-x 1 root admin 20 25 Mai
14:18 /opt/local/lib/libturbojpeg.dylib - libturbojpeg.0.dylib lrwxr-xr-x 1
root admin 20 25 Mai 14:16 /opt/local/lib/libturbojpeg.dylib.mp_1432586226 -
libturbojpeg.0.dylib |
There's a lot of problems, as outline before. Also, you have an awful lot of
stale files (.mp_timestamp) which shouldn't happen too often either - but
seems to be a common thing on your system.
Mihai
signature.asc
Description: OpenPGP digital signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports thinks xcode is not installed...?
On 03.08.2015 04:01 AM, Carlo Tambuatco wrote:
I recently upgraded my harddrive to a hybrid SSD and had to reinstall OS X
Yosemite then restore everything from Time Machine backup.
I then re installed XCode albeit a newer version, this time I went with the
XCode 7 beta 4 release.
The problem is that you are using an unreleased, testing Xcode version.
It seems to automatically install the xcode command line
tools without me needing to do xcode-select --install.
Anyway, I recently did an upgrade of all my outdated ports and got this
warning
message:
Warning: Xcode does not appear to be installed; most ports will likely fail to
build.
Meanwhile it is downloading, compiling, installing, activating and cleaning
everything just fine. It seems macports thinks xcode is not there while it is
using its compilers to do its work...
What is going on and is this going to lead to problems down the road?
First, answering the second question. Yes, it will lead to problems down the
road, for the first port that requires Xcode (or more specifically xcodebuild.)
The answer to the first question is more sophisticated.
OS X 10.11, as you may know, introduces the rootless mode, which means that
write access to locations such as /usr and /System (lest /usr/local) are
prohibited - even for the root user.
Due to this, the command line tools cannot be installed into the usual location
- which has traditionally been /usr. Instead, they are now installed in
/Library/Developer/CommandLineTools. The Xcode SDK path seems also to be set to
this value.
The backside of that coin, however, is, that the normal tools as shipped by
Xcode (like xcodebuild) are still installed in
/Applications/Xcode.app/Contents/Developer - and as port checks the path
registered with xcode-select, it will not find these tools.
That's a tiny bit of a problem.
Is there anything I need to do to fix this?
At the moment, I have no idea how to fix that.
Then again, I haven't seen xcode-select --help for the Beta version of Xcode
yet, either.
It may be that Apple has decoupled the SDK path from the CLT path (xcode-select
-p), but as I said, I don't know.
A workaround *might* be setting the SDK path to
/Applications/Xcode.app/Contents/Developer and adding
/Library/Developer/CommandLineTools to the PATH value in
${prefix}/etc/macports.conf, but I doubt that's a proper solution and may well
break Xcode itself (or more specifically, xcodebuild.)
Mihai
signature.asc
Description: OpenPGP digital signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports thinks xcode is not installed...?
On 03.08.2015 06:18 AM, Ryan Schmidt wrote: On Aug 2, 2015, at 10:50 PM, Mihai Moldovan wrote: On 03.08.2015 04:01 AM, Carlo Tambuatco wrote: I recently upgraded my harddrive to a hybrid SSD and had to reinstall OS X Yosemite then restore everything from Time Machine backup. I then re installed XCode albeit a newer version, this time I went with the XCode 7 beta 4 release. The problem is that you are using an unreleased, testing Xcode version. While we don't support beta or pre-release versions of Xcode or OS X, merely using them is not necessarily a problem. No, but they void your warranty and may well drown your kitten in a pool of blood. OS X 10.11, as you may know, introduces the rootless mode, which means that write access to locations such as /usr and /System (lest /usr/local) are prohibited - even for the root user. This is the first I'd heard of it. I like it. Thanks for letting us know. That may sound cool for us (and the unsuspecting user, that cannot mess up the system easily anymore), but it will inevitably break legacy behavior, like Xcode installing the CLTs in /usr. I've seen this exact report (although I guess from a different user) on IRC a few days ago, so the latest Xcode Beta version may have broken old behavior? I haven't had any problems building most ports under OS X 10.11 beta with Xcode 7 betas so I suspect something else is going on. As far as I know, you should still run xcode-select --install to install the command line tools. I'm not aware of them being installed automatically. While that may be true, it seems that at least Xcode 6 has always been installed CLTs in /Library/Developer/CommandLineTools. I have that directory on my system. The binaries installed in /usr *seem* to be mere shims that call the real binaries in /L/D/CLT. -rwxr-xr-x 1 root 37M Apr 20 03:26 /Library/Developer/CommandLineTools/usr/bin/clang -rwxr-xr-x 1 root 14K Nov 4 2013 /usr/bin/clang You should also select the Xcode location, using sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer (or wherever you put it). The problem with that is that the CLTs are not installed there. Even Xcode 6 installed CLTs to /usr and left /Applications/Xcode.app alone. They (or their shims) were still easily picked-up due to being in the default PATH location, so nothing bad happened. For instance, you won't find clang in /Applications/Xcode-beta.app/Contents/Developer/usr/bin/. With OS X 10.11, this situation could change dramatically... Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gtk-mac-integration
On 25.07.2015 06:14 PM, Ludwig wrote: I’ve come across a few ports that require gtk-mac-integration, but that package is not in the repository. I vaguely remember reading that it’s been replaced by gtk-osx-application-gtk2 or ige-mac-integration, but now I can’t find that reference. I’ve tried with each installed but they don’t seem to provide the GTK_MAC flags that configure looks for in ports requiring gtk-mac-integration. How would one go about fixing this? Should the replacement(s) set the GTK_MAC flags, or should the affected ports’ configure scripts be looking for something else? The GTK_MAC integration it talks about *probably* (but I don't know) relates to gtk2 +quartz (i.e., the quartz variant.) I don't recommend selecting, though, and changing to Quartz is not a simple process. Basically, you will have to rebuild all ports you installed so far. (Obviously only gtk ports, but do you *really* know which port uses GTK and which one does not?) CC'ing someone who might be able to help better. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Cannot upgrade libnetpbm
On 17.07.2015 05:00 PM, Barrie Stott wrote: In trying to upgrade, an error occurred with libnetpbm. I cleaned it and tried again only to get the same error. I have no idea how to get past this so I am asking for help. libnetpbm is hosted on SourceForge. SourceForge is down. You will need to wait for it to be available again. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Does Gnome take up tons of disk space? It uses some Gnome stuff.
On 07.07.2015 11:05 PM, David Evans wrote: At any rate, you can remove it and its dependencies fairly easily if you decide it's not what you want. sudo port -f uninstall gnumeric rdepof:gnumeric sudo port -v uninstall --follow-dependencies gnumeric is better. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: octave-control configure fail
On 04.07.2015 04:34 PM, Marius Schamschula wrote: That means octave was not revision bumped with the gcc48 update. You’ll need to rebuild octave. As gcc49 was also updated recently, octave will need to be rev-bumped. You should add a ticket on MacPorts trac. Revbumped in https://trac.macports.org/changeset/138295 Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: octave-control configure fail
On 05.07.2015 05:46 AM, Ryan Schmidt wrote: If octave truly requires a revbump following every gcc upgrade, that's horrible. But if that's going to remain the case, then I guess a comment should be added to the top of every affected gcc port reminding us of that. It hardcodes gfortran's path (and maybe more?) :( So yes, for everything but a revbump of gcc ports, octave must be revbumped (and maybe even octave-control.) Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Effect of Wireshark 2.0 using QT libraries instead of GTK
On 27.06.2015 11:02 PM, Kok-Yong Tan wrote: Will the XQuartz/X11 windowing system still be needed? Only for the GTK2/3 interfaces. And even then not strictly, because GTK can be built making use of Cocoa. It's everything but perfect though, discouraged and users shouldn't try to switch between the two implementations (the best way is to uninstall and reinstall all ports, setting up the variants first.) It seems upon cursory investigation to run natively using Apple's Aqua windowing system. This is true for qt4-mac and qt5-mac, yes. These ports are using the Cocoa interface and don't need X11. However, there's also at least qt4-x11, so NOT using X11 is not mandatory. Depends on the user's choice. If so, since it runs natively in Aqua, will there be a MacPorts version of it? No! Because the wireshark port already has a qt variant! For switching between gtk2, gtk3 and Qt, you'll need to deactivate the current wireshark port (sudo port deactivate wireshark) and install with the correct variant set. For the Qt interface: sudo port -v install wireshark +qt Thus, the wireshark port is already good to go. There's one caveat though. As far as I know, the Qt interface is not yet ready to replace the GTK2/GTK3 interface because it's lacking some/most(?) features, so I do not recommend enabling this for the current wireshark port. I do not know off-hand how wireshark 2.0.0 will improve on this situation. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Upgrades that include netpbm
On 13.06.2015 03:51 PM, Brandon Allbery wrote: On Sat, Jun 13, 2015 at 3:56 AM, Barrie Stott zen146...@zen.co.uk mailto:zen146...@zen.co.uk wrote: My worry now is that if run sudo port -f deactivate netpbm then that newly deactivated version of netpbm will no longer register as outdated so it will not be upgraded when I run sudo port upgrade outdated. Will I not have to run sudo port install netpbm straight after my forced deactivation? outdated includes installed-but-inactive ports. No, it does not. That's one problem. If no outdated port pulls in netpbm, it won't get updated. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Upgrades that include netpbm
On 12.06.2015 05:21 PM, Barrie Stott wrote: Whenever I perform such an 'upgrade outdated', a message is displayed when trying to configure netpbm saying that I should force a deactivation of netpbm and then the upgrade stops. Normally I deactivate netpbm, upgrade netpbm and upgrade outdated. Is there any reason why I cannot force deactivate netpbm before starting the 'upgrade aoutdated' in the first place? That would break other ports that depend upon netpbm. Worse, I think port will automatically re-activate it, if it comes to such a port. So you wouldn't win anything. Sadly, making netpbm conflict with itself at built time is the only way to make sure it doesn't use its own headers/libraries when compiling. Trace mode would fix that, but we currently have no way of activating or deactivating trace mode on a per-ports basis. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Help
public shaming On 05.06.2015 09:34 PM, René J.V. Bertin wrote: On Friday June 05 2015 15:27:49 Cheesy One wrote: There's not much documentation on mama online. Try searching for *being a* mama. That should give you a few more hits O:-) Please don't ever do this again. People can easily get offended and you have no way to determine how easy that is - even when you supposed to make a joke only. This gets worse when acknowledging the fact that this list is publicly available and free for everyone to join. This especially includes people from different cultures, which potentially could interpret a pun on typo as a very bad insult. It goes without mention that behavior like this sheds a bad light on the project and before you know MacPorts will be known as that place slimy nerds twist one's words and have fun on your expense for trivial mistakes. We certainly do not want this. I don't want to have to repeat this again. I had hoped the latest friction point that lead to a whole upstream project ceasing cooperation with MacPorts based on offense taught to handle situations generally with a bit more diplomacy and respect for each other. Looks I was wrong after all. Mihai /public shaming signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libjpeg vs. libjpeg-turbo
On 24.05.2015 04:43 PM, René J.V. Bertin wrote: On Sunday May 24 2015 02:16:06 Ryan Schmidt wrote: I don't currently plan to keep a functional jpeg port around. If it turns out later that some port or someone absolutely requires the original libjpeg we can add a new port for it at that time, but based on other distributions adopting libjpeg-turbo I don't foresee that need arising. I think I made it clear that I have this requirement, but I suppose I'll just keep extending my own port repository. I might decide to downgrade port:jpeg to v8 just to bring it in line with the alternatives, but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise. TLDR: you're making a great fuzz about essentially nothing; deeper explanation below. I see you are concerned about getting the exact same output out of an encoded JPEG image. libjpeg-turbo fulfills this purpose. Iff all algorithms are implemented adhering to specification, a JPEG decoder will always produce the same raw output. The magic lies within the JPEG encoder, but that's not breaking anything, given that encoders should adhere to the specifications (and libjpeg-turbo does that, being a fork of the original IJG jpeg software anyway.) Naturally, new features as implemented in IJG jpeg won't be supported, but those are not formally standardized yet and I don't see this happening either. They are informal, experimental extensions and are not reviewed with much love in the standardization committees. Your whole fear gets even important when keeping in mind that the JPEG decoder used in OS X as implemented in Apple's ImageIO framework is not IJG jpeg or even a fork of that anyway, but a totally new implementation. If this whole stuff concerns you so much, the fact that native Cocoa stuff uses an entirely different implementation should have been driving you the walls for a long time already now. And that's not even keeping in mind cross-platform issues potentially coming from *other* platform's software again, like Microsoft's own implementation in the Windows API (or wherever exactly they implemented it.) Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libjpeg vs. libjpeg-turbo
On 25.05.2015 04:52 AM, Ryan Schmidt wrote: On May 24, 2015, at 8:52 PM, Lawrence Velázquez wrote: Replacing libjpeg with libjpeg-turbo. I think this point is off-topic, as this discussion is primarily about maintainability and not performance. ...I assumed it was also about performance. If we object to changes IJG is making to jpeg, we can also just stop updating jpeg past 9, or we can downgrade it to 8. For me, it also is. I'm dependent upon a fast JPEG decompressor for another application I'm part of upstream. I do not particularly care what the default JPEG port is in MacPorts as long as there is a choice for being able to switch to libjpeg-turbo (i.e., a path-based dependency), but I very much prefer libjpeg-turbo for speed and compatibility reasons (again, Linux distributions switched to libjpeg-turbo and a cross-platform application benefits from the same toolchain even on the other platforms.) Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libjpeg vs. libjpeg-turbo
On 22.05.2015 09:33 PM, René J.V. Bertin wrote: On Friday May 22 2015 17:28:31 Mihai Moldovan wrote: also, that’s ridiculous since we only officially support the current and previous OS release (and we probably shouldn’t be helping people to keep running systems that aren’t receiving security patches from Apple anymore). That was my initial reaction, too, but I feel that we shouldn't break functionality that was provided free-of-charge (regarding maintenance) until now. https://forums.gentoo.org/viewtopic-p-7050414.html Okay, once we can confirm that ppc can compile libjpeg-turbo, we can begin work on migrating to it. It seems only 1.4.0 and higher do work on non-x86(_64), though, so we will need to update libjpeg-turbo first: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200095 We could craft a solution to keep jpeg around that based on arch (ppc) or version (darwin 8 and lower), but that would mean we essentially get 2 ports in As I've argued earlier, I think we'll want to keep port:jpeg around anyway, for the simple reason that no one can foresee if and when software will start using jpeg9 features ... Never. The features are experimental and the standardization committees are not in favor of even adding them. Linux distros switched to libjpeg-turbo unanimously. FreeBSD is not following this trend, a whole, but has path-based dependencies with a default on jpeg, so meh. Almost counts as libjpeg-turbo. It'd be stupid to have to reintroduce the port then, rather than beginning the whole transition with moving libjpeg to an install location where it can co-exist with other libraries. We do not have a concept of virtual packages. You are trying to be too smart and it will eventually painfully go wrong. For proper support of virtual packages, base needs to be extended. Variants are NOT the way to go here. Dependencies on variants are NOT supported, not counting the kludge that is enforce_variants. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libjpeg vs. libjpeg-turbo
On 22.05.2015 04:06 PM, Daniel J. Luke wrote: On May 21, 2015, at 11:11 PM, Mihai Moldovan io...@macports.org wrote: This would involve verifying that libjpeg-turbo works (or at least builds) correctly on PowerPC and Intel Macs running 10.4 and up. This could become an issue on PPC and older versions. Who can test, whether current libjpeg-turbo builds? also, that’s ridiculous since we only officially support the current and previous OS release (and we probably shouldn’t be helping people to keep running systems that aren’t receiving security patches from Apple anymore). That was my initial reaction, too, but I feel that we shouldn't break functionality that was provided free-of-charge (regarding maintenance) until now. If it does build there, and we can verify it - great - otherwise I don’t think it should stop us from moving forward. Well, if it doesn't work there, we'd have to keep the jpeg port around to not completely break these installations. At least I'd hate to break them. We could craft a solution to keep jpeg around that based on arch (ppc) or version (darwin 8 and lower), but that would mean we essentially get 2 ports in one Portfile: a stub replaced_by one for darwin 9 and higher or non-ppc and the real libjpeg deal for darwin 8 and lower or ppc. Something tells me that's a really ugly hack. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: libjpeg vs. libjpeg-turbo
On 22.05.2015 02:49 AM, Ryan Schmidt wrote: On May 20, 2015, at 5:11 AM, Clemens Lang wrote: Yes, we would have to revbump all dependents of the jpeg port if we do this. Since it is unlikely that mozjpeg and libjpeg-turbo will ever implement the changes to become compatible with libjpeg.9.dylib there is no way to avoid the rebuild for this kind of switch. I wondered why libjpeg-turbo would not incorporate libjpeg 9 features, and found this article explaining why: http://libjpeg-turbo.org/About/Jpeg-9 I'd be surprised to see any software use jpeg 9 features. Based on the above article, and the referenced instances of how the current developer of libjpeg is interacting with the community, You put that very diplomatically... I'm open to replacing jpeg with libjpeg-turbo, with the option to use the mozjpeg fork of libjpeg-turbo instead. Yes and yes. This would involve verifying that libjpeg-turbo works (or at least builds) correctly on PowerPC and Intel Macs running 10.4 and up. This could become an issue on PPC and older versions. Who can test, whether current libjpeg-turbo builds? Then, assuming it does, identifying all ports that link with libjpeg; changing the dependency from port:jpeg to path:lib/libjpeg.dylib:libjpeg-turbo; increasing their revision; and marking jpeg as replaced_by libjpeg-turbo. ACK. I count over 200 ports marked as depending on jpeg; there might be more that aren't marked. 212 if my calculations are correct. The pool is surprisingly low. It would be good to verify that at least a good portion of those can compile with libjpeg-turbo before committing, though it sounds like it's already pretty well-tested in other distributions. I'd skip that. If it works with jpeg, it's supposed to work with libjpeg-turbo (mind it being a drop-in replacement.) Making sure that libjpeg-turbo builds is higher priority. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Changing PATH and downloading mpich-default
On 06.04.2015 02:56 AM, Mihai Moldovan wrote: On 06.04.2015 12:46 AM, Evan Phillips wrote: Mihai and Lawrence, port xz was not installed. I ran: $ sudo port clean all $ sudo port -dt install mpich-default and the installation is failing at processing. Attached is the log. This is getting stranger still. Now it's ignoring *all* dependencies and going straight to mpich-default? That sounds like you have an alias for port to -n? What is sudo type port? Thanks to Joshua for pointing out I misinterpreted the output. That's the mpich-default main.log only, not the full debug output of port. The dependencies were built successfully this time, so cleaning was the only necessary step to getting them to install correctly. The mpich-default failure is another thing. Can you try again without -t, this time? Just port -v clean mpich-default; port -v install mpich-default Although I don't believe it is, the failure *might* be a consequence of trace mode, judging by the :info:build darwintrace: connect: Connection refused messages. If it still doesn't work, please follow the section 7.1 on https://guide.macports.org/#project.tickets to create a bug report. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Changing PATH and downloading mpich-default
On 06.04.2015 12:46 AM, Evan Phillips wrote: Mihai and Lawrence, port xz was not installed. I ran: $ sudo port clean all $ sudo port -dt install mpich-default and the installation is failing at processing. Attached is the log. This is getting stranger still. Now it's ignoring *all* dependencies and going straight to mpich-default ? That sounds like you have an alias for port to -n? What is sudo type por t? Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Changing PATH and downloading mpich-default
On 05.04.2015 11:07 AM, Ryan Schmidt wrote: On Apr 4, 2015, at 20:51, Evan Phillips wrote: After installing the Macports package, I appended /opt/local/bin:/opt/local/sbin:/ to the PATH variable using the EXPORT command. Probably a mistake: PATH=/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin That looks like a reasonable value for PATH. How might I reset or change this? I realized this when I was trying to download mpich-default: sudo port -v install mpich-default --- Computing dependencies for mpich-default --- Dependencies to be installed: gcc49 cctools llvm-3.5 cloog gmp isl gcc_select ld64 ld64-latest libgcc libiconv libmpc mpfr libxml2 xz gettext expat mpi-doc mpi_select I wonder of we have a(n internal) dependency problem here? ---^^ Obviously xz is to be installed, but the distfile(s) of llvm-3.5 depend on xz. `use_xz yes` is correctly, well, used. llvm-3.5 is installed because of cctools and ld64-latest. I don't get the ordering, though. xz could potentially be installed before llvm-3.5. But maybe the dependencies to be installed list does not have any ordering. In any case -- I can't tell why xz iz not installed before llvm-3.5 currently. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Changing PATH and downloading mpich-default
On 05.04.2015 06:58 PM, Evan Phillips wrote: Mihai - here it is: http://pastebin.com/tp8LjW2U Thanks. That wasn't too helpful, trace mode is failing... What's the output of port installed xz? It should not be installed or active (in your case, at least.) I haven't uninstalled half of my system to reproduce this (and won't), neither did I try to install mpich-default. I did however run (sudo) port -v deactivate xz; (sudo) port -dsvt extract llvm-3.5 and this correctly re-activated xz prior to extracting llvm-3.5 (naturally because xz was already installed and activated on my system), so whatever is happening on your system, I cannot reproduce it easily. If port installed xz does say that none is installed, can you please try sudo port -v clean llvm-3.5; sudo port -dsvt extract llvm-3.5; sudo port -v clean llvm-3.5, just to see if manually running the extract phase suddenly makes port respect the xz extract dependency? Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Changing PATH and downloading mpich-default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.04.2015 06:36 PM, Evan Phillips wrote: Brandon - I reran it. Here is the output: http://pastebin.com/prmyUX2f Can you re-run with both -d and -t, please? Trace mode will print the dependencies respected in each phase, while the normal debug output won't. (Yeah, using trace mode for this is just an ugly hack...) Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVIWgdAAoJEB/WLtluJTqHgAMQAK4W/xMQGU8/K+4LjisLYTb5 5n5z6O9+jBncn+rz9vVyVmAhQm0o1R/EuVKD4xxsK6KdPdPuCEu3p5achFlWp0dF 45b2WERXh0ulqdyuQhBgWvsHCv7QETImXaW45qFvmRlbRkOX+t3Jvg/VPcw0lsct wXH7M3xMDs+wPmG2qr9bplJe6fF/TrWwQwgyWRDQirpUmGbGpFUqk8GBEJiUpexx Xe4Y9e4wmUx8BM7ND+ogc7OSuluCPeEw49OdJcqvNX2vhaBr4dG5/3i8cxH8yKbk IlGhoufiTunsTwCWoCf3yXnKSO1vOQGSji9TZnSUVFzhKBZ/sTBSancAC4L/mBEj rIqac39yg95uXAnEkFvv4cs5rWX1ZEYor+RMF6k3SgbjcKSumyrOsO/EYrNvJSwd zrHwt6pIwqDwUQnESSK8G+K7gk4VIPjjXRvlA5tY7XubUWzLiShq7iA2g4lujJnI Akc6BqCi06rDqONmME+GGAZ/jkPYB9tQ4ZaRzuUpRIUK4FdptUuFvOAnumnggjTp ywRoUWfsp2bxXxx+Lpny5MNL5EyzOZdf9O4q3Kxwan8GOzJMqT/+WP2cqVnoQuq+ 5zlmHblFfJ278mLyBPG6l0mqggGSBbi0mp02WGWdJWV23GYJoXymFesAuz/vp1lp KjDVeAs0j3wP4O+569q/ =Xs9m -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: thread CPU usage monitor?
On 24.03.2015 06:39 PM, Pierre Malard wrote: Their is a lot of utilities like « MenuMeters » (http://www.ragingmenace.com) which can dodo that. A other Mac OS X integrated tool is « Activity Monitor » which can give you a lot of information about system. Neither MenuMeters nor the Activity Monitor utility can show information on a per-THREAD basis. I don't know of any application for OS X to get this kind of information out of the box, sorry. A rather ugly workaround may be running spindump on the to-be-debugged process. This will list all threads, together with the time spent on each function. It's not top-like, though, and only a momentary snapshot. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: thread CPU usage monitor?
On 24.03.2015 07:03 PM, Christopher Jones wrote: Can’t be sure but I am guessing Rene already knows about Activity Monitor… As far as I know it cannot do exactly what was asked, which is show info on threads ? Have you tried htop ? It seems to claim to be able to do thus, and MacPorts has a port for it ;) Unfortunately, I'm a vivid user of htop and it looks like it's not showing individual threads on OS X, even if configured to not hide userland or kernel threads. Believe me, I would notice 85 firefox threads in the output. This may be an htop-OS X-limitation. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: what was up with ntp again?
On 23.03.2015 02:31 PM, Brandon Allbery wrote: (If your clock still drifts after that, file a radar with Apple. Replacing Apple's ntpd with a full one is probably not the best of ideas, although it can be done if needed. But full ntpd is not actually suitable for anything but certain scientific applications that require nanosecond accuracy; you pay quite a bit in CPU and power for that accuracy, and there are very few applications that require more than millisecond clock accuracy. One wonders how much better Linux etc. would perform if they didn't use full ntpd.) rantPretty good, if they use my favorite time keeping daemon chrony./rant For reference: https://fedoraproject.org/wiki/Features/ChronyDefaultNTP Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: what was up with ntp again?
On 23.03.2015 05:51 PM, Brandon Allbery wrote: On Mon, Mar 23, 2015 at 12:15 PM, Mihai Moldovan io...@ionic.de mailto:io...@ionic.de wrote: rantPretty good, if they use my favorite time keeping daemon chrony./rant ...and your port for it is pending? :p (Seriously, I've been using full ntpd because pacemaker isn't quite enough for my constantly changing circumstances, but I can tell it slows things down a bit and it appears to be complicating or at least fragmenting memory somewhat. An alternative would be nice.) chrony requires access to the RTC device. Unfortunately, OS X doesn't even provide a /dev/rtc node. I've never looked into porting it for OS X due to that problem. There likely is some XNU interface to the whole RTC stuff, but I never felt motivated enough for rewriting chrony to use that -- if it's even possible. I have been using chrony on an embedded machine without a real RTC device and that worked. But naturally, without being able to change the drift, it won't do you much good. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: what was up with ntp again?
On 23.03.2015 07:05 PM, Christopher Jones wrote: I also do not have /etc/ntp.drift on either of my OSX10.10 machines. On 23 Mar 2015, at 5:54pm, Brandon Allbery allber...@gmail.com mailto:allber...@gmail.com wrote: No /etc/ntp.drift on my 10.9 machine either. I do have /private/var/db/ntp.drift But this one exists. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: what was up with ntp again?
On 23.03.2015 07:17 PM, Chris Jones wrote: On 23 Mar 2015, at 6:14 pm, Mihai Moldovan io...@macports.org wrote: The default permissions are likely to be fine: -rw-r--r-- 1 root wheel 9 Dec 24 02:58 /var/db/ntp.drift That file hasn't been updated for a while ? Yep. But my clock is perfectly synchronized, I have pacemaker running: root 255 0.0 0.0 2447228136 ?? Ss 19Dec14 5:32.35 /usr/libexec/pacemaker -b -e 0.0001 -a 10 and ntpd: root84513 0.0 0.0 2446576344 ?? Ss 24Dec14 0:28.03 /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift Ah, ntpd was started on 12/24/2014. That may explain why the drift file was last touched at that time. So it seems it only uses it when starting up, on my system anyway? I have never installed the full ntpd on my machine either, so it's all Apple-sauce. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: what was up with ntp again?
On 23.03.2015 07:23 PM, Chris Jones wrote: So why was mine seemingly updated only yesterday ? I've never done anything w.r.t. ntp or pacemaker on this machine, so whatever setting is running it must by definition be the default Apple setup ... ? You likely rebooted yesterday or the like. I haven't done so on a while, obviously... Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: what was up with ntp again?
On 23.03.2015 07:27 PM, Christopher Jones wrote: On 23 Mar 2015, at 6:24pm, Mihai Moldovan io...@macports.org wrote: You likely rebooted yesterday or the like. I haven't done so on a while, obviously… yes, I did reboot around then yesterday. Perhaps I mis understood [Brandon]’s mail though but that seemed to suggest even a reboot wouldn’t update it. But if it does then fine, (non)mystery solved… That's just a misunderstanding. The file is created/updated once whenever Apple's ntpd starts, but never touched again afterwards (until the next time Apple's ntpd is started.) It's not a once in a lifetime deal. So, his explanation fits beautifully. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Apache source?
On 24.03.2015 01:02 AM, Gary Fitts wrote: I installed the MacPorts Apache2 package (apache 2.2.9) hoping to have a build environment where I can add a custom Apache module. But there doesn’t seem to be any build environment — no source files etc, just binaries. Am I missing something, or is there another source package somewhere? Apache modules are typically build via apxs. Note that macports features a (somewhat short) list of modules already: run port search mod_ In any case, building modules does not need any source per se, but only, as Brandon correctly mentioned, headers, libraries and apxs. Which droids are you looking for? Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: mod_unique_id: unable to find IPv4 address
On 21.03.2015 02:30 AM, Gary Fitts wrote: Installed MacPorts for the first time, then installed apache2. When I run sudo port load apache2, an httpd process starts up, and even responds to requests (to http://localhost) if I get them in fast enough. But then the process exits (whether or not it received any requests). The error log shows this: [Fri Mar 20 11:40:41 2015] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Fri Mar 20 11:40:46 2015] [alert] (EAI 8)nodename nor servname provided, or not known: mod_unique_id: unable to find IPv4 address of iMac.local Configuration Failed I’ve searched the archives of this list and I see several references to similar problems, but no resolutions. Any help would be appreciated! The easiest way of fixing this is to add your hostname (iMac.local) to the 127.0.0.1 and ::1 entries in /etc/hosts, like this: sudo -e /etc/hosts change to: 127.0.0.1localhost iMac.local ::1localhost iMac.local I don't know why the stateless autoconfiguration stuff fails in your case and I can't test it either, because my hostname is resolvable within my system by my own (internal and external) name server. Mihai signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Possible corrupt PortIndex file for rsync...
On 21.03.2015 01:04 AM, Carlo Tambuatco wrote:
Sorry, I hate sounding like I'm answering my own questions, but I did
a selfupdate and I think that fixed the PortIndex issue...?
Both selfupdate and sync will refresh the PortIndex by downloading the
one generated on the MacPorts server, yes.
I don't know what happened there, but if it was a one-time corruption,
or even no corruption per se at all and it's fixed now, you're good.
If, and only if, you still see this problem rise up and have no other
way of fixing it (for instance by finding out what causes the corruption
in your network or between rsync.macports.org and your machine or ...)
you can forcefully regenerate the index. Note that this will take a
pretty long time, which stands in no comparison to the simple fetching
port sync/selfupdate do:
sudo bash -c 'cd $(dirname $(port file bashdb))/../../
/opt/local/bin/portindex -f .'
(Assuming a default installation of ${prefix} = /opt/local)
On Fri, Mar 20, 2015 at 7:50 PM, Carlo Tambuatco oraclmas...@gmail.com
mailto:oraclmas...@gmail.com wrote:
Let me clarify a bit...I don't know if this possible corruption issue
is in any way connected to the fact I can't install a certain port. I
was trying to install bashdb 4.2 to complement my bash 4.3 install
from macports and there was an error in configuring the port...which
when consulting the log for the configuration, revealed a warning that
I was using bash 4.3...so there is possibly a version mismatch between
bashdb 4.2 and bash 4.3...
Well, bashdb really is at 4.2, while bash is at 4.3:
root@nopileos/opt/macports-gitsvn# port info bashdb
bashdb @4.2-0.8 (devel)
[...]
root@nopileos/opt/macports-gitsvn# port info bash
bash @4.3.33 (shells)
[...]
This is a known issue, see: https://trac.macports.org/ticket/43590
Judging by that ticket, let's be diplomatic and say that the maintainer
has too much other stuff to do.
Mihai
signature.asc
Description: OpenPGP digital signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmymoney crashes on startup after update
On 24.02.2015 01:43 PM, Stan Sanderson wrote:
On Feb 24, 2015, at 3:07 AM, René J.V. Bertin rjvber...@gmail.com wrote:
On Monday February 23 2015 19:08:31 Stan Sanderson wrote:
__ZN6CppGui13getCInterfaceEv
That's CppGui::getCInterface() which should be provided by something called
port:gwenhywfar4 and is referenced in a plugin (kmm_kbanking) that belongs
to KMyMoney.
Do you know if gwenhywfar4 was upgraded *after* kmymoney? That's about the
only logical explanation I can see how kmm_kbanking.so could have been built
without errors but now doesn't load. Easy enough to check by activating the
previous version.
You have the answer. Activating the previous version of gwenhywfar4 allowed
kmymoney4 to load and function.
In the meantime, you can use `port activate` to revert to the previous KMM
version, and ditto with gwenhywfar4 if required. Or you can try to build it
yourself from source.
I will do a rebuild of KMM.
Have you tried running ,,port rev-upgrade''? Issues like these should be
caught by rev-upgrade. (Also make sure that the policy is set to rebuild
instead of report in ${prefix}/etc/macports.conf.)
Mihai
signature.asc
Description: OpenPGP digital signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmymoney crashes on startup after update
On 24.02.2015 04:52 PM, René J.V. Bertin wrote:
On Tuesday February 24 2015 15:56:56 Mihai Moldovan wrote:
Have you tried running ,,port rev-upgrade''? Issues like these should be
caught by rev-upgrade.
Does it check each and every file known to belong to ports depending on an
upgraded port? In this case we're talking about a plugin module, so not
something linked statically, and with a platform-aspecific extension at
that.
Plugins should be caught as well. If they are not, this is a bug and
should be reported as that.
(Also make sure that the policy is set to rebuild
instead of report in ${prefix}/etc/macports.conf.)
I'm sure Stan would have seen the warning posted by the reporting-only policy
;)
Don't blindly assume stuff. There are easily multiple reasons why users
may not see this.
The default policy is rebuild anyway, and if the user didn't change it,
kmymoney's breakage should have been caught and rebuilt (if detected of
course.) This doesn't work out, though, if upgrading generally didn't
complete and failed. In this case, rev-upgrade is not even run.
Then, there's always the possibility of users not seeing messages due
to output spam and seemingly unrelated content.
Mihai
signature.asc
Description: OpenPGP digital signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: cmake portgroup RelWithDebInfo variant?
On 28.07.2014 06:14 pm, René J.V. Bertin wrote:
- can one have local portgroup definitions/overrides?
I wouldn't know what speaks against that.
- what would be a good variant name to enable the RelWithDebInfo (release
with debug info) cmake type? I currently use
{{{
if { [variant_isset nostrip] } {
configure.args-delete -DCMAKE_BUILD_TYPE=Release
configure.args-append -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
-DCMAKE_STRIP:FILEPATH=/bin/echo
}
}}}
but that's not the most satisfying name I ever came up with ...
I think no* variant names should be avoided, replacing them with the appropriate
base name (in this case strip) and making them the default.
Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: cmake portgroup RelWithDebInfo variant?
On 28.07.2014 07:29 pm, René J.V. Bertin wrote: On Jul 28, 2014, at 18:52, Mihai Moldovan wrote: - can one have local portgroup definitions/overrides? I wouldn't know what speaks against that. Neither do I, nor do I know how to go about them. Add a registry directory under the directory that holds my local port files? Hum, I rather understood this as override whatever the PortGroup does in the Portfile. That should be totally OK, but defining own PortGroups? I don't think that's a great idea... I think no* variant names should be avoided, replacing them with the appropriate base name (in this case strip) and making them the default. Except that would probably cause problems with all ports currently installed without that implicit-gone-explicit variant, That's not a big deal. Add the default variant, revbump and you're good to go. plus I'm not sure that without nostrip build results are always being stripped. So what is the default then? Maybe is a little non-deterministic... In other words, the actual no-stripping effect of that personal variant is to take a step to avoid that stripping takes place. In that case, nostrip is probably OK. Still, it might confuse users to see that their binaries aren't stripped when nostrip is not set. OTOH, +relwithdebinfo seems a bit long/heavy for a variant name. +reldep? +debopt? +devel (as it's something more of interest to developers than endusers)? Would you understand what reldep/debopt/devel do without having to look it up? If not, chances are those are bad names for what you want. Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Need help: Some port fetches consistently fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28.07.2014 09:22 pm, Sam Finn wrote: Doesn’t a 403 indicate that the server received and understood the request, but refused to act on it? In any event, there is no proxy and I’ve checked that my firewalls (the mac os firewall and intego net barrier) are down. Am I missing something? 403 means that the server denied you accessing the file due to (mostly) permission problems. However, this behavior is not reproducible outside of your environment, so there must be something intercepting requests. At least not reproducible by me with any provided mirror. Other information that may (or may not) be helpful: * I’m reaching the network through an apple AirPort Extreme, which is providing both NAT and DHCP services * The computer I’m working on right now is set-up as the default host (i.e., it has a DHCP reservation, whose IP is the default host). What does /usr/bin/curl -o /dev/null http://lil.fr.distfiles.macports.org/expat/expat-2.1.0.tar.gz; return? Still the 403 HTTP error? If yes, it seems to be a site-specific problem. Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT1qWKAAoJEB/WLtluJTqHR7oP/ivJHy9+kQYNYxMpOrlh6pF9 UJBpTg3nl4sYQjI5br18ZjKEZRBQLNfac5T11aSUtk6HzR1NXhqsY4jAOjHbQxP+ u/ZThqEXT8mT/JVHMO9/u6hF3XVFQSs6QgwbbxUklfqEA/m+3hFs3MKiWvyFBBJR DJ4OY5FtQRYH1Et7WyWPhvOSDmcR/H75FpEVYBEFwaebTCNXyO8frY9LyTk8RHEp N6ahznEKWLr+NQI3Y+KH690WY3a4plzdiyi1VU7FPotgHYKXpuo4ym4+lHjRp9Ub AJUkGmfWOE7yf2mHeocMFgIx2BEDa5m+FsMGhLCQP+SigC+bL3B88DTmo9CkmL1x ptuDH9A9nscNk3iJlbs4NSuOy/UxzPIi8R5tGy4Z2inCwMbfRk0OZ/CplbPTv5/m jlfAVHEkVSJOe944VM0VZFTrLjS3VQW4kRw3GJXl1fR2pV8iLmoResqcUkLCmdr4 PP2UJpOBs1vORs2dS3H8P4BUPWSl+bRfeRyaF+qerXdGc3qnXR3pjcX91ETP6SjL h1dtlDVsfr4/5f0YA1GuYq4pqUcyWbf5xvFur+UMtPjdJMc0EGjRWCE2IkUkuAfL imhyWVbnqawajbmlfWwA1daskgrrp3L2S+kKqa3RJps201QHgXeJy6d/5Z48/lMi y4+DLYnwpcsxViDQ9Wp2 =h1nn -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Need help: Some port fetches consistently fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28.07.2014 09:36 pm, Sam Finn wrote: No 403 error this time: Weird. But thanks to toby, here's another idea: /usr/bin/curl -o /dev/null -A MacPorts/2.3.1 libcurl/7.30.0 http://lil.fr.distfiles.macports.org/expat/expat-2.1.0.tar.gz MacPorts is using a special user agent string. Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT1qgbAAoJEB/WLtluJTqHi5cP/1IuI3tFvTCdqpy1ype3d8pW oqk0/0Pd8w+PGzW/XtwxpBRZBLp2y9mRUnLBju91AvTfH8PdepFKrg4FzXMF7/D8 9SX3eIxNHtE9m0vlt1YGlkpDnGB9xog3nyjgcjZBl1zzZI1iO/du+hycn8UKyC5l NnIdQMF7Cf/WJUSZoJVypJ5wqCTuqJQMq15B4MMnDZP1CsUHIwUrj+3d85RiKJL5 B1lm2ZJ+5ZnJegVZQrggxWRWOUDuRZwTqwUGurYck/YhLVH+hPK1gRnsswLwJWCH CmwSjC2mIDENJ5N0l0jI2tPmKbCVaZsvQBiybOH9y0lE83OjVI1P8CyziHkxav1l 6SbeOV2ie5fdvTZQn0pJqCa9hGoHLwgZ9p5OuJRWjWfEBgy0IC3QDHinMW9eDNuo iXSQJgO4N9UsFvGqBuIhNE/zO+4JDx5uBzHXs5hPfQc7+m2x1px0wRlNZ6++LhO7 vrteg5EAfp0wOTtQeN1PH88FTkRZ89C2WTLmhTtCqedpHWyWvtiYJRBnbl/PnmYx qcV0VvUzU2dJ6P8D4cBcSkwgZTG0m3eossBlQyYt5zUiWONfZQvdfNKJ1gkFPe7z +d6/ZMl727xrB8BkwaMxb3Go8iyd0A3D8QfP9v01jIXV/VFnF1RJZCO83zQXiJGM 93LLlJ9uDXO1fBaMCnpc =dAG6 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Need help: Some port fetches consistently fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28.07.2014 09:54 pm, Sam Finn wrote: Thanks very much for all your efforts! Appletree [129] Yeah? /usr/bin/curl -vo /dev/null -A MacPorts/2.3.1 libcurl/7.30.0 http://lil.fr.distfiles.macports.org/expat/expat-2.1.0.tar.gz [...] GET /expat/expat-2.1.0.tar.gz HTTP/1.1 User-Agent: MacPorts/2.3.1 libcurl/7.30.0 Host: lil.fr.distfiles.macports.org Accept: */* HTTP/1.1 200 OK [...] OK, the sent user agent is fine and the HTTP server response is, too. What makes me wonder is that your main.log shows 403 OK as the error message. That should be either 200 OK or 403 Forbidden, but not 403 OK in general... What does echo $http_proxy $ALL_PROXY say, if anything? Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT1q4YAAoJEB/WLtluJTqHhRUQAMRbs+4YQb5NTC0YX36LpBPR 1iZACGmEgBBhs81WUUwYupiW5tml4Ux35RB0VBHqIdqryNEDJUnDmQhHa0z6a+ef FssJiRkS4yX6Sg7T110BvMyATaUd2EMbXKWPMKe6lixUO5mKIXdySu43L/Qag+iK Wk2MixVfcpTr2Mru+4n2YQxE7RyL68rnW258kAelQUg7GXyvTocW4bggVNK7EL9e FYiiNNw40NagijuSsZldR5tO4xtN+fsXN4kLfsDwMFCsBsRSCFFj3rSGs3UdU0Gw lKxDmOqclv5n6laGXr2+vMUobMj3N93t1T3AZFzbXmyK9xYhK53a9D6wlgx0KB4X fy28sSJSMlofGiTYJlaxoNVk2qWqJTl3zR8gnYUWCSKlMFa4KmPjtcU8+A27RDUj XGYfGnxcioHcsjNS27KoNgPsTKo5n4n8VQHRik/nwTDU5bhtwO+7+s2moOXgf14+ D3N+PaWLA3qFZXFwEQGRiimodU+j6YrlY535NFVnDnJK1L1geuOlWHWpiC06+zI+ MqesAr6afML8bBtCsHFIY9zVzSZ1v+NDTe2Kd3UAYssbF/Grdgq7kt6Oh4LhsoKm d6g6DKVRGORsGROS5XWmWy+7eJT4wSB9aY+qNlzECUUr/QCrYSuqQ88hVI/QtBg3 icBudhQkc1dkhmwtU92I =Ogp8 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Need help: Some port fetches consistently fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28.07.2014 11:01 pm, Sam Finn wrote: In bash, Appletree [132] Yeah? bash bash-3.2$ echo http_proxy: '$http_proxy'; ALL_PROXY: '$ALL_PROXY' http_proxy: ''; ALL_PROXY: '' bash-3.2$ echo $http_proxy $ALL_PROXY bash-3.2$ So there's no global proxy defined... The only other options added by MacPorts are -R and --disable-epsv. The last option only applies to FTP transfers, so we can ignore that. Does port -v fetch expat also fail with the aforementioned symptoms? Feel free to test with -R, but if that doesn't show any 403 errors, I'm out of ideas what could be wrong. Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT1sHAAAoJEB/WLtluJTqHRroQAJ4XSFHh1vrC2yMiecRLldTO cuf1VKUhJxDiw3997c0mUjdK6MMUP1VwJda+FNsGSBFnoAlp3SFg3mgQEcpehkGL c9VHUZmRIp43uHWEiB5/p18CIf0m5fw1M/vN4zyEUT5WTSosBTXZAQvPYCeLfoJu njln2fK2kXcQrxOhlvfWuXHl46425UShIHDDXabOXyDGm2IRkmBkKLX8DcGGDtQI RWbPez60FXkRydMLvH9yyH4P7KgZD02zSBUycIlinaJ49sFSBYnIhzgSKyWZiqXJ bpjN2VMj/+0bYPKYszg0YuWjIJ9id2dR2eTzQeuBLMIEAW0XXGNM/sYKCgi2OFHz qY+Pjky9dY+cY8e5fT5244unCxOkq0eKNRZMUgVfe+Q0qUWFLhtT782q2LVQ/aZJ /k4V0YYHqMpwx/u6TvrExSSg2qqkD03f5ip9xQesL0p5KwRcWMFlfDS5Ie7+zPA6 LWXGrR4JztxlXcNwh9CVv7HYZEjb7g9whC+gxlOGZ5PjZ8Oy4311YRfhRTfxWBXc bV/pbHOzHAVnvp3awI4lWTRuBESCsOozKOS+cQjqPq1mISb2rkv3Wx52hDtFG+fi VpOu0g5vy8igMqiqSrxXewy4thJKhuKEnRbpCO27DBXsP/qdrXC+KKCrCmahvsf4 KiTO73E0aJq9el9I6yz3 =sI3A -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Need help: Some port fetches consistently fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28.07.2014 11:46 pm, Sam Finn wrote: No joy. I can only suggest adding -R to the previous curl call. I doubt it changes the result, but who knows... (-R tries to fetch the remote file's time stamp, if possible.) Short of that... no idea... MacPorts is using the system's curl library when compiling itself, so there shouldn't be any compatibilities. You did reinstall or rebuild MacPorts itself after upgrading to Mavericks, right? sudo port -sv selfupdate takes care of that. Mihai -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT1tGpAAoJEB/WLtluJTqHGAYQAOPHfMX6uGbRU7xXqMcmTX3S QKPyY3Ddp4WbuMPQWo3OraY2/Cr/vYqaoIajtj2MDirr9Kp0DwZMkpUa7S25KiQv rOg29jGrDeV5bD6O22+qeA/F0iPgHEueDF1U4Yq9b1AwXiavMDwnp85oo0XlOnNO mMve9hHsIp42GOJd2t5SRLCnIvG2wrN7o//qfwRctM4r31hI6imXSyveZ3YR0h4d ILojoPRfwvJON3Bymo5rMQec9pix1PWbMx0r3nApOFbB8ZYsVVbXa7saxLXmGZDo jRsUSvVxC6Lwr8NI4J5HWYbZTZiEEM0toi/tE++drxpLFEQffwxewZqZdKWFCfC3 WkwDRnTUQJTXLfpI4Z0wQ2Gi2qDqEfP8v5OkDGoNTxSE1tz0wx9XO9SOCI96X81D Hs2+zg1KWAL/1wdEcb2OK9fyxdQaZL7sio6kv7jyKfPf+WxTG1d9YnQ7VBcurQSe G0QWtgLDKAKp6y7+wjjOWKfoAqsVoOzoDd3mXm6e7iPmc+w55AUXDBd+Q2MaLv9Z q6Eoe/aduAjEs8LS3snDR1qPBmvs/8BiJkHJWuDU8GSY+2+H4E9XJYo+ByMB6z8e hGaJZwfoYxstKPWXR4nKS3nE5mg/PgbtCBsyiL8tWjCAqGKpqj0iUgNuojpvVEKS D2BZxo/qpMb/K/TjX9hB =JHQP -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: PIL + ReportLab vs Pillow
* On 08.07.2014 01:28 pm, p...@macports.org wrote: On 8 Jul 2014, at 02:00, Mihai Moldovan io...@ionic.de wrote: * On 07.07.2014 11:32 am, Peter Danecek wrote: Why not allowing that either PIL or Pillow satisfies the dependency where possible. [...] This would avoid potential conflicts if users need to install other (still) PIL dependent software. That would be possible, yes. But as I understood it, Pillow is a drop-in replacement for PIL and is always supposed to work with software initially written for PIL. Probably, yes. But I do not know the details about compatibility, so would not make the statement that Pillow can *always* replace PIL. I found this: +1. The only thing Pillow could not provide was the distribution name PIL on PyPI. So you must pip install Pillow instead of PIL. Everything else e.g. from PIL import Image should be the same. Alex Clark, Pillow (PIL fork) author From that, and the fact that most Linux distributions are only shipping Pillow (checked Debian, Gentoo, Centos -- all with the same result) and not seem to be running into trouble or even patching packages that formerly used PIL, I think it's safe to say that Pillow can *always* replace PIL. (Just not the other way around.) However, I'm not a python programmer and might be wrong. My thinking was that, as Pillow is supposed to be a PIL-compatible drop-in replacement, we could avoid all problems like - package1 - Pillow - package2 - PIL = package1 can't be installed at the same time with package2 (and vice versa) This is why I am proposing the solution above. If at least one of the above packages (e.g. package1) can install with both alternatives, you will be able to install, but the sequence is relevant. If both support alternative, you have no problem at all. Of cause, if you would replace PIL as dependency in all ports at one time, no conflicts arise. I'll replace all occurrences of PIL with the path:-based alternative you suggested. (Note that while PIL is supposed to always be substitutable with Pillow, the other way is not possible, if specialized Pillow features are being used.) Does that make sense? I this is true, PIL could be phased out at some point. Yes, this is what I'm aiming at. It hasn't been updated in 4 years anyway, while Pillow is still actively developed. (We can leave PIL in the tree, I'd just like to get all dependencies switched to Pillow. Maybe PIL development will magically pick up again one day, who knows.) Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: PIL + ReportLab vs Pillow
* On 07.07.2014 11:32 am, Peter Danecek wrote: Why not allowing that either PIL or Pillow satisfies the dependency where possible. [...] This would avoid potential conflicts if users need to install other (still) PIL dependent software. That would be possible, yes. But as I understood it, Pillow is a drop-in replacement for PIL and is always supposed to work with software initially written for PIL. However, I'm not a python programmer and might be wrong. My thinking was that, as Pillow is supposed to be a PIL-compatible drop-in replacement, we could avoid all problems like - package1 - Pillow - package2 - PIL = package1 can't be installed at the same time with package2 (and vice versa) (Note that while PIL is supposed to always be substitutable with Pillow, the other way is not possible, if specialized Pillow features are being used.) Does that make sense? Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: PIL + ReportLab vs Pillow
Hi, I've actually hit this issue today. I need rst2pdf, which has an (undeclared, I'll fix this) runtime dependency on py27-Pillow and py27-reportlab. py27-reportlab currently depends on py27-pil, while newer subports depend on Pillow. I've been in touch with the maintainer, I hope I can quote his answer freely. * On 05.07.2014 05:27 pm, Andrew Stromnov wrote: Dependency on PIL (py27-pil) comes from good old times, when Pillow even did not exist. PIL software was abandoned in 2007, and so don’t have any support for py3k. This said, my proposal is to also switch py27-reportlab to py27-Pillow, as I see no good reason to keep depending on pil. I have already patched this, but have to test it (only lightly with rst2pdf) before filing a trac ticket and posting the patch. Glenn, I believe this will also fix your initial problem? Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: infinality patches
* On 23.06.2014 06:14 pm, René J.V. Bertin wrote:
What libfreetype do X11 applications under MacPorts use, with which
anti-aliasing settings?
Supposing it's the freetype port that determines the display quality of fonts
(and not the one that ships with XQuartz), what are the chances that the
Infinality patches would provide the same benefits as they do under Linux?
Because font display quality leaves a bit to be desired under XQuartz, IMHO
...
Infinality would be great.
However, could we please take care not to run into this bug?
https://bugs.gentoo.org/show_bug.cgi?id=494764
MacPorts obviously ships ${prefix}/share/ghostscript/9.10/Resource/Font (I just
checked), so we're fine, but I'd like to keep it like this. Not being able to
print is a pretty big deal.
A further question, René. I have only used infinality on Gentoo, and there we
have this awesome eselect [fontconfig|infinality|lcdfilter] tool:
root@valery~# eselect infinality list
Available styles:
[1] debug
[2] infinality
[3] linux
[4] nyx
[5] osx
[6] osx2 *
[7] win7
[8] win98
[9] winxp
[0 running job(s)] {history#10006} 3:41:55 14-06-24
root@valery~# eselect lcdfilter list
Available styles:
[1] custom
[2] default
[3] infinality *
[4] infinality-classic
[5] infinality-nudge
[6] infinality-push
[7] infinality-sharpened
[8] infinality-shove
[9] linux
[10] nyx
[11] osx
[12] ubuntu
[13] vanilla
[14] windows-7
[15] windows-7-light
[16] windows-xp
[17] windows-xp-light
[0 running job(s)] {history#10008} 3:42:16 14-06-24
root@valery~# eselect fontconfig list | grep -i infin
[27] 52-infinality.conf *
How would the configuration be done on OS X?
AFAIK, eselect mainly creates symlinks, but could as well also do $MORE_MAGIC.
I've never looked into that.
Obviously, infinality can be tweaked to quite some display options, which is
great, but I'm not quite sure how to make that easily user configurable.
Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: cdrtools: MacPorts version doesn't work as expected but manually compiled one does
Hi Davide Do you, by any chance, get the same output from MacPort's cdrtools and the manually compiled one when running sudo /opt/local/bin/cdrecord -scanbus I suspect the problem to be caused by requiring root permissions. The manually installed version has likely set setuid root on the installed binary, while this part may have been stripped by MacPorts. Just a wild guess, though. Best regards Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Setting locale
Just a quick follow-up. * On 22.05.2014 04:39 pm, Gustavo Seabra wrote: Especially, LC_CTYPE=UTF-8” seems suspicious, as “UTF-8” doesn’t seem to be a valid specification. This is indeed legal, even if it looks strange. LC_CTYPE takes a charset encoding, you can get a list of all supported ones with locale -m. Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: small doubt regarding gcc_select ...
* On 12.05.2014 05:59 pm, Peter Danecek wrote: I just realised that `port select gcc` sets /opt/local/bin/c++ - /opt/local/bin/c++-mp-4.8, while there is no corresponding link for `cc`. Nice catch. Would it not be cleaner to either - point also cc to `/opt/local/bin/gcc` I'm in favor of this. Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Installing Octave port into new Mavericks system fails
* On 09.05.2014 10:25 am, Jerry wrote: I get: $ port installed atlas The following ports are currently installed: atlas @3.10.1_5+gcc48 (active) Can you verify that you’re seeing the same error? Not if I understand the above result. Doesn't that indicate that atlas is installed? Yes, it is installed. Also the most recent version. No need to worry about that (for now.) FWIW the thread there mentions gcc48 and FWIW I used variant +gcc48, as in sudo port install octave +atlas+docs+fltk+gcc48 If you look at my original post (with some generated output), all it says is that a bunch of dependencies were not installed but it doesn't give a clue why or what to do about it. Try to run sudo port clean octave sudo port -dsv install octave +atlas+docs+fltk+gcc48 21 | tee ~/octave-build.log Afterwards pack the build log up (warning: it may and likely will be OVER 9000) using e.g., bzip2 -9 ~/octave-build.log and attach it here. Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
