Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard  wrote:
> 
>> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
>>> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
>>> 
>>> This issue only affects the very small percentage of the MacPorts user 
>>> population (including developers and maintainers) that clones the git 
>>> repository. Most users will use the rsync server, on which we do generate 
>>> portindexes for each macOS version.
>> 
>> Of course, but note how I used the word collective, which was supposed to 
>> include the idea that portindex has to be run each time by every user. :)
>> 
> 
> I would actually believe the number of affected users should be between
> very small and zero.

Pretty much.

In any case, between the capabilities of Git itself and the facilities GitHub 
provides, I do not believe it is possible to do what you suggest.

vq
Sent from my iPhone
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 30, 2016, at 9:54 PM, Clemens Lang  wrote:
> 
> Our Subversion repository has been split into several repositories on
> GitHub.

Please note that Ryan ran the svn2git conversion several times this
weekend, so any clones made previously will have nothing in common with
the final repositories, and a naïve "git pull" will try to produce
a merge commit. This is not desirable.

You should instead press the proverbial reset button. Assuming you made
a straightforward clone and only checked out a local master branch:

$ git fetch
$ git reset --hard origin/master
$ git gc --aggressive

This fetches the new history, forces your local master branch to match
ours, and garbage-collects the old objects.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: command line tools for Xcode 8.1?

[Lawrence Velázquez]

> On Oct 28, 2016, at 3:34 PM, Murray Eisenberg  
> wrote:
> 
> Under OS X 10.11.6, I just updated Xcode to version 8.1 via App Store.
> 
> Release notes for Xcode 8.1 say:
> 
> Known Issues
> • There are no Command Line Tools (OS X 10.11) for Xcode 8.1.
>   Xcode 8.1 contains SDKs that are incompatible with earlier
>   toolchains. Developers who want to make use of the Xcode
>   8 SDKs from the command line must choose the SDK with
>   xcode-select. Developers on OS X El Capitan who have installed
>   versions of the Command Line Tools (OS X 10.11) for Xcode 8.1
>   should install Command Line Tools (OS X 10.11) for Xcode
>   7.3.1. (28234439) 
> 
> How does that affect Macports?

It doesn't. Nothing has changed since 8.0.

https://lists.macosforge.org/pipermail/macports-dev/2016-September/033749.html

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Servers down?

[Lawrence Velázquez]

> On Oct 22, 2016, at 5:11 PM, Fielding, Eric J (329A) 
>  wrote:
> 
> I am guessing that the lack of access to MacPorts yesterday (Friday)
> may have been related to the massive DDoS attack on the Dyn DNS
> servers.

This seems unlikely to me, as our unplanned downtime began (I think) on
Thursday (UTC).

> Because Dyn uses their content delivery network to provide DNS,
> different areas were affected to differing degrees from what I saw
> reported. The regular MacPorts rsync mostly worked for me on Friday
> and still works today. As they say, your mileage may vary.

The downtime affected systems that were still hosted at Mac OS Forge,
including svn.macports.org and trac.macports.org. rsync.macports.org is
now hosted at Friedrich-Alexander-Universität Erlangen-Nürnberg in
Germany and was therefore unaffected.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Moving to GitHub: Status Update, Action Required

[Lawrence Velázquez]

> On Oct 22, 2016, at 9:40 AM, Marko Käning  wrote:
> 
>> On 22 Oct 2016, at 15:34 , Ryan Schmidt  wrote:
>> 
>> as well as the "hub" command line program in the "hub" port.
> 
> Exactly, that’s the one I meant. Perhaps it’s worth mentioning it on the
> wiki page.

I've added several tools to the list since last night. Further
suggestions are welcome.

https://trac.macports.org/wiki/WorkingWithGit#tools

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Moving to GitHub: Status Update, Action Required

[Lawrence Velázquez]

> On Oct 21, 2016, at 10:55 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
>> On Oct 21, 2016, at 9:47 PM, Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>>> On Oct 21, 2016, at 10:20 PM, Craig Treleaven <ctrelea...@macports.org> 
>>> wrote:
>>> 
>>> Also, is the consensus that a graphical user interface over git
>>> more likely to be harmful than helpful?  The Tools section at the
>>> bottom of the page doesn’t give any kind of recommendation.
>> 
>> I don't know that there is any sort of consensus on that. Everyone
>> has their own preferences, and Git is almost absurdly flexible about
>> workflows. I don't think our documentation should recommend any
>> particular tools.
> 
> I think it would be reasonable for us to mention that GitHub Desktop
> is a GUI client that exists and works for basic operations like
> creating or switching between branches and committing changes and has
> a handy diff viewer to see your changes before committing and even
> lets you select which portions of your diff you want to commit. But it
> is of no help with even slightly more advanced git commands.

Sure, we should certainly list more tools; that section is a bit sparse.
I just meant that we shouldn't recommend any one tool over the others
(e.g., "if you like GUI tools, you should use X").

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Servers down?

[Lawrence Velázquez]

> On Oct 21, 2016, at 5:30 PM, Carlo Tambuatco  wrote:
> 
> I can't even get to the migration page on macports.org...

Yes, {svn,trac}.macports.org is still down, and probably others.

vq

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: webkit-gtk2: Will it ever be fixed?

[Lawrence Velázquez]

> On Oct 17, 2016, at 9:07 PM, Bachsau <w...@bachsau.name> wrote:
> 
> Am 18.10.16 um 02:35 schrieb Lawrence Velázquez:
>> You probably want webkit2-gtk.
> 
> Yes, this is what I tried to install and fails, sorry.

Do one of these correspond to the problem you're seeing? If not, please file a 
bug report.

https://trac.macports.org/report/16?PORT=webkit2-gtk

vq

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: webkit-gtk2: Will it ever be fixed?

[Lawrence Velázquez]

> On Oct 17, 2016, at 8:19 PM, Bachsau <w...@bachsau.name> wrote:
> 
> Am 18.10.2016 um 01:19 schrieb Lawrence Velázquez:
>> Are you talking about webkit-gtk-2.0?
> 
> I think so. Whats the alternative?

You probably want webkit2-gtk.

% port echo 'webkit*'
webkit-gtk
webkit-gtk-2.0
webkit-gtk-devel
webkit-gtk3
webkit-gtk3-2.0
webkit-gtk3-devel
webkit-sharp
webkit2-gtk
webkit2-gtk-devel

>> That port is not supported on recent systems, and it errors out with
>> a message saying so.
> 
> No, it fails with "command execution failed"...

That's not really useful, but I assure you that the webkit-gtk-2.0 port
aborts on Sierra with a "not supported" message, and this will not be
"fixed". Perhaps you are not seeing this message because a dependency is
causing the failure.

In any case, try using one of the WebKit2 ports.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: webkit-getk2: Will it ever be fixed?

[Lawrence Velázquez]

