Re: building some ports stalls on xcodebuild

[Ryan Schmidt]

On Nov 17, 2015, at 9:25 AM, Michael Parson wrote:

> My system:
> 
> Late 2009 27" iMac
> OS X 10.10.5
> 
> $ xcodebuild -version
> Xcode 7.1.1
> Build version 7B1005
> 
> While trying to build gmp, it has hung. Looking at 'ps auxw' output, it
> looks like this is the hung command:
> 
> macports25239   0.0  0.2  2667116  32808 s001  S+8:13AM 0:00.76 
> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk / -find 
> clang
> 
> The config.log:
> 
> -- start --
> 
> $ cat config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> It was created by GNU MP configure 6.0.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
> 
>  $ ./configure --prefix=/opt/local --enable-cxx
> 
> ## - ##
> ## Platform. ##
> ## - ##
> 
> hostname = happy
> uname -m = x86_64
> uname -r = 14.5.0
> uname -s = Darwin
> uname -v = Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT 2015;
> root:xnu-2782.50.1~1/RELEASE_X86_64
> 
> /usr/bin/uname -p = i386
> /bin/uname -X = unknown
> 
> /bin/arch  = unknown
> /usr/bin/arch -k   = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo  = Mach kernel version:
> Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT 2015;
> root:xnu-2782.50.1~1/RELEASE_X86_64
> Kernel configured for up to 8 processors.
> 4 processors are physically available.
> 8 processors are logically available.
> Processor type: i486 (Intel 80486)
> Processors active: 0 1 2 3 4 5 6 7
> Primary memory available: 16.00 gigabytes
> Default processor set: 322 tasks, 1992 threads, 8 processors
> Load average: 3.03, Mach factor: 4.95
> /bin/machine   = unknown
> /usr/bin/oslevel   = unknown
> /bin/universe  = unknown
> 
> PATH: /opt/local/bin
> PATH: /opt/local/sbin
> PATH: /bin
> PATH: /sbin
> PATH: /usr/bin
> PATH: /usr/sbin
> 
> 
> ## --- ##
> ## Core tests. ##
> ## --- ##
> 
> configure:3040: checking build system type
> 
> -- end --
> 
> If I change into the build dir and run the './configure' line from the log, it
> runs clean.
> 
> This doesn't seem to be restricted to the 'gmp' port either, I was
> originally having issues with the 'libpng' port.  I thought that maybe
> something had gotten goofed up after my recent HD crash/restore from
> TimeMachine, so I decided to follow the 'macports migration' steps and
> attempt a clean/fresh install of my wanted ports from scratch and 'gmp'
> is where it got hung up this time.

We've had other reports of xcodebuild hanging before; check the issue tracker 
or mailing list archives. xcodebuild is Apple software, so Apple is the one to 
whom you should report the problem, since they're the only ones who can fix it.

One cause of problems we've seen before is if your computer's macports user 
does not have the correct home directory set. Check with "dscl . -read 
/Users/macports". The correct home directory is /opt/local/var/macports/home.


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

building some ports stalls on xcodebuild

[Michael Parson]

My system:

Late 2009 27" iMac
OS X 10.10.5

$ xcodebuild -version
Xcode 7.1.1
Build version 7B1005

While trying to build gmp, it has hung. Looking at 'ps auxw' output, it
looks like this is the hung command:

macports25239   0.0  0.2  2667116  32808 s001  S+8:13AM 0:00.76 
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk / -find clang

The config.log:

-- start --

$ cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU MP configure 6.0.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/opt/local --enable-cxx

## - ##
## Platform. ##
## - ##

hostname = happy
uname -m = x86_64
uname -r = 14.5.0
uname -s = Darwin
uname -v = Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT 2015;
root:xnu-2782.50.1~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = Mach kernel version:
 Darwin Kernel Version 14.5.0: Tue Sep  1 21:23:09 PDT 2015;
root:xnu-2782.50.1~1/RELEASE_X86_64
Kernel configured for up to 8 processors.
4 processors are physically available.
8 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3 4 5 6 7
Primary memory available: 16.00 gigabytes
Default processor set: 322 tasks, 1992 threads, 8 processors
Load average: 3.03, Mach factor: 4.95
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin


## --- ##
## Core tests. ##
## --- ##

configure:3040: checking build system type

-- end --

If I change into the build dir and run the './configure' line from the log, it
runs clean.

This doesn't seem to be restricted to the 'gmp' port either, I was
originally having issues with the 'libpng' port.  I thought that maybe
something had gotten goofed up after my recent HD crash/restore from
TimeMachine, so I decided to follow the 'macports migration' steps and
attempt a clean/fresh install of my wanted ports from scratch and 'gmp'
is where it got hung up this time.


