Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
On Sat, Mar 22, 2014 at 2:49 AM, Bradley Giesbrecht wrote: On Mar 20, 2014, at 3:54 AM, Clemens Lang wrote: As a port maintainer, one key thing I'd like to know is the breakdown of OS versions that my users are running. The data is available for that, right? Just a matter of extracting and presenting it? Yes, that data is available. I think all the graphs need to be given a little thought. If somebody has the time to make a list of graphs that might be useful given the data we have, feel free to make a wiki page for that or even just reply to that email. Anything helps :) Does anyone have a quick link to the db schema or better yet a data dump from stats.macports.neverpanic.de;) ? You'll need to ask Clemens for the actual data dump, but the schema can be found here: https://trac.macports.org/browser/branches/gsoc11-statistics/stats-server/db/schema.rb Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts 2.3.0-beta1 now available for testing
Just a though/suggestion, if still in time: would it be possible to add an option to the port command allowing to override the number of build jobs configured in macports.conf ? Most of the time I let MacPorts builds grind away in the background, and so allow only 2 out of my 4 (virtual) cores, but there are times I'd like to go higher without having to edit the configuration file ... R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts 2.3.0-beta1 now available for testing
It is build.jobs=1 René J.V. Bertin rjvber...@gmail.com wrote: Just a though/suggestion, if still in time: would it be possible to add an option to the port command allowing to override the number of build jobs configured in macports.conf ? Most of the time I let MacPorts builds grind away in the background, and so allow only 2 out of my 4 (virtual) cores, but there are times I'd like to go higher without having to edit the configuration file ... R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Is missing python.default_version bug?
Dear MacPorts users, Some ports like py-ipython and py-cython do not set `python.default_version`. The result is that `port install py-ipython` pulls py24-ipython. So (1) should this be reported as a bug (the patch is trivial in any case)? (2) I could not find how to tell port that `py-ipython` should install `py27-ipython`, so I installed `py27-ipython` directly. Is this the recommended way? And (3) is there a way to globally tell macports that I want `python.default_version 27` by default? Mathias ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmail cannot send email : reason identified (?)
On 22 Mar 2014, at 14:16 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote: And I think I know why: the kioslave entry is commented out in the kdepimlib toplevel CMakeLists.txt file … Any idea what this was commented out? Is that a patch applied only to make KMail run on MacPorts or is that coming from KDE? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmail cannot send email : reason identified (?)
At 4:31 PM +0100 3/22/14, mk-macpo...@techno.ms wrote: On 22 Mar 2014, at 14:16 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote: And I think I know why: the kioslave entry is commented out in the kdepimlib toplevel CMakeLists.txt file Any idea what this was commented out? Is that a patch applied only to make KMail run on MacPorts or is that coming from KDE? I hesitate to say anything, because I really don't know anything about the problem at hand, but could the 'ioslave' be a daemon that they're trying to start? OS X won't permit that but Linux does. Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmail cannot send email : reason identified (?)
On 22 Mar 2014, at 16:37 , Craig Treleaven ctrelea...@cogeco.ca wrote: but could the 'ioslave' be a daemon that they're trying to start? OS X won't permit that but Linux does. Hmm, perhaps this is a good time to change over to KDE-DEVEL to clarify this issue. I am not knowledgable enough to answer anything here, but on KDE-DEVEL there is Ian’s initiative to improve KDE on Mac and this might be a topic to bring up there as well. (I’ve never tried to build kmail on the Mac, because I don’t want two programs to mess with my emails. Mail.app alone is troublesome enough on Mavericks these days.) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmail cannot send email : reason identified (?)
On Sat, Mar 22, 2014 at 11:37 AM, Craig Treleaven ctrelea...@cogeco.cawrote: At 4:31 PM +0100 3/22/14, mk-macpo...@techno.ms wrote: On 22 Mar 2014, at 14:16 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote: And I think I know why: the kioslave entry is commented out in the kdepimlib toplevel CMakeLists.txt file Š Any idea what this was commented out? Is that a patch applied only to make KMail run on MacPorts or is that coming from KDE? I hesitate to say anything, because I really don't know anything about the problem at hand, but could the 'ioslave' be a daemon that they're trying to start? OS X won't permit that but Linux does. KDE on OS X already starts plenty of daemons (notably kdeinit). While you're supposed to do stuff through launchd, it's not absolutely mandatory, can't be enforced, and KDE would be rather difficult to get working at all if you couldn't. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Is missing python.default_version bug?
This was a leftover of the old behavior from when `py-*` ports were actually `py24-*` ports in disguise, instead of stub ports like they are now. jmr seems to have fixed it in r118101https://trac.macports.org/changeset/118101 On Sat, Mar 22, 2014 at 9:38 AM, Mathias Laurin mathias.lau...@gmail.comwrote: Dear MacPorts users, Some ports like py-ipython and py-cython do not set `python.default_version`. The result is that `port install py-ipython` pulls py24-ipython. So (1) should this be reported as a bug (the patch is trivial in any case)? (2) I could not find how to tell port that `py-ipython` should install `py27-ipython`, so I installed `py27-ipython` directly. Is this the recommended way? And (3) is there a way to globally tell macports that I want `python.default_version 27` by default? Mathias ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Is missing python.default_version bug?
On Mar 22, 2014, at 08:38, Mathias Laurin wrote: Some ports like py-ipython and py-cython do not set `python.default_version`. The result is that `port install py-ipython` pulls py24-ipython. So (1) should this be reported as a bug (the patch is trivial in any case)? This was intended behavior. (2) I could not find how to tell port that `py-ipython` should install `py27-ipython`, so I installed `py27-ipython` directly. Is this the recommended way? Yes, you’re meant to install py27-ipython, if that’s what you want; there’s no reason to install py-ipython. And (3) is there a way to globally tell macports that I want `python.default_version 27` by default? No, that wouldn’t make sense. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmail cannot send email : reason identified (?)
On Mar 22, 2014, at 16:54, Brandon Allbery wrote: Any idea what this was commented out? Is that a patch applied only to make KMail run on MacPorts or is that coming from KDE? The comment in the Portfile (from Nicos) states that we don't need it ... Anyway, I just rebuilt the port from sources after commenting out the patch entry as well as the MAILTRANSPORT_INPROCESS_SMTP off switch. In other words, the port should have been build as much stock as possible. No luck, sadly, but I guess I'll have to try rebuilding the kdepim runtime too. KDE on OS X already starts plenty of daemons (notably kdeinit). While you're supposed to do stuff through launchd, it's not absolutely mandatory, can't be enforced, and KDE would be rather difficult to get working at all if you couldn't. All (or most) those daemons are started through DBus, and that in itself seems to work. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
Hi, Does anyone have a quick link to the db schema or better yet a data dump from stats.macports.neverpanic.de;) ? You'll need to ask Clemens for the actual data dump, but the schema can be found here: https://trac.macports.org/browser/branches/gsoc11-statistics/stats-server/db/schema.rb Sure, I can provide a full dump – I'd rather not mail it to the list, though, so please contact me off-list if you want a dump. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
At 7:20 PM +0100 3/22/14, Clemens Lang wrote: Hi, Does anyone have a quick link to the db schema or better yet a data dump from stats.macports.neverpanic.de;) ? You'll need to ask Clemens for the actual data dump, but the schema can be found here: https://trac.macports.org/browser/branches/gsoc11-statistics/stats-server/db/schema.rb Sure, I can provide a full dump - I'd rather not mail it to the list, though, so please contact me off-list if you want a dump. I'd take a copy. Maybe you could just put it on DropBox or something similar? Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
A smarter migration behaviour (was Re: usage numbers for macports vs. homebrew?)
The amount of traffic to this list that comes down to “you need to run the migration steps from the [Migration] page” is astounding, and it must be a real drain on the time of those who by now must have answered hundreds of such questions. It seems to me like we could go a long way toward solving the problem by: 1. saving at install time the output of `uname -r` (OS release) into a file in /opt/local/etc/macports/ 2. every time `port` is run, compare the stored with the current value and stop with an error message if they differ (or more likely if they differ in more than the patch level) The error message could direct the user to the Migration page. (Even better if we had a new `port` action to perform the migration steps automatically, even if it wasn’t particularly picky whether a port is being reinstalled because it was requested or simply active at the time of the migration.) Would this be a workable solution or am I missing something? Davor On Mar 18, 2014, at 8:27 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: This mostly already exists: it’s currently only for packages that are installed. port echo requested port setrequested … Presently, to get your between-installs behavior, you’d dump the output of echo requested to a file then read it back in. Hilariously, our Migration page (!!! this is something that should go away !!!) breaks even this! There’s the tiny after-the-fact note you notice once you’ve lost all the information that “oh, I could have done requested instead of everything. On Mar 18, 2014, at 23:11, Kevin Reid kpr...@switchb.org wrote: One of the things that would make even a manual rebuild much more convenient is if MacPorts allowed a port to be “requested” even if it is not installed. (I think I recall that the Debian package manager works in a way like this.) Then the upgrade process would be closer to uninstall * install requested This would also be useful in cases like this where a port is broken (can't be fetched/built/installed); I would like to be able to have a port requested-but-not-installed as a reminder to install it when it is no longer broken. OS upgrades are one of the ways ports end up broken, too. (If this feature were to exist, it should also remember what variants were requested; I don't know whether the requested-state information currently includes this but I would assume not.) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
Just a concerned question: Why is that database given away to anyone who asks? Sure, there are only 10 users who have committed all their information to Clemens’ server neverpanic.de, but I don’t see why information like that shall be spread even further. Greets, Marko ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Collaborating on Github (was Re: usage numbers for macports vs. homebrew?)
On Mar 18, 2014, at 10:54 AM, Daniel J. Luke dl...@geeklair.net wrote: GitHub was the new exciting place to be as well. GitHub plus not having to learn/use tcl seem to be the major features that pull people/create interest from what I've seen (but I haven't looked in on it in a while). Github is really good at lowering the barrier to participation. I’ve noticed how many of the Perl modules from CPAN have moved their development there. Here is a comment from David Golden, one of the core Perl devs: http://www.dagolden.com/index.php/361/convert-to-git-and-get-more-patches/ Its issue tracker may not be as good as Trac or Bugzilla, especially for big projects with hundreds of open issues, but for collaboration over code it’s the best tool out there right now. Davor___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
Hi, Just a concerned question: Why is that database given away to anyone who asks? I agree this is a valid question; let's discuss that before I hand out any statistics data. However, there are other parts of the database besides the schema that are rather hard to setup (e.g. the database of ports). Sure, there are only 10 users who have committed all their information to Clemens’ server neverpanic.de, but I don’t see why information like that shall be spread even further. The plus of information you'd get from a dump that you currently cannot see on the web interface is the connection between a user's UUID and the ports he installed. You cannot drill down on users in the current web interface, even if the data allows doing that. I think however, that's a feature we don't want to support, and maybe I should not be handing out the statistics data (you can generate some for your own local tests) but just the data from the categories and ports tables. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
On Mar 22, 2014, at 12:04 PM, Clemens Lang c...@macports.org wrote: Hi, Just a concerned question: Why is that database given away to anyone who asks? I agree this is a valid question; let's discuss that before I hand out any statistics data. However, there are other parts of the database besides the schema that are rather hard to setup (e.g. the database of ports). Sure, there are only 10 users who have committed all their information to Clemens’ server neverpanic.de, but I don’t see why information like that shall be spread even further. The plus of information you'd get from a dump that you currently cannot see on the web interface is the connection between a user's UUID and the ports he installed. You cannot drill down on users in the current web interface, even if the data allows doing that. I think however, that's a feature we don't want to support, and maybe I should not be handing out the statistics data (you can generate some for your own local tests) but just the data from the categories and ports tables. On the other hand, the user data is anonymized by the UUID, right? Is there anything in the data that ties the data to a user, beyond the UUID, which is generated randomly by the user install? ipaddress? I’m not arguing that the data should be completely public, but checking where we are were the data to become completely public through accident or hack, etc. And maybe I’m suggesting that it might not be so dangerous to make the data available to a trusted committer as a step toward improving the system... James ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
Hi, On the other hand, the user data is anonymized by the UUID, right? Is there anything in the data that ties the data to a user, beyond the UUID, which is generated randomly by the user install? ipaddress? We only store the UUID, there's no connection to any personal data. The apache logfile has IPs, but those are regularly rotated and I'll look into anonymizing those even more, possibly by clearing any but the first two octets. I do not log any post data along with the IP address, so I cannot tie IPs to UUIDs, except maybe by correlating the last-update timestamp and the logfile. I’m not arguing that the data should be completely public, but checking where we are were the data to become completely public through accident or hack, etc. And maybe I’m suggesting that it might not be so dangerous to make the data available to a trusted committer as a step toward improving the system... What about people who are not committers? Plus, development can be done with random auto-generated data and there even is a script to generate some in the source tree. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
postfix build fails with clang error
I can build postfix by itself but if I add any variants it fails with the error below. I'm trying to build postfix +dovecot_sasl +mysql5 +pcre +tls and all the added variants get built but it fails on postfix. Any help greatly appreciated. Fresh OS X 10.8.5 on MacPro3,1, Quad-Core Intel Xeon, 2.8 GHz, 4GB RAM Error occurred with with Xcode 5.1 so I removed thinking some new clang problem and installed Xcode 4.6.3, but same error. Here's the tail end of /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/main.log ... :info:build cp libmaster.a ../../lib/libmaster.a :info:build /usr/bin/clang -DNO_PCRE -arch x86_64 -DHAS_MYSQL -I/opt/local/include/mysql5/mysql -Wmissing-prototypes -Wformat -Wno-comment -DBIND_8_COMPAT -DNO_NETINFO -DRESOLVE_H_NEEDS_ARPA_NAMESER_COMPAT_H -g -Os -I. -I../../include -DMACOSX -o master master.o master_conf.o master_ent.o master_sig.o master_avail.o master_spawn.o master_service.o master_status.o master_listen.o master_vars.o master_wakeup.o master_watch.o master_flow.o master_monitor.o ../../lib/libglobal.a ../../lib/libutil.a -L/opt/local/lib -R/opt/local/lib -L/opt/local/lib -arch x86_64 -lresolv -L/opt/local/lib/mysql5/mysql -lmysqlclient -lz -lm -lresolv :info:build ranlib ../../lib/libmaster.a :info:build clang: error: unknown argument: '-R/opt/local/lib' [-Wunused-command-line-argument-hard-error-in-future] :info:build clang: note: this will be a hard error (cannot be downgraded to a warning) in the future :info:build make: *** [master] Error 1 :info:build make: *** Waiting for unfinished jobs :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/work/postfix-2.11.0/src/master' :info:build make: *** [update] Error 1 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/work/postfix-2.11.0' :info:build Command failed: cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/work/postfix-2.11.0 /usr/bin/make -j4 -w :info:build Exit code: 2 :error:build org.macports.build for port postfix returned: command execution failed :debug:build Error code: CHILDSTATUS 93866 2 :debug:build Backtrace: command execution failed while executing system -nice 0 $fullcmdstring (eval body line 1) invoked from within eval system $notty $nice \$fullcmdstring invoked from within command_exec build (procedure portbuild::build_main line 8) invoked from within $procedure $targetname :info:build Warning: targets not executed for postfix: org.macports.activate org.macports.build org.macports.destroot org.macports.install :notice:build Please see the log file for port postfix for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/main.log ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: postfix build fails with clang error
I’d open a ticket, since whatever variant causes code to build with -R is at fault. -R means nothing to clang (hence extraneous flags error). On Mar 22, 2014, at 20:07, te...@digital-outpost.com wrote: :info:build clang: error: unknown argument: '-R/opt/local/lib' [-Wunused-command-line-argument-hard-error-in-future] ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: postfix build fails with clang error
Thanks Jeremy. I created a ticket. Same clang error on a core i5 iMac, OS X 10.9.2, Xcode 5.1 No clang error on an iMac core2 duo running 10.8.5 with Xcode 5.0. postfix with variants builds fine. Why? -Terry On 2014-03-22 17:07, te...@digital-outpost.com wrote: I can build postfix by itself but if I add any variants it fails with the error below. I'm trying to build postfix +dovecot_sasl +mysql5 +pcre +tls and all the added variants get built but it fails on postfix. Any help greatly appreciated. Fresh OS X 10.8.5 on MacPro3,1, Quad-Core Intel Xeon, 2.8 GHz, 4GB RAM Error occurred with with Xcode 5.1 so I removed thinking some new clang problem and installed Xcode 4.6.3, but same error. Here's the tail end of /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/main.log ... :info:build cp libmaster.a ../../lib/libmaster.a :info:build /usr/bin/clang -DNO_PCRE -arch x86_64 -DHAS_MYSQL -I/opt/local/include/mysql5/mysql -Wmissing-prototypes -Wformat -Wno-comment -DBIND_8_COMPAT -DNO_NETINFO -DRESOLVE_H_NEEDS_ARPA_NAMESER_COMPAT_H -g -Os -I. -I../../include -DMACOSX -o master master.o master_conf.o master_ent.o master_sig.o master_avail.o master_spawn.o master_service.o master_status.o master_listen.o master_vars.o master_wakeup.o master_watch.o master_flow.o master_monitor.o ../../lib/libglobal.a ../../lib/libutil.a -L/opt/local/lib -R/opt/local/lib -L/opt/local/lib -arch x86_64 -lresolv -L/opt/local/lib/mysql5/mysql -lmysqlclient -lz -lm -lresolv :info:build ranlib ../../lib/libmaster.a :info:build clang: error: unknown argument: '-R/opt/local/lib' [-Wunused-command-line-argument-hard-error-in-future] :info:build clang: note: this will be a hard error (cannot be downgraded to a warning) in the future :info:build make: *** [master] Error 1 :info:build make: *** Waiting for unfinished jobs :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/work/postfix-2.11.0/src/master' :info:build make: *** [update] Error 1 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/work/postfix-2.11.0' :info:build Command failed: cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/work/postfix-2.11.0 /usr/bin/make -j4 -w :info:build Exit code: 2 :error:build org.macports.build for port postfix returned: command execution failed :debug:build Error code: CHILDSTATUS 93866 2 :debug:build Backtrace: command execution failed while executing system -nice 0 $fullcmdstring (eval body line 1) invoked from within eval system $notty $nice \$fullcmdstring invoked from within command_exec build (procedure portbuild::build_main line 8) invoked from within $procedure $targetname :info:build Warning: targets not executed for postfix: org.macports.activate org.macports.build org.macports.destroot org.macports.install :notice:build Please see the log file for port postfix for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_postfix/postfix/main.log ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: postfix build fails with clang error
I suspect this takes us to which version of clang is in use. As the “suggested work around warning flag” suggests: [-Wunused-command-line-argument-hard-error-in-future] Perhaps it was a warning and is now an error (or wasn’t a warning and now is, and warnings are treat as errors). On Mar 22, 2014, at 21:19, te...@digital-outpost.com wrote: Thanks Jeremy. I created a ticket. Same clang error on a core i5 iMac, OS X 10.9.2, Xcode 5.1 No clang error on an iMac core2 duo running 10.8.5 with Xcode 5.0. postfix with variants builds fine. Why? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: postfix build fails with clang error
To close this up, Jeremy was very helpful (on a Saturday afternoon) in determining that an older version of clang/command line tools would successfully build postfix with variants. Contrary to some postings I saw on the interwebs, deleting Xcode.app does not also remove the command line tools. Installing older command line tools from the Apple dev site did the trick. I opened a ticket since someone will want to build postfix with variants using Xcode/clang 5.1. -Terry On Mar 22, 2014, at 5:13 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: I’d open a ticket, since whatever variant causes code to build with -R is at fault. -R means nothing to clang (hence extraneous flags error). On Mar 22, 2014, at 20:07, te...@digital-outpost.com wrote: :info:build clang: error: unknown argument: '-R/opt/local/lib' [-Wunused-command-line-argument-hard-error-in-future] ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