> On Oct 17, 2016, at 7:13 PM, Bachsau  wrote:
> 
> Since my upgrade to macOS sierra I tried compiling and installing webkit-gtk2 
> for weeks, again and again. Even though I got a new version every time, it 
> still fails to build.
> 
> Will it ever be fixed? I find it so disturbing that I always come across 
> broken ports. If a build fails, please don't distribute it via port upgrade 
> until fixed. :(

Are you talking about webkit-gtk-2.0? That port is not supported on recent 
systems, and it errors out with a message saying so.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: python, port select and group

[Lawrence Velázquez]

Hello,

> On Oct 13, 2016, at 7:30 AM, Björn Raupach  wrote:
> 
> At first I assumed it sets the default symlink for the command in
> /usr/bin

MacPorts almost never touches /usr.

The "port select" command creates symlinks under $prefix, according to
rules specified by the relevant *_select port. For instance,
python_select (used by "port select --set python") creates these files:

https://trac.macports.org/browser/trunk/dports/sysutils/python_select/files/base

> select —summary
> 
> Name Selected Options
>   ===
> awscli   py34-awscli  py34-awscli none
> mavenmaven3   maven3 none
> mysqlmysql56  mysql56 none
> pip  none none
> python   none python26-apple python27-apple python34 none
> python3  none python34 none
> 
> Why is python in more than one group?

The python, python2, and python3 groups are distinct from one another
and install different symlinks. This is an attempt to adhere to PEP 394
as best we can.

https://trac.macports.org/browser/trunk/dports/sysutils/python2_select/files/base
https://trac.macports.org/browser/trunk/dports/sysutils/python3_select/files/base
https://www.python.org/dev/peps/pep-0394

> If I call python from the command line it launches the python3.4 even
> though port select shows that none is selected.
> 
> port select —set python python34 yields an error: Selection ‘python34’ for 
> ‘python’ failed: symlink: /opt/local/etc/select/python/current -> python34: 
> file already exists.

This problem was brought up previously on this list. You may have
uninstalled python34 at some point while it was selected; the "port
select" code doesn't handle this properly and leaves dangling symlinks.
Can you run this and tell us what it returns? (If you see any messages
about permissions, run it again with "sudo".)

$ find -L /opt/local -type l

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: OpenSSL 1.0.2j won't connect to Google

[Lawrence Velázquez]

> On Oct 4, 2016, at 12:48 AM, S P Arif Sahari Wibowo  
> wrote:
> 
> Macports upgraded my OpenSSL to 1.0.2j and now it cannot connect to Google 
> servers.

Other than updating to the latest releases, we have not made any
significant changes to the openssl port since 1.0.2h.

https://trac.macports.org/changeset?reponame==153177%40trunk%2Fdports%2Fdevel%2Fopenssl=148306%40trunk%2Fdports%2Fdevel%2Fopenssl

You should probably contact upstream.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Please : unsubscribe my account

[Lawrence Velázquez]

> On Oct 3, 2016, at 11:43 AM, Abdulrahman Alshammari  
> wrote:
> 
> Thanks.

You can unsubscribe using the Mailman page linked at the bottom of every 
macports-users email.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Address of nonexistent hosts...?

[Lawrence Velázquez]

> On Sep 29, 2016, at 6:04 PM, Carlo Tambuatco 
> wrote:
> 
> Just installed a port and got this message:
> 
> Warning: Your DNS servers incorrectly claim to know the address of
> nonexistent hosts. This may cause checksum mismatches for some ports.
> See this page for more information:
> 
> 
> So I visited the site but it doesn’t look like any of the cases apply
> to me

Are you sure? What happens if you visit a nonexistent domain in your
browser?

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Sierra transition: qt5-base upgrade failing

[Lawrence Velázquez]

> On Sep 26, 2016, at 12:13 PM, Joseph C Slater, PhD, PE 
>  wrote:
> 
> Many of the packages I use have dependencies on qt5-base, as I've discovered 
> trying to rebuild/upgrade. 
> 
> However, it fails to build, according to the log, reporting:
> :info:configureXcode not set up properly. You may need to confirm the 
> license
> :info:configureagreement by running /usr/bin/xcodebuild without arguments.
> 
> Well, that doesn't work. Of course, the correct command is 
> sudo /usr/bin/xcodebuild -license
> 
> However this doesn't change the error. Is this consistent with others at this 
> time (and awaiting updating)?

https://trac.macports.org/ticket/52200

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

[Lawrence Velázquez]

> On Sep 25, 2016, at 11:24 AM, Ken Cunningham 
>  wrote:
> 
> And although the fortran compiler is written in C and C++ (according
> to the gcc fortran website) it does not in the end actually link it's
> output binaries to libstdc++ (as you've just demonstrated) so there is
> no worry about letting it proceed to completion on a system running
> Macports on 10.11, or any other version, including
> LibCxxOnOlderSystems.

Right. The C compiler is also written in C++.

> Thanks, everyone. I always learn something from these brief
> discussions.

lol, "brief"
:P

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

[Lawrence Velázquez]

> On Sep 25, 2016, at 8:29 AM, Ken Cunningham  
> wrote:
> 
> What is happening exactly on my MacPros running 10.11, I wonder?
> Software installed by macports on 10.11 is using clang++ (mostly) and
> g++ (sometimes).

What MacPorts-provided software is using g++? It should not be doing
that.

> clang++ is linking against libc++, and g++ is presumably linking
> against libstdc++ as that is what it does
> 

> Why exactly is the situation different on a LibCxxOnOlderSystems
> installation?

As Chris said, it's easier to get lucky and avoid conflicts mixing two
libstdc++/libsupc++ than it is mixing libstdc++ and libc++.

There is no fundamental difference, just an increase in visibility.

>> As far as I know, you can use the C or Fortran compilers as much as
>> you'd like. Several ports do this for various reasons. 
> 
> But not easily to link c++ code against libc++.

Right.

>> These dependencies are coming from the +gfortran variants, which
>> instruct the builds to use the Fortran compiler from gcc6. This is
>> fine and expected.
> 
> but won't work on LibCxxOnOlderSystems, if it links the binaries
> against lilbstdc++

Why would the Fortran compiler link its build products against
libstdc++? Are you seeing this behavior?

>> What links against libstdc++, specifically?
> 
> gcc6 itself, at least.

This is not a problem unless GCC provides C++ API.

> It would appear there are a few choices.
> 
> 1. give up and accept it's an either / or situation
> 2. just let it go on, and see how it works with cross linking -- is this
> what 10.11 macports does?

No. No MacPorts-provided software should be compiling with
MacPorts-provided FSF g++. We consider such behavior a bug.

> 3. figure out how to make this work:
> ,
> possibly by wrapping g++ in a shell script that does it for every use.


I don't think it's worth accommodating g++ at all. MacPorts should not
be using it, and anyone who wants to use it for their own projects might
not appreciate us hijacking its default C++ standard library.

Apple handled this in their olde tyme libstdc++ by fixing it to use
libc++abi instead of libsupc++.

> 4. a parallel installation of macports with libstdc++ and gcc, to
> install gimp, octave, qemu, and whatever other similar gcc-requiring
> ports come along.


Please provide evidence that these ports are actually using g++. If they
are, then they should be fixed to not do so. If they are not and are
only using gcc and/or gfortran, then *there is no problem*.

FWIW, I have py35-numpy+gcc6 installed, and none of its object files
link to libstdc++, although many of them do link to MacPorts'
libgcc_s.1.dylib.

% port -q contents py35-numpy | xargs otool -L | fgrep 'libstdc++'
% echo $?
1

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

[Lawrence Velázquez]

> On Sep 25, 2016, at 9:49 AM, Yongwei Wu  wrote:
> 
> I actually do not think this is normally an issue. If the dynamic
> libraries manage the lifetime of their own object, i.e. do not do
> something like creating an object in a library but not providing
> a function to destroy it (so that the application needs to delete it),
> bad things should not occur. At least that is the only case I am aware
> of.

Right, Chris mentioned this earlier. If we were writing a C++
application, it might very well be tractable. The overarching issue
(which applies to many aspects of MacPorts) is that we are managing
*many* applications that *other people* have written, and it is
difficult to police them all.

> (I encountered this kind of problems on Windows, which was even
> worse, as each new release of MSVC brought in a different C/C++
> runtime, which can also be either static or dynamic.)

LOL that sounds terrible. Maybe we should count our blessings.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

[Lawrence Velázquez]

> On Sep 24, 2016, at 10:12 PM, Ken Cunningham
>  wrote:
> 
> I realize I asked this a bit ago about qemu, and received a very
> reasonable big caution regarding any attempt to combine gcc of any
> version on a system set up with LibCxxOnOlderSystems...
> 
> but I just thought I'd mention that a few more fairly common ports
> appear to be failing to install without access to gcc, so this might
> turn out to be a problem.

The problem is not really about libc++; it's about mixing multiple C++
runtimes. The problem also existed pre-libc++ (albeit much more subtly)
because our GCC C++ compilers didn't use the same libstdc++/libsupc++
that Apple's compilers did.

Corollary: This all only concerns the GCC C++ compiler / standard
library / runtime. As far as I know, you can use the C or Fortran
compilers as much as you'd like. Several ports do this for various
reasons. Perhaps they need to compile Fortran code, in which case GCC is
their only option. Or maybe their C code is optimized significantly
better by GCC or requires GCC extensions/libraries. (Example: Until
relatively recently, anything using OpenMP had to be compiled with GCC.)

> in gimp's case, it pulls in py27-numpy that seems to want to pull in
> gcc6 no matter what variants I try.

> octave has what seems to be a hard build dep for gcc6 directly, even
> if I select the +clang37 variant...

These dependencies are coming from the +gfortran variants, which
instruct the builds to use the Fortran compiler from gcc6. This is fine
and expected.

> and letting gcc6 start building, it certainly links against libstdc++
> (in the freshly built libgcc), which will blow everything up.

What links against libstdc++, specifically?

> So this could turn out to be a hard choice for systems set up like
> this, I guess, unless Jeremy has a fancy trick up his sleeve.

Jeremy unfortunately cannot do much of anything about GCC. I believe
Apple employees are not allowed to look at GPL3 code.

> At the moment, it appears you can either get c++11 ports, OR any ports
> which require gcc, but not both. But then I see "-std=gnu++11" in this
> long line, which puzzles me a bit...

I wouldn't be surprised if GCC used C++11 features. It doesn't really
matter because it is self-hosted.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Starting gimp2

[Lawrence Velázquez]

> On Sep 24, 2016, at 4:35 PM, Jeffrey Singleton 
> wrote:
> 
> You run it from command line

You probably need to install "xorg-server" first. This is basically
equivalent to installing XQuartz.

> or you can install the latest from Gimp.org which does not require
> X11 anymore.

This might be what the "gimp-app" port packages.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: macOS Sierra / 10.12 support - where are we?

[Lawrence Velázquez]

> On Sep 21, 2016, at 3:14 PM, Brandon Allbery <allber...@gmail.com> wrote:
> 
>> On Wed, Sep 21, 2016 at 3:09 PM, Lawrence Velázquez <lar...@macports.org> 
>> wrote:
>> 
>> I don't believe anyone has set off a build for the express purpose of 
>> creating Sierra archives, but the Sierra worker is nonetheless quite busy.
> 
> I recall Ryan mentioning that he was doing so.

I think that was just for Python modules.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: macOS Sierra / 10.12 support - where are we?

[Lawrence Velázquez]

> On Sep 21, 2016, at 2:54 PM, Richard L. Hamilton  wrote:
> 
> Are the build-bots building binary packages for Sierra yet

I don't believe anyone has set off a build for the express purpose of creating 
Sierra archives, but the Sierra worker is nonetheless quite busy.

https://build.macports.org/builders/ports-10.12_x86_64-builder
https://build.macports.org/builders/ports-10.12_x86_64-watcher

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 13, 2016, at 3:06 AM, David Epstein  
> wrote:
> 
> One thing that seems to be brought out (by the erroneous answer by “port 
> provides ligpng.la")

It's not erroneous, in the sense that libpng.la really does exist and belong to 
the libpng port. The problem, as Ryan had already noted, is that the mechanism 
for deleting .la files that is in the current base release mistakenly leaves 
symlinks behind.

> is that I made a mistake when updating the OS, to have updated my MacPorts 
> installation, rather than reinstalled. I have been hankering after 
> reinstalling, but Ryan persuaded me not to. This seems to be a new bit of 
> evidence that I ought to reinstall

Reinstalling would not help, as Sinan's reply demonstrated. The libpng build 
would again generate libpng16.la and libpng.la, and base would then delete the 
former but not the latter. And you'd be back where you started.

This won't be fixed for you until the next MacPorts release.

vq
Sent from my iPhone
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 12, 2016, at 7:25 AM, David Epstein  
> wrote:
> 
> When I now run
>> sudo find -L /opt/local -type l -exec port provides {} +
> 
> I get
>> /opt/local/lib/libpng.la is provided by: libpng
>> /opt/local/libexec/qt4/include/QtCLucene is provided by: qt4-mac
>> /opt/local/libexec/qt4/include/QtDesignerComponents is provided by: qt4-mac
>> /opt/local/libexec/qt4/Library/Frameworks/QtCLucene.framework/Headers is 
>> provided by: qt4-mac
> 
> With regard to your remark about libpng, isn’t it the case that the MacPorts 
> guide now indicates that it is not necessary to start from scratch when the 
> OS is upgraded? Anyway, I have not been starting from scratch on MacPorts 
> with recent OS upgrades. So libpng would perhaps have been left over from 
> previous operating systems,. I don’t see why it would have been uninstalled.

I'm not sure where the Guide says that, but it shouldn't. We do still recommend 
reinstalling after major OS upgrades.

https://trac.macports.org/wiki/Migration

> I should read more documentation on “port select”. I think that “man port” 
> does not give an adequate explanation, and I would welcome a pointer to 
> fuller documentation about “port select”.

The new documentation system has a "port-select" manpage, but I'm not sure if 
that has been released.

>>> I agree that some of the select group entry names we've chosen are not 
>>> optimal in the way in which they differ from the name of the port they 
>>> provide. It might be a pain to fix that at this late date.
> 
> Presumably you have hard-wired this connection between a select group entry 
> name and some particular Apple binary. How do I find out which Apple binary?

They're not really hardcoded. It's just that they've been out there for a 
while, and presumably people are using them.

The symlinks to be created are described in a *_select port's "base" file.
https://trac.macports.org/browser/trunk/dports/sysutils/python_select/files/base

The *_select port itself can create select entries corresponding to the 
system-provided installations.
https://trac.macports.org/browser/trunk/dports/sysutils/python_select/Portfile

The paths to the system files are described in separate files.
https://trac.macports.org/browser/trunk/dports/sysutils/python_select/files

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 7:59 PM, David Epstein  
> wrote:
> 
> In view of all my moans and groans, I would like to make it clear that I 
> think MacPorts is great, and it adds greatly to my productivity. I use it all 
> the time, and tend to regard it as “Just there and working perfectly” usually 
> without thinking of the arduous contributions being made behind the scenes. I 
> guess one only becomes aware of this when something isn’t quite right. This 
> is rare with MacPorts, which means that it is even easier to take for granted.

No worries at all. We certainly appreciate hearing about functionality that you 
find confusing or difficult to use; it helps us decide what to work on.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: qemu, and using gcc45+ compilers on systems set up with LibCxxOnOlderSystems and libc++

[Lawrence Velázquez]

> On Sep 11, 2016, at 11:25 PM, Ken Cunningham 
>  wrote:
> 
> I am not totally sure how to use gcc* versions, building cxx code, when my 
> system has been set up for LibCxxOnOlderSystems, and all the installed ports 
> to date link against libc++.
> 
> I _think_ I can just 
> 
> sudo port install gcc49
> 
> for example. This would build gcc49 using clang, and I believe that command 
> would link gcc itself against libc++, which I guess is no big deal and maybe 
> a fine thing.

No, that does not happen. g++ uses its own C++ standard library and runtime.

> Then - assuming that goes OK - when I try to build something with gcc49, 
> according to this page:
> 
> 
> 
> I would do something like this with the flags to keep gcc on trac with libc++.
> 
> 
> g++ -nostdinc++ -I/include/c++/v1 \
>   test.cpp -nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc
> 
> Have to set that collection into the CXX flags and LDFLAGS, I would think.
> 
> Just a bit nervous about blowing things up...
> 
> Any thoughts, comments, or experience much appreciated

Someone else can elaborate if they want, but all I'll say at the moment is that 
we have encountered an obscene amount of trouble involving g++, libstdc++, and 
libc++, and a long time ago we basically decided that g++ was dead to us.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 6:33 PM, Ryan Schmidt  wrote:
> 
>> On Sep 11, 2016, at 5:22 PM, Ryan Schmidt  wrote:
>> 
>>> On Sep 11, 2016, at 4:57 PM, David Epstein  
>>> wrote:
>>> 
>>> I do not understand the issues involved and their ramifications, so I may 
>>> be saying something stupid, but it seems to me, as a naive user, that this 
>>> reveals a rather bad design fault in “port select”. An "available version" 
>>> should either be “none” or the true name of an installed port. I realize 
>>> that resources  to fix things are scarce, but could the ability to choose a 
>>> random name at least be acknowledged as bad practice, and could a ticket be 
>>> provided for work to be done so that this behaviour becomes impossible?
>> 
>> I think we don't consider this to be a design fault, but a feature. In other 
>> words, it was not a mistake that the select group entry can differ from a 
>> port; it was a deliberate decision to allow that. As has been pointed out, 
>> we want to be able to select things that are part of macOS and are not 
>> provided by a port.
>> 
>> I agree that some of the select group entry names we've chosen are not 
>> optimal in the way in which they differ from the name of the port they 
>> provide. It might be a pain to fix that at this late date.
> 
> Maybe we could also display the name of the port, if any, that provides each 
> select group entry.

That's an idea, although then entries like "python27-apple" would appear to 
come from "python_select", which would be a little weird.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 5:57 PM, David Epstein  
> wrote:
> 
> I’m not sure if I am allowed to put my name on some kind of cc list for the 
> ticket, since I’m not intending to work on the problem, but only want to know 
> when it has gone away.

Feel free to Cc yourself on the ticket Mojca linked earlier.

https://trac.macports.org/ticket/47755

> Possibly I misunderstand, but your earlier emails seem to imply that you feel 
> that the only problem with “select” in MacPorts is the creation of symlinks 
> that are not deleted when uninstalling. However, I do not believe this is the 
> whole story. For example, my command
>> port installed ‘*python*3*’
> 
> was answered
>> “None of the specified ports is installed”.
> 
> Nevertheless the directory /opt/local/etc/select/python3 remains on my system 
> as useless clutter and there is no obvious way to delete it except manually, 
> which ought to be a “No-no". This has nothing to do with symlinks.

This is not really an issue, unless you're a neat freak. The same thing happens 
with configuration files that are installed in post-activate phases.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 6:29 PM, Ryan Schmidt  wrote:
> 
>> On Sep 11, 2016, at 5:24 PM, Brandon Allbery wrote:
>>> On Sun, Sep 11, 2016 at 6:22 PM, Ryan Schmidt wrote:
>>> 
>>> On my system I see the contents of that directory are provided by the 
>>> following ports:
>> 
>> I think they're complaining that the directory itself should have been 
>> cleaned up. We don't have the concept of files/directories shared between 
>> ports, so it just doesn't get listed and therefore doesn't get cleaned up.
> 
> MacPorts does delete empty directories whenever a port is deactivated...

But not all the files in the etc/select tree come from ports.

% port provides /opt/local/etc/select/**/current
/opt/local/etc/select/gcc/current is not provided by a MacPorts port.
/opt/local/etc/select/python/current is not provided by a MacPorts port.
/opt/local/etc/select/python2/current is not provided by a MacPorts 
port.
/opt/local/etc/select/python3/current is not provided by a MacPorts 
port.
/opt/local/etc/select/virtualenv/current is not provided by a MacPorts 
port.

This is cut from the same cloth as the symlink issue: The selection mechanism 
is implemented half in base and half in ports, and there's something of an 
impedance mismatch.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 2:41 AM, David Epstein  
> wrote:
> 
> I ran the suggested find command and double checked that all the entries are 
> broken symlinks. Ideally I would like to get rid of all of them, but safely. 
> From my point of view, the danger is that these filenames occur in some 
> different list in /opt/local, unknown to me, and that this list would be 
> corrupted if I simply delete the broken symlinks using /bin/rm .

I don't think "port select" registers its links anywhere.

These files are created by the python select group. You ought to be able to 
delete them.

> /opt/local/bin/2to3
> /opt/local/bin/idle
> /opt/local/bin/pydoc
> /opt/local/bin/python
> /opt/local/bin/python-config
> /opt/local/bin/pythonw
> /opt/local/bin/smtpd.py
> /opt/local/etc/select/python/current
> /opt/local/man/man1/python.1
> /opt/local/share/man/man1/python.1
> /opt/local/Library/Frameworks/Python.framework/Headers
> /opt/local/Library/Frameworks/Python.framework/Python
> /opt/local/Library/Frameworks/Python.framework/Resources
> /opt/local/Library/Frameworks/Python.framework/Versions/Current

python3:

> /opt/local/bin/2to3-3
> /opt/local/bin/idle3
> /opt/local/bin/pydoc3
> /opt/local/bin/python3
> /opt/local/bin/python3-config
> /opt/local/bin/python3m
> /opt/local/bin/python3m-config
> /opt/local/bin/pyvenv
> /opt/local/etc/select/python3/current
> /opt/local/man/man1/python3.1
> /opt/local/share/man/man1/python3.1

ipython:

> /opt/local/bin/iptest
> /opt/local/bin/ipython
> /opt/local/etc/select/ipython/current
> /opt/local/share/man/man1/ipython.1

ipython2:

> /opt/local/bin/iptest2
> /opt/local/bin/ipython2
> /opt/local/etc/select/ipython2/current
> /opt/local/share/man/man1/ipython2.1

pip:

> /opt/local/bin/pip
> /opt/local/etc/select/pip/current

I initially thought that these were created by ipython and ipython2, but their 
base files seem to disagree, so I don't know where these are from.

> /opt/local/man/man1/ipython.1
> /opt/local/man/man1/ipython2.1


I assume these are parts of "libpng" and "qt4-mac" or "qt4-x11". See what this 
tells you:

find -L /opt/local -type l -exec port provides {} +

> /opt/local/lib/libpng.la
> /opt/local/libexec/qt4/include/QtCLucene
> /opt/local/libexec/qt4/include/QtDesignerComponents
> /opt/local/libexec/qt4/Library/Frameworks/QtCLucene.framework/Headers

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 6:24 AM, David Epstein  
> wrote:
> 
> I hope that I’m believed when I say that I’m extremely careful never to 
> operate on /opt/local except via port. I do use programs like unix find and 
> unix ls that are not supposed to change anything.

No, it's very clear that you haven't been mucking around inside your MacPorts 
prefix. The issue is that select symlinks are not updated when the selected 
port is deactivated. That is not great behavior.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 4:13 AM, David Epstein  
> wrote:
> 
> For those few interested in this thread, and who have not followed so far, 
> the relevant line of output from
> “port select —summary” was
>> llvm   none  mp-llvm-3.5 none
> 
> I think that this is a either a bug in “port select —summary” or a 
> misinterpretation of the output from
> “port select —summary”.
> 
> In contrast, here is what “port installed” thinks:
>> port installed mp-livm-3.5
> gives
>> None of the specified ports are installed.

Port names and select entries need not match. The "mp-llvm-3.5" select entry 
corresponds to the "llvm-3.5" port.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 11, 2016, at 3:40 AM, David Epstein <david.epst...@warwick.ac.uk> 
> wrote:
> 
>> On 10 Sep 2016, at 23:10, Lawrence Velázquez <lar...@macports.org> wrote:
> 
> … snip …
> 
>>>> Did you uninstall python27?
>>> 
>>> I think so. The ls -l command above does not find /opt/local/bin/python*, 
>>> except for symbolic links.
>>> What port command could I give to make sure?
>> 
>> "port installed python27 and active”
> 
> Confusingly this gets an answer that is readily misinterpreted, namely
>> None of the specified ports are installed.
> 
> In contrast
>> port installed python27
> 
> does not (inadvertently) deceive: it gives
>> The following ports are currently installed:
>>  python27 @2.7.11_2

Yes, that's right. That port *is not active*, so it was not displayed by the 
first command.

>> What you could try is  explicitly setting and then unsetting:
>> 
>>  sudo port select --set python python27-apple
> 
> I tried this and got:
>> Selecting 'python27-apple' for 'python' failed: symlink: 
>> /opt/local/etc/select/python/current -> python27-apple: file already exists
> So then I did
>> ls -l /opt/local/etc/select/python/current
> and got
>> lrwxr-xr-x  1 root  admin  8  9 Jun 19:13 
>> /opt/local/etc/select/python/current@ -> python27
> This seems to me to indicate a bug in “port select —summary”.

No, the bug is in the way base doesn't clean up select links when the selected 
port is deactivated.

> Firstly, it seems to answer incorrectly for inactive ports, like python27 in 
> my case. I would have expected “port select —summary” to give python27 as an 
> option.

Why? You can't select an inactive port.

> Secondly, it seems to incorrectly and indirectly imply that python26-apple 
> and python27-apple are installed, which I think was your interpretation, but 
> they aren’t installed, as I have checked with the “port installed” command.

The "python*-apple" entries denote the system Python installations. There are 
no ports with those names.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 10, 2016, at 5:51 PM, David Epstein  
> wrote:
> 
> I do not want to rely on my memory of which of these I have uninstalled. I 
> need to be told by a reliable program.

Run this:

find -L /opt/local -type l

This will print any broken symlinks in your MacPorts prefix. Email the output 
to this list, and we can tell you what you can safely delete.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 10, 2016, at 5:51 PM, David Epstein <david.epst...@warwick.ac.uk> 
> wrote:
> 
>> On 10 Sep 2016, at 19:38, Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>> Did you uninstall python27?
> 
> I think so. The ls -l command above does not find /opt/local/bin/python*, 
> except for symbolic links.
> What port command could I give to make sure?

"port installed python27 and active"

> What port command can I give to extirpate remnants of an uninstalled port, if 
> there are any remnants?

There isn't one, to my knowledge. By definition, uninstalling a port removes 
its archive, which is how we could tell what files it installed.

IIRC the only "remnants" might be files created by a post-activate phase, which 
MacPorts does not track. Deactivation should remove everything else.

Your issue is not related to any of this, though.

> I ran “port select —summary” as you suggested and got the response
> 
> Name   Selected  Options
>      ===
> cython none  none
> gccnone  none
> ipythonnone  none
> ipython2   none  none
> ipython3   none  none
> llvm   none  mp-llvm-3.5 none
> nosetests  none  none
> pipnone  none
> python none  python26-apple python27-apple none
> python2none  python26-apple python27-apple none
> python3none  none

Okay, I was thinking that the groups would still have the stale setting, but 
they don't, so this won't help.

> I do not want to rely on my memory of which of these I have uninstalled. I 
> need to be told by a reliable program. What would happen if I gave one of 
> your commands below, with argument a port that was still installed?

Nothing will happen, I think, because the groups are already set to "none". 
What you could try is  explicitly setting and then unsetting:

sudo port select --set python python27-apple
sudo port select --set python none

And likewise for "python2". Unfortunately you don't have any Python 3 ports 
installed.

> My guess is that only the symbolic link would be removed, leaving the true 
> file in place, but I would like to be sure before I take any action.

Correct; "port select" does not affect the contents of any ports.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts missing links

[Lawrence Velázquez]

> On Sep 10, 2016, at 1:42 PM, David Epstein  
> wrote:
> 
> I gave the command:
> 
> ls -l /opt/local/bin/py*
> and the system replied:
> 
>> lrwxr-xr-x  1 root  wheel  23  9 Jun 19:13 /opt/local/bin/pydoc@ -> 
>> /opt/local/bin/pydoc2.7
>> lrwxr-xr-x  1 root  wheel  23  9 Jun 17:19 /opt/local/bin/pydoc3@ -> 
>> /opt/local/bin/pydoc3.5
>> lrwxr-xr-x  1 root  wheel  24  9 Jun 19:13 /opt/local/bin/python@ -> 
>> /opt/local/bin/python2.7
>> lrwxr-xr-x  1 root  wheel  31  9 Jun 19:13 /opt/local/bin/python-config@ -> 
>> /opt/local/bin/python2.7-config
>> lrwxr-xr-x  1 root  wheel  24  9 Jun 17:19 /opt/local/bin/python3@ -> 
>> /opt/local/bin/python3.5
>> lrwxr-xr-x  1 root  wheel  31  9 Jun 17:19 /opt/local/bin/python3-config@ -> 
>> /opt/local/bin/python3.5-config
>> lrwxr-xr-x  1 root  wheel  25  9 Jun 17:19 /opt/local/bin/python3m@ -> 
>> /opt/local/bin/python3.5m
>> lrwxr-xr-x  1 root  wheel  32  9 Jun 17:19 /opt/local/bin/python3m-config@ 
>> -> /opt/local/bin/python3.5m-config
>> lrwxr-xr-x  1 root  wheel  25  9 Jun 19:13 /opt/local/bin/pythonw@ -> 
>> /opt/local/bin/pythonw2.7
>> lrwxr-xr-x  1 root  wheel  25  9 Jun 17:19 /opt/local/bin/pyvenv@ -> 
>> /opt/local/bin/pyvenv-3.5

Those are symlinks created by "port select". Presumably you set up the python, 
python2, and python3 select groups at some point.

> You will see that none of the files on the righthand side of the arrow -> 
> appears on any lefthand side. I tried “port provides” on both lefthand and 
> righthand sides and received error messages from port such as
>> /opt/local/bin/pydoc2.7 does not exist.

Did you uninstall python27?

> and
>> /opt/local/bin/pydoc is not provided by a MacPorts port.

Right, because that file was created by "port select" and not a port.

> How do I get rid of the symbolic links, other than using /bin/rm, something I 
> have been told never to do?
> 
> How can I find all hanging links like this in /opt? Presumably there is a 
> clever formula using unix find.

Try running "port select --summary" (although I'm not sure whether this feature 
has been released). It will list the select groups on your system and their 
current settings. If any of those settings corresponds to a port you have 
uninstalled, you should be able to remove the symlinks with

sudo port select --set python none
sudo port select --set python2 none
sudo port select --set python3 none
etc etc etc

> I wonder what causes this kind of problem? I cannot remember any of my port 
> processes terminating incorrectly. I have lately been uninstalling 
> python-related ports, because I had too many different versions of python on 
> my machine, and I was getting confused.

The symlinks created by "port select" are not modified if the selected port is 
subsequently deactivated or uninstalled. I think there is an open ticket about 
this, but I can't find it at the moment.

vq
___
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?

[Lawrence Velázquez]

> On Aug 26, 2016, at 12:01 PM, [ftp83plus]  wrote:
> 
> This log is truncated because Pastebin doesn't accept its large size for free 
> users. How would I post that?

https://trac.macports.org/newticket

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: sea.us.rsync.macports.org mirror

[Lawrence Velázquez]

> On Aug 22, 2016, at 3:41 PM, Jonathan Stickel  wrote:
> 
> OK, thanks. Maybe put a note on the wiki until resolved?

Done: https://trac.macports.org/wiki/Mirrors?action=diff=85

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: sea.us.rsync.macports.org mirror

[Lawrence Velázquez]

> On Aug 22, 2016, at 3:22 PM, Jonathan Stickel  wrote:
> 
> I recently started using the sources mirror at sea.us.rsync.macports.org. I 
> noticed today that it looks stuck, with nothing changed since 8/5/16. I sent 
> an email to mir...@pnnl.gov (as suggested by the message during syncing), I 
> but wanted to report it here also.

https://trac.macports.org/ticket/52055

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Fail to execute a custom local portfile

[Lawrence Velázquez]

> On Aug 21, 2016, at 10:14 AM, Rainer Müller  wrote:
> 
>> On 2016-08-21 15:37, Giovanni Grieco wrote:
>> 
>> But I can’t install my package via ‘port install’ because MacPorts
>> throws me the following error:
>> 
>> “Unable to execute port: Could not open file:
>> /Users/…/Documents/macports/… /Portfile”
>> 
>> 
>> 
>> I have the file in that directory, I can open and write it. So I don’t
>> know what the problem is.
>> 
>> Permissions are all set to macports:macports 755, both directories and
>> files; port lint doesn’t find any error  related to Portfile; I have
>> sources.conf with my local repository.
> 
> The port command drops privileges to the macports user, which therefore
> needs access to the Portfile.
> 
> You need to check the permissions on all components of the path leading
> up to the Portfile, not just the Portfile itself. In this case, the
> ~/Documents directory would be 0700 by default, if I remember correctly.
> 
> To manually test the access, you can use sudo to switch to this user:
> 
> $ sudo -u macports cat $(port file kwm)
> 
> You can then check all directory permissions with bash like this:
> 
> $ bash -c 'IFS=/; for p in $(port file kwm); do path="${path%/}/$p";
> paths+=("$path"); done; ls -lad "${paths[@]}"'
> 
> Make sure all directories have at least the +x bit set for everyone,
> that allows the macports user to reach through.

If you're not comfortable setting o+x all the way down, you can use ACLs to 
give search access to just the "macports" user.

chmod +a 'macports allow search' ~ ~/Documents
chmod -R o+x ~/Documents/macports

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Idea: Port Checks for Disk Space Before Compiling?

[Lawrence Velázquez]

> On Aug 11, 2016, at 12:14 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> On Aug 11, 2016, at 11:08, Jean-François Caron <jfca...@phas.ubc.ca> wrote:
>> 
>> On Aug 11, 2016, at 09:55 , Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>>> The +analyzer variant is already enabled by default. Which clang port are 
>>> you building, and on what OS?
>> 
>> This was for a regular “port upgrade outdated” of clang-3.6 
>> @3.6.2_3+analyzer to clang-3.6 @3.6.2_4+analyzer.
>> 
>> I am on OSX 10.9.5.  Maybe it’s too old.
> 
> We build packages for 10.6 and later. But they take time to compile and 
> upload. You may have been upgrading between the time that the update was 
> committed and the time that the build completed. 

Hm, it looks like we are missing the clang-3.6 archive for 10.9 and *only* 10.9.

http://packages.macports.org/clang-3.6

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Idea: Port Checks for Disk Space Before Compiling?

[Lawrence Velázquez]

> On Aug 11, 2016, at 9:05 AM, Jean-François Caron  wrote:
> 
> I’m glad my idea wasn’t as silly as I had thought.  Maybe this will go 
> somewhere.  
> 
> I needed to build clang locally because I use the +analyzer variant.  Maybe 
> this variant could be made default, since it has no performance impacts and 
> shouldn’t cause any problems for users who ignore the analyzer.  There are 
> probably more people who currently do +analyzer than people who would insist 
> on -analyzer if it were default.

The +analyzer variant is already enabled by default. Which clang port are you 
building, and on what OS?

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Idea: Port Checks for Disk Space Before Compiling?

[Lawrence Velázquez]

> On Aug 10, 2016, at 9:04 PM, Ryan Schmidt  wrote:
> 
>> On Aug 10, 2016, at 5:15 PM, Mojca Miklavec  wrote:
>> 
>> The major problem is that there is basically no way to predict how
>> much space an installation of a port from source might need (one might
>> be able to do some heuristics based on old build logs from the
>> buildbot or so, but that might be quite some work for very little gain
>> and it won't work well for non-default variants etc).
> 
> It would be easy for the buildbot to record the size of the installed 
> package, even if the package isn't distributable, and could submit that 
> information to our hypothetical new web site, from which MacPorts could query 
> it.

This could be helpful, but it wouldn't provide information about the *maximum* 
disk space required by a build, which could easily surpass the size of the 
final build products.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: how to install an earlier version?

[Lawrence Velázquez]

On Aug 10, 2016, at 8:30 PM, Jim DeLaHunt  wrote:

> I have the current version of a port installed. I have never had an
> earlier version installed. But I would like to install an earlier
> version now.  How can I do this?

https://trac.macports.org/wiki/howto/InstallingOlderPort

vq
___
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)

[Lawrence Velázquez]

> On Jul 30, 2016, at 7:24 PM, [ftp83plus]  wrote:
> 
> Should I simply let step 2 as it was, not 
> sudo port -v install libcxx +universal
> 
> but
> 
> sudo port -v install libcxx
> 
> like I did when it failed the first time?

I doubt that has anything to do with the Python crash.

vq
___
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)

[Lawrence Velázquez]

On Jul 30, 2016, at 1:57 PM, [ftp83plus]  wrote:

> Python 27 fails to build: http://pastebin.com/zJZM4vM8 and log: 
> http://pastebin.com/0L1rTQZP
> 
> What is the issue this time?

https://trac.macports.org/ticket/51891

vq
___
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)

[Lawrence Velázquez]

On Jul 30, 2016, at 8:58 AM, [ftp83plus]  wrote:

> So should I rebuild libcxx +universal variant first before performing
> Step 4 of the LibcxxOnOlderSystems?

Yes, unless you can figure out why libomp is being installed +universal
and prevent that.

vq
___
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)