--
Michael Parson
Austin, TX
KF5LGQ
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Fwd: [MacPorts] #49721: (potentially) dangerous bug in Qt5

[René J . V . Bertin]

Hi,

A small FYI-style note of warning for people who use Qt5 for their own 
development (or to install applications) other than through existing MacPorts 
ports. 

The issue I ran into was possible only because of a specific set of conditions 
that may have existed only on my own computer, but I am not yet convinced there 
are no other faces to this bug in Qt.

R.

--  Forwarded Message  --

Subject: [MacPorts] #49721: dangerous bug in Qt5
Date: Tuesday November 17 2015, 09:32:27
From: MacPorts 
To: rjvber...@gmail.com, macports-tick...@lists.macosforge.org

#49721: dangerous bug in Qt5
-+
 Reporter:  rjvbertin@…  |  Owner:  macports-tickets@…
 Type:  defect   | Status:  new
 Priority:  Normal   |  Milestone:
Component:  ports|Version:
 Keywords:   |   Port:  qt5
-+
 Last week I ran into a dangerous bug in Qt5, as a result of which I had to
 restore a large part of /Applications from backup.

 The bug is in QtCore::QStandardPaths (QSP) which provides applications
 with a way to obtain the paths to a range of standard locations, in
 readable ("system") and writable ("user") form. The class also has a
 switch to put it into testing mode that changes the returned locations,
 intended for use in unittests/autotests so that they don't overwrite or
 delete anything in the actual locations.

 On OS X, QSP returns locations that are compliant with the OS X way of
 doing things (app. data into ~/Library/Application Support, for instance)
 and App Store rules.

 For the `ApplicationsLocation` it returns `/Applications`, which seems
 reasonable (but in fact has nothing to do with the role of the
 ApplicationsLocation on Linux). This location makes no difference between
 readable and writable, and more importantly, not either between regular
 and testing mode.

 As a result, software tests that verify functionality involving reading
 and writing from ApplicationsLocation will
 - attempt to get the testing ApplicationsLocation
 - store files there, do stuff with them
 - cleanup afterwards

 The code that wreaked havoc on my machine did the cleanup with a
 `removeDir(ApplicationsLocation)`, in other words, `rm -rf /Applications`.
 Evidently it didn't print exactly what it was doing, it just seemed to
 hang (fortunately I have an HDD, not an SDD). (And of course I have since
 reverified all permissions in /Applications.)

 I reported the bug upstreams, but at the moment any fixing appears to be
 blocked by a single Qt dev, and a fix isn't likely to be included anytime
 soon anyway (5.7, maybe).

 I did include a fix in the QSP patch of my own [ticket:48967
 port:qt5-kde], of course.

 I did run into this problem while developing a port, but I don't think
 there is much risk with published ports. `port test` probably doesn't run
 with elevated privileges, and port maintainers should just check any
 (auto)tests or keep/set `test.run no`.

 However, anyone using the installed Qt5 SDK should be aware of the risk.

-- 
Ticket URL: 
MacPorts 
Ports system for OS X
-
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Variant conflicts

[Bachsau]

Hi there!
Today I ran a port upgrade outdated and got the following message:

> Error: gtk3: Variant quartz conflicts with x11
> Error: Unable to open port: Error evaluating variants

But my variants.conf is
> -x11 +no_x11 +quartz +bash_completion

So whats going on? There's a minus in front of x11 so it should not try to 
install x11 AND quartz.

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: building some ports stalls on xcodebuild

[Clemens Lang]

Hi,

- On 17 Nov, 2015, at 17:07, Ryan Schmidt ryandes...@macports.org wrote:

>> While trying to build gmp, it has hung. Looking at 'ps auxw' output, it
>> looks like this is the hung command:
>> 
>> macports25239   0.0  0.2  2667116  32808 s001  S+8:13AM 0:00.76
>> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk / -find
>> clang

> We've had other reports of xcodebuild hanging before; check the issue tracker 
> or
> mailing list archives. xcodebuild is Apple software, so Apple is the one to
> whom you should report the problem, since they're the only ones who can fix 
> it.

In previous instances of these hangs, a reboot has always fixed them. I had the
idea that the hangs might be related to permissions of cache files in
/var/folders, but a recent ticket seems to have disproved that. If you feel like
debugging these hangs with dtruss(1), that would be very welcome. Try also
blowing away your /var/folders/* (although at this point I have little hope that
it will help).

Otherwise, just reboot and enjoy your Windows-like system.

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