Re: Failure to build glib2 as part of xsane dependency

[Chris Jones]

You need to uninstall any ports built using 4.0, then uninstall 
clang-4.0 and llvm-4.0, then reinstall the ports you need using clang 3.9.


Chris

On 09/05/17 19:56, ges...@ftp83plus.net wrote:

Doesn't work.

The following ports will break:
 cctools @895_4
 ld64-latest @274.2_1

I selected "y" anyway, but as expected, got the same error message:

cctools: Variant llvm39 conflicts with llvm40

El 2017-05-09, a las 13:58, Ken Cunningham escribió:


sudo port uninstall clang-4.0 llvm-4.0 should do it for you.

don't forget to change the line in macports.conf about
default_compilers, removing clang-4.0.

BTW I appear to have fixed clang-4.0 for snow leopard, and depending
on what Jeremy wants to do with that, it should be working in macports
or upstream eventually.

Although I'd recommend you stick with clang-3.8 or clang-3.9 for now,
clang-4.0 for snow leopard will work soonishly. There's a word... :>

Best,

Ken



On 2017-05-09, at 10:53 AM, ges...@ftp83plus.net
 wrote:


Me again.

I forgot, but how do I uninstall the broken llvm40 version?
On Step 7, it complains about conflict between llvm39 and llvm 40.

Thanks

El 2017-05-05, a las 19:05, Ken Cunningham escribió:



On 2017-05-04, at 12:32 PM, ges...@ftp83plus.net
 wrote:


Hello there,

I needed to reinstall MacPorts on Snow Leopard, and followed the
instructions in LibcxxOnOlderSystems (I recall some ports wouldn't
compile properly without it), including the experimental steps.
Only there, I replaced clang 3.9 by clang 4.0.

However, it failed on completing xsane compilation, as glib2 failed:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log

is pasted there:
https://pastebin.com/dmNJFQKU

From what I could read, it can't find a given header file. How did
it went missing?





As mentioned privately, it seems likely you've stumbled across this
bug  which Jeremy
reported a few months ago.

It looks like a new regression and I don't see that error on 10.6
with clang-3.7, clang-3.8, or clang-3.9, so if you back up in the
libcxxonoldersystems instructions and install clang-3.8 or clang-3.9
you should be OK.

I haven't tried clang-4.0 to confirm this bug / error on my system
yet, but I could assume I'd see it too if I did.

Best,

Ken










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


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

Re: GitHub migration complete

[Chris Jones]

On 31/10/16 10:41, René J.V. Bertin wrote:

On Monday October 31 2016 10:49:55 Clemens Lang wrote:

Hi,


Just as with Subversion, the answer is no. Remember that the PortIndex
is specific to the macOS version you are running, so a server-generated


Ah, of course. I didn't actually know this but indeed port versions could be 
specific to OS version or platform even if no other specific information is 
stored.
Sorry for the noise.

Pity though, the first-run portindex of a fresh git clone just took about 5 
quarters of an hour on one of my machines (a good 5s/port).



That is a one time operation. hardly worth worrying about.


Additionally, git does not preserve timestamps from the repository on
checkout, so you might actually end up re-generating the index locally
anyway.


I think that wouldn't (or shouldn't) happen as the timestamp would be newer. 
And of course the auto-regeneration could be deactivated if the server always 
serves an up-to-date index.

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


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

Re: GitHub migration complete

[Chris Jones]

On 31/10/16 09:49, Clemens Lang wrote:

Hi,

On Mon, Oct 31, 2016 at 10:18:42AM +0100, René J.  V. Bertin wrote:

I may have overlooked this, but does github have any provisions that
would allow the PortIndex files to be generated on the server and
served with the actual repo contents? That would probably give a very
significant reduction in the resources spent collectively to
regenerate those files...


Just as with Subversion, the answer is no. Remember that the PortIndex
is specific to the macOS version you are running, so a server-generated
PortIndex could only generate all of them into different files.

Additionally, git does not preserve timestamps from the repository on
checkout, so you might actually end up re-generating the index locally
anyway.


After the initial checkout, when the first time generation of the index 
does take a short while, subsequent updates are from my perspective fast 
enough that this is not something to worry about. (I personally actually 
prefer to be generating it myself anyway).


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

Re: trouble building mtr 0.87 on snow leopard. Solved with a hack...

[Chris Jones]

On 28/10/16 14:08, Peter Hancock wrote:

On 28/10/2016 13:10, Chris Jones wrote:


On 28/10/2016 11:03, Peter Hancock wrote:

On a snow leopard machine, mtr won't upgrade from 0.86 to 0.87.
The trouble, according to the log, is that IPPROTO_SCTP isn't defined.


What I did was to edit /usr/include/netinet/in.h
and give IPPROTO_SCTP the same value (132) as it has on
the Yosemite machine on which mtr build.

It built, and seems to work (for what I use it for, anyway).


Needless to say, that is not a good idea, hacking the system files...


Yes of course it's Wrong. (Once it built, I removed the hack.)
Sadly I've never learnt how to use "patch" or indeed (m?)any of the tools one 
needs
to tweak things in macports ...


I don't really care what you do to your own machines, in private. Just 
don't post advice like this to the list, for others to follow ;)


Please also keep your replies on-list.

Chris





Instead you should patch the source for mtr to define  IPPROTO_SCTP in some 
appropriate header file there...



Peter


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

Re: trouble building mtr 0.87 on snow leopard. Solved with a hack...

[Chris Jones]

On 28/10/16 12:45, Peter Hancock wrote:

On 28/10/2016 11:03, Peter Hancock wrote:

On a snow leopard machine, mtr won't upgrade from 0.86 to 0.87.
The trouble, according to the log, is that IPPROTO_SCTP isn't defined.


What I did was to edit /usr/include/netinet/in.h
and give IPPROTO_SCTP the same value (132) as it has on
the Yosemite machine on which mtr build.

It built, and seems to work (for what I use it for, anyway).


Needless to say, that is not a good idea, hacking the system files...

Instead you should patch the source for mtr to define  IPPROTO_SCTP in 
some appropriate header file there...


Chris

___
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

[Chris Jones]

> On 22 Oct 2016, at 12:54 pm, Richard Cobbe  wrote:
> 
>> On Fri, Oct 21, 2016 at 08:12:59PM +0200, Clemens Lang wrote:
>> Hello MacPorts users and developers,
>> 
>> MacPorts will be moving to GitHub soon. We're sending this email to
>> inform you about changes in how you access the MacPorts repositories and
>> bug tracker. Additionally, this email contains information on planned
>> downtimes.
> 
> Is there/will there be a story for people who cannot use rsync to pull down
> updates because they're behind a restrictive proxy?
> 
> This affects one of the three computers on which I maintain a MacPorts
> installation.  I currently use the mechanisms described at
>  to get around this,
> but of course those instructions are coupled very tightly to SVN.

This probably should not be necessary with github, as it use ssh or https . 

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

Re: lvm-3.3 problem with sierra

[Chris Jones]

P.s. When sending a log file as an attachment please give the file name a 
proper suffix, .txt, as without this email readers often do not know what to do 
with it. The right extension makes it possible to view on iOS for instance 

> On 9 Oct 2016, at 5:47 pm, Chris Jones  wrote:
> 
> Hi,
> 
>> On 9 Oct 2016, at 2:13 pm, Comer Duncan  wrote:
>> 
>> I tried to follow the upgrade procedure and eventually got the complaint 
>> that lvm-3.3 is not supported. I'm attaching the log file and ask for  
>> advice about ways around this obstacle. Thanks for your help!
> 
> Personally i don't quite follow the migration guide word for word, as when 
> reinstalling I prefer, instead of just blindly reinstalling everything as it 
> was, going through the list by hand and deciding what I really still want.
> 
> In this case if you have explicitly installed llvm, or clang, 3.3 then do not 
> try and reinstall it and pick a newer version. If it is being pulled in as a 
> dependency of some other port, check that port to see if it has other 
> variants you can use instead. Almost certainly all ports that needs an 
> llvm/clang version installed will actually be using something a lot newer 
> than 3.3 now. 
> 
> Chris
> 
>> 
>> Comer
>> 
>> ___
>> macports-users mailing list
>> macports-users@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: lvm-3.3 problem with sierra

[Chris Jones]

Hi,

> On 9 Oct 2016, at 2:13 pm, Comer Duncan  wrote:
> 
> I tried to follow the upgrade procedure and eventually got the complaint that 
> lvm-3.3 is not supported. I'm attaching the log file and ask for  advice 
> about ways around this obstacle. Thanks for your help!

Personally i don't quite follow the migration guide word for word, as when 
reinstalling I prefer, instead of just blindly reinstalling everything as it 
was, going through the list by hand and deciding what I really still want.

In this case if you have explicitly installed llvm, or clang, 3.3 then do not 
try and reinstall it and pick a newer version. If it is being pulled in as a 
dependency of some other port, check that port to see if it has other variants 
you can use instead. Almost certainly all ports that needs an llvm/clang 
version installed will actually be using something a lot newer than 3.3 now. 

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

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

Re: soreEyes (and where are my System 7 ports?)

[Chris Jones]

On 27/09/16 10:10, René J.V. Bertin wrote:

On Tuesday September 27 2016 04:00:26 Ryan Schmidt wrote:


Yes it would. I've changed it in the Trac footer. I expect there are many 
places in the guide and wiki where this needs to be changed, but the 
documentation needs a major overhaul anyway.


Might I suggest adding the small nuance that it's something for "users of the Mac 
operating system"?


FWIW, I personally prefer "Ports system for the Mac operating system" as 
first suggested. Saying its for 'users' seems redundant info to me.


___
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

[Chris Jones]

> On 25 Sep 2016, at 3:32 pm, Yongwei Wu  wrote:
> 
> 
> 
>> On 25 September 2016 at 22:21, Chris Jones  wrote:
>> 
>> 
>> 
>>> On 25 Sep 2016, at 2:49 pm, Yongwei Wu  wrote:
>>> 
>>> 
>>> 
>>>> On 25 September 2016 at 21:35, Chris Jones  
>>>> wrote:
>>>> 
>>>> 
>>>>> On 25 Sep 2016, at 2:25 pm, Brandon Allbery  wrote:
>>>>> 
>>>>> 
>>>>>> On Sun, 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). clang++ is linking against libc++, and g++ is 
>>>>>> presumably  linking against libstdc++ as that is what it does -- yet 
>>>>>> there appear to be no visible issues...and these libraries find each 
>>>>>> other. 
>>>>> 
>>>>> An additional complication is that it's not using the same libstdc++: 
>>>>> it's using the GPL3 one with C++11 support, not Apple's GPL2/pre-C++11 
>>>>> one. So potentially the clash here is between the two libstdc++ versions, 
>>>>> not libstdc++ and libc++.
>>>> 
>>>> Indeed, mixing two different libstdc++ runtimes has the same sort of 
>>>> issues as mixing libstd++ with libc++.
>>> 
>>> 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. (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.)
>> 
>> Its exactly the same situation as with libc++ v libstdc++. There are ways it 
>> can be ok and ways you can run into problems. The only guaranteed way (I 
>> know of) to not have issues is not to do it.
> 
> ​My point is that a well-designed application/library should not do this. And 
> if it did it, problems might have occurred long ago (esp. on Windows, 
> supposing a Windows port exists). If things are going on well so far, we 
> probably do not need to worry much. At least I do not see what we can do to 
> help the case at the moment.

You are missing my point. For a single application, built by one developer it 
might be possible to avoid (I would still argue its a bad design choice). We 
are talking about Macports though, which is a very different beast. Its an 
ecosystem of many libraries and applications. There is no way to police it to 
make mixing work, so the only solution is to not do it.

> 
> -- 
> Yongwei Wu
> URL: http://wyw.dcweb.cn/
___
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

[Chris Jones]

> On 25 Sep 2016, at 2:49 pm, Yongwei Wu  wrote:
> 
> 
> 
>> On 25 September 2016 at 21:35, Chris Jones  wrote:
>> 
>> 
>>> On 25 Sep 2016, at 2:25 pm, Brandon Allbery  wrote:
>>> 
>>> 
>>>> On Sun, 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). clang++ is linking against libc++, and g++ is presumably  
>>>> linking against libstdc++ as that is what it does -- yet there appear to 
>>>> be no visible issues...and these libraries find each other. 
>>> 
>>> An additional complication is that it's not using the same libstdc++: it's 
>>> using the GPL3 one with C++11 support, not Apple's GPL2/pre-C++11 one. So 
>>> potentially the clash here is between the two libstdc++ versions, not 
>>> libstdc++ and libc++.
>> 
>> Indeed, mixing two different libstdc++ runtimes has the same sort of issues 
>> as mixing libstd++ with libc++.
> 
> 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. (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.)

Its exactly the same situation as with libc++ v libstdc++. There are ways it 
can be ok and ways you can run into problems. The only guaranteed way (I know 
of) to not have issues is not to do it.

> 
> -- 
> Yongwei Wu
> URL: http://wyw.dcweb.cn/
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[Chris Jones]

> On 25 Sep 2016, at 2:25 pm, Brandon Allbery  wrote:
> 
> 
>> On Sun, 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). clang++ is linking against libc++, and g++ is presumably  
>> linking against libstdc++ as that is what it does -- yet there appear to be 
>> no visible issues...and these libraries find each other. 
> 
> An additional complication is that it's not using the same libstdc++: it's 
> using the GPL3 one with C++11 support, not Apple's GPL2/pre-C++11 one. So 
> potentially the clash here is between the two libstdc++ versions, not 
> libstdc++ and libc++.

Indeed, mixing two different libstdc++ runtimes has the same sort of issues as 
mixing libstd++ with libc++.

> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
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

[Chris Jones]

On 25 Sep 2016, at 1:29 pm, Ken Cunningham  
wrote:

>> 
>> The problem is not really about libc++; it's about mixing multiple C++
>> runtimes.
> 
> Indeed.
> 
> 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). 
> clang++ is linking against libc++, and g++ is presumably  linking against 
> libstdc++ as that is what it does -- yet there appear to be no visible 
> issues...and these libraries find each other. 

Thats just the point, there might not *appear* to be problems. You can actually 
have an application using libraries built with each runtime, seemingly run just 
fine, as long as the two runtimes do not attempt to exchange (incompatible) 
information. For instance, the std::string class has a different implementation 
between the two, and attempting to between the two will cause issues. In your 
cases you are probably being lucky and not tripping over the issue.

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

Because you are mixing the two runtimes more often, and thus more likely to run 
into problems.

The bottom line is whilst you might be able to get away with it in a few corner 
cases, you cannot reliably mix the two runtimes, so it should nit be done.

Chris

> 
> 
>> 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++. I sent the link on how to do 
> that previously, and may be forced to explore that. It just looks like a lot 
> of messing with the compiler commands on every port using g++, which seems 
> unpleasant -- unless I were to wrap g++ in a shell script that does it 
> automatically, perhaps...
> 
> 
> 
>> 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++
> 
>> What links against libstdc++, specifically?
> 
> gcc6 itself, at least. And by default at least, any c++ code gcc would 
> compile 
> 
>> 
>> Jeremy unfortunately cannot do much of anything about GCC. I believe
>> Apple employees are not allowed to look at GPL3 code.
> 
> I wasn't thinking he'd need to read the gcc compiler code.
> 
>> I wouldn't be surprised if GCC used C++11 features. It doesn't really
>> matter because it is self-hosted.
> 
> It's an alternative way to get c++11 code compiled; I was just noticing that 
> clang++/libc++ aren't the only option for c++11.
> 
> 
> 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?
> 3. figure out how to make this work: 
> , possibly 
> by wrapping g++ in a shell script that does it for every use.
> 4. a parallel installation of macports with libstdc++ and gcc, to install 
> gimp, octave, qemu, and whatever other similar gcc-requiring ports come along.
> 
> 
> 
> K
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Starting gimp2

[Chris Jones]

> On 25 Sep 2016, at 12:01 pm, Eneko Gotzon  wrote:
> 
> 
>> On Sun, Sep 25, 2016 at 1:49 AM, David Liontooth  
>> wrote:
>> I could install gimp.app, but it's version 2.8.2 and gimp2 is 2.8.18, so 
>> I'll just try to figure out how to start gimp2.
> 
> I think ​2.8.2 > 2.8.18 (2.8.2 > 2.8.02).

No, these are not numbers put application versions. 2.8.2 is older than 2.8.18.

> 
> -- 
> Eneko Gotzon Ares
> enekogot...@gmail.com
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: how to maintain multiple active versions of a port (e.g. octave)?

[Chris Jones]

One last question … can you give me a quick idea of how much work would be 
involved in me attempting to locally implement the first approach you mentioned 
(different ports for different versions of octave). That is, starting with the 
files for the 3.8.2 revision of the octave port, what would be involved in 
creating a local octave38 port that could be installed simultaneously with the 
regular, current octave port? Am I crazy to attempt this?


Th first thing you could do is just check what the port currently 
installs. Run


> port contents octave

That will give you a list of all the files installed. You would have to 
make each and every one of those is in a location specific to its 
version, so two versions could be installed at once. You would then need 
to make sure each port using octave picks up what it needs properly. My 
guess is this is a lot of work (when I did it for root5/root6 it was a 
big deal...)


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