[Lawrence Velázquez]

> On Jul 29, 2016, at 1:35 AM, Ken Cunningham
>  wrote:
> 
> Hi,
> 
> There are many here smarter than me, but it would see your error is
> here:
> 
>> /opt/local/bin/clang++-mp-3.3   -pipe -Os -stdlib=libc++   -arch i386 
>> -mmacosx-version-min=10.6 -Wl,-search_paths_first 
>> -Wl,-headerpad_max_install_names  -L/opt/local/lib 
>> -Wl,-headerpad_max_install_names  
>> CMakeFiles/cmTC_70577.dir/testCXXCompiler.cxx.o  -o cmTC_70577  
>> ld: warning: ignoring file /usr/lib/libc++.dylib, file was built for 
>> unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 
>> 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked 
>> (i386): /usr/lib/libc++.dylib
> 
> You're building for -arch i386, but your libc++.dylib does not have
> that architecture (it's likely going to be x64_86) -- So somewhere
> ( probably in your macports.conf file, I would think) your
> architecture is not set correctly.

The libomp port is being installed +universal. Since it uses the muniversal-1.0 
portgroup, MacPorts builds it for each architecture separately, then lipo(1)s 
everything together at the end.

The problem is that the i386 build is trying to link to libc++, which in your 
case appears to be provided by libcxx. But libomp does not declare a dependency 
on libcxx, so MacPorts did not attempt to rebuild libcxx +universal. You may 
have to do this yourself.

vq___
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)