Re: A general upgrade question

[Chris Jones]

Hi,

I would suggest in your case, because your port list might be a little 
out of date, to not use the ./restore_ports.tcl scripts. Instead, 
manually look at your myports.txt and requested.txt files, decide which 
ports you still want and try install them one by one, with whatever 
variants you want (and are still valid for the new OS etc., as things do 
change). In my experience the list of ports you need to request is often 
not that long (use the requested.txt file) and thus this isn't as 
onerous as it might sound, and more reliable.


Chris

On 23/09/16 15:41, William H. Magill wrote:

I have two systems, an iMac and a Mac Mini.
The iMac doesn’t do much - mostly aspell, and so my update to Sierra went quite 
smoothly.

The Mac Mini on the other hand, is a bit more of a workhorse. Primarily acting 
as a web server.
And, as I updated to Sierra, I discovered to my chagrin that I had been 
practicing —If it ain’t broke, don’t fix it.
Evidently not updating any ports since I upgraded to El Capitan!
Oops.

To make a long story short.
Instead of first checking to see what kind of updating I needed to do before 
tackling the new Mac Ports, I just went ahead
and followed the migration guide.
Everything went smoothly until I hit the rebuiild phase:  ./restore_ports.tcl 
myports.txt

This command itself worked well — what happened was that the rebuild through 
lots of warning errors.
Typically of the type:

Error: p5.16-perl-ostype has been replaced by p5.22-perl-ostype; please install 
that instead.
Error: org.macports.configure for port p5.16-perl-ostype returned: obsolete port

In investigating, I noted that the command:

sudo port outdated

No installed ports are outdated.

But that this command:

sudo port obsolete

Error: Unrecognized action "port obsolete”

That behavior seems to be a bug, but I don’t know the expected behavior.

At any rate, what I was attempting to do was generate a list of those obsolete 
and therefore failed installs
to make manual installation possible.

In particular, I’m assuming that there is a parent install which included these 
as dependencies, and that if I
re-installed that, it would pick-up all of the others.
(I seem to have had a bunch of P5.16 modules installed, which should have been 
updated before I tried to begin the overall update.)

Is there an obvious way to find that parent?




T.T.F.N.
William H. Magill
# iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.12
# Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.12

mag...@icloud.com
mag...@mac.com
whmag...@gmail.com








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


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

Re: command not found

[Chris Jones]

On 02/09/16 15:05, Ignatios Athanasiadis wrote:

The files, /opt/local and /opt/local/var/macports/software exist and when I run 
echo $PATH it includes the path /opt/local/bin.
However, the file /opt/local/bin/port does not exist.
Also when I used to run open whatever.pdf file a pdf file would open. Is this a 
macports related problem as well?


Unlikely, unless you where using a macports provided PDF viewer as your 
preferred application. What application used to start ? Preview ? If so, 
then this probably nothing to do with Macports, just another side affect 
of your failed file restoration.


One thing you could do is to check the messages in Console (start the 
Console application) to see if that gives any hint as to what is happening.


Chris



I may sound silly, sorry for my ignorance.


On 2 Sep 2016, at 14:53, Ryan Schmidt  wrote:



On Sep 2, 2016, at 7:54 AM, Ignatios Athanasiadis  wrote:

Hi all,

I tried to restore some files in my mac and they were restored unsuccesfully.
Now whe I try to access macports I get a command like: command not found.
Does this mean that I have lost all my ports?

Many thanks.


This doesn't necessarily mean that anything is gone. It could just mean that 
your PATH has been reset to its default value.

Does /opt/local still exist? Does /opt/local/bin/port still exist? If so, 
proceed:

What happens if you run:

echo $PATH

Does it include /opt/local/bin? If not, fix your PATH definition in your 
~/.profile or ~/.bash_profile.


If you follow Chris' suggestion to re-run the MacPorts installer, it will 
automatically fix your PATH for you, if that was the problem. It will also 
reinstall /opt/local/bin/port and the other parts of MacPorts, without 
affecting any ports you had installed.


You can also check /opt/local/var/macports/software. That's where your 
installed ports are stored. If that directory exists and contains lots of 
stuff, then your ports are still installed.



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


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

Re: command not found

[Chris Jones]

On 02/09/16 14:20, Ignatios Athanasiadis wrote:

OK let me give more details then.
I did not use the time machine at all, it was not even configured.
Yesterday I did some work but then I figured out that I wanted to go back to 
what I had in the morning.
But the timemachine gave me the option to recover the file status I had 
yesterday morning.
When I chose some files to be recovered, the process was killed by telling me 
that the files could not be copied since I did not have authorisation for it.
Since then there are some stuff going wrong in my mac.
One of them is the macports.


If TimeMachine was not configured, why did you try and use it to go back 
? sounds like this was your error.


If you don't have any other back ups (no recent bootable clones ?) then 
it sounds like you are going to have to clean up your mess by 
reinstalling whatever is broken.


Chris



Thanks again.

On 2 Sep 2016, at 14:14, Chris Jones  wrote:


On 02/09/16 14:11, Ignatios Athanasiadis wrote:

Hi,

The command I used was : port version

Ignatios


Then yes, it looks like whatever it was you did (again, it helps to be 
specific, you really have not said what you did) has hosed your macports 
installation in someway. You can start by trying to just reinstall macports, 
following

https://www.macports.org/install.php

If you are lucky, once 'port' is returned your installed ports might be OK, but 
there is no way to know this from the information you have so far provided, so 
you might end up having to reinstall them all as well.

Chris



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

Re: command not found

[Chris Jones]

On 02/09/16 14:11, Ignatios Athanasiadis wrote:

Hi,

The command I used was : port version

Ignatios


Then yes, it looks like whatever it was you did (again, it helps to be 
specific, you really have not said what you did) has hosed your macports 
installation in someway. You can start by trying to just reinstall 
macports, following


https://www.macports.org/install.php

If you are lucky, once 'port' is returned your installed ports might be 
OK, but there is no way to know this from the information you have so 
far provided, so you might end up having to reinstall them all as well.


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

Re: command not found

[Chris Jones]

I tried to restore some files in my mac and they were restored unsuccesfully.
Now whe I try to access macports I get a command like: command not found.
Does this mean that I have lost all my ports?


would help if you told us what command you where trying to run ...
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Updating tk +quartz failed on Snow Leopard

[Chris Jones]

On 25/08/16 04:30, Kevin Walzer wrote:

On 8/24/16 5:26 AM, Mojca Miklavec wrote:


According to

http://stackoverflow.com/questions/307128/how-do-i-cast-id-to-a-float
I guess that
 scalefactor = ([[win backingScaleFactor] floatValue] == 2.0) ? 2
: 1;
instead of
 scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
should wok.

That compiles on 10.6 at least (I didn't check the actual
functionality, I don't even have GUI access to that 10.6 VM).


Unfortunately, this patch breaks the build on 10.11. clang complains
with this error:

/Users/kevin/tcl-tk-fossil/tk/unix/../macosx/tkMacOSXXStubs.c:901:18:
error:
  bad receiver type 'CGFloat' (aka 'double')

Any suggestions here? Given a choice between supporting an obsoleted
version of the OS and the current one, my choice is for the current one.


Why don't you only apply the patch when needed, i.e. when building on 
OSX 10.6, but skip it elsewhere ?




--Kevin


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

Re: Install both root5 and root6?

[Chris Jones]

Hi,

You can have both installed at once. You just cannot have both using the 
same python variant (for technical reasons in how ROOT installs in 
python support). The error message should explain this quite clearly.


So exactly what variants are you using, and what messages do you get ?

Chris

On 07/19/2016 04:51 PM, Jean-François Caron wrote:

I tried installing root6 after already having root5 installed, and I get an 
error about how the two cannot be active at once.  Isn’t this what root_select 
is for?  I mean, I can have multiple pythons installed, so why not ROOT?

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


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

Re: missing ports?

[Chris Jones]

> On 3 Jun 2016, at 7:23 pm, Ryan Schmidt  wrote:
> 
>> On Jun 1, 2016, at 10:21, Ryan Williamson  
>> wrote:
>> 
>> Hello,
>> 
>> I'm a fairly new user of MacPorts, so if this is a stupid question, please 
>> excuse the newbie in the room.
>> 
>> On Friday of last week I had the list of available ports pulled up in the 
>> 'amusements' category.
>> https://www.macports.org/ports.php?by=category&substr=amusements
>> 
>> On that day there were "tons" (yes - a very technical term) of different 
>> ports listed, but today, I see only 2.
>> I know that for example, "agree", "chef", and "cowsay" were all listed, but 
>> those are gone now.
>> 
>> Does that Ports list get updated from time to time?
>> 
>> The page also says:
>> 
>> "The MacPorts Project currently distributes 10812 ports, organized across 73 
>> different categories and available below for viewing. This form allows you 
>> to search the MacPorts software index, last updated on (unknown) at 
>> (unknown)."
>> 
>> Below the search by box is a link to view the complete port list.
>> Follow that link and it now says:
>> 
>> "The MacPorts Project currently distributes 20825 ports, organized across 83 
>> different categories and available below for viewing. This form allows you 
>> to search the MacPorts software index, last updated on 2016-05-31 at 
>> 09:00:32 America/Los_Angeles."
>> 
>> So, it does indeed appear that the list was just updated, but why the 
>> difference (10K vs 20K)
>> 
>> I do see that "agree", "chef", and "cowsay" are all listed in the 
>> TracBrowser under textproc
>> https://trac.macports.org/browser/trunk/dports?order=name#textproc
>> 
>> They still don't show up in the available ports list:
>> https://www.macports.org/ports.php?by=category&substr=textproc (note 
>> textproc)
>> 
>> Thanks for helping out a rookie.
> 
> Not your fault. A change was committed that was not compatible with the 
> currently released version of MacPorts, which broke the import script that 
> populates the database the web site uses. I've fixed it:
> 
> https://trac.macports.org/changeset/149165
> 
> It may take a few hours for the old versions of the pages to fall out of the 
> cache. 


Don't the following two lines, 33 and 34, need commenting out as well ?

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

Re: gcc-6

[Chris Jones]

On 19/05/16 13:51, René J.V. Bertin wrote:

On Thursday May 19 2016 11:22:35 René J.V. Bertin wrote:


So it seems that the only feasible things are skipping the ObjC and/or ObjC++ compilers, 
and the Java compiler. I'll try to round up my "little" experiment to assess if 
that makes a lot of difference in installation footprint.


Skipping those components gives me a destroot directory that is 185Mb big, as opposed to 
the 359Mb from the binary package for 10.9 . I must add that I build with 
optflags="-Os -march=core2", though; -Os overriding GCC's default -O2 may have 
made some difference too.

Still, a pretty significant reduction in size that might interest users who install gcc 
only because they need a Fortran compiler. Ports that used to depend simply on port:gccXY 
because they need either Java or Fortran will need to change to using a path: style 
dependency on a representative component; that should call for installation of the 
"uncut" port if that component is missing.


For me, thats not enough of a saving to warrant the general disturbance 
such a split would cause.


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

Re: JDK

[Chris Jones]

On 31/03/16 16:50, Ryan Schmidt wrote:

On Mar 31, 2016, at 10:47 AM, Abdulrahman Alshammari wrote:

On Mar 31, 2016, at 11:26 AM, Ryan Schmidt wrote:

On Mar 31, 2016, at 10:00 AM, Abdulrahman Alshammari wrote:


Someone told me that I can download JDk from macports. However, I could not 
find the any port belong to this. What I need is to update my JDK version 
without going to Oracle website.


I'm not aware of a port that provides the JDK. Why don't you want to download 
it from Oracle?


Because I want to make it as a dependency for other software. Is there any way. 
I remember your suggestion about jdk checker, but it will be better if I can 
download it.


Hmm. We have a port for oracle-instantclient, but we are not able to download 
its distfiles automatically due to restrictions imposed by the Oracle web site; 
they require agreeing to a license agreement first. So installing that port is 
somewhat inconvenient for users. I don't know if the JDK has similar 
restrictions. In any case, the JDK probably needs to install into system 
locations, so it would not be suitable for installing via a port. I think we 
just expect the user to install the JDK manually. The JDK used to be part of OS 
X, so it was a non-issue, and we haven't really developed a better strategy now 
that JDK is separate.



I think given the nature of the JDK is really is not something we want 
macports installing automatically for a user. I for one would want to be 
made very aware when its required. So I think really the right thing to 
do here is to just check if it is available, and if not issue a message 
to the user telling them what to do to install it themselves (at which 
point they can decide if they really want the port that requires it...).


Chris




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


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

Re: libgcc fails to build

[Chris Jones]

You have been told several times you need to clean the *failing* port, which is 
not xsane but libgcc Please run

> sudo port clean libgcc
> sudo port install libgcc

and then post the *complete* log you get…

On 19 Mar 2016, at 5:03 pm, [ftp83plus] mailto:ges...@ftp83plus.net>> wrote:

> Hello all, 
> 
> this is a log of failure of libgcc after cleaning xsane and trying to install 
> it again:
> 
> http://pastebin.com/H0rQ7M03 
> 
> Any idea what would cause the failure?
> 
> 
> 
> 
> El 2016-03-17, a las 15:35, Ryan Schmidt escribió:
> 
>> 
>> On Mar 17, 2016, at 2:21 PM, [ftp83plus] > > wrote:
>> 
>>> Indeed its is not a clean attempt as I tried many times. The first failure 
>>> was a non-specific segmentation fault, so I restarted the process.
>> 
>> Before reporting a problem, always clean and try again. An unclean build 
>> attempt can, in some cases, itself be the cause of a build failure.
>> 
>> Segmentation faults leave behind crash logs in 
>> Library/Logs/DiagnosticReports which may provide further insight.
>> 
>> 
>>> On my previous install of Macports, I didn't experience any issue 
>>> installing xsane, but I didn't performed the libcxx update back then.
>> 
>> Let's be clear that at this point, xsane is not involved. The build failure 
>> is in libgcc.
>> 
>> It's certainly possible that using libc++ instead of libstdc++ is 
>> contributing to the build failure; libc++ was, after all, not tested by most 
>> software developers on the OS you're using, and compiling a compiler is 
>> certainly a complicated proposition. However, at this point we don't know 
>> what's causing your build failure.
>> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org 
> 
> https://lists.macosforge.org/mailman/listinfo/macports-users 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: QEMU on Powerbook G4 running 10.5.8

[Chris Jones]

Then i guess you have your answer ;)

> On 14 Mar 2016, at 4:34 pm, John T. Chung  wrote:
> 
> I did try that command a while back:
> 
> It gives this error during the build:
> 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_emulators_qemu-usermode/qemu-usermode/work/qemu-0.9.0/darwin-user/signal.c:56:
> error: storage size of `target_sigaltstack_used' isn't known
> make[1]: *** [signal.o] Error 1
> make: *** [subdir-i386-darwin-user] Error 2
> sh-3.2#
> 
> Line 56 contains this:
> 
> struct sigaltstack target_sigaltstack_used = {
> 0, 0, SA_DISABLE
> };
> 
> 
>> On Tue, Mar 15, 2016 at 12:32 AM, Chris Jones  
>> wrote:
>> 
>> Just try to install it and see what happens
>> 
>> > sudo port install qemu-usermode
>> 
>>> On 14 Mar 2016, at 3:52 pm, John T. Chung  wrote:
>>> 
>>> OK thanks, sorry to be dense, so could I install that version on a PPC mac?
>>> 
>>> # port install qemu-usermode @0.9.0
>>> 
>>> ?
>>> 
>>>> On Mon, Mar 14, 2016 at 11:42 PM, Rainer Müller  
>>>> wrote:
>>>> On 2016-03-14 15:23, John T. Chung wrote:
>>>> > what's the last version which supports OSX? Could I install an earlier
>>>> > version?
>>>> 
>>>> I think it would be the one in the ports tree:
>>>> 
>>>> $ port info qemu-usermode
>>>> qemu-usermode @0.9.0 (emulators)
>>>> 
>>>> Rainer
>>>> 
>>>> PS: Please keep the mailing list in CC.
>>> 
>>> 
>>> 
>>> -- 
>>> John Chung
>>> Technology Architect
>>> Nyquest Consulting
>>> http://www.nyquest.com
>>> Mobile 419.464.9637 Office: 419.973.9072
>>> ___
>>> macports-users mailing list
>>> macports-users@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-users
> 
> 
> 
> -- 
> John Chung
> Technology Architect
> Nyquest Consulting
> http://www.nyquest.com
> Mobile 419.464.9637 Office: 419.973.9072
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Trying to execute LibcxxOnOlderSytems (2nd ed.)

[Chris Jones]

> On 14 Mar 2016, at 12:49 am, [ftp83plus]  wrote:
> 
> I thought I done that with :
> 
>> sudo port clean ld64-136
>> and
>> sudo port clean libcxx
>> 
>> as ld54-136 failed to compile as a dependency of libcxx. Received:
>> 
>> Error: Failed to install ld64-136
>> Please see the log file for port ld64-136 for details:
>> 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ld64/ld64-136/main.log
>> Error: The following dependencies were not installed: clang-3.4 ld64 
>> ld64-136 libcxxab
> 
> 
> After correcting these lines in the macports.conf file following Ryan's 
> advice:
> 
> # Whether MacPorts should automatically run rev-upgrade after upgrading
> # ports.
> #revupgrade_autorun yes
> 
> # Whether rev-upgrade should automatically rebuild ports with broken
> # linking or merely report the breakage. Supported values are "report"
> # and "rebuild".
> revupgrade_mode report
> 
> The last line originally read:
> #revupgrade_mode  rebuild
> 
> ld64-136 build log is there: http://pastebin.com/rJ95ZwK9
> libcxx build log is there: http://pastebin.com/7DZGYGCV
> Both logs were updated at the same time, so I posted them both.
> 
> I don't see the "Skipping complete" anymore in the logs as Ryan said, but the 
> first error reads:
> :info:build src/ld/parsers/lto_file.cpp:36:25: error: unordered_set: No such 
> file or directory
> 
> Could it be that some important file is missing or wasn't fetched properly?


Unordered_set is only available in C++11, which the ancient gcc 4.2 compiler 
being used will not support... 
> 
> 
> 
>> El 2016-03-13, a las 16:11, Chris Jones escribió:
>> 
>> 
>> 
>>> On 13 Mar 2016, at 7:02 pm, [ftp83plus]  wrote:
>>> 
>>> Ok, thanks for specifying. 
>>> 
>>> Why does it fail, now?
>> 
>> Because you have not changed anything... You are simply explicitly 
>> specifying some options identical to the defaults... You need to follow the 
>> advice Ryan has already given you...
>> 
>>> 
>>>> El 2016-03-13, a las 12:30, Brandon Allbery escribió:
>>>> 
>>>>> On Sun, Mar 13, 2016 at 5:18 AM, [ftp83plus]  wrote:
>>>>> Now it's getting even more confusing for me: why would a commented out 
>>>>> line still be run? 
>>>> 
>>>> The comment is showing you what the default action is if you don't say 
>>>> anything.
>>>> 
>>>> -- 
>>>> brandon s allbery kf8nh   sine nomine 
>>>> associates
>>>> allber...@gmail.com  
>>>> ballb...@sinenomine.net
>>>> unix, openafs, kerberos, infrastructure, xmonad
>>>> http://sinenomine.net
>>> 
>>> ___
>>> macports-users mailing list
>>> macports-users@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-users
> 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Trying to execute LibcxxOnOlderSytems (2nd ed.)

[Chris Jones]

> On 13 Mar 2016, at 7:02 pm, [ftp83plus]  wrote:
> 
> Ok, thanks for specifying. 
> 
> Why does it fail, now?

Because you have not changed anything... You are simply explicitly specifying 
some options identical to the defaults... You need to follow the advice Ryan 
has already given you...

> 
>> El 2016-03-13, a las 12:30, Brandon Allbery escribió:
>> 
>>> On Sun, Mar 13, 2016 at 5:18 AM, [ftp83plus]  wrote:
>>> Now it's getting even more confusing for me: why would a commented out line 
>>> still be run? 
>> 
>> The comment is showing you what the default action is if you don't say 
>> anything.
>> 
>> -- 
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com  ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Is there a good version of Time Machine?

[Chris Jones]

Hi,

On 29/02/16 11:35, Ryan Schmidt wrote:

Backups to a locally attached disk work fine. I've used this for years without 
backups becoming corrupted.

Backups to an Apple Time Machine over the network, whether over Ethernet or 
wireless, work fine. I've used this for years without backups becoming 
corrupted.

Backups to Server.app's Time Machine Server over the network, whether over 
Ethernet or wireless, should work fine, since it's a feature Apple offers and 
charges money for, but I have not personally used this yet.


I concur. I've used all three of the methods above and have *never* had 
problems with corruptions with them.




Backups to a non-Apple network-attached storage (NAS) device that claims to 
have Time Machine support will become corrupted over time, with the likelihood 
increasing greatly if backups are attempted over wireless. I have used this for 
years, and have had to start my backup over from scratch after Time Machine 
declared it corrupted more times than I can recall. Non-Apple implementations 
of AFP (i.e. netatalk) are simply not sufficiently compatible with Apple's 
implementation to work reliably with Time Machine, no matter what the 
third-party vendor trying to sell it to you says.


Again, I agree. For a while I used a WD NAS drive as my TM backup drive, 
and these more than once got corrupted and the backups had to be started 
from scratch...


Chris


My recommendation is to alternate backups between two different disks. That way 
if you lose one backup you still have the other. You could even keep them in 
different locations, i.e. one at home and one at work. Even if you only have 
one backup and lose it, that's not a problem because it's a backup; you still 
have the original.

-Ryan



On Feb 28, 2016, at 7:26 PM, [ftp83plus]  wrote:

I learnt the hard way that TM's efficiency is not necessarily what you expect 
it to be. Corruption from power loss on an external drive three times, surprise 
corruption on Linux server running AFP 3.4-compatible Netatalk two times in 3 
months.

On directly-connected hard drives, there are very few issues.
Over the network and especially wireless, just a small glitch can corrupt the 
backups.
Even Apple's own hardware doesn't necessarily prevent catastrophic failures.

Reading forums here and there, it seems there's no relationship between 
connected equipment and risk for Time Machine backups. I understood TM is 
basically so complex that it can't be repaired, no matter what some anecdotic 
evidence show.

So to answer your question Dave Horsfall, I don't think there's a "good" 
version of TM. It's all sweet while it works, but when it fails, it's usually the 
nastiest way you could expect.

Pat

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


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

Re: Is there a good version of Time Machine?

[Chris Jones]

On 22/02/16 12:38, Bachsau wrote:



Am 22.02.2016 um 08:52 schrieb Dave Horsfall :

I ask because either it won't back up .dotfiles, or I've forgotten to
click one of those box thingies...


Time Machine can do complete system restores, which is why it needs to backup 
every file. However, it could be possible that it doesn't display them in 
history. I would try Googling and poking around in some plist files.


That would be my guess. Plenty of information on the web if you take the 
time to do a simple search. Take a look at for instance


http://www.cnet.com/uk/how-to/how-to-access-hidden-files-to-restore-in-time-machine/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Guile is broken, again...

[Chris Jones]

Just compress the log file before posting it. It will be a fraction of 
its original size then...


On 10/02/16 05:14, Dave Horsfall wrote:

Sigh...  Looks like I have to shorten my messages for this list, even
though we're asked to include as much info as possible...

I don't like publishing my personal site, but said log can be found over
on www.horsfall.org/Guile.log


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

Re: dolfin on el capitan

[Chris Jones]

On 09/02/16 00:31, Gideon Simpson wrote:

The log file is 5 megs, should I open a new ticket and post it to the
site? Or send it to the list serve?


whatever you do compress the log file first, using bzip2 or similar. It 
will then be a lot smaller.




-gideon


On Feb 8, 2016, at 7:30 PM, Brandon Allbery mailto:allber...@gmail.com>> wrote:


On Mon, Feb 8, 2016 at 7:27 PM, Gideon Simpson
mailto:gideon.simp...@gmail.com>> wrote:

:info:build [ 14%] Built target vtkCommon
:info:build make[1]: Leaving directory

`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vtk5/vtk5/work/VTK5.10.1'
:info:build make: *** [all] Error 2


Full log please; the above is an independent branch of a parallel
build finishing, then make exiting because all branches independent of
the failing one have completed.

--
brandon s allbery kf8nh   sine nomine
associates
allber...@gmail.com 
ballb...@sinenomine.net 
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net





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


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

Re: mac ports on mac ox x 10.10.5

[Chris Jones]

On 15/12/15 13:19, Mahendra Mundru wrote:

Hi all,
I installed x code 7.2, command line tools and
I followed the instructions at https://www.macports.org/install.php

when i try to selfupdate

38c98607ad02:~ mandru$ sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org
: Operation timed out (60)
rsync error: error in socket IO (code 10) at
/SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after
rsync://rsync.macports.org/release/tarballs/base.tar

/opt/local/var/macports/sources/rsync.macports.org/release/tarballs

Exit code: 10
Error: Error synchronizing MacPorts sources: command execution failed
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing
MacPorts sources: command execution failed


Looks like your local network is blocking rsync. Follow up with your 
local system admin. Also see


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

for alternatives.




when i try to install

38c98607ad02:~ mandru$ sudo port install freetype glib2 cairo
Password:
Error: Port freetype not found

Can someone help me with this to solve?


Probably a result of the above rsync issue. Fix that first.

Chris



*Thanks & Regards,*
*Mahendra Mundru,*
*Software Engineer*


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


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

Re: error upgrading gcc48 port

[Chris Jones]

> On 1 Nov 2015, at 5:13 p.m., Fabrizio Salvatore 
>  wrote:
> 
> I simply did a port upgrade outdated. after I moved to the new OS... :-(

Then, as i already asked, which port was being upgraded just before the 
installation of gcc48 was triggered ? The output should tell you this. Just 
post it all if you cannot work it out yourself.

> 
>> On 1 November 2015 at 16:53, Marius Schamschula  
>> wrote:
>> Fabricio,
>> 
>> Unfortunately, yes.
>> 
>> Plan B: You have to find the port(s) that require gcc. Most likely were are 
>> looking for another port that needs Fortran.  Given that you are a 
>> scientist, that could mean any number of candidates.
>> 
>> What were you trying to install when your machine attempted to install gcc48?
>> 
>>> On Nov 1, 2015, at 10:35 AM, Fabrizio Salvatore 
>>>  wrote:
>>> 
>>> Hi Marius,
>>> 
>>> I see the following:
>>> 
>>> sudo port dependents gcc48
>>> Password:
>>> Error: Registry error: gcc48 not registered as installed.
>>> 
>>> Do I have it installed in order to check dependencies?
>>> 
>>> Cheers,
>>> 
>>> fab
>>> 
>>> -- 
>>> +++
>>> Dr Fabrizio Salvatore|e-mail: p.f.salvat...@sussex.ac.uk
>>> Department of Physics and Astronomy, University of Sussex,
>>> Brighton, Sussex, BN1 9QH, United Kingdom
>>> Tel.:  +44 (0)1273 67 8749; Fax: +44 (0)1273 67 8068
>>> http://epp.phys.susx.ac.uk/epp/FabrizioSalvatore
>>> facebook.com/p.fabrizio.salvatore
>>> +++
>> 
>> Marius
>> --
>> Marius Schamschula
> 
> 
> 
> -- 
> +++
> Dr Fabrizio Salvatore|e-mail: p.f.salvat...@sussex.ac.uk
> Department of Physics and Astronomy, University of Sussex,
> Brighton, Sussex, BN1 9QH, United Kingdom
> Tel.:  +44 (0)1273 67 8749; Fax: +44 (0)1273 67 8068
> http://epp.phys.susx.ac.uk/epp/FabrizioSalvatore
> facebook.com/p.fabrizio.salvatore
> +++
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Command Line Tools warning

[Chris Jones]

On 30/10/15 13:21, Brethen, Mark Douglas. (MSFC-ES22)[ESSSA] wrote:

Did that.

Is it possible to reinstall 6.2,


https://developer.apple.com/downloads/

you probably want to reinstall command line tools and Xcode...

 or should I go ahead and install 7.1?



On Oct 30, 2015, at 2:31 AM, Chris Jones  wrote:


Try starting Xcode, and make sure in the preferences section for updates 
everything is up to date. Also accept any licenses etc.

On 30/10/15 05:30, Mark Brethen wrote:

I don’t plan on installing El Capitain for a while. Macports website says 6.1 
or later for Yosemite. I have 6.2.

xcode-select -print-path
/Applications/Xcode.app/Contents/Developer

So that’s not it.

I’m stumped.


On Oct 30, 2015, at 12:09 AM, Stephen J. Butler  
wrote:

I think 6.2 is too old for El Capitain (and maybe even for Yosemite). You need 
to upgrade to 7 or 7.1 for El Capitain.

On Thu, Oct 29, 2015 at 11:58 PM, Mark Brethen  wrote:
I upgrading to Yosemite and followed the macports migration document. Now, 
though the 'port install' command succeeds, I get the following warning 
whenever I install a port:

Warning: The Xcode Command Line Tools don't appear to be installed; most ports 
will likely fail to build.

I have Xcode 6.2 and installed the Command Line Tools using 'xcode-select 
—install’

Have overlooked something?


Mark




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





Mark




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


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


Thanks,

Mark

Mark D. Brethen
Stress Analyst
DSI - Jacobs
Marshall Space Flight Center
Bldg 4203, Cube 4321
Work: (256) 961-2147
Email: mark.bret...@nasa.gov
Web: http://www.davisdsi.com/





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

Re: error upgrading gcc48 port

[Chris Jones]

On 30/10/15 12:26, Fabrizio Salvatore wrote:

I see that there are two ports related to gcc48, one of which is active:

--->  The following versions of gcc48 are currently installed:
--->  gcc48 @4.8.2_2
--->  gcc48 @4.8.3_3 (active)

How do I remove both and make gcc49 the default one?


specify the version when uninstalling

> sudo port uninstall gcc48@4.8.2_2

etc.

( gcc49 is a different port to gcc48 anyway, and can be installed along 
side, as can the gcc5 port which is the recommended default version now 
anyway )




Thanks for your help!

Fab



On 29 October 2015 at 22:41, Eneko Gotzon mailto:enekogot...@gmail.com>> wrote:


On Thu, Oct 29, 2015 at 10:43 PM, Fabrizio Salvatore
mailto:p.fabrizio.salvat...@googlemail.com>> wrote:

Is there any instruction anywhere on how to do that?


Port uninstall .


--
Eneko Gotzon Ares
enekogot...@gmail.com 




--
+++
Dr Fabrizio Salvatore|e-mail: p.f.salvat...@sussex.ac.uk

Department of Physics and Astronomy, University of Sussex,
Brighton, Sussex, BN1 9QH, United Kingdom
Tel.:  +44 (0)1273 67 8749; Fax: +44 (0)1273 67 8068
http://epp.phys.susx.ac.uk/epp/FabrizioSalvatore
facebook.com/p.fabrizio.salvatore

+++

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

Re: Command Line Tools warning

[Chris Jones]

Try starting Xcode, and make sure in the preferences section for updates 
everything is up to date. Also accept any licenses etc.


On 30/10/15 05:30, Mark Brethen wrote:

I don’t plan on installing El Capitain for a while. Macports website says 6.1 
or later for Yosemite. I have 6.2.

xcode-select -print-path
/Applications/Xcode.app/Contents/Developer

So that’s not it.

I’m stumped.


On Oct 30, 2015, at 12:09 AM, Stephen J. Butler  
wrote:

I think 6.2 is too old for El Capitain (and maybe even for Yosemite). You need 
to upgrade to 7 or 7.1 for El Capitain.

On Thu, Oct 29, 2015 at 11:58 PM, Mark Brethen  wrote:
I upgrading to Yosemite and followed the macports migration document. Now, 
though the 'port install' command succeeds, I get the following warning 
whenever I install a port:

Warning: The Xcode Command Line Tools don't appear to be installed; most ports 
will likely fail to build.

I have Xcode 6.2 and installed the Command Line Tools using 'xcode-select 
—install’

Have overlooked something?


Mark




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





Mark




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


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

Re: gcc49 vs gcc48

[Chris Jones]

On 30/10/15 01:18, Brandon Allbery wrote:


On Thu, Oct 29, 2015 at 9:15 PM, David Strubbe mailto:dstru...@macports.org>> wrote:

The problem that was being mentioned here is that gcc48 doesn't
build. That should not imply that ports already built with gcc48
have any problem. So there is no need to recompile anything. Just
when building new ports use a different version not gcc48.


But there are ports (and I believe one of them was at the start of this
thread) that bake specific compilers into themselves, and therefore have
compiler-specific variants.

That said, the fix for this is to look for any +gcc48 on ports to be
installed and replace it with +gcc49. (Ports that had +gcc48 as default
variant *should* use a different compiler already; if not, file a bug.)


or better yet, use +gcc5, to use the most recent stable gcc release.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: error upgrading gcc48 port

[Chris Jones]

Hi,

Gcc 4.8 currently does not build on OSX 10.11.

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

I recommend uninstalling it, and any ports that need it, and reinstall them 
using a new gcc version.

Chris



> On 29 Oct 2015, at 10:10 a.m., Fabrizio Salvatore 
>  wrote:
> 
> Hi all,
> 
> I have tried yesterday to upgrade the outdated ports and I have an error, 
> which I report below. Does anyone have the same problem? I have the most 
> recent version of XCode and El Capita OS.
> 
> Thanks!
> 
> Fab
> 
> Error: org.macports.build for port gcc48 returned: command execution failed
> Please see the log file for port gcc48 for details:
> 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc48/gcc48/main.log
> Error: Unable to upgrade port: 1
> (attached is the logfile)
> 
> 
> -- 
> +++
> Dr Fabrizio Salvatore|e-mail: p.f.salvat...@sussex.ac.uk
> Department of Physics and Astronomy, University of Sussex,
> Brighton, Sussex, BN1 9QH, United Kingdom
> Tel.:  +44 (0)1273 67 8749; Fax: +44 (0)1273 67 8068
> http://epp.phys.susx.ac.uk/epp/FabrizioSalvatore
> facebook.com/p.fabrizio.salvatore
> +++
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: darwin14 - darwin15 issue

[Chris Jones]

Follow the migration guide

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

On 27/10/15 08:33, Paolo Denti wrote:

Selfupdated macports  for el capitain, then attempting to upgrade outdated.
Error for gcc48 and dependencies.
darwin14 platform, darwin15 platform requested, see below:

The following installed ports are outdated:
gcc48  4.8.5_0 < 4.8.5_0  (platform darwin 14 !=
darwin 15)
libxml22.9.2_2 < 2.9.2_2  (platform darwin 14 !=
darwin 15)
m4 1.4.17_0 < 1.4.17_0  (platform darwin 14
!= darwin 15)
openssl1.0.2d_0 < 1.0.2d_0  (platform darwin 14
!= darwin 15)
pkgconfig  0.28_0 < 0.28_0  (platform darwin 14 !=
darwin 15)
python2_select 0.0_1 < 0.0_1  (platform darwin 14 !=
darwin 15)
python27   2.7.10_3 < 2.7.10_3  (platform darwin 14
!= darwin 15)
python_select  0.3_5 < 0.3_6
sqlite33.8.11.1_0 < 3.8.11.1_0  (platform darwin
14 != darwin 15)
xmahjongg  3.7_2 < 3.7_2  (platform darwin 14 !=
darwin 15)
xorg-bigreqsproto  1.1.2_0 < 1.1.2_0  (platform darwin 14 !=
darwin 15)
xorg-inputproto2.3.1_0 < 2.3.1_0  (platform darwin 14 !=
darwin 15)
xorg-kbproto   1.0.6_0 < 1.0.7_0
xorg-libice1.0.9_0 < 1.0.9_0  (platform darwin 14 !=
darwin 15)
xorg-libpthread-stubs  0.3_0 < 0.3_0  (platform darwin 14 !=
darwin 15)
xorg-libsm 1.2.1_0 < 1.2.1_0  (platform darwin 14 !=
darwin 15)
xorg-libX111.6.3_0 < 1.6.3_0  (platform darwin 14 !=
darwin 15)
xorg-libXau1.0.8_0 < 1.0.8_0  (platform darwin 14 !=
darwin 15)
xorg-libxcb1.11_1 < 1.11.1_0
xorg-libXdmcp  1.1.2_0 < 1.1.2_0  (platform darwin 14 !=
darwin 15)
xorg-util-macros   1.19.0_0 < 1.19.0_0  (platform darwin 14
!= darwin 15)
xorg-xcb-proto 1.11_1 < 1.11_1  (platform darwin 14 !=
darwin 15)
xorg-xcmiscproto   1.2.2_0 < 1.2.2_0  (platform darwin 14 !=
darwin 15)
xorg-xextproto 7.3.0_0 < 7.3.0_0  (platform darwin 14 !=
darwin 15)
xorg-xf86bigfontproto  1.2.0_0 < 1.2.0_0  (platform darwin 14 !=
darwin 15)
xorg-xproto7.0.27_1 < 7.0.28_0
xorg-xtrans1.3.5_0 < 1.3.5_0  (platform darwin 14 !=
darwin 15)

Any suggestion?



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


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

Re: Migration instruction site is down

[Chris Jones]

Both links work just fine for me... must be your end.

On 21/10/15 08:15, Ryan Crocker wrote:

neither of those links are working.  I just get the beachball and
nothing happens.  I’ve tried on two different routers, computers and my
phone. Though the text version of:

http://webcache.googleusercontent.com/search?q=cache:https://trac.macports.org/wiki/Migration&strip=1&vwsrc=0

will load up the navigation page, but none of the links work.

Ryan Crocker
Postdoctoral Researcher
University of Vermont
Dept. of Mechanical Engineering
315-212-7331
rya...@gmail.com 
rcroc...@uvm.edu





On Oct 20, 2015, at 5:24 PM, Rainer Müller mailto:rai...@macports.org>> wrote:

On 10/21/2015 01:26 AM, Ryan Crocker wrote:

I just switched to El Captain and I wanted to migrate macports over
to that OS.
I tried:

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

but that site is down.  Does anyone have the instructions or another
site where
they are posted.


Sorry for the inconvenience. Please try one of these:

https://webcache.googleusercontent.com/search?q=cache:https://trac.macports.org/wiki/Migration

https://web.archive.org/web/*/https://trac.macports.org/wiki/Migration

Rainer




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


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

Re: about fragmentation (of free disk space)

[Chris Jones]

Hi

> On 10 Oct 2015, at 7:45 p.m., Daniel J. Luke  wrote:
> 
>> On Oct 10, 2015, at 7:28 AM, René J.V. Bertin  wrote:
>> HFS+ is supposed to contain algorithms that limit file fragmentation, but 
>> without a background process that moves files (or file blocks), it cannot 
>> prevent free space fragmentation, just limit it. On a spinning disks that 
>> can become a limit on performance (I presume that theoretically the same 
>> applies to SSDs too)
> 
> random access time for a SSD is 1-3 orders of magnitude less than for a 
> rotational drive.
> 
> As with anything, you need to measure ‘real world use’ to be certain, but 
> it’s probably not an issue for SSDs at all.


Exactly. Also, access time does not change depending in what was accessed last, 
because nothing is physically moving as it is in a traditional HD. This is why 
fragmentation hurts HDs but is really not an issue  in SSDs. In fact, moving 
data around to 'fix' fragmentation (aka defraging) probably does more harm than 
good. The best you can do with an SSD is make sure trim is enabled, and then 
just let the drive sort itself out...

> 
>> and any process that requires contiguous files will ultimately fail if those 
>> cannot be obtained, regardless the underlying medium if it doesn't take that 
>> aspect into account.
> 
> Which API lets you know if you have a contiguous file or not / how do you 
> ‘require’ a contiguous file on disk?
> 
>> Any thoughts on this, regardless of whether free disk space fragmentation is 
>> a real-world issue or not?
> 
> maybe something like hfsdbug could help you determine if it’s something to 
> worry about or not?
> 
> http://osxbook.com/software/hfsdebug/
> 
> -- 
> Daniel J. Luke
>
> ++ 
> | * dl...@geeklair.net * |
>   
> | *-- http://www.geeklair.net -* |
>   
> ++ 
> |   Opinions expressed are mine and do not necessarily   |
>   
> |  reflect the opinions of my employer.  |
>   
> ++
> 
> 
> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Incompatible library version

[Chris Jones]

Do not set DYLD_LIBRARY_PATH, doing so is a bad idea. If MatLab requires 
this (is it really needed ??, I am quite surprised this is done into 
internals inside an application in /Applications), report this as a bug 
against MatLab...


On 08/10/15 08:21, Michel Perez wrote:

Jeremy,
Indeed, the DYLD_LIBRARY_PATH is set… by MATLAB !
mperez$ set | grep DYLD
DYLD_LIBRARY_PATH=/Applications/MATLAB_R2015a.app/bin/maci64:/Applications/MATLAB_R2015a.app/sys/os/maci64:/usr/local/qwt-6.0.1/lib:
Will I have to choose between matlab and macport?
What should I do?
Michel

On 08 Oct 2015, at 07:45, Jeremy Sequoia mailto:jerem...@apple.com>> wrote:

Yep, it looks like you probably have DYLD_INSERT_LIBRARIES or
DYLD_LIBRARY_PATH set.  Don't do that ;).

To confirm, run 'set | grep DYLD'

Check your shell init scripts.

Sent from my iPhone...

On Oct 7, 2015, at 22:12, Michel Perez mailto:michel.pe...@insa-lyon.fr>> wrote:


Thanks Jeremy for your reply
The output of otool command is:

mperez$ otool -L /opt/local/lib/libtiff.5.dylib
/opt/local/lib/libtiff.5.dylib:
/opt/local/lib/libtiff.5.dylib (compatibility version 8.0.0, current
version 8.4.0)
/opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current
version 8.1.0)
/opt/local/lib/libjpeg.9.dylib (compatibility version 11.0.0, current
version 11.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)