[Lawrence Velázquez]

> On Jul 29, 2016, at 4:05 PM, Ken Cunningham
>  wrote:
> 
> I believe macports automatically sets build_arch to the proper value
> depending on your hardware .
> 
> 
> 
> Don't forget, in macports.conf, the commented out values are actually
> the default values being used, they are not really ignored.

This is true in general, but for build_arch the commented-out "i386" is
a placeholder. The method used to dynamically choose its default is
explained in the preceding comment.

vq
___
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)

[Lawrence Velázquez]

> On Jul 29, 2016, at 10:57 AM, [ftp83plus]  wrote:
> 
> And why would it use clang-3.3 when it's explicitly told to use clang 3.4?

The build failure is in libomp, which has the following compiler whitelist:

# According to documentation builds with clang >= 3.3
compiler.whitelist  clang \
macports-clang-3.3 \
macports-clang-3.4 \
macports-clang-3.5 \
macports-clang-3.6 \
macports-clang-3.7 \
macports-clang-3.8 \
macports-clang-3.9

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: New Mac OS Forge administrator

[Lawrence Velázquez]

On Nov 19, 2015, at 9:49 PM, Ryan Schmidt  wrote:

> I'm pleased finally to be able to tell you that I have been hired to be your 
> new Mac OS Forge administrator.

wait what

WHAT

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Fwd: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Lawrence Velázquez]

Forwarding message that didn't make it to the list.

vq

 Begin forwarded message:
 
 From: Eric A. Borisch ebori...@gmail.com
 Subject: Re: [MacPorts] #47755: Broken symlink left by select code when 
 selected port is deactivated causes poppler and other ports using aclocal to 
 fail during configuration.
 Date: June 25, 2015 at 12:40:12 AM EDT
 To: Lawrence Velázquez lar...@macports.org
 Cc: Ryan Schmidt ryandes...@macports.org, 
 macports-users@lists.macosforge.org macports-users@lists.macosforge.org
 
 
 
 On Wednesday, June 24, 2015, Lawrence Velázquez lar...@macports.org 
 mailto:lar...@macports.org wrote:
 On Jun 24, 2015, at 8:02 PM, Ryan Schmidt ryandes...@macports.org  wrote:
 
  On Jun 24, 2015, at 5:10 PM, Christopher Ramos wrote:
 
  Perhaps it would be feasible to employ an agent or daemon that logs
  all changes to a user's installation. That way, if it's ever bungled
  by an outside force, the user could do something like sudo port
  revert snapshot-06222015. This would remove any files not
  registered by the daemon to have been present at the time of the
  requested snapshot; if need be, previously installed or files (or
  files that were in a different state) would retrieved from the
  Internet.
 
  A daemon to detect such actions is an interesting suggestion. This
  could adversely affect performance. I'm also not sure how we would
  instruct the daemon what changes are ok and what changes aren't. For
  example, installing /opt/local/lib/libsomething.dylib without using
  MacPorts would not be ok, but creating /opt/local/etc/something.conf
  would probably be fine. Installing /opt/local/bin/something would be
  bad, but a database server installed with MacPorts that modifies the
  contents of /opt/local/var/db/something/ while it runs would be ok.
 
 What functionality would this enable? We don't maintain a permanent
 local history of archives or the registry. We don't maintain old
 versions of the ports tarballs. We keep old binary archives on
 packages.macports.org http://packages.macports.org/, but that wouldn't help 
 users who don't install
 from binaries. I don't think we can implement snapshot functionality
 without abusing the word snapshot. Frankly, anyone who wants the
 ability to roll their installation back to a previous state should start
 making incremental backups.
 
 snark If only on OS vendor would make an easy automated backup solution. 
 /snark
 
 I can see the utility a port verify active or something similar that would 
 check installed files against what's in the archives, but beyond that, this 
 is out of scope, IMHO. A tar --compare, perhaps? This would be slow, but 
 minimal to implement. I can't recall if checksums are kept in the archives 
 off the top of my head, but that could be another route.
 
   - Eric

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Lawrence Velázquez]

On Jun 24, 2015, at 2:31 PM, Christopher Ramos chrisdavidra...@gmail.com 
wrote:

 You can systematically avoid it by letting the operating system's
 security do its thing: Don't use superuser privileges to build
 software, and don't use them to install unless you know what it's
 going to do.
 
 Wow, you know, wow. Now you have me wondering if I've gotten too
 comfortable using sudo.

As a rule, you should not use sudo unless you're pretty sure that you
know why you need it. The operating system already has a solution for
keeping one user's processes from scribbling over files owned by another
user. Try to take advantage of it.

(Admittedly, accidents do happen. Ryan just brought up a not-uncommon
circumstance: Sometimes third-party developers use MacPorts to create
installers for distribution, but they don't use a custom prefix, so the
installers scribble into /opt/local — usually after asking you for admin
authentication.)

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Lawrence Velázquez]

On Jun 24, 2015, at 8:02 PM, Ryan Schmidt ryandes...@macports.org wrote:

 On Jun 24, 2015, at 5:10 PM, Christopher Ramos wrote:
 
 Perhaps it would be feasible to employ an agent or daemon that logs
 all changes to a user's installation. That way, if it's ever bungled
 by an outside force, the user could do something like sudo port
 revert snapshot-06222015. This would remove any files not
 registered by the daemon to have been present at the time of the
 requested snapshot; if need be, previously installed or files (or
 files that were in a different state) would retrieved from the
 Internet.
 
 A daemon to detect such actions is an interesting suggestion. This
 could adversely affect performance. I'm also not sure how we would
 instruct the daemon what changes are ok and what changes aren't. For
 example, installing /opt/local/lib/libsomething.dylib without using
 MacPorts would not be ok, but creating /opt/local/etc/something.conf
 would probably be fine. Installing /opt/local/bin/something would be
 bad, but a database server installed with MacPorts that modifies the
 contents of /opt/local/var/db/something/ while it runs would be ok.

What functionality would this enable? We don't maintain a permanent
local history of archives or the registry. We don't maintain old
versions of the ports tarballs. We keep old binary archives on
packages.macports.org, but that wouldn't help users who don't install
from binaries. I don't think we can implement snapshot functionality
without abusing the word snapshot. Frankly, anyone who wants the
ability to roll their installation back to a previous state should start
making incremental backups.

I suppose we could merely maintain a log of changes, which might be
helpful when a user suspects their installation has been tampered with.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Lawrence Velázquez]

On Jun 23, 2015, at 5:20 PM, Christopher David Ramos m74z00...@gmail.com 
wrote:

 Please forgive me if what I'm suggesting is not feasible. That said, it was 
 my understanding that makefiles include instructions on what and where 
 libraries should be built.

More or less.

 If there were a special Macports version of git that included a daemon, could 
 it not be used to overrule the default install directories for any libraries 
 a git project's makefile may call for?

It could not. Git has nothing to do with Make or makefiles.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Lawrence Velázquez]

On Jun 23, 2015, at 11:03 PM, Christopher D. Ramos
chrisdavidra...@gmail.com wrote:

 That said, I don't think it's merely incidental.

I assure you that it is.

 After all, git is, in a sense, part of the Macports ecosystem by
 virtue of a version of it being hosted by Macports. Is there not
 a policy about hosting ports -- whether version control or other types
 of software distribution mechanisms -- that may distribute projects
 that ultimately harm a Macports installation?

It would be one thing if Git were more akin to dpkg/apt or rpm/yum,
which are proper systems for distributing software. Git is closer to
rsync in this regard — basically a fancy downloader. It does far less
than you seem to think it does. The important code here is the build
system (the input to Autotools, Make, CMake, Ninja, SCons, whatever).

 My reason for bringing up /opt/local was because I was wondering if
 there was a chance that the makefile of some git project (or any other
 project management system!) might instruct it (implicitly or
 explicitly) to install under /opt/local.

There is a chance, yes. A makefile author can write anything, and a Make
process can do anything that the invoking user can do. You can try
searching for /opt/local in the relevant configure script or makefile
if you're curious.

 And if so, how could this be systematically avoided.

You can systematically avoid it by letting the operating system's
security do its thing: Don't use superuser privileges to build software,
and don't use them to install unless you know what it's going to do.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: How to fix faulty symlink in XCode 3.2.6, issue 14018?

[Lawrence Velázquez]

On Jun 20, 2015, at 8:49 PM, semaphor...@yahoo.com wrote:

 I get the same error in the main.log from the gnuradio port:
 :info:configure CMake Warning at 
 /opt/local/share/cmake-3.2/Modules/Platform/Darwin.cmake:182 (message):
 :info:configure   The SDK Library/Frameworks path
 :info:configure 
 :info:configure//Library/Frameworks
 :info:configure 
 :info:configure   is not set up correctly on this system.  This is known to 
 occur when
 :info:configure   installing Xcode 3.2.6:
 :info:configure 
 :info:configurehttp://bugs.python.org/issue14018
 :info:configure 
 :info:configure   The problem may cause build errors that report missing 
 system frameworks.

That's not an error. It's a warning.

 Then
 :info:configure CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
 :info:configure   user force-enabled gnuradio-companion but configuration 
 checked failed
 :info:configure Call Stack (most recent call first):
 :info:configure   grc/CMakeLists.txt:45 (GR_REGISTER_COMPONENT)
 :info:configure 
 :info:configure 
 :info:configure -- Configuring incomplete, errors occurred!
 
 MacPorts still can't build dependencies for gqrx.

Your log snippets are not providing a complete picture of what's going on. I 
strongly suspect that your assumptions are incorrect, and that the error you're 
seeing has nothing to do with the Xcode symlinks. But we can't know from this 
limited information.

Please open a Trac ticket and attach a clean, complete log.

https://guide.macports.org/chunked/project.html#project.tickets

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

[Lawrence Velázquez]

Moving this to macports-users, as it's quite off-topic for the ticket.
You may have to subscribe to the list to respond.

https://trac.macports.org/wiki/MailingLists


On Jun 19, 2015, at 3:59 PM, MacPorts nore...@macports.org wrote:

 #47755: Broken symlink left by select code when selected port is
 deactivated causes poppler and other ports using aclocal to fail during
 configuration.
 ---+
  Reporter:  lukasz@…  |  Owner:  macports-tickets@…
  Type:  defect| Status:  new
  Priority:  Normal|  Milestone:
 Component:  base  |Version:  2.3.3
 Resolution:|   Keywords:
  Port:|
 ---+
 
 Comment (by m74z00219@…):
 
 Replying to [comment:19 ryandesign@…]:
 
 Replying to [comment:18 m74z00219@…]:
 
 
 I tried removing the symlink to wxwin.m4, but install still fails.
 I think my problem extends to the fact that I've been fooling around
 with git (from macports). The log refers to a list of items that were
 not installed by Macports...or at least not registered to have been
 installed by Macports.
 
 Actually, after uninstalling some git repo related stuff (sudo make
 uninstall), I was successfully able to install encfs -- thanks!
 
 Is this typical of git repo project installations to interfere with
 Macports?
 
 The method of software distribution (i.e. from a git or hg or svn or
 cvs or bzr repository, or from a tarball download) should have no
 bearing on whether a project interferes in some way with MacPorts.
 You'll have to be more specific about the problem you're experiencing,
 if you still need help with it, but it sounds like it's not related to
 this ticket, and if it's something you're doing outside of MacPorts
 (using `make` for example) then it sounds like it's not related to
 MacPorts.
 
 While my original ticket (#48052) was rightly marked duplicate, it
 turned out that my inability to install encfs was two-fold -- the
 broken / unregistered symlink from wxWidgets and Git project
 compilations.
 
 You're right on that it was the making that caused the issue, so in
 certain respects the conflicting software was my fault.

It's still not at all clear what you did. Did you make install
something to the MacPorts directory tree? Did you tell the build where
to install its files, or did it do so of its own volition?

 That said, Macports does host a Git port, which is a software
 distribution platform. There is no indication / warning that Git
 projects involving compilation may install libraries that might
 interfere with Macports.

I don't think you understand what Git is.

Git is not a platform by any reasonable definition of the word. It's
a version control system: a tool that allows content creators (usually
software developers) to organize and distribute their work (usually
source code). Git has nothing to do with compiling or installing; as
Ryan already said, a project's choice of version control does not affect
how it builds and works (Git submodules and such notwithstanding).
A project that interferes with MacPorts will do so whether you retrieve
it with Git or Mercurial or Subversion or curl or wget or Safari or lynx
or floppy disk.

 Maybe it is warranted that Macports add a disclaimer to the Git port?

This would not be warranted. We might as well add such warnings to any
port that allows you to download a file or compile a binary.

 Or, perhaps a guide to preventing conflicts with Macports when
 building Git projects?

I don't know how we could do this in a meaningful way. It would be like
writing a guide to preventing a word processor from overwriting files in
your home directory. Either (a) you're telling the program to overwrite
those files yourself, in which case you just have to stop, or (b) the
program is doing so on its own, in which case you can't do much, other
than file a bug report and stop using the program.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython notebook problem

[Lawrence Velázquez]

On Jun 19, 2015, at 1:39 PM, Sean Farley s...@macports.org wrote:

 Peter Danecek peter.dane...@ingv.it writes:
 
 Any news on this?
 Or should I have a look at it?
 
 Ack, I completely forgot about this. If you can do it, that'd be great.

I've created a port for functools32.

https://trac.macports.org/browser/trunk/dports/python/py-functools32/Portfile?rev=137789

Someone who actually uses py27-ipython should fix that; a new dependency should 
suffice.

vq

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Error installing py-virtualenvwrapper

[Lawrence Velázquez]

On Jun 16, 2015, at 11:53 PM, Brandon Allbery allber...@gmail.com wrote:

 On Tue, Jun 16, 2015 at 11:47 PM, Yang Zhang yanghates...@gmail.com wrote:
 :info:build Download error on https://pypi.python.org/simple/pbr/ : [SSL: 
 CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) -- Some 
 packages may not be found!
 
 Sounds like you might have an evil (MITM) https proxy in the way? Or you need 
 to use a proxy in the first place, and without it the request is being 
 blocked/intercepted by a captive portal and it's being served a self-signed 
 error page.
 
 (Unless someone messed up the certs on pypi.python.org, which seems unlikely. 
 10.10 should have appropriate certificates already.)