I do not know if I shot myself in the foot, but it hurts: not a
single macport program works !
Thanks again,
Michel

On 08 Oct 2015, at 01:28, Jeremy Huddleston Sequoia
mailto:jerem...@apple.com>> wrote:

It looks like you either have an outdated version of libtiff or are
using DYLD_INSERT_LIBRARIES to shoot yourself in the foot.

What's the output of 'otool -L /opt/local/lib/libtiff.5.dylib'?

--Jeremy


On Oct 7, 2015, at 07:06, Michel Perez mailto:michel.pe...@insa-lyon.fr>> wrote:

Hello,

I got the Incompatible library version error whatever the software
I lauch.
I tried to reinstall macport but still get the following error:

dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
 Referenced from:
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_xrc-3.0.dylib
 Reason: Incompatible library version:
libwx_osx_cocoau_xrc-3.0.dylib requires version 8.0.0 or later, but
libtiff.5.dylib provides version 6.0.0
Trace/BPT trap: 5

Thanks for your help

*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr 
Web: http://michel.perez.net.free.fr 
*

___
macports-users mailing list
macports-users@lists.macosforge.org

https://lists.macosforge.org/mailman/listinfo/macports-users




*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr 
Web: http://michel.perez.net.free.fr 
*



*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr 
Web: http://michel.perez.net.free.fr
*



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


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

Re: Darwin Version

[Chris Jones]

> On 2 Oct 2015, at 2:33 p.m., Bachsau  wrote:
> 
> 
>> Am 02.10.2015 um 15:24 schrieb Brandon Allbery :
>> 
>> If you don't like it, don't use OS X, because Apple is not going to change. 
>> It will break stuff as it sees fit. This is the price of living in Apple's 
>> world.
> 
> 
> Maybe. Seems like I'm just not getting what is technically causing these 
> problems. When libraries change, and it breaks a particular application, why 
> can't I recompile just that? And why would the build of a newly installed 
> port fail, just because there are other ports installed that were compiled 
> against older system libraries?

Oh sure, there may well be some ports, or combination of ports that could carry 
on working just fine. Its just the 'clean slate' approach as per the migration 
instructions are the only way to make sure all the potential issues are removed.

Frankly i do not see what the issue is with following the migration guide. Even 
on my old late 2008 MBPro it only took a few hours or so to do the complete 
rebuild. 

Chris

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

Re: Versions in ports

[Chris Jones]

On 14/09/15 17:39, Harald Hanche-Olsen wrote:

Chris Jones wrote:


[…] A normal upgrade will first upgrade all the ports
dependencies, as required, such that you end up with a consistent
updated port. Only if you specifically disable this can you get into a
mess.


But if ports A and B both depend on port C, and you run “port upgrade
A”, then it will upgrade C as well, if necessary, but then what about B?

Concerns like this is one reason why I never upgrade ports individually,
but rather just run “port upgrade outdated” instead.


I also update all ports at once.

However, your concern above will be caught by the rev-upgrade mechanism.

Chris



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

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

Re: Versions in ports

[Chris Jones]

On 14/09/15 15:49, Artur Szostak wrote:

Then why not protect all other upgrade operations with a -f | --force
flag, except when upgrading everything? It seems much too easy at the
moment to perform an upgrade operation that has a good chance of leading
to an inconsistent state.


no it will not. A normal upgrade will first upgrade all the ports 
dependencies, as required, such that you end up with a consistent 
updated port. Only if you specifically disable this can you get into a mess.





*From:* Brandon Allbery [allber...@gmail.com]
*Sent:* 14 September 2015 16:32
*To:* Artur Szostak
*Cc:* Macports Users ‎[macports-users@lists.macosforge
*Subject:* Re: Versions in ports

On Mon, Sep 14, 2015 at 10:22 AM, Artur Szostak
mailto:aszos...@partner.eso.org>> wrote:

To me, it feels like the MacPorts documentation is misleading the
end user to believe that upgrading/downgrading individual packages
is a routine and safe procedure, when my experience tells me
otherwise. Can anyone point me to the reason behind these design
decisions?


I suspect you are reading experience with something like yum or apt-get
into a ports-based system. MacPorts gets most of its behavior from BSD
ports/pkgsrc, and the documentation tends to assume that you are
familiar with that.

--
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net


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


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

Re: XRG has been updated to work on Yosemite

[Chris Jones]

How very timely of them, given OSX 10.11 might well be announced rather 
imminently..


On 09/09/15 16:46, Manfred Antar wrote:

XRG has been updated to work on Yosemite
The binary is available at the developer’s website.
The source code is also available there, It would be nice to be able to build 
it from source

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


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

Re: OS X 10.11 status

[Chris Jones]

> On 19 Aug 2015, at 5:49 pm, "semaphor...@yahoo.com"  
> wrote:
> 
> It's not just a matter of compiling, but compilation TIME. It takes 
> significantly longer than it would on 10.10. On the other hand, my test is 
> done on a hardware machine, not a VM one, so I guess it's just another case 
> of "it (doesn't) work on my machine.

Something is indeed up with your machine i would say. Compilation times in my 
vm compare very favourable to those in the host machine, running 10.10.

> 
> Enviado desde mi iPhone
> 
>> El 2015-08-19, a las 11:53, Dominik Reichardt  escribió:
>> 
>> 
>> 
>>> Am 19.08.2015 um 17:18 schrieb Chris Jones :
>>> 
>>> 
>>> 
>>>>> On 19/08/15 16:13, C.T. wrote:
>>>>> 
>>>>> Experience: 10.11 is still in beta, and it shows. With XCode beta, expect 
>>>>> HOURS of compilations for a mere update, and many manual operations since 
>>>>> MacPorts doesn’t yet recognizes El Capitan
>>> 
>>> I disagree on two of the three points.
>>> 
>>> Yes, you should expect to compile all ports as there are no binary archives 
>>> as of yet.
>>> 
>>> However, as long as you have the correct Xcode installed (the latest beta) 
>>> and have installed MacPorts from source, it works just as smoothly in a VM 
>>> where I am testing it as in the host OSX10.10 machine.
>>> 
>>> Yes its beta, but I've not had any significant issues in the limited 
>>> playing I have done in the VM ...
>>> 
>>> Chris
>> 
>> Thanks, 
>> yes, I know it is beta - that doesn't put me off very much, I've used 
>> previous betas since 10.7, so I know what to expect. Mostly at this stage it 
>> was ok.
>> Whether I migrate during the beta and compile everything or later with the 
>> finished system, doesn't matter much to me anyway. Since I tend to need 
>> +universal or some other variant, I need to compile most ports instead of 
>> just getting the binaries. Also I'm not using that many ports, Gimp is the 
>> one with the biggest dependencies...
>> 
>> So, seems like I'll backup and jump...
>> 
>> Thanks again
>> 
>> 
>> 
>>>>> 
>>>>>> El 19 ago 2015, a las 4:41, Dominik Reichardt  
>>>>>> escribió:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I’m itching to switch but often need MacPorts. Do any of you have 
>>>>>> experience yet with it *AND* MacPorts?
>>>>>> 
>>>>>> In previous switches, I switched by using the development version of 
>>>>>> MacPorts and following the migration steps of any major OS X upgrade, 
>>>>>> still the way to go?
>>>>>> 
>>>>>> 
>>>>>> Take care
>>>>>> 
>>>>>> Dom
>>>>>> ___
>>>>>> macports-users mailing list
>>>>>> macports-users@lists.macosforge.org
>>>>>> https://lists.macosforge.org/mailman/listinfo/macports-users
>>>> 
>>>> ___
>>>> macports-users mailing list
>>>> macports-users@lists.macosforge.org
>>>> https://lists.macosforge.org/mailman/listinfo/macports-users
>>> ___
>>> macports-users mailing list
>>> macports-users@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-users
>> ___
>> macports-users mailing list
>> macports-users@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: OS X 10.11 status

[Chris Jones]

On 19/08/15 16:13, C.T. wrote:



Experience: 10.11 is still in beta, and it shows. With XCode beta, expect HOURS 
of compilations for a mere update, and many manual operations since MacPorts 
doesn’t yet recognizes El Capitan


I disagree on two of the three points.

Yes, you should expect to compile all ports as there are no binary 
archives as of yet.


However, as long as you have the correct Xcode installed (the latest 
beta) and have installed MacPorts from source, it works just as smoothly 
in a VM where I am testing it as in the host OSX10.10 machine.


Yes its beta, but I've not had any significant issues in the limited 
playing I have done in the VM ...


Chris




El 19 ago 2015, a las 4:41, Dominik Reichardt  escribió:

Hi,

I’m itching to switch but often need MacPorts. Do any of you have experience 
yet with it *AND* MacPorts?

In previous switches, I switched by using the development version of MacPorts 
and following the migration steps of any major OS X upgrade, still the way to 
go?


Take care

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




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


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

Re: Problems with gettext

[Chris Jones]

You have clipped the useful bits. Post the whole thing, zipped if large



> On 8 Aug 2015, at 2:21 pm, -  wrote:
> 
> 
> 
> Yes, there was a log file.  Here is the last bit of a long file:
> 
> :info:build Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_ma
> cports_sources_rsync.macports.org_release_tarballs_ports_devel_gettext/gettext/w
> ork/gettext-0.19.5" && /usr/bin/make -j4 -w all
> :info:build Exit code: 2
> :error:build org.macports.build for port gettext returned: command execution 
> fai
> led
> :debug:build Error code: CHILDSTATUS 19793 2
> :debug:build Backtrace: command execution failed
>while executing
> "system -nice 0 $fullcmdstring"
>("eval" body line 1)
>invoked from within
> "eval system $notty $nice \$fullcmdstring"
>invoked from within
> "command_exec build"
>(procedure "portbuild::build_main" line 8)
>invoked from within
> "portbuild::build_main org.macports.build"
>("eval" body line 1)
>invoked from within
> "eval $procedure $targetname"
> :info:build Warning: targets not executed for gettext: org.macports.install 
> org.
> macports.build org.macports.destroot
> 
>> On Fri, 7 Aug 2015, Chris Jones wrote:
>> 
>> 
>> 
>>> On 07/08/15 13:30, - wrote:
>>> 
>>> For some days now any port action that calls for gettext bombs.  Here is
>>> one part of the result:
>>> 
>>> Error: org.macports.build for port gettext returned: command execution
>>> failed
>>> 
>>> Any thoughts?
>> 
>> Yes. Is that all that was posted, or was a log file mentioned by chance ??
>> ___
>> macports-users mailing list
>> macports-users@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
>> 
> 
> XB
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Problems with gettext

[Chris Jones]

On 07/08/15 13:30, - wrote:


For some days now any port action that calls for gettext bombs.  Here is
one part of the result:

Error: org.macports.build for port gettext returned: command execution
failed

Any thoughts?


Yes. Is that all that was posted, or was a log file mentioned by chance ??
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: transfer /opt/local to another machine

[Chris Jones]

And it's more than likely that it will happen. It would surprise me somewhat if 
Atlas doesn't check for `-march=native` support, and that would give you AVX 
(and later) support if your i7 supports that.
You ought to ask the question the other way round: how much of a (real-world) 
performance hit would you see when running Atlas built on a C2Duo on an i7.

BTW: I do feel that "base" could add -march=native in user installations (with 
an optional override and not on the build bots) since AFAIU locally built packages are 
not intended to be distributed. The only times I've seen this flag cause issues is when 
running in a VM hosted on an i7, where the VM doesn't support the AVX instruction set and 
the compiler presumes it to be available.


For me that would just cause more problems that it would solve. Ports 
would then be built differently based on where they are being built, 
which is not a nice situation for debugging etc. I am also willing to 
bet the number of ports that would significantly benefit from compiling 
with higher instruction set support, AVX etc., is a very very select 
few. For most there simply will not be much in the way of an appreciable 
gain to the end user. Better to just for those few (like Atlas) handle 
it specifically in the port file, as is done).


Chris


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

Re: transfer /opt/local to another machine

[Chris Jones]

On 13/04/15 10:27, j. van den hoff wrote:

thanks to both of you for your answers and clarifications.

On Mon, 13 Apr 2015 04:04:14 +0200, Ryan Schmidt
 wrote:



On Apr 12, 2015, at 5:54 AM, j. van den hoff wrote:


I just have upgraded two x86_64 machines from 10.9. to 10.10.3 and
upgraded one of them according to the migration guide (i.e.
uninstalled/reinstalled all ~ 800 macports packages). this took an
astonishing long time (over night, basically) partly due to a
multi-hour recompilation of the `atlas' library. and that was on the
faster machine with an SSD...


This is intentional, because atlas is performance-sensitive, so the
port is deliberately programmed to not use precompiled binaries from
our build server, and to instead build on your computer. My
understanding is that the build process builds atlas many times, with
different compiler settings, then tries out each one to see which one
is actually fastest on your particular computer, then installs that
one. That's why it takes so long.


yes, I understand that. I'm not sure, however, how much of a performance
hit I will see when using the intel core-i7 optimized binary on an intel
core 2 duo, so I just would try it out, whether it's OK for my use (that
would mean via `octave', which I am using only sporadically, so ...).


If the core-i7 build is using CPU instructions your core 2 due does not 
have, then the performance hit will be 'significant' (i.e. it simply 
will not run...).


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

Re: something you always ...... about the X11 clipboard(s)

[Chris Jones]

OT: Recent developments have been chipping away at/from that "best
unix for the desktop" aspect, while KDE has given Linux a desktop
that's getting close to being as good (but KF5 seems to be making the
same kind of choices I dislike in recent OS X versions, so I'll
probably will hang on to OS X a while longer).


Your kidding there right ;) As far as I am concerned KDE went down the
toilet when it switched from KDE3 to the bloated mess KDE4 is !


Just to clarify, I was talking about KDE as a desktop environment. The 
applications themselves are OK, and indeed due to QT4 etc. have better 
standalone/cross platform support than before.

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

Re: something you always ...... about the X11 clipboard(s)

[Chris Jones]

OT: Recent developments have been chipping away at/from that "best unix for the 
desktop" aspect, while KDE has given Linux a desktop that's getting close to being 
as good (but KF5 seems to be making the same kind of choices I dislike in recent OS X 
versions, so I'll probably will hang on to OS X a while longer).


Your kidding there right ;) As far as I am concerned KDE went down the 
toilet when it switched from KDE3 to the bloated mess KDE4 is !


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

Re: XQuartz on 10.6 (in a VM)

[Chris Jones]

On 26/03/15 17:46, René J.V. Bertin wrote:

On Thursday March 26 2015 11:22:44 Brandon Allbery wrote:


It shouldn't be using :0.0 but instead the launchd socket. Or have you
"improved" that? In which case you get to debug your own breakage.


I have done nothing to improve that, this is what I get by launching X11 by 
hand. Period.


No, wrong. Even if you choose to launh X11/Xquartz by hand, unless you 
have explicitly turned off launchd support your DISPLAY connection still 
would take the form


> echo $DISPLAY
/private/tmp/com.apple.launchd.PjdrVEAjIV/org.macports:0



So according to you, I shouldn't be able to connect to foo.local:0.0 because 
that's not using a launchd socket either?

R
  ___
Do not post admin requests to the list. They will be ignored.
X11-users mailing list  (x11-us...@lists.apple.com)
Help/Unsubscribe/Update your Subscription: 
https://lists.apple.com/mailman/options/x11-users/jonesc%40hep.phy.cam.ac.uk

This email sent to jon...@hep.phy.cam.ac.uk



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

Re: what was up with ntp again?

[Chris Jones]

> On 23 Mar 2015, at 6:20 pm, Brandon Allbery  wrote:
> 
>> On Mon, Mar 23, 2015 at 2:17 PM, Chris Jones  
>> wrote:
>> > The default permissions are likely to be fine:
>> >
>> > -rw-r--r-- 1 root wheel 9 Dec 24 02:58 /var/db/ntp.drift
>> 
>> That file hasn't been updated for a while ?
> 
> That would be correct for the Apple ntpd/pacemaker setup. It's created once 
> and not updated thereafter, which is the root of the usual problem --- real 
> ntpd will adjust the drift when it changes, Apple's does not, and new 
> machines will usually see changes in their clock drift as they settle in. And 
> the fix is to remove the out of date one, run Apple ntpd or full ntpd without 
> pacemaker running to let it create a more up to date one, and then restart 
> pacemaker, as I described originally.

So why was mine seemingly updated only yesterday ? I've never done anything 
w.r.t. ntp or pacemaker on this machine, so whatever setting is running it must 
by definition be the default Apple setup ... ?

> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: what was up with ntp again?

[Chris Jones]

> On 23 Mar 2015, at 6:14 pm, Mihai Moldovan  wrote:
> 
>> On 23.03.2015 07:17 PM, René J.V. Bertin wrote:
>> I didn't have that file either (OS X 10.9), and the pacemaker manpage does 
>> say something about the daemon exiting if the file isn't recreated within a 
>> certain time after deleting it. I've created empty files for both 
>> /var/db/ntp.drift and /etc/ntp.drift to see if they get populated; what 
>> should the permissions be?
> 
> The default permissions are likely to be fine:
> 
> -rw-r--r-- 1 root wheel 9 Dec 24 02:58 /var/db/ntp.drift

That file hasn't been updated for a while ?

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

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

[Chris Jones]

Hi,

Could be wrong but as I understood things /Library/Frameworks was only 
ever for privately installed stuff used by third party applications, not 
system libraries (those are under /System/Library/Frameworks and in the 
Xcode package area) and as such I am surprised this area was ever search 
by default by the system compiler.


Chris

On 12/03/15 13:44, René J.V. Bertin wrote:

Hi

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 ?

Thanks,
R.

--  Forwarded Message  --

Subject: [Qt bugreports] Shawn Rutledge shared "QTBUG-44947: Using frameworks on OS 
X is not documented" with you
Date: Thursday March 12 2015, 12:37:39
From: Shawn Rutledge (via JIRA) 
To: rjvber...@gmail.com

Shawn Rutledge shared an issue with you

I imagine you know all about this now? ;-)
Qt /  QTBUG-44947
Using frameworks on OS X is not documented

This message was sent by Atlassian JIRA (v6.3.9#6339-sha1:46fa261)  


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



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

Re: Status of gfortran?

[Chris Jones]

On 08/03/15 20:42, Michael Crawford wrote:

ask about in on a high energy physics list, or a HEP google group.
particle physicists are heavily into fortran.


Speaking as one, we used to use F77, years back, but these days we 
mostly use C++.


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

Re: /opt/local/macports/software

[Chris Jones]

On 20/01/15 02:37, Joshua Root wrote:

Daniel J. Luke wrote:

On Jan 19, 2015, at 6:34 AM, René J.V. Bertin  wrote:
What could be an option:
- use xz instead of bzip2 to compact things a bit more


this would probably be a small change (I think there's support for gzip and zip 
already) - but changing your local archive type means you won't get binary 
archives.


This was true in the past, but no longer. Setting portarchivetype only
affects the type of archives that are generated when building locally.
Each archive site now has an associated archive type, which happens to
be tbz2 for packages.macports.org and its mirrors.

We do support building txz archives already, and they can happily
coexist with downloaded tbz2 ones. The catch is that you have to have
the xz port installed to install or activate any txz archives. So the
default is not going to change unless/until Apple starts shipping xz
with OS X.


Or... MP starts shipping xz as a requirement, such as is done with TCL. 
If using xv saves more than it takes up (almost certainly the case) it 
is something to consider.


Chris



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



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

Re: /opt/local/macports/software

[Chris Jones]

Hi,

On 20/01/15 02:49, Craig Treleaven wrote:

At 8:20 PM + 1/19/15, Chris Jones wrote:

 > On 19 Jan 2015, at 7:13 pm, Craig Treleaven
 wrote:
 > At 3:11 PM + 1/19/15, Chris Jones wrote:

 ...


 Does anyone else find it bizarre that, in 2015, we've got such an
active thread about saving a few gigs of space?


Nope. Saving disk space when not required is always a good idea.


If I buy a sub-compact car, I can hardly complain that my skiis won't
fit inside.I truly understand cost constraints and tradeoffs. However,
if a compressed archive of MacPorts-installed packages is the tipping
point for your system...I'd say you're running far too close to the edge.


Its not a matter of being close to the edge. If you have a system with 
say a SSD 128 GB drive, I do not think it is then unreasonable for that 
user to ask why they have to lug around GBs of archives which, unless 
you regular use the activate/deactivate feature (and I still suspect the 
majority of users do not) is of rather limited benefit.


Don't get me wrong, I also do understand why MP does this. I am just say 
IMO its a reasonable question to ask.



 > If one has a too-small SSD, it seems more-than-a-little strange to
complain that building/installing a bunch of software packages
consumes it.  Get a bigger drive.  Or smaller expectations.

And how pray does one do that in a Mac Book with non-upgradable Solid
state storage...


Upgrade:

http://eshop.macsales.com/shop/SSD/OWC


Great, for those in the US .. Plus I don't think upgrading is available 
for all Macs with built in SSDs (might be wrong there, but I think so).




Or the time-honoured fashion in the Apple world...trade up.


I am not sure the 'spend you way out' is the right answer here.

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

Re: /opt/local/macports/software

[Chris Jones]

Hi,

> On 19 Jan 2015, at 8:28 pm, René J.V. Bertin  wrote:
> 
> On Monday January 19 2015 20:20:06 Chris Jones wrote:
> 
>>> If one has a too-small SSD, it seems more-than-a-little strange to complain 
>>> that building/installing a bunch of software packages consumes it.  Get a 
>>> bigger drive.  Or smaller expectations.
>> 
>> And how pray does one do that in a Mac Book with non-upgradable Solid state 
>> storage...
> 
> Getting smaller expectations is impossible for Mac owners, then? :P

I had obviously ignored that part of the reply as 'not a sensible solution'...

> 
> Seriously, there are reasons to cast a wallet-vote against certain products. 
> Absence of upgradable/replaceable memory (volatile and non-volatile) are 
> among the main reasons (though only just before absence of ethernet).

It might surprise you but I personally agree with Apple's direction here, but 
we are going OT. It is what it is, and despite what some think minimising disk 
usage is a reality for a lot of people.

Chris

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

Re: /opt/local/macports/software

[Chris Jones]

Hi,

> On 19 Jan 2015, at 7:13 pm, Craig Treleaven  wrote:
> 
> At 3:11 PM + 1/19/15, Chris Jones wrote:
>> ...
> 
> Does anyone else find it bizarre that, in 2015, we've got such an active 
> thread about saving a few gigs of space?

Nope. Saving disk space when not required is always a good idea.

> 
> If one has a too-small SSD, it seems more-than-a-little strange to complain 
> that building/installing a bunch of software packages consumes it.  Get a 
> bigger drive.  Or smaller expectations.

And how pray does one do that in a Mac Book with non-upgradable Solid state 
storage...

> 
> Having archives where one can activate/deactivate in moments is an awesome 
> feature.  Upgrade go bad?  Switch back in moments.  Need multiple versions of 
> a package with conflicting variants, switch in seconds.  Etc.
> 
> It would be folly to remove such a fantastic feature to cater to a few 
> space-constrained users.

No one to my knowledge has suggested that. Just that it should be an *option*...

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

Re: /opt/local/macports/software

[Chris Jones]

But I admit it is not very useful nowadays. It should be optional, at least when
the version installed is the default one, i.e. the binary can be re-downloaded
verbatim from the server (not a bespoken version with various variants set).


I disagree. I often use deactivation and activation, and I'd have to re-download
the archive every time I did that, it would be a major hassle for me.


The idea was it would be optional to keep or not keep the archive...

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

Re: /opt/local/macports/software

[Chris Jones]

It is also correct that all other package systems you're familiar with
never have to build locally from source.


True, but I don't agree it completely negates the argument.


Possibly if you can get away with always operating in binary mode then
we could re-download missing archives from packages.macports.org
, If you can't (and there are lots of
reasons why things might not be be prebuilt for you) then you really
want those archives.


That is a choice a user might wish to make for themselves... If they 
have limited disk space then even for packages without binary archives a 
user might prefer to accept the CPU cost of re-building from source, if 
they ever need to, to keeping the archive on disk just in case...


Chris

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

Re: /opt/local/macports/software

[Chris Jones]

Well, I'm a grownup and willing to take these chances.  I don't
play with activate/deactivate.  I know of no other distros that
"wastes" that kind of disk space for that.  That some wish to
use this feature, fine.  But I need those gigs back.


Removing these files will very likely break your upgrade to the next
MacPorts version. The upgrade process will run a script that uses a
condition you fulfilled by removing these files to trigger more work,
which will fail because you're not actually in the situation the
script expects you to be.

You'll get to keep the pieces.

TL;DR: These files are needed. Do not remove them. Do not tamper with
MacPorts' internals.


I agree right now is a bad idea to manually nuke these files, and it 
should not be done.


I also though agree with the OP its valid to question why it is really 
needed, as it is a bit of a resource waste for some people.


I also think that comparing MP to *both* other OSX package managers, and 
other OSes, are both valid and interesting comparisons to make.


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

Re: /opt/local/macports/software

[Chris Jones]

On 19/01/15 09:34, Ryan Schmidt wrote:

Please Reply All so that the discussion stays on the mailing list.


On Jan 19, 2015, at 3:26 AM, Akim Demaille wrote:


Le 19 janv. 2015 à 09:27, Ryan Schmidt a écrit :


Hi Ryan,


If you mean /opt/local/var/macports/software, that's where the compressed 
archives of all your installed ports are stored. You are not meant to interact 
with this directory manually. To remove an archive from this directory, 
uninstall the corresponding port. If you're still using the port and don't wish 
to uninstall it, then you should not delete the corresponding archive in this 
directory, or you won't be able to re-activate the port if you deactivate it. 
There may be other aspects of MacPorts that also assume you have not tampered 
with the contents of this directory.


Well, I'm a grownup and willing to take these chances.  I don't
play with activate/deactivate.  I know of no other distros that
"wastes" that kind of disk space for that.  That some wish to
use this feature, fine.  But I need those gigs back.


Of note is that MacPorts used to not do this, or rather, using these archives used to be 
optional, and not the default. Previously, the default was that the contents of 
/opt/local/var/macports/software was the actual software being installed. Hard links 
would then be created in the "real" locations. This did not waste disk space, 
however various new features of OS X interacted badly with this, including Spotlight as 
of OS X v10.4 and Time Machine as of OS X v10.5, so we were forced to remove the previous 
mode of operation and insist on using archives instead.