Blegh, the build shouldn't be downloading anything anyway. Looks like a missing 
dependency.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Error installing py-virtualenvwrapper

[Lawrence Velázquez]

On Jun 16, 2015, at 11:47 PM, Yang Zhang yanghates...@gmail.com wrote:

 Ran into the below error—not sure what the next steps are as this
 doesn't necessarily seem like an issue with MacPorts itself, but I'm
 not sure.  Below is the log
 /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-virtualenvwrapper/py27-virtualenvwrapper/main.log
 from running sudo port clean py27-virtualenvwrapper; sudo port install
 py27-virtualenvwrapper.  Any ideas?

I have created a port for the pbr library (which your build was trying
to download from PyPI) and updated py-virtualenvwrapper to 4.6.0.

https://trac.macports.org/log?revs=137665-137670

Please clean, update, and try installing again:

% sudo port clean py27-virtualenvwrapper
% sudo port selfupdate
% sudo port install py27-virtualenvwrapper

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython notebook problem

[Lawrence Velázquez]

On Jun 15, 2015, at 3:07 PM, Brandon Allbery allber...@gmail.com wrote:

 On Mon, Jun 15, 2015 at 3:01 PM, Gideon Simpson gideon.simp...@gmail.com 
 wrote:
 
 ImportError: No module named functools32
 
 IPython notebook format depends on the jsonschema package:
 
 I think the bottom part is boilerplate; functools32 is not part of jsonschema 
 (and I don't see it in MacPorts offhand).

Maybe we should add it?

https://pypi.python.org/pypi/functools32

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ipython notebook problem

[Lawrence Velázquez]

On Jun 15, 2015, at 3:01 PM, Gideon Simpson gideon.simp...@gmail.com wrote:

 When I try launching ipython notebook, I get the error:
 
 
 ImportError: No module named functools32
 
 IPython notebook format depends on the jsonschema package:
 
 https://pypi.python.org/pypi/jsonschema
 
 Please install it first.
 
 But
 port installed py-jsonschema
 The following ports are currently installed:
   py-jsonschema @2.5.1_0 (active)

What Python version is IPython installed against? And do you have the matching 
jsonschema?

% port installed '*-ipython' '*-jsonschema'

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47790: pstree: update to 2.39 2.39)

[Lawrence Velázquez]

On Jun 8, 2015, at 8:32 AM, Jan Stary h...@stare.cz wrote:

 Are the ports that install no libraries supposed to say so?

Yes. This prevents MacPorts from rebuilding them as +universal if
a dependent's architecture doesn't match.

 From the top of my head, there are many ports that don't.

Those ports are wrong.

 Maybe I am missing something, but shouldn't the ports that _do_
 install libraries explicitly say so, with 'installs_libs no' being the
 default?

I expect that most ports install at least one library. In our case,
false positives are better than false negatives.

 (And if 'installs_libs no' _is_ the default, why have it in the
 Portfile?)

The default is yes.

 Please excuse my ignorance: how does a macport user specify, say, the
 exact CC to use when installing a port?

By doing something like this:

sudo port install pstree configure.compiler=macports-clang-3.6

 The provided Makefile then also uses the specified CC and CFLAGS and
 build time, right?

No. MacPorts automatically sets CC, CXX, etc. in the configure
environment based on the value of configure.compiler. It does not add
these variables to the build environment.

 The README should still be installed, even if there is also a manpage.
 
 Why?

Why not? Plenty of other ports do so. The more documentation, the
better.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: accelerated zlib experiment (and parallel afsctool)

[Lawrence Velázquez]

On Jun 5, 2015, at 4:17 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 Rather as a different port I think, or simply as an update to the existing 
 port, but only if there's demand.

There's no difference. The point is that we don't want to become a de facto 
upstream.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: zlib acceleration?

[Lawrence Velázquez]

On May 29, 2015, at 8:52 AM, Rainer Müller rai...@macports.org wrote:

 Even if this CloudFlare patch offers any performance improvements, the
 authors did not bother to implement it the sane way respecting licenses
 for further distribution. In this form, it will never be included
 upstream and we should not do it either.

+1

 The Intel patch looks better, applying zlib license to the files added.
 Also it has a check for availability of the SSE 4.2 feature before
 execution of the machine instruction.
 
 Unfortunately, I couldn't find any zlib mailing list archive containing
 the discussion of including the Intel patches.

https://web.archive.org/web/20131201003911/http://mail.madler.net/pipermail/zlib-devel_madler.net/2013-November/thread.html

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: `port -pf upgrade outdated` is incredibly unsafe ??

[Lawrence Velázquez]

On May 28, 2015, at 2:47 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 It should be safe to build ports that do not depend directly on a failed 
 port, but it seems not impossible that the ABI-changing effect of the update 
 of an indirect dependency permeates to a direct dependency.

I would consider this a bug in the dependent port. That indirect dependency 
should be a direct dependency.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: `port -pf upgrade outdated` is incredibly unsafe ??

[Lawrence Velázquez]

On May 28, 2015, at 1:09 PM, Kurt Pfeifle kurt.pfei...@googlemail.com wrote:

 Ok then: which one of the two switches is the unsafe one? I guess the -f? Or 
 has the combination of the two even more damage potential?

They're both unsafe.

-f does different things depending on the build phase, but all of them amount 
to plowing through despite problems. For instance, activating a port usually 
fails if some of that port's files already exist. Force-activating just 
overwrites those files.

-p tells MacPorts to continue processing ports and commands, even on failure. 
This can cause problems when upgrading a port and its dependencies, as MacPorts 
will blindly continue to upgrade ports despite their dependencies' builds 
failures.


 I started to make it a habit using them, because so often the upgrade does 
 not run through to continue with a few hundred other packages because of just 
 one or two or three packages fail…

Ignoring errors is a bad way to handle this situation. You should upgrade more 
often or uninstall some ports. (And report build failures to us, naturally.)


 If the -f (or the combo of -pf) is indeed so terribly unsafe as you say (I do 
 not doubt your statement, even though I do not understand the reason for it), 
 then there should be at least one of the following:
 
   • Add a warning (including the reason for it) to the port manpage.
   • Emit a warning on the command line, whenever this option is used.

Those are good ideas.


vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?

[Lawrence Velázquez]

On May 28, 2015, at 1:01 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 On Thursday May 28 2015 12:42:20 Lawrence Velázquez wrote:
 
 So the OP is trying to build ImageMagick x86_64.
 
 Are there ways to that other than requesting a +universal build of it, or of 
 another port which has ImageMagick as its first dependency?

OP is on Yosemite. MacPorts defaults to x86_64 builds on Yosemite.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?

[Lawrence Velázquez]

On May 28, 2015, at 9:16 AM, ^. .^ sixmilliondollar...@gmail.com wrote:

 when running macports to install software i get the following error
 
 quote
  Error: Cannot install ImageMagick for the arch(s) 'x86_64' because 
  Error: its dependency libtool is only installed for the arch 'i386' 
  Error: and the configured universal_archs 'i386 ppc' are not sufficient.
  Error: Unable to execute port: architecture mismatch
 /quote
 
 
 I found the macports.conf file and uncommented 
 build_arch   i386 
 
 and i cleaned all. but the error remains the same.

You may have to edit macports.conf again and set universal_archs x86_64 i386.


 this machine did not have macports on it last time around so i did not follow 
 the whole list of migration commands. but should i?

Was MacPorts present on the machine when you upgraded to Yosemite? If so, then 
you should follow the migration instructions. If not, you don't have to.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: yosemite and 2008/9 macbookpro compatability, macports install settings for older architecture?

[Lawrence Velázquez]

On May 28, 2015, at 11:22 AM, René J.V. Bertin rjvber...@gmail.com wrote:

 Was he doing a universal build? ImageMagick doesn't have +universal as a 
 default variant, so I don't see why one would need universal_archs if one 
 just wants or needs to build the entire tree in 32bit mode ...

MacPorts tries to remedy architecture mismatches by building dependencies 
+universal.

So the OP is trying to build ImageMagick x86_64. Its dependency libtool is 
already installed, but its architecture is unsatisfactory. MacPorts tries to 
fix this by rebuilding libtool +universal, but it notices that universal_archs 
doesn't contain x86_64 and bails out.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: zlib acceleration?

[Lawrence Velázquez]

On May 27, 2015, at 3:50 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 The link to the zlib ML on that page has gone stale, so I can't check whether 
 those Intel patches ever made it into zlib

Probably not, given that the latest upstream release occurred months prior.

 Does anyone know what the status is on this? According to livecheck, 
 port:zlib is up to date ...

It *is* up to date. zlib @1.2.8_0 provides the latest upstream release.

http://www.zlib.net

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Zathura (0.3.3_0) fails to upgrade

[Lawrence Velázquez]

On May 27, 2015, at 4:37 PM, Kurt Pfeifle kurt.pfei...@googlemail.com wrote:

 
 $ sudo port -pf upgrade zathura
 ---  Computing dependencies for zathura
 ---  Building zathura
 Error: org.macports.build for port zathura returned: command execution failed
 Please see the log file for port zathura for details:
 
 /opt/local/var/macports/logs/_opt_local_var_macports_sources_fco.it.rsync.macports.org_macports-release_tarballs_ports_office_zathura/zathura/main.log
 Error: Unable to upgrade port: 1
 To report a bug, follow the instructions in the guide:
 http://guide.macports.org/#project.tickets 
 http://guide.macports.org/#project.tickets
 
 $ port log girara
 []
 LIBS= -L/opt/local/lib -lgirara-gtk3  -L/opt/local/lib -lgtk-3 -lgdk-3 
 -lpangocairo-1.0 -lpangoft2-1.0 -lpango-1.0 -lm -lfontconfig -lfreetype 
 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 
 -lglib-2.0 -lintl  -L/opt/local/lib -lgthread-2.0 -lglib-2.0 -lintl  
 -L/opt/local/lib -lgmodule-2.0 -lglib-2.0 -lintl  -L/opt/local/lib -lglib-2.0 
 -lintl  -lpthread -lm -L/opt/local/lib -lsqlite3  -lmagic -L/opt/local/lib 
 -lz 
 The minimum required version of GIRARA is 0.2.4
 DFLAGS  = -g
 make: *** [.version-checks/GIRARA] Error 1
 make: *** Waiting for unfinished jobs
 CC  = /usr/bin/clang -fdiagnostics-color=always
 touch .version-checks/GLIB
 make: Leaving directory 
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_fco.it.rsync.macports.org_macports-release_tarballs_ports_office_zathura/zathura/work/zathura-0.3.3'
 Command failed:  cd 
 /opt/local/var/macports/build/_opt_local_var_macports_sources_fco.it.rsync.macports.org_macports-release_tarballs_ports_office_zathura/zathura/work/zathura-0.3.3
   /usr/bin/make -j8 -w all PREFIX=/opt/local 
 Exit code: 2
 
 $ port list girara
 girara @0.2.0  devel/girara

girara was updated an hour ago. Please run a selfupdate and try upgrading again.

vq

P.S. Unrelated: Stop using port -pf upgrade and never use it again. It's 
incredibly unsafe.___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Backing up MacPorts directories

[Lawrence Velázquez]

On May 26, 2015, at 7:11 AM, Steve Holden st...@coordinated.org wrote:

 Is it recommended to omit any of the directories under
 ‘/opt/local/var/macports’ from backups (e.g. ‘distfiles’, ‘sources’)?
 https://guide.macports.org/#internals.hierarchy
 
 Whilst I’d like a fully-functioning MacPorts installation if I have to
 boot from or restore from a backup drive, I wondered whether any of
 its build directories could be safely omitted? Would their contents be
 re-downloaded or re-built automatically (or could they be manually)?

You can probably omit these.

- var/macports/build: A scratch directory for port builds. There
  shouldn't be anything in there, unless a build was interrupted and you
  didn't run `port clean` afterwards.
- var/macports/distfiles: A cache for ports' source distributions.
  MacPorts will redownload anything it can't find here.
- var/macports/logs: MacPorts' logs.
- var/macports/sources: Contains the ports tree and MacPorts base source
  code. I believe `port selfupdate` repopulates this, so you need not
  back it up.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 25, 2015, at 10:23 AM, René J.V. Bertin rjvber...@gmail.com wrote:

 I did discover one obstacle to swapping libjpeg.8.dylib from port:jpeg and 
 port:libjpeg-turbo: the former sets compatibility version 13.0.0, the latter 
 version 9.0.0 . BTW, libjpeg.9.dylib has compat. version 11.0.0 ... so I'm 
 not sure to what extent upstream really know what they're doing with OS X 
 specific library versioning ...

Compatibility numbers are not compared across major library versions because 
client images use specific major libraries. You should not get into a situation 
where you are comparing libjpeg.8.dylib compat 13.0.0 and libjpeg.9.dylib 
compat 11.0.0.

 So if libjpeg is to be maintained as a 3rd alternative a patch will be 
 required to change the compatibility and current version that is stored in 
 libjpeg.8.dylib .

We should not roll back a library's compatibility number. Doing so presumes 
that the newer version is backwards-compatible with the older version.

It would make more sense to bring libjpeg-turbo up to compatibility version 
13.0.0.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 24, 2015, at 10:52 PM, Ryan Schmidt ryandes...@macports.org
wrote:

 ...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.

I suppose I should have said that *my* interest in this discussion is
about maintenance and not performance. But better performance would
definitely be a plus.

And from a maintenance perspective, libjpeg-turbo looks like a clear
win.

- libjpeg-turbo upstream seems to care about maintaining compatibility
  while making meaningful improvements.
- libjpeg upstream seems to be willing to break compatibility
  frequently, for the sake of making changes of questionable utility.

The former could get us better performance and improved stability. To
ensure that stability with the latter, we'd have to freeze it at an old
version forever.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 24, 2015, at 9:00 PM, Ryan Schmidt ryandes...@macports.org wrote:

 On May 24, 2015, at 9:43 AM, René J.V. Bertin wrote:
 
 I think I made it clear that I have this requirement, but I suppose I'll 
 just keep extending my own port repository.
 
 No, sorry, I missed that you have this requirement. Why do you need libjpeg 
 instead of libjpeg-turbo?

I'm not convinced that it's need so much as want.

 but I think I won't. I'm just not convinced that recent/fast machines will 
 see any measurable gain from the whole exercise.
 
 ...which exercise?

Replacing libjpeg with libjpeg-turbo. I think this point is off-topic, as this 
discussion is primarily about maintainability and not performance.

 The issue is moot if port:jpeg is discontinued. If it's not, it's special in 
 that there are 3 alternatives that each provide one of two ABI versions, and 
 only port:jpeg being unambiguous about what version it provides.
 Anyway, I think it's something that can be decided upon on a case-by-case 
 basis. There is precedence; gstreamer comes to mind.
 
 gstreamer1 and gstreamer010 are named after the project version number, not 
 any included library's version number. There are many many ports named after 
 the project version number

Yes, and nearly all of them are a significant pain to maintain. This is one 
reason I'm paring back our Python selection. (GCC is on deck.) I would like to 
avoid creating more versioning if we can help it.

 But if we don't let the user choose between libjpeg-turbo and mozjpeg, how 
 then is a user who wants to use mozjpeg going to do that? Imagine I want to 
 compress a bunch of images using ImageMagick, and I want them to be as small 
 as possible, and I don't care if it takes longer to encode them. That's what 
 mozjpeg is for. I had envisioned that in this situation, I would 
 force-deactivate libjpeg-turbo, activate mozjpeg, and then use ImageMagick as 
 planned. Then when I was done I would deactivate mozjpeg and re-activate 
 libjpeg-turbo. Though thinking about it now, I guess for that use case it 
 wouldn't really matter if ImageMagick declared its dependency on 
 path:lib/libjpeg.dylib:libjpeg-turbo or just port:libjpeg-turbo; either way, 
 libjpeg-turbo will have to be forcibly deactivated.


It doesn't matter for that specific case, but a user who for some reason wanted 
to always use mozjpeg could still install it up front and let all dependencies 
pick it up.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 23, 2015, at 9:04 PM, Ryan Schmidt ryandes...@macports.org wrote:

 I do wish to do at least some basic functionality testing of a libjpeg 
 replacement on Tiger and Leopard. I do not want to be the cause of much of 
 MacPorts ceasing to function properly for users of those systems, if it can 
 be reasonably avoided.
 
 I verified libjpeg-turbo 1.4.0 builds and destroots on real PowerPC Macs 
 running 10.4 and 10.5, but have not yet installed or used it.
 
 I plan to rebuild a port I maintain--graphviz--and all its dependencies to 
 use libjpeg-turbo, then verify that I can create a graph with graphviz that 
 both uses (reads) jpeg input files and produces (writes) a jpeg output file. 
 Then I would probably repeat the test with mozjpeg instead of libjpeg-turbo. 
 If that works, I'll be satisfied to replace jpeg with libjpeg-turbo/mozjpeg.

Running `port test libjpeg-turbo` would be useful as well.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 22, 2015, at 10:06 AM, Daniel J. Luke dl...@geeklair.net 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).
 
 If it does build there, and we can verify it - great - otherwise I don’t 
 think it should stop us from moving forward.

Fortunately, libjpeg-turbo 1.4.0 builds fine for PowerPC (under 10.6 Rosetta, 
at least).

https://trac.macports.org/changeset/136595

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 22, 2015, at 10:06 AM, Daniel J. Luke dl...@geeklair.net wrote:

 On May 21, 2015, at 11:11 PM, Mihai Moldovan io...@macports.org wrote:
 
 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).
 
 If it does build there, and we can verify it - great - otherwise I don’t 
 think it should stop us from moving forward.

+1

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: libjpeg vs. libjpeg-turbo

[Lawrence Velázquez]

On May 20, 2015, at 6:31 AM, René J.V. Bertin rjvber...@gmail.com wrote:

 As a related question: libjpeg-turbo depends on port:nasm, but I cannot get 
 it NOT to insist on reinstalling nasm+universal, not even using a 
 path:${prefix}/bin/nasm style dependency. How to get around that? Evidently 
 there is no point in installing nasm +universal just to build something 
 +universal ...

The nasm port doesn't install any libraries or headers, so it should be setting 
installs_libs no to disable architecture checks. I just corrected this.

https://trac.macports.org/changeset/136524

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: migration question

[Lawrence Velázquez]

On Apr 11, 2015, at 8:46 AM, René J.V. Bertin rjvber...@gmail.com wrote:

 On Saturday April 11 2015 06:27:21 Ryan Schmidt wrote:
 
 Unless you plan to meticulously analyze each port's build script, you won't 
 know whether that build script makes
 
 It's not like it's difficult to search for os.platform and/or os.major ... 
 and of course it would be the 1st thing to check in case of trouble (at least 
 I hope I'd think of that :)).

Inspecting portfiles is not sufficient. You'd also have to look at each port's 
build system to verify that it invokes the compiler with the correct options.

 Has it ever been considered to let (oblige) such checks (to) use a procedure 
 rather than a variable, so that base can register when a port/variant has 
 OS X versions-specific behaviour?

The correct way of conditionalizing based is with the platform command, but 
it's often not flexible enough. For instance, it can't express apply this 
script on Darwin 12 and earlier. Using the variable is also just cleaner in 
many cases.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Changing PATH and downloading mpich-default

[Lawrence Velázquez]

On Apr 5, 2015, at 12:58 PM, Evan Phillips phill...@purdue.edu wrote:

 Mihai - here it is:
 http://pastebin.com/tp8LjW2U

Neither of these logs is complete.

DEBUG: Executing org.macports.main (llvm-3.5)
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: Skipping completed org.macports.archivefetch (llvm-3.5)
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: Skipping completed org.macports.fetch (llvm-3.5)
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: Skipping completed org.macports.checksum (llvm-3.5)
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: extract phase started at Sun Apr  5 12:53:48 EDT 2015

Please run

$ sudo port clean all
$ sudo port -dt install mpich-default

and provide the new log if it still fails.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: about Qt 5.x and OS X 10.6

[Lawrence Velázquez]

 On Mar 20, 2015, at 4:46 PM, René J.V. Bertin rjvber...@gmail.com wrote:
 
 So I am now exploring an option that may be a bit unusual: OS-specific port 
 versions. Nothing as fancy as it seems: for OS X 10.6 users 
 port:qt5-mac-devel will appear to be at 5.3.2 and for all other users it will 
 appear to be at 5.4.x .
 
 I'm aware that this could set precedence

It wouldn't; the ld64 port used to do this until very recently.

vq
Sent from my iPhone
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Trac is back (eom)

[Lawrence Velázquez]

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Announce: OpenSSH 6.8 released (fwd)

[Lawrence Velázquez]

On Mar 18, 2015, at 4:46 PM, Dave Horsfall d...@horsfall.org wrote:

 Someone might want to take a look at this; both the BSD people and the 
 Penguins are all over it.

https://trac.macports.org/ticket/47190

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /Library/Frameworks no longer a default location?

[Lawrence Velázquez]

On Mar 12, 2015, at 9:44 AM, René J.V. Bertin rjvber...@gmail.com wrote:

 Not really MacPorts-related, but is it true that /Library/Frameworks
 is no longer searched automatically by the compiler and linker, as
 suggested by https://codereview.qt-project.org/108400 ?

Not sure how you're concluding that; that bug report doesn't say
anything about the Apple toolchain. Maybe QMake was changed to ignore
/Library/Frameworks, or maybe Apple's prerelease toolchain does so.
Current Clang and ld64 certainly still search /Library/Frameworks.

% echo 'int main() {}' | /opt/local/bin/clang-mp-3.7 -x c - -o /dev/null -v 
-Wl,-v
clang version 3.7.0 (trunk 231583)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
 /opt/local/libexec/llvm-3.7/bin/clang -cc1 -triple 
x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free -main-file-name 
- -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim 
-masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v 
-dwarf-column-info -resource-dir 
/opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.0 -fdebug-compilation-dir 
/Users/larryv/Projects/MacPorts/git-svn/trunk/dports -ferror-limit 19 
-fmessage-length 120 -stack-protector 1 -mstackrealign -fblocks 
-fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature 
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o 
/var/folders/t2/1q6yn0z16n9_d8s578lh4ndmgn/T/--9e1e98.o -x c -
clang -cc1 version 3.7.0 based upon LLVM 3.7.0svn default target 
x86_64-apple-darwin14.1.0
ignoring nonexistent directory /usr/local/include
#include ... search starts here:
#include ... search starts here:
 /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 /opt/local/libexec/llvm-3.7/bin/ld -demangle -dynamic -arch x86_64 
-macosx_version_min 10.10.0 -o /dev/null 
/var/folders/t2/1q6yn0z16n9_d8s578lh4ndmgn/T/--9e1e98.o -v -lSystem 
/opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.0/lib/darwin/libclang_rt.osx.a
@(#)PROGRAM:ld  PROJECT:ld64-236.3
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m arm64
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
%

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: handbrake?

[Lawrence Velázquez]

On Jan 26, 2015, at 11:15 AM, Lawrence Velázquez lar...@macports.org wrote:

 I have been working on this for the past couple of weeks

I'm done.
http://trac.macports.org/log/?rev=132828stop_rev=132815

Here's the meat.
http://trac.macports.org/changeset/132827

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /etc/paths

[Lawrence Velázquez]

On Feb 6, 2015, at 1:49 PM, Michael keybou...@gmail.com wrote:

 On 2015-02-06, at 10:25 AM, Luc Bourhis luc_j_bour...@mac.com wrote:
 
 Not launchd, no. It's for the shell and it helps with MANPATH too. man 
 path_helper for the details.
 
 Interesting. I'm surprised MacPorts doesn't stuff something in there.

(1) We consider /etc/paths to be a system file. We don't like modifying 
system files.
(2) Modifying /etc/paths affects all users' settings, which is undesirable.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [git] fatal: HTML documentation is not provided by this distribution of git

[Lawrence Velázquez]

On Feb 5, 2015, at 8:11 AM, Luc J. Bourhis luc_j_bour...@mac.com wrote:

 git help -w returns
 
 fatal: HTML documentation is not provided by this distribution of git
 
 even though /opt/local/share/doc/git-doc has the HTML doc files and port
 variants list [+]doc. It must be weird as Google did not return anything
 and scouring Macports mailing lists and bug reports did not either.

Are you sure you're executing /opt/local/bin/git and not /usr/bin/git?

% /opt/local/bin/git help -w merge
[Safari opens]
% /usr/bin/git help -w merge
fatal: HTML documentation is not provided by this distribution of git.
%

Did you just install the git port? If so, try running `hash -r` to refresh your 
shell's command hash table, so that `git` refers to /opt/local/bin/git.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [git] fatal: HTML documentation is not provided by this distribution of git

[Lawrence Velázquez]

On Feb 5, 2015, at 4:43 AM, Luc J. Bourhis luc_j_bour...@mac.com wrote:

 The HTML documentation is installed:
 
 
 
 but git help refuses to serve it:

Does `git help -w` work?

I have git @2.2.2_0+credential_osxkeychain+doc+pcre+perl5_16+python27+svn 
installed, and `git help -w` works just fine. `git help` also works because I 
have `help.format=html` in my ~/.gitconfig.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Using Xcode toolchain internals (Was: apple clang vs macports clang performance)

[Lawrence Velázquez]

On Jan 28, 2015, at 5:58 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 Really now, even if that's true for the other stuff in there, it
 shouldn't be for libclang

Says who? Apple can reserve that particular library for internal use if it 
wants. (This doesn't mean that you *cannot* use it, it means that it's a *bad 
idea* to use it.)

 Or else Apple does do secret things with its clang version ...

I expect Apple does make its own modifications to the compiler it ships. They 
don't even call it Clang.

% /usr/bin/clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
% /opt/local/bin/clang-mp-3.7 --version
clang version 3.7.0 (trunk 226372)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

In any case, this has nothing to do with secrecy; it's about expectations of 
support and stability. The vendor can change a private ABI/API whenever it 
feels like, so it's a poor idea to rely on it. The libraries in 
XcodeDefault.xctoolchain aren't even versioned.

 Neither the Xcode SDKs nor the CLT contain those libraries, so I expect
 
 Eh? The CLT have libclang in /usr/lib.

What?

% ls /usr/lib/libclang*
zsh: no matches found: /usr/lib/libclang*

Are you sure your library is from the CLT? What does `pkgutil --file-info` say 
about it?

 That library is of course only useful code that uses functionality clang 
 provides. Exactly what kdev-clang does: it provides a clang-based C/C++ 
 parser. You can compare it to the debugger library for which lldb is a 
 front-end that could be replaced by a graphical front-end, or one that looks 
 and feels like gdb.

I know what libclang is. None of this means that it's wise to utilize a copy of 
libclang that is pretty clearly not intended for public use.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: handbrake?

[Lawrence Velázquez]

On Jan 25, 2015, at 2:39 PM, Ludwig macpo...@metaspasm.org wrote:

 Is any work being done on the broken Handbrake port?  It's been over a year
 since the last revision.  I'll see what I can do with it, but I don't want to
 step on toes or duplicate effort.

I have been working on this for the past couple of weeks; if anyone's been 
wondering why I've been committing infrequently lately, this is why. Turns out 
that wrangling 19 build systems in one port is not particularly simple.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: hypermail port problem

[Lawrence Velázquez]

On Jan 23, 2015, at 3:28 AM, jerome schatten rom...@shaw.ca wrote:

 I did, Ryan and I installed it again, It took about 10 minutes -- and it 
 returned Software Installed at the end of the process. But command line tools 
 as such does not seem to appear anywhere.  In the gui if you go to 
 Applications - Xcode - Preferences you will see command line tools at the 
 bottom That's the only reference to it that I can find. Maybe this is the 
 clue?
 I appreciate your help -- I'm not trying to be difficult!

As Ryan said, the absence of the CLT is probably not what's causing your 
difficulty.

For future reference, one telltale sign that the CLT are installed is the 
presence of /usr/include. One reason (I'm sure there are others) that some 
build systems need the CLT is that they insist on looking for headers in 
/usr/include and fail if that directory doesn't exist.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pulseaudio 5.0 fails to build

[Lawrence Velázquez]

On Jan 23, 2015, at 5:00 AM, René J.V. Bertin rjvber...@gmail.com wrote:

 On Friday January 23 2015 01:26:20 Ryan Schmidt wrote:
 
 Point and Rect are Carbon types. Carbon is obsolete and should no longer be 
 used.
 
 Go tell that to the FOSS maintainers who use out of courtesy to us... I know 
 it shouldn't be used for new, Mac-specific applications, I wouldn't be 
 surprised if Apple themselves use it in some of the FOSS stuff they ship with 
 OS X. The fact that the Carbon headers are (now) buried deeply in a framework 
 with a telling name like CoreServices would support that, IMO.

Whether or not Apple itself still ships Carbon code is completely irrelevant. 
Apple deprecated Carbon years ago, and its continued use in any shipping code 
should be considered a bug.

At the very least, it should be accessed via CoreServices/CoreServices.h, not 
directly.

 /Developer should only exist on OS X 10.6 and earlier. If you have this 
 directory on OS X 10.9, delete it. All it can do is cause problems.
 
 That's a different question I think. I'm not yet ready to give up what's 
 still my favourite IDE O:-) and am still planning to see experiment some more 
 with it.

You can do what you like, as ever. We don't have to support it, as ever. And we 
do not support having outdated versions of Xcode installed.

That being said, the PulseAudio build should be smarter about the headers it 
uses.

 My first experiences seem to indicate that it still builds (some) legacy and 
 platform-agnostic software, and its presence only caused problems here 
 because it was accessed explicitly. After all, the current dev tools are 
 supposed to be able to co-exist with each other because of an almost indecent 
 level of putting everything in the Xcode app bundle (5Gb for Xcode 6.1 or 
 something like that?) so they should also ignore /Developer.

The different Xcodes probably ignore each other just fine. The issue here is a 
third-party build system that indiscriminately includes obsolete headers.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pulseaudio 5.0 fails to build

[Lawrence Velázquez]

On Jan 22, 2015, at 7:51 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 Same. But I bet you don't get this (copied from my initial message):
 
  cal/include/glib-2.0 -I/opt/local/lib/glib-2.0/include 
 -I/opt/local/include -I/Developer/Headers/FlatCarbon/ -
 
 or at least you have nothing at that particular location. Seems the build 
 process picks up things in /Developer when they exist:
 
 checking looking for Apple CoreService Framework... checking 
 /Developer/Headers/FlatCarbon/CoreServices.h usability... no
 checking /Developer/Headers/FlatCarbon/CoreServices.h presence... no
 
 
 Could be worth it trying to deactivate that logic for 10.7 or 10.8 and beyond?

Does doing so fix your build?

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: hypermail port problem

[Lawrence Velázquez]

On Jan 23, 2015, at 1:31 AM, jerome schatten rom...@shaw.ca wrote:

 *S*ystem: MacMini -- late 2014 - Yosemite 10.10.1; Xcode installed.
 
 I've installed macports 2.3.3 with no problems; I've installed port hypermail 
 with no 'apparent' problem. I've followed the MacPorts Guide every step of 
 the way.

For others' benefit, OP already opened a ticket about this:

https://trac.macports.org/ticket/46655

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: CarbonHeaders obsolete: uninstall dependencies

[Lawrence Velázquez]

On Jan 19, 2015, at 5:47 PM, René J.V. Bertin rjvber...@gmail.com wrote:

 I somehow missed this obsolescence...
 Why exactly have the CarbonHeaders gone obsolete

Because ports should be using the headers provided by the host.

https://trac.macports.org/ticket/42500#comment:6
https://trac.macports.org/ticket/46521#comment:4

 what does removal mean for code that includes AvailabilityMacros.h? I've made 
 a number of patches to KDE4 that rely on that header, and KDE uses Carbon 
 itself.

I might be mistaken, but you should probably be using the system's Kernel 
framework header instead of AvailabilityMacros.h directly.

Or use Xcode's headers.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: CarbonHeaders obsolete: uninstall dependencies

[Lawrence Velázquez]

On Jan 19, 2015, at 5:30 PM, Tim Johnson t...@akwebsoft.com wrote:

 Since I have only entry - level knowledge of macports, and I don't
 wish to do damage I'm must ask :
 
 Is this just a matter of running 
  sudo port libunwind-headers ?
 and then
  sudo port uninstall CarbonHeaders ?

Hi Tim,

You probably don't need to keep libunwind-headers installed, so the easiest 
resolution would be to uninstall them both.

% sudo port uninstall --follow-dependencies libunwind-headers

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: CarbonHeaders obsolete: uninstall dependencies

[Lawrence Velázquez]

On Jan 19, 2015, at 9:29 PM, Jeremy Huddleston Sequoia jerem...@macports.org 
wrote:

 On Tiger and later, you should use AvailabilityMacros.h as provided by the 
 SDK.
 
 On Leopard and later, you should use Availability.h as provided by the SDK

Oh right, silly me. Otherwise changing deployment target and base SDK wouldn't 
really work.

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html#//apple_ref/doc/uid/1163i-CH1-107837

In any case, you shouldn't be using CarbonHeaders' headers.

vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users