I am not familiar with what other package management systems do.


It is correct that all others I am familiar with do not require the user 
to effectively have two copies (albeit one compressed) on their system, 
the installed one and the original install media (whether that be tar, 
rpm, deb or whatever).


So I think it is a reasonable question as to why MP requires this. My 
SSD is quite big, so space does not concern me particularly, but also I 
very rarely activate/deactivate (I would guess I am not that different 
to a lot of users here) and thus could easily give this option up. If I 
remove something then decide I want it back, well I have to re-download 
the binary tarball or rebuild it.


I think keeping these tarballs should be made optional again, in some way...

Chris

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

Re: error installing qgis

[Chris Jones]

> On 2 Jan 2015, at 6:00 am, Brandon Allbery  wrote:
> 
>> On Fri, Jan 2, 2015 at 12:46 AM, P Kishor  wrote:
>> https://dl.dropboxusercontent.com/u/3526821/main.log
> 
> So, the actual error is a link error for a bunch of missing symbols. Looking 
> for why those symbols might be missing, I find this:
> 
>> :info:build ld: warning: ignoring file 
>> /Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.dylib, file was 
>> built for i386 which is not the architecture being linked (x86_64): 
>> /Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.dylib
>> :info:build [  1%] ld: warning: ignoring file 
>> /Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_datetime.dylib, file 
>> was built for i386 which is not the architecture being linked (x86_64): 
>> /Applications/GRASS-6.4.app/Contents/MacOS/lib/libgrass_datetime.dylib
> And farther up:
> 
>> :info:configure -- Found GRASS: /Applications/GRASS-6.4.app/Contents/MacOS 
>> (6.4.0RC5)
> 
> Which is a very bad sign (and your build error is a good example of why); 
> cmake is perfectly happy to use random stuff it finds lying around, even when 
> they are not appropriate (in this case because it's i386-only on a system 
> that is otherwise x86_64).
> 
> The qgis port has a grass variant (port install qgis +grass) which will, if 
> used, pull in MacPorts' grass package. Unfortunately, qgis is not preventing 
> use of random other grass packages, which are unlikely to work properly, if 
> this variant isn't selected. If you want to use this, you should remove the 
> standalone application so that it can't interfere with the correct grass 
> package.

And a ticket should be issued so the port maintainer is aware, and can look 
into preventing this from happening when the grass variant is not enabled. Its 
normally possible to do, one way or another...

Cheers chris

> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: error installing qgis

[Chris Jones]

Just compress it, using bzip2 or whatever you prefer then. 

Text logs always compress very well so it will be much smaller...

Chris


> On 2 Jan 2015, at 5:46 am, P Kishor  wrote:
> 
> The log file is 360 KB, so I have put it on my Dropbox/Public folder
> (see link below)
> 
> https://dl.dropboxusercontent.com/u/3526821/main.log
> 
> 
>> On Thu, Jan 1, 2015 at 9:42 PM, Brandon Allbery  wrote:
>>> On Thu, Jan 1, 2015 at 11:32 PM, P Kishor  wrote:
>>> 
>>> Hi, I am not sure what to make of your email. The log file is 2562
>>> lines long, so I included the last 20 or so lines where the actual
>>> error message appears (or so it seems to me).
>> 
>> 
>> That's not the actual error message; it is where the build system noticed
>> that an error occurred, somewhere after the actual error occurred. The
>> actual error is not present, only a notification that some error did occur.
>> 
>> (Pretty much everyone who is not familiar with how build systems work
>> assumes that this notice from the build system is the actual error and/or is
>> somehow sufficient for anyone else to be able to diagnose the problem. Also,
>> most people don't understand that on a multicore machine, the actual build
>> error is often *well* before the build system notices it --- it will
>> continue to build unrelated things, and only report after those unrelated
>> things have finished. This is why we insist that people provide *full* build
>> logs.)
>> 
>> --
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com  ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> 
> 
> 
> -- 
> Puneet Kishor
> Manager, Science and Data Policy
> Creative Commons
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Is trac.macports.org down?

[Chris Jones]

On 18/12/14 15:27, Brandon Allbery wrote:

On Thu, Dec 18, 2014 at 10:15 AM, Daniel J. Luke mailto:dl...@geeklair.net>> wrote:

also, why would homebrew be using a patch from macports like that
anyway?


Homebrew's been "reusing" stuff for a while now.


Strange how they don't just take a copy to use themselves, hosting it in 
their servers. What happens if MacPorts changes/removes the patch... Oh 
I know, their stuff breaks ;) Funny how they think they know better...


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

Re: gcc49 vs gcc48

[Chris Jones]

On 19/11/14 10:45, René J.V. Bertin wrote:

On Wednesday November 19 2014 10:20:23 Chris Jones wrote:


That though does not make what I said incorrect. clang 3.4 fully
supports c++11. A statement of fact.


Please don't take my statement about C++11 support out of context.
Relevant earlier thread: "clang++-mp-3.4 doesn't find initializer_list on OS X 
10.6"


If you don't do the same to mine ;)

Lets leave this here...

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

Re: gcc49 vs gcc48

[Chris Jones]

The issue you describe is an issue with the *deployment* of clang in
MacPorts/OSX. Something else.


 ... or an issue with the package itself that prevents it being 
compiled with clang (I have come across plenty of issues myself of code 
that compiles with gcc but fails with clang, because of bugs in the code 
itself that gcc lets through... and vice versa, both compilers have 
their personal nuances). Or perhaps an issue with way the port is set up.


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

Re: gcc49 vs gcc48

[Chris Jones]

On 18/11/14 23:05, René J.V. Bertin wrote:

On Tuesday November 18 2014 22:59:51 Chris Jones wrote:


Clang 3.4 fully supports c++11 ( if i recall correctly it is complete as of 
3.3). So whatever problems you where having it wasn't because clang does not 
fully support c++11...


Sorry, but yes. The support is not complete in 10.6 (and possibly other 
pre-10.9 OS X version). The symptom is that it cannot find the appropriate 
C++11 headerfiles but instead picks those from Apple's gcc-4.2 .


That though does not make what I said incorrect. clang 3.4 fully 
supports c++11. A statement of fact.


http://clang.llvm.org/cxx_status.html

The issue you describe is an issue with the *deployment* of clang in 
MacPorts/OSX. Something else.


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

Re: gcc49 vs gcc48

[Chris Jones]

> On 18 Nov 2014, at 6:30 pm, René J.V. Bertin  wrote:
> 
> On Tuesday November 18 2014 18:16:53 Chris Jones wrote:
> 
>>> This is on 10.6.8, where the C++ runtime issues are in fact more with 
>>> clang. Using a recent GCC is the only sort-of-reliable way to build C++11 
>>> code.
>> 
>> Not true. In the ROOT6 port we use MacPorts clang (3.4) compiler on 
>> OSX<10.9 in order to support c++11. using clang as opposed to gcc is 
>> better as it avoids the c++ runtime issue better (not entirely but much 
>> better).
> 
> I recall a recent discussion explaining why/how C++11 support in clang 3.4 
> was less complete than in GCC. In any case I can't get kdevplatform and 
> kdevelop to build with clang 3.4 on OS X 10.6.8 (on 10.9 it works fine), but 
> gcc 4.8 and 4.9 have no issues.

Clang 3.4 fully supports c++11 ( if i recall correctly it is complete as of 
3.3). So whatever problems you where having it wasn't because clang does not 
fully support c++11...

> 
> Also, I don't think there's a C++ runtime issue on 10.6.8 (or rather, it's 
> the opposite; using libc++ is neigh impossible). 
> 
> R.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: gcc49 vs gcc48

[Chris Jones]

On 18/11/14 18:12, René J.V. Bertin wrote:

On Tuesday November 18 2014 17:57:55 Chris Jones wrote:


the portfile has been setup to use by the port maintainer. Specifically,
forcing the use of gcc to build c++ code is very problematic due to the
much discussed runtime issues, and consequently very unsupported.


This is on 10.6.8, where the C++ runtime issues are in fact more with clang. 
Using a recent GCC is the only sort-of-reliable way to build C++11 code.


Not true. In the ROOT6 port we use MacPorts clang (3.4) compiler on 
OSX<10.9 in order to support c++11. using clang as opposed to gcc is 
better as it avoids the c++ runtime issue better (not entirely but much 
better).


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

Re: gcc49 vs gcc48

[Chris Jones]

On 18/11/14 17:53, René J.V. Bertin wrote:

On Tuesday November 18 2014 11:59:10 Lawrence Velázquez wrote:



The GPL does not prohibit binary distribution.


No, but I was under the impression that Apple doesn't want to distribute GPLed 
binaries. As I said, I'm not complaining.


Yes, setting configure.compiler to "macports-gcc-4.8" automatically adds a 
library dependency on gcc48, although it's not clear to me why a dependency on libgcc 
wouldn't be sufficient.


And it's apparently not a hard dependency; no errors are generated after 
force-deactivating gcc48, no reinstalls forced etc.


Be aware that manually choosing your own compiler is not supported.


Whatever, as long as configure.compiler=X is supported :)


Its supported in as much as the option is there...

Its not support in the sense there are no guarantees as to whether 
things will work properly if you use it to change the compiler from what 
the portfile has been setup to use by the port maintainer. Specifically, 
forcing the use of gcc to build c++ code is very problematic due to the 
much discussed runtime issues, and consequently very unsupported.


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

Re: pykde4

[Chris Jones]

The long paths are not a MacPorts specific issue

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750231

On 10/11/14 08:20, Nicolas Pavillon wrote:

Hello,

It's been some time, but I had tried to make a Portfile for pykde4, and
then gave up because of several different issues, including the
dependencies to X11. These repeated paths also surely ring a bell. I
don't think I ever got around them, but did not try that hard either.

Cheers,

Nicolas


On 10/11/2014 16:08, Ryan Schmidt wrote:

On Nov 9, 2014, at 12:04 PM, René J.V. Bertin wrote:


Has anyone tried his/her hand at a Portfile for PyKDE4, with success?
I'm doing just that, but one of the blocks I'm running into has to do
with MacPort's convoluted naming for build directories:

-- Configuring done
CMake Error: Cannot open file for write:
/Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_py-pykde4/py33-pykde4/work/build/CMakeFiles/_Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build___pycache___pykdeconfig.cpython-33.pyc.dir/build.make.tmp

CMake Error: : System Error: File name too long
CMake Error: Could not create
/Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_py-pykde4/py33-pykde4/work/build/CMakeFiles/_Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build___pycache___pykdeconfig.cpython-33.pyc.dir/cmake_clean.cmake

CMake Error: Cannot open file for write:
/Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_py-pykde4/py33-pykde4/work/build/CMakeFiles/_Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build___pycache___pykdeconfig.cpython-33.pyc.dir/DependInfo.cmake.tmp

CMake Error: : System Error: File name too long
-- Generating done
CMake Error: Cannot open file for write:
/Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_py-pykde4/py33-pykde4/work/build/CMakeFiles/_Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build__Volumes_Debian_MP6_var_macports_build__Volumes_Debian_MP6_site-ports_kde_py-pykde4_py33-pykde4_work_build___pycache___pykdeconfig.cpython-33.pyc.dir/progress.make.tmp

CMake Error: : System Error: File name too long

Grr!

The path shown above seems to have unnecessarily repeated bits. Do you
perhaps have some kind of recursive symlink problem going on? What is
causing the very long names in the build/CMakeFiles directory? Surely
it's pykde4's build system that's responsible for anything happening
in there. Or perhaps something you're doing in your portfile; hard to
say since I haven't seen your portfile.


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


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


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

Re: Configuring coreutils 94ºC (201,2ºF) reached

[Chris Jones]

On 31/10/14 07:43, Eneko Gotzon wrote:

[Maybe this kind of reports are stupid]


Just the wrong place. This list has nothing to do with the cooling 
capabilities of your machines. If you have concerns on that front you 
should take them to Apple, not here.



--
Eneko Gotzon Ares


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



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

Re: libintl.8.dylib not loaded?

[Chris Jones]

in an attempt to minimize exposure to Shellshock.  IIRC I got the above
from someone on this list.


Together, if I recall, with a number of posts saying it was also a very 
bad idea


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

Re: Customisation of the MacPorts download method

[Chris Jones]

Hi,

How have you figured the VM to connect to the network. Direct, or NAT ?

Does MacPorts work OK on the host machine directly ?

I have serveral OSX VMs running in a MacMini, previously running OSX 
10.9 (now 10.10), and they worked just fine with MacPorts. I have them 
connecting directly to my home network, so they appear as machines in 
their own right on the network. This is with VMware fusion though, not 
virtual box, which I am not familiar with, but I imagine it has similar 
networking options... If you are currently using NAT, I would maybe see 
if a direct connection helps ...


Chris

On 27/10/14 16:32, Artur Szostak wrote:

OK,

I am running OS X 10.9 in VirtualBox on a MacMini, itself running 10.9. The 
purpose is to have a build/test image that can be thrown away and recreated. 
MacPorts 2.3.1 is installed on the virtual machine guest from the provided 
package: 
https://distfiles.macports.org/MacPorts/MacPorts-2.3.1-10.9-Mavericks.pkg

When trying to install wcslib with the following command:
   sudo port install wcslib
The command hangs at the point where it is trying to download the file 
wcslib-4.23.tar.bz2 from ftp://ftp.atnf.csiro.au/pub/software/wcslib/. At some 
point it eventually times out and the command fails.

When trying to download the file 
(ftp://ftp.atnf.csiro.au/pub/software/wcslib/wcslib-4.23.tar.bz2) manually with 
the curl command, I reproduce the hang. However, when trying to download the 
same file with wget it downloads successfully.

Looking through the verbose trace of curl's connection produces no clues as to 
what may be wrong:

$ curl -v ftp://ftp.atnf.csiro.au/pub/software/wcslib/wcslib-4.23.tar.bz2
* Adding handle: conn: 0x7fa751805e00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fa751805e00) send_pipe: 1, recv_pipe: 0
* About to connect() to ftp.atnf.csiro.au port 21 (#0)
*   Trying 150.229.106.20...
* Connected to ftp.atnf.csiro.au (150.229.106.20) port 21 (#0)
< 220-This is the anonymous FTP server operated by
< 220-  CSIRO Astronomy and Space Science and
< 220-  CSIRO ICT Centre.
< 220-
< 220-All transfers from this machine are logged.
< 220 If you don't agree with this policy then please disconnect now.

USER anonymous

< 230 Anonymous user logged in

PWD

< 257 "/" is your current location
* Entry path is '/'

CWD pub

< 250 OK. Current directory is /pub

CWD software

< 250 OK. Current directory is /pub/software

CWD wcslib

< 250 OK. Current directory is /pub/software/wcslib

EPSV

* Connect data stream passively
< 229 Extended Passive mode OK (|||60326|)
*   Trying 150.229.106.20...
* Connecting to 150.229.106.20 (150.229.106.20) port 60326

TYPE I

(hangs, no more output)


So, its clear its a networking problem, but its not clear at what level. It 
could be either on the server side, in the VirtualBox networking, or in curl 
itself.
I would love to solve the route cause of the problem, but I do not see how this 
is going to be fixed anytime soon. Thus, for the time being I need a workaround 
if possible: Can one tell MacPorts to use a different download tool?

Kind regards.

Artur


From: Jeremy Lavergne [jer...@lavergne.gotdns.org]
Sent: 27 October 2014 16:40
To: Artur Szostak
Cc: macports-users@lists.macosforge.org
Subject: Re: Customisation of the MacPorts download method

Can you elaborate on the issues?

Rather than avoiding the problem it’d be best to fix it.


On Oct 27, 2014, at 11:38, Artur Szostak  wrote:


Am I correct in assuming that MacPorts uses curl or the curl library to perform 
source code downloads?
And is there any way to customise this? for example, get MacPorts to use wget 
instread?

The reason is that I am experiencing problems with curl, while wget works.

Kind regards.


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



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

Re: Yosemite upgrade

[Chris Jones]

> On 19 Oct 2014, at 7:33 pm, Carlo Tambuatco  wrote:
> 
> Supported or not...this way seemed to work for a majority of my ports and I 
> was wondering whether nuking all 459 of my ports for the sake of a few that 
> don't work seems like an inefficient solution. It seems there are other ways 
> to approach this problem...

If you want to go against the advice of the experts (not me btw) and not follow 
the migration guide that is your choice. The guide says what it does for good 
reasons, not just for the fun of reinstalling... 

> 
>> On Sun, Oct 19, 2014 at 2:30 PM, Chris Jones  
>> wrote:
>> 
>> 
>> 
>> 
>> > On 19 Oct 2014, at 7:26 pm, Lawrence Velázquez  wrote:
>> >
>> >> On Oct 19, 2014, at 12:57 PM, Chris Jones  
>> >> wrote:
>> >>
>> >> I still think something went wrong and some memory of your previous OSX 
>> >> 10.9 installations is still present. I cannot see how you would get 
>> >> messages regarding Darwin 13 otherwise.
>> >
>> > It seems that Carlo successfully upgraded all his other ports, and the 
>> > ones he listed are the ones that failed for one reason or another. Since 
>> > they are left over from Mavericks, base considers them outdated.
>> 
>> My understanding though is this is not a supported way of upgrading after an 
>> OS upgrade. Removing all ports first then reinstalling those you want is the 
>> recommendation.
>> 
>> >
>> > vq
> 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Migrating to Yosemite---cannot run 'port -qv installed' after OS upgrade

[Chris Jones]

> On 19 Oct 2014, at 7:30 pm, Carlo Tambuatco  wrote:
> 
> 
> 
>> On Sun, Oct 19, 2014 at 2:28 PM, Chris Jones  
>> wrote:
>> 
>> 
>>> On 19 Oct 2014, at 7:23 pm, Brandon Allbery  wrote:
>>> 
>>>> On Sun, Oct 19, 2014 at 2:21 PM, Chris Jones  
>>>> wrote:
>>>> Well yes, you do not have to reinstall everything after removal. The 
>>>> important bit is the removal step... ;)
>>> 
>>> But the thing you complained about was exactly "remove or reinstall (...) 
>>> as you see fit". It was not admitting to other possibilities, just saying 
>>> you could choose to remove something instead of rebuilding it.
>> 
>> I read it as though the 'as fit' was applying to the whole process, so 
>> leaving the old ports as is, built for the old OS, was an option. That was 
>> the part I was commenting on. If that is not what was intended, then my 
>> mistake.
> 
> Whenever I do a port upgrade I use the -u option ie:
> sudo port -u upgrade outdated.

> 
> That should get rid of all outdated ports built for earlier platforms 
> shouldn't it? Am I missing something?

Yes. Following a major OS upgrade you are suppose to do what it says in the 
migration guide...

>  
>>> 
>>> -- 
>>> brandon s allbery kf8nh   sine nomine associates
>>> allber...@gmail.com  ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
> 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Yosemite upgrade

[Chris Jones]

> On 19 Oct 2014, at 7:26 pm, Lawrence Velázquez  wrote:
> 
>> On Oct 19, 2014, at 12:57 PM, Chris Jones  wrote:
>> 
>> I still think something went wrong and some memory of your previous OSX 10.9 
>> installations is still present. I cannot see how you would get messages 
>> regarding Darwin 13 otherwise.
> 
> It seems that Carlo successfully upgraded all his other ports, and the ones 
> he listed are the ones that failed for one reason or another. Since they are 
> left over from Mavericks, base considers them outdated.

My understanding though is this is not a supported way of upgrading after an OS 
upgrade. Removing all ports first then reinstalling those you want is the 
recommendation.

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

Re: Migrating to Yosemite---cannot run 'port -qv installed' after OS upgrade

[Chris Jones]

> On 19 Oct 2014, at 7:23 pm, Brandon Allbery  wrote:
> 
>> On Sun, Oct 19, 2014 at 2:21 PM, Chris Jones  
>> wrote:
>> Well yes, you do not have to reinstall everything after removal. The 
>> important bit is the removal step... ;)
> 
> But the thing you complained about was exactly "remove or reinstall (...) as 
> you see fit". It was not admitting to other possibilities, just saying you 
> could choose to remove something instead of rebuilding it.

I read it as though the 'as fit' was applying to the whole process, so leaving 
the old ports as is, built for the old OS, was an option. That was the part I 
was commenting on. If that is not what was intended, then my mistake.

> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Migrating to Yosemite---cannot run 'port -qv installed' after OS upgrade

[Chris Jones]

> On 19 Oct 2014, at 7:17 pm, Brandon Allbery  wrote:
> 
>> On Sun, Oct 19, 2014 at 2:15 PM, Chris Jones  
>> wrote:
>> ... it is not a matter of 'seeing fit'. Unless you want ongoing problems, 
>> the only correct thing to do is to reinstall *all* your ports...
> 
> Uninstalling port you don't want any more is perfectly legitimate, provided 
> it's not a dependency of something you do want, and will hopefully shorten 
> the amount of time spent rebuilding.

Well yes, you do not have to reinstall everything after removal. The important 
bit is the removal step... ;)

( I normally use this migration as a way of clearing out ports I once 
installed, but no longer want. I keep the list of previously installed ports, 
as reference, but then only reinstall stuff as and when i want it... )

> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Migrating to Yosemite---cannot run 'port -qv installed' after OS upgrade

[Chris Jones]

> On 19 Oct 2014, at 7:02 pm, Carlo Tambuatco  wrote:
> 
> Have you upgraded macports to the newest version for OS X 10.10? Do you have 
> your Xcode command line tools installed for OS X 10.10? Are you using the 
> latest available Xcode 6.1? Unless you've explicitly uninstalled all your 
> ports yourself they should still be there when you install the newest version 
> of macports. You are then free to view all installed ports and 
> uninstall/reinstall them as you see fit.

... it is not a matter of 'seeing fit'. Unless you want ongoing problems, the 
only correct thing to do is to reinstall *all* your ports 

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

> 
>> On Sun, Oct 19, 2014 at 1:58 PM, Leo Singer  wrote:
>> Hi,
>> 
>> I just upgraded my system to Yosemite. Unfortunately, I did not get the list 
>> of installed ports and uninstall them before I upgraded the OS. Now it is 
>> too late:
>> 
>> $ port -qv installed
>> Error: Current platform "darwin 14" does not match expected platform "darwin 
>> 13"
>> Error: If you upgraded your OS, please follow the migration instructions: 
>> https://trac.macports.org/wiki/Migration
>> OS platform mismatch
>> while executing
>> "mportinit ui_options global_options global_variations"
>> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
>> mismatch
>> 
>> Is there any way to trick MacPorts into letting me run 'port installed' and 
>> 'sudo port -f uninstall installed' at this point?
>> 
>> Thanks,
>> Leo
>> 
>> 
>> P.S. Note that the migration instructions may be clearer if they are 
>> organized in chronological order, i.e., the 'port -qv installed', etc. might 
>> come before upgrading the OS and reinstalling Xcode.
>> 
>> ___
>> macports-users mailing list
>> macports-users@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Yosemite upgrade

[Chris Jones]

> On 19 Oct 2014, at 6:00 pm, Carlo Tambuatco  wrote:
> 
> I'd like to get some feedback on those logfiles I sent first before I do a 
> clean wipe of all my macports and spend the next 10 hours or so downloading, 
> configuring, building and reinstalling 459 separate ports. There may be a 
> simpler solution.

So do i take it that you didn't do this when you upgraded, i.e. You didn't 
properly follow the migration guide ? If so, then thats your problem. You need 
to do what it says, there is no alternative.

> 
>> On Sun, Oct 19, 2014 at 12:57 PM, Chris Jones  
>> wrote:
>> Hi,
>> 
>>> On 19 Oct 2014, at 5:50 pm, Carlo Tambuatco  wrote:
>>> 
>>> I upgraded to Xcode 6.1, installed the command line tools for 10.10, 
>>> re-installed macports using the appropriate 10.10 installer .dmg. Then 
>>> upgraded all my macports. The only thing I can think of that you may be 
>>> referring to that I have not done so far is update the macports.conf 
>>> file...?
>> 
>> When you say you upgraded all your ports, did you do this exactly how the 
>> guide says ? I.e. Did you first uninstall them all, then, reinstall them 
>> from scratch ?
>> 
>>> 
>>> From the macports migration page:
>>> 
>>> "If your macports.conf contains uncommented settings for universal_archs or 
>>> build_arch, you will likely want to update them, since unlike earlier OS 
>>> versions, the compiler on Snow Leopard and later will build for x86_64 by 
>>> default on systems that support it. The default values will be fine for 
>>> almost all users, so unless you know you need something different, just 
>>> comment out these two lines.
>>> 
>>> Several other settings in macports.conf have changed their defaults over 
>>> the years. Take a moment to compare each line of your macports.conf with 
>>> the corresponding line in macports.conf.default in the same directory. 
>>> Unless you know a reason why a line your settings file should be different 
>>> from the defaults, adopt the line from the defaults file."
>>> 
>>> I don't really know enough about these settings to mess with them myself. 
>>> Did you change any values in the macports.conf file or 
>>> macports.conf.default file to get it to work? Other than this I can't think 
>>> of anything I did that is different to the steps for migrating macports.
>>> 
>> I did not touch any conf files.
>> 
>> I still think something went wrong and some memory of your previous OSX 10.9 
>> installations is still present. I cannot see how you would get messages 
>> regarding Darwin 13 otherwise. At this point i would perhaps suggest 
>> completely wiping macports
>> 
>> https://guide.macports.org/chunked/installing.macports.uninstalling.html
>> 
>> Then reinstall from scratch.
>> 
>> Chris
>> 
>>> 
>>> 
>>> 
>>>> On Sun, Oct 19, 2014 at 12:34 PM, Chris Jones  
>>>> wrote:
>>>> Hi,
>>>> 
>>>> gcc48 and libgcc installed fine for me in a OSX10.10 VM I had running with 
>>>> the Xcode 6.1 beta prelease. Did you correctly follow the MacPorts 
>>>> migration guide after upgrading your OS.
>>>> 
>>>> https://trac.macports.org/wiki/Migration
>>>> 
>>>> The references below to Darwin 13 (OSX 10.9) suggests to me you did not 
>>>> follow the migration instructions..
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>>> On 19 Oct 2014, at 4:15 pm, Carlo Tambuatco  wrote:
>>>>> 
>>>>> Just upgraded to XCode 6.1. There are still a few hiccups, ports that 
>>>>> fail to upgrade for one reason or another:
>>>>> 
>>>>> db46   4.6.21_9 < 4.6.21_9  (platform darwin 13 
>>>>> != darwin 14)  
>>>>> 
>>>>> gcc47  4.7.4_1 < 4.7.4_1  (platform darwin 13 != 
>>>>> darwin 14)  
>>>>> 
>>>>> gcc48  4.8.3_0 < 4.8.3_0  (platform darwin 13 != 
>>>>> darwin 14)  
>>>>> 
>>>>> libgcc 4.9.1_0 < 4.9.1_0  (platform darwin 13 != 
>>>>> darwin 14)  
>>>>> 
>>>>> llvm-3.3   3.3_4 < 3.3_4  (platform darwin 13 != 
>>>>> darwin 14)  
>>>>> 
>>>>> py26-wx

Re: Yosemite upgrade

[Chris Jones]

Hi,

> On 19 Oct 2014, at 5:50 pm, Carlo Tambuatco  wrote:
> 
> I upgraded to Xcode 6.1, installed the command line tools for 10.10, 
> re-installed macports using the appropriate 10.10 installer .dmg. Then 
> upgraded all my macports. The only thing I can think of that you may be 
> referring to that I have not done so far is update the macports.conf file...?

When you say you upgraded all your ports, did you do this exactly how the guide 
says ? I.e. Did you first uninstall them all, then, reinstall them from scratch 
?

> 
> From the macports migration page:
> 
> "If your macports.conf contains uncommented settings for universal_archs or 
> build_arch, you will likely want to update them, since unlike earlier OS 
> versions, the compiler on Snow Leopard and later will build for x86_64 by 
> default on systems that support it. The default values will be fine for 
> almost all users, so unless you know you need something different, just 
> comment out these two lines.
> 
> Several other settings in macports.conf have changed their defaults over the 
> years. Take a moment to compare each line of your macports.conf with the 
> corresponding line in macports.conf.default in the same directory. Unless you 
> know a reason why a line your settings file should be different from the 
> defaults, adopt the line from the defaults file."
> 
> I don't really know enough about these settings to mess with them myself. Did 
> you change any values in the macports.conf file or macports.conf.default file 
> to get it to work? Other than this I can't think of anything I did that is 
> different to the steps for migrating macports.
> 
I did not touch any conf files.

I still think something went wrong and some memory of your previous OSX 10.9 
installations is still present. I cannot see how you would get messages 
regarding Darwin 13 otherwise. At this point i would perhaps suggest completely 
wiping macports

https://guide.macports.org/chunked/installing.macports.uninstalling.html

Then reinstall from scratch.

Chris
> 
> 
> 
>> On Sun, Oct 19, 2014 at 12:34 PM, Chris Jones  
>> wrote:
>> Hi,
>> 
>> gcc48 and libgcc installed fine for me in a OSX10.10 VM I had running with 
>> the Xcode 6.1 beta prelease. Did you correctly follow the MacPorts migration 
>> guide after upgrading your OS.
>> 
>> https://trac.macports.org/wiki/Migration
>> 
>> The references below to Darwin 13 (OSX 10.9) suggests to me you did not 
>> follow the migration instructions..
>> 
>> Chris
>> 
>> 
>> 
>>> On 19 Oct 2014, at 4:15 pm, Carlo Tambuatco  wrote:
>>> 
>>> Just upgraded to XCode 6.1. There are still a few hiccups, ports that fail 
>>> to upgrade for one reason or another:
>>> 
>>> db46   4.6.21_9 < 4.6.21_9  (platform darwin 13 != 
>>> darwin 14)  
>>> 
>>> gcc47  4.7.4_1 < 4.7.4_1  (platform darwin 13 != 
>>> darwin 14)  
>>> 
>>> gcc48  4.8.3_0 < 4.8.3_0  (platform darwin 13 != 
>>> darwin 14)  
>>> 
>>> libgcc 4.9.1_0 < 4.9.1_0  (platform darwin 13 != 
>>> darwin 14)  
>>> 
>>> llvm-3.3   3.3_4 < 3.3_4  (platform darwin 13 != darwin 
>>> 14)  
>>> 
>>> py26-wxpython-2.8  2.8.12.1_0 < 2.8.12.1_0  (platform darwin 13 
>>> != darwin 14)  
>>> 
>>> pypy   2.4.0_0 < 2.4.0_0  (platform darwin 13 != 
>>> darwin 14)  
>>> 
>>> v8 3.23.17.23_1 < 3.23.17.23_1  (platform 
>>> darwin 13 != darwin 14) 
>>> 
>>> 
>>> 
>>> The failure of gcc47 and gcc48 seem to be connected to the failure to 
>>> configure llvm-3.3
>>> 
>>> Here's the specific llvm-3.3 error:
>>> 
>>> Error: Failed to configure llvm-3.3, consult 
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.3/llvm-3.3/work/llvm-3.3.src/config.log
>>> 
>>> 
>>> Error: org.macports.configure for port llvm-3.3 returned: configure 
>>> failure: command execution failed
>>> 
>>> I will attach the log file for the llvm-3.3 error.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> pypy fails because of a checksum mismatch:
>>> 
>>> Error: Checksum (md5) mismatch for pypy-2.4.0-src.tar.bz2
>>> 
>>> Error: Checksum (sha1) mismatch for pypy-2.4.0-src.tar.bz2
>&g

Re: Yosemite upgrade

[Chris Jones]

Hi,

gcc48 and libgcc installed fine for me in a OSX10.10 VM I had running with the 
Xcode 6.1 beta prelease. Did you correctly follow the MacPorts migration guide 
after upgrading your OS.

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

The references below to Darwin 13 (OSX 10.9) suggests to me you did not follow 
the migration instructions..

Chris



> On 19 Oct 2014, at 4:15 pm, Carlo Tambuatco  wrote:
> 
> Just upgraded to XCode 6.1. There are still a few hiccups, ports that fail to 
> upgrade for one reason or another:
> 
> db46   4.6.21_9 < 4.6.21_9  (platform darwin 13 != 
> darwin 14)  
> 
> gcc47  4.7.4_1 < 4.7.4_1  (platform darwin 13 != 
> darwin 14)  
> 
> gcc48  4.8.3_0 < 4.8.3_0  (platform darwin 13 != 
> darwin 14)  
> 
> libgcc 4.9.1_0 < 4.9.1_0  (platform darwin 13 != 
> darwin 14)  
> 
> llvm-3.3   3.3_4 < 3.3_4  (platform darwin 13 != darwin 
> 14)  
> 
> py26-wxpython-2.8  2.8.12.1_0 < 2.8.12.1_0  (platform darwin 13 
> != darwin 14)  
> 
> pypy   2.4.0_0 < 2.4.0_0  (platform darwin 13 != 
> darwin 14)  
> 
> v8 3.23.17.23_1 < 3.23.17.23_1  (platform darwin 
> 13 != darwin 14) 
> 
> 
> 
> The failure of gcc47 and gcc48 seem to be connected to the failure to 
> configure llvm-3.3
> 
> Here's the specific llvm-3.3 error:
> 
> Error: Failed to configure llvm-3.3, consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.3/llvm-3.3/work/llvm-3.3.src/config.log
> 
> 
> Error: org.macports.configure for port llvm-3.3 returned: configure failure: 
> command execution failed
> 
> I will attach the log file for the llvm-3.3 error.
> 
> 
> 
> 
> 
> pypy fails because of a checksum mismatch:
> 
> Error: Checksum (md5) mismatch for pypy-2.4.0-src.tar.bz2
> 
> Error: Checksum (sha1) mismatch for pypy-2.4.0-src.tar.bz2
> 
> Error: Checksum (rmd160) mismatch for pypy-2.4.0-src.tar.bz2
> 
> 
> Error: org.macports.checksum for port pypy returned: Unable to verify file 
> checksums
> 
> 
> 
> I'm not sure what the problem with v8 is so I'll try to attach the log file 
> for that as well.
> 
> 
>> On Sat, Oct 18, 2014 at 8:16 PM, Ryan Schmidt  
>> wrote:
>> Remember to Reply All when you reply.
>> 
>> 
>> On Oct 18, 2014, at 7:13 PM, Carlo Tambuatco wrote:
>> 
>> > Yeah, just upgraded my ports yesterday after upgrading to Yosemite, and 
>> > cmake along with other ports such as pypy etc fail to upgrade properly. I 
>> > am using the Xcode 6.0 toolchain, so do I need to wait for Xcode 6.1 to be 
>> > released officially before upgrading these ports?
>> 
>> Yes, to build cmake, you need the 10.10 SDK. It's in Xcode 6.1, both the 
>> final version which Apple will release to everyone later and the pre-release 
>> versions, if you can still find it, or the beta versions (but not the final 
>> version) of Xcode 6.0.
>> 
>> 
>> > Ports that have failed the upgrade process after migrating to Yosemite:
>> >
>> > apple-gcc42@5666.3 lang/apple-gcc42
>> 
>> apple-gcc42 is not supported on Yosemite for now.
>> 
>> > clisp  @2.49   lang/clisp
>> > cmake  @3.0.2  devel/cmake
>> > db46   @4.6.21 databases/db46
>> > gcc47  @4.7.4  lang/gcc47
>> 
>> I haven't yet fixed gcc47 and lower for Yosemite, though I intend to. gcc48 
>> and up should work.
>> 
>> > gcc48  @4.8.3  lang/gcc48
>> > gstreamer1-gst-plugins-base@1.4.3  
>> > gnome/gstreamer1-gst-plugins-base
>> > libgcc @4.9.1  lang/gcc49
>> > llvm-3.3   @3.3lang/llvm-3.3
>> > llvm-gcc42 @2336.11lang/llvm-gcc42
>> 
>> llvm-gcc42 is not supported on Yosemite for now.
>> 
>> > py26-wxpython-2.8  @2.8.12.1   python/py-wxpython-2.8
>> > pypy   @2.4.0  lang/pypy
>> > v8 @3.23.17.23 lang/v8
> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Yosemite upgrade

[Chris Jones]

> On 19 Oct 2014, at 10:19 am, René J.V. Bertin  wrote:
> 
>> On Saturday October 18 2014 19:16:39 Ryan Schmidt wrote:
>> Remember to Reply All when you reply.
>> 
>> 
>>> On Oct 18, 2014, at 7:13 PM, Carlo Tambuatco wrote:
>>> 
>>> Yeah, just upgraded my ports yesterday after upgrading to Yosemite, and 
>>> cmake along with other ports such as pypy etc fail to upgrade properly. I 
>>> am using the Xcode 6.0 toolchain, so do I need to wait for Xcode 6.1 to be 
>>> released officially before upgrading these ports?
>> 
>> Yes, to build cmake, you need the 10.10 SDK. It's in Xcode 6.1, both the 
>> final version which Apple will release to everyone later and the pre-release 
>> versions, if you can still find it, or the beta versions (but not the final 
>> version) of Xcode 6.0.
> That's a really curious requirement for a FOSS utility

Not really. Cmake provides the means to build full native Cocoa applications, 
and to do this it needs access to an OSX SDK. 

> ... doesn't it build on earlier versions of OS X that lack the 10.10 SDK by 
> definition? Or doesn't a binary built on, say, 10.6, run on 10.10?

It requires the SDK for the platform it is being built for, so on OSX10.10 
needs the 10.10 SDK, on 10.9 the 10.9 SDK and so on... I guess in theory you 
could target an older OSX release, so use 10.9 SDK on 10.10, but as this is not 
needed in MacPorts, the binaries are always specific for a given OS, the system 
SDK is used to provide the most up to date features... 

So yes, it builds fine and provides binaries on older OSX releases. Its just a 
(temporary) issue with 10.10 until Xcode 6.1 is available.
 
> 
> R
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Yosemite, XCode 6.1?

[Chris Jones]

Its quite simple, you need the OSX 10.10 SDK, which is only available in Xcode 
6.1, which for whatever reason is not released yet. You need to wait for it


> On 18 Oct 2014, at 10:20 pm, Gregory Shenaut  wrote:
> 
> I'm rebuilding my ports after installing Yosemite, and I'm stuck at cmake 
> like several other people. I currently have XCode 6.0.1.
> 
> However, I'm also seeing this unusual (to me) message: “Warning: All 
> compilers are either blacklisted or unavailable; defaulting to first fallback 
> option”.
> 
> And I note that in the cmake log, it appears to require the MacOSX10.10.sdk, 
> which is a component of XCOde 6.1.
> 
> I could download a pre-release version of XCode 6.1 from the Apple site, but 
> it seems odd to me that the ports won't compile with the released version of 
> XCode.
> 
> My questions: (1) does the warning have anything to do with the cmake issue? 
> (2) do I have to install XCode 6.1? (3) Or should I search for a copy of 
> MacOSX10.10.sdk and just install it?
> 
> Thanks,
> Greg Shenaut
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Problem with $DISPLAY

[Chris Jones]

On 13/10/14 15:09, René J.V. Bertin wrote:

On Monday October 13 2014 14:34:15 Chris Jones wrote:


Any scripts that make any assumptions on what $DISPLAY looks like are
flawed by designed...



My argument is not based on what some standard says about what DISPLAY
should or should look like, but the basic premise that extracting
information from $DISPLAY is just a bad idea and should be avoided.


In other words, you mean that *you consider* assumptions on $DISPLAY's 
information content to be design flaws, it's not a universal truth.


Clearly its my opinion, as I stated it. Apologies if that was not obvious.


As long as there is documentation that's not contradicted/superseded by more 
recent/authoritative documents and that states that the 1st element of $DISPLAY 
refers to the X server host, using that information in code may not be the most 
future-proof way of doing things, but it might be the only way of doing things.


On the other hand, even if it did not exist (and I have no time to 
search, or interest in doing so) the absence of such documentation does 
*not* make the documents you quoted the absolute definition of the 
standard. Xorg's view as Brandon has already stated is a very biased 
view towards the way things are in Linux-land.


Chris

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

Re: Problem with $DISPLAY

[Chris Jones]

Hi,


Any scripts that make any assumptions on what $DISPLAY looks like are
flawed by designed...


I don't agree :
(and not being an English fully-native speaker myself I won't comment about 
arguments with grammatical errors :P )

http://www.xfree86.org/4.0/X.7.html#toc4
http://www.x.org/archive/X11R6.8.0/doc/X.7.html#sect4

{{{
DISPLAY NAMES
From the user's perspective, every X server has a display name of the 
form:

   hostname:displaynumber.screennumber

This information is used by the application to determine how it should 
connect to  the  server  and  which
screen it should use by default (on displays with multiple monitors):

[...]
On POSIX systems, the default display name is stored in your DISPLAY 
environment variable.  This  variable
is set automatically by the xterm terminal emulator.  However, when you 
log into another machine on a net‐
work, you may need to set DISPLAY by hand to point to your display.  
For example,

% setenv DISPLAY myws:0
$ DISPLAY=myws:0; export DISPLAY
}}}

If you have a reference to an RFC paper or similar stating different I am of 
course willing to modify my opinion accordingly.


My argument is not based on what some standard says about what DISPLAY 
should or should look like, but the basic premise that extracting 
information from $DISPLAY is just a bad idea and should be avoided.


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

Re: Problem with $DISPLAY

[Chris Jones]

On 13/10/14 11:50, René J.V. Bertin wrote:

Come to think of it, I can't (or maybe, refuse to) see a good, compelling 
reason why a local X11 server would have to use a non-human-readable $DISPLAY 
spec if it can be identified uniquely through :0 (or :1, :2 etc for subsequent 
instances). It's also how Linux manages things if additional users log in.
What the client X11 library does with that to get to a local (file-based or 
not) socket is its own internal affair with which the client has no business, 
but IMVHO the protocol has no business breaking assumptions that have always 
been valid and thus (again, IMVHO), became a de-facto standard.
I do have scripts that parse $DISPLAY to determine if they're dealing with a local or 
remote server, possibly even to identify the particular host being displayed on, and/or 
whether they're dealing with a main or secondary server (there were times I used a 2nd 
X11 server deliberately). Of course I could rewrite the scripts to deal with any kind of 
"blatheblathebla:X[.Y]" scheme, again, I fail to see a compelling reason why I 
would have to (or want to impose it on anyone).


Any scripts that make any assumptions on what $DISPLAY looks like are 
flawed by designed...


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

Re: Problem with cssh

[Chris Jones]

On 13/10/14 01:05, René J.V. Bertin wrote:

On Sunday October 12 2014 18:54:12 Brandon Allbery wrote:



No, it still uses launchd. And, such unusual DISPLAYs *do* exist outside of


Only if you leave the launchd plist in place. I prefer to launch my X11 server 
by hand or not at all, so the plist gets thrown out 1st thing after each 
XQuartz update.
Maybe that's simply the explanation why $DISPLAY is :0 for me (or :1 or :2).


Your mode of operation is highly non-standard... Most people find the 
launchd approach very convenient. Why would you *want* to have to start 
it by hand all the time...

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

Re: Why I Run Old System Software

[Chris Jones]

> On 12 Oct 2014, at 1:20 am, C.T.  wrote:
> 
> Apple didn't make the scanner, but when they cut something the software 
> relies upon to work, that's Apple's responsibility.

Apple did not just cut it with no warning, vendors where given plenty of 
warning via, for instance, the developer previews of OSX 10.7. If the vender in 
question choose to ignore that, and presumably still haven't released a new 
driver, then that is patently not Apple's problem, as the vendor has, by 
intention or just lack of action, chosen to no longer support that device on 
OSX. Thats their chose, not Apple's.


> Of course it would much easier if there were no patent on Rosetta's 
> technology, where it could have been released as open source.

Rosetta is(was) far too tightly integrated with the OS for that to ever happen, 
if possible at all. You might as well ask Apple to release the code for its 
entire OS.  Good luck with that one.

Anyway, this is now getting more than a bit OT for this list...


> 
>> El 11/10/2014, a las 17:25, Dominik Reichardt  escribió:
>> 
>> 
>>>> On 11.10.2014, at 21:22, Chris Jones  wrote:
>>>> 
>>>> But now 10.6 has less of the automation and integration we love from OS X. 
>>>> Using its Safari is now strongly discouraged because of security flaws. I 
>>>> absolutely need two independent browsers, and I won't install a Google 
>>>> product on my machines. I can't launch two Firefox profiles in the same 
>>>> user session. And I need one of these browsers to be very fast.
>> 
>> Curios, I saved C.T.’s actual email to reply to this point but it got 
>> somehow lost in my inbox…
>> 
>> Anyway, if I don’t understand you completely wrong, you can easily launch 
>> two firefox sessions on OS X with each using a different profile.
>> Firefox profiles are stored in ~/Library/Application 
>> Support/Firefox/Profiles.
>> 
>> I use two profiles, the default one that gets used automatically when you 
>> start Firefox (profile name: default) and another one called “test”.
>> 
>> To launch Firefox with a specific profile launch it with 
>> /Applications/Firefox.app/Contents/MacOS/firefox-bin -no-remote -P 
>> profilename
>> 
>> I use an apple script with just the command
>> do shell script "/Applications/Firefox.app/Contents/MacOS/firefox-bin 
>> -no-remote -P test  &> /dev/null &”
>> 
>> Worked for me since OS X 10.6.
>> Just now I found that the -no-remote switch might no longer be necessary. It 
>> used to be important so that the second instance would really use the 
>> profile set with -P and not the profile of the already running instance. 
>> Might be that this has changed in the last five/six years.
>> 
>> And sorry if I misunderstood you. 
>> 
>> Take care
>> 
>> Dominik
> 
> Sounds fair, basically I expected a second session to just pop the session 
> chooser dialog before launching. Apparently I'd need to explicitly tell it to 
> use a given profile.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Why I Run Old System Software

[Chris Jones]

> On 11 Oct 2014, at 8:13 pm, C.T.  wrote:
> 
> 
>> El 11/10/2014, a las 6:25, Chris Jones  escribió:
>> 
>> A lot. Rosetta was not just an application you could install, but an 
>> extension of the underlying OS to provide the translation layer for PowerPC 
>> applications. It would need to be kept in sync with any updates to the OS, 
>> and clearly Apple decided they wanted to stream line things by removing it, 
>> and I can understand that. For me, 10.7 was the right time to do it.
> !0.7 was way too early to ditch Rosetta IMHO. Apple never provided a suitable 
> replacement for my scanner driver that would render Rosetta unnecessary.

Did Apple make that scanner ? I presume not, in which case its not Apples 
responsibility to provide drivers for all possible third party devices, but the 
vender of those devices. If they choose not to provide an Intel driver 
supporting 10.7, thats not Apples fault.


> But I also understood Rosetta is patent-encumbered. A FOSS alternative would 
> be nice. I can make a makeshift network scanner with a Raspberry Pi and hours 
> of tweaking, but I feel for people who wouldn't want to go through such 
> lengths just to operate a perfectly good scanner with a now-awful XSANE 
> interface.
> 
> 
>> El 11/10/2014, a las 5:31, René J.V. Bertin  escribió:
>> 
>> On Friday October 10 2014 19:18:06 Michael Crawford wrote:
>>> (On the thread about the bash function problem, someone asked why the
>>> fellow runs such an old version of OS X.)
>> 
>> Progress for the sole sake of progress ain't progress
> Exactly. What significant progress was made from SL to Lion? Cutting 
> functionality isn't progress. Most netadmins refused to "upgrade" to Lion as 
> everything was dumbed-down and much useful functionality was lost. And I 
> disliked subsequent versions purely on aesthetics. Flat and translucent is 
> ugly, sorry.
> 
>> 
>> I'd thrown in the trend to ever bigger is better (remember the 17" iMac? 
>> That's the one I would have had place for but it was no longer available 
>> when I also had the money). And that includes software packages (oh, Apple 
>> also sells disk space? O:-) ).
> iMac or MacBook Pro? In the latter case I always thought its $3k base price 
> tag broke a psychological barrier, even as far as an Apple product is 
> concerned.
> 
> 
>>> No. Snow Leopard no longer receives updates of any sort, and Lion will
>>> likely follow as soon as Yosemite drops.
>>> http://support.apple.com/kb/HT1222
>> 
>> I see they still haven't produced an EOL statement (is 10.6 Server still for 
>> sale??), we just have to deduce the fact for ourselves.
>> That said, we cannot really complain that 10.6 was EOLed as soon as 10.7 
>> came out.
> Have they produced EOL notices before? Can't recall that.
> 
>> It wouldn't cost Apple anything either to change the 10.6 EULA and allow it 
>> to be run in a VM.
> I think some parts of this OS are patent-encumbered and that Apple would have 
> to ask for permission to other editors before allowing that.
> 
>> About 10.9:
>>> It's also much nicer all around.
>> 
>> Tastes differ. I wouldn't call it that way. 10.6 is faster, more stable, 
>> never required me to ssh in to reboot the machine after the initial upgrade 
>> because it'd gone off on an IMMENSE "local TimeMachine" backup I never asked 
>> for, etc. 
>> In fact, certain changes in 10.9 (like with Mail.app) have gotten me to 
>> investigate KDE for alternatives ... And 10.6 still has Rosetta (and 
>> frankly, how much would it have cost to provide that tech as an optional 
>> install?)
>> That said, there's very little not to prefer in 10.9 if you're coming from 
>> 10.8, from what I've seen. Apart from plugins for QuickLook, apparently :)
> But now 10.6 has less of the automation and integration we love from OS X. 
> Using its Safari is now strongly discouraged because of security flaws. I 
> absolutely need two independent browsers, and I won't install a Google 
> product on my machines. I can't launch two Firefox profiles in the same user 
> session. And I need one of these browsers to be very fast. 
> 
> Its iCal doesn't play well with third-party iCal servers.
> 
> There's no reason why iCloud compatibility wouldn't be made available as an 
> option to SL users.
> 
> And 10.9 is widely known to cause some mysterious issues on perfectly capable 
> machines if the upgrade process goes wrong. The problem being, Apple isolated 
> the user from the underlying process a 

Re: Why I Run Old System Software

[Chris Jones]

> 
> In fact, certain changes in 10.9 (like with Mail.app) have gotten me to 
> investigate KDE for alternatives ... And 10.6 still has Rosetta (and frankly, 
> how much would it have cost to provide that tech as an optional install?)

A lot. Rosetta was not just an application you could install, but an extension 
of the underlying OS to provide the translation layer for PowerPC applications. 
It would need to be kept in sync with any updates to the OS, and clearly Apple 
decided they wanted to stream line things by removing it, and I can understand 
that. For me, 10.7 was the right time to do it.


> That said, there's very little not to prefer in 10.9 if you're coming from 
> 10.8, from what I've seen. Apart from plugins for QuickLook, apparently :)
> 
>> My memory is hazy but I think it was a problem in Safari.  I will look
>> it up I posted it online somewhere.
> 
> You'd be better off installing TenFourFox. Flash support will remain 
> problematic until HTML5 video becomes the standard, but I'd advise to stay 
> away from 10.5 . I tried it on my G4 Powerbook and ditched it immediately, 
> way too slow.
> 
> R
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users