Re: Reporting Xcode/compiler version in main.log
On 29.11.2013, at 9.23, Ryan Schmidt wrote: > > On Nov 28, 2013, at 14:56, Mojca Miklavec wrote: > >> Looking at https://trac.macports.org/ticket/40248 I started wondering >> why the Xcode and compiler version aren't written to the main.log >> automatically. >> >> Would this extra line be easy to add? > > I have long wished that essential system information — OS X version, Xcode > version, command line tools version (can we figure that out?), chosen > compiler, compiler version, CPU type, build_arch, universal_archs, selected > variants — be written to the first few lines of the log. Currently some of > that information is there, but buried among hundreds of lines of less useful > information. > +1 ! ! Jyrki ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Reporting Xcode/compiler version in main.log
On Nov 28, 2013, at 14:56, Mojca Miklavec wrote: > Looking at https://trac.macports.org/ticket/40248 I started wondering > why the Xcode and compiler version aren't written to the main.log > automatically. > > Would this extra line be easy to add? I have long wished that essential system information — OS X version, Xcode version, command line tools version (can we figure that out?), chosen compiler, compiler version, CPU type, build_arch, universal_archs, selected variants — be written to the first few lines of the log. Currently some of that information is there, but buried among hundreds of lines of less useful information. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: request for commit! (maintainer haspatch)
On Thu, Nov 28, 2013 at 10:53 PM, Peter Danecek wrote: > > Dear committers, > > this ticket: http://trac.macports.org/ticket/41122 is still waiting for a > commit, it is fixing an defect. > > The fix was provides already some time ago and I have several other > submissions pending and I already asked for commits to the list, so I am > wondering how the submission/fix to commit process could be streamlined or > what I could do to reduce the times involved. > > Would you like to see a particular format of this mails and/or the subject > when asking from a commit? > Anything else what would helps? > > In case, there are problems with the patches or submissions, or I am doing > some fundamental error, please do not silently ignore, but comment and let me > know about it, otherwise I will never know what is the problem. > > Here some other submissions which I believe are in a decent state: > > http://trac.macports.org/ticket/41334 > http://trac.macports.org/ticket/41337 > http://trac.macports.org/ticket/41499 Thanks a lot, committed. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
request for commit! (maintainer haspatch)
Dear committers, this ticket: http://trac.macports.org/ticket/41122 is still waiting for a commit, it is fixing an defect. The fix was provides already some time ago and I have several other submissions pending and I already asked for commits to the list, so I am wondering how the submission/fix to commit process could be streamlined or what I could do to reduce the times involved. Would you like to see a particular format of this mails and/or the subject when asking from a commit? Anything else what would helps? In case, there are problems with the patches or submissions, or I am doing some fundamental error, please do not silently ignore, but comment and let me know about it, otherwise I will never know what is the problem. Here some other submissions which I believe are in a decent state: http://trac.macports.org/ticket/41334 http://trac.macports.org/ticket/41337 http://trac.macports.org/ticket/41499 Thanks! ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Reporting Xcode/compiler version in main.log
Hi, Looking at https://trac.macports.org/ticket/40248 I started wondering why the Xcode and compiler version aren't written to the main.log automatically. Would this extra line be easy to add? Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
ROOT update to work around FreeType issue
Hi, Could someone with commit access take a look at. https://trac.macports.org/ticket/41572 ? It adds a work around for an issue ROOT has with the recent FreeType 2.5.1 update. Not yet really clear where the issue lies, but my bet is with ROOT itself, so this work around (which is to revert to ROOT using its own internal FreeType build) will be needed I think with the current 5.34.12 release. cheers Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Certificate Authorities: curl-ca-bundle, certsync, keychain
On 2013-11-28 15:25, Landon Fuller wrote: > certsync is tested and works on 10.6+, and is building successfully on all > the buildbots, and a MacPorts update has now shipped with support for > auto-loading certsync's startup item. I've been running certsync since May > without any noticed ill-effects. I have been using certsync since you announced it here on the list and so far, I did not experience any problems. I am fine with moving to certsync as the new default. For older OS X versions <=10.5, the certsync port could just depend on the curl-ca-bundle and not install any files. Or should we keep the path: dependency style anyway to allow using curl-ca-bundle as an alternative? > I would like to propose that we move to using certsync by default, as a > replacement for curl-ca-bundle. To briefly rehash the benefits of certsync: > - Uses the CAs Apple provides -- that way MacPorts doesn't have to be > in the business of distributing CA certificates. > - Also includes any custom CAs that the user has added. This is the > case for many people who use internal CAs to sign certificates for their > corporate (or personal) services. > - Automatically updates when the System Keychain(s) or trust settings > are modified. The only catch is that custom added certificates or trust anchors need to be in the system keychain to be picked up by certsync by default. As a side note, as of Mavericks the version of curl distributed by Apple uses SecureTransport instead of OpenSSL and accesses the keychain directly to check for trusted CAs [1]. Due to this, /usr/bin/curl looses some functionality. MacPorts' curl still uses OpenSSL and with certsync it will use the same list of certificates without loosing any functionality. Rainer [1] http://curl.haxx.se/mail/archive-2013-10/0036.html ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
XCode 5 and c++ libs
Hi: Yet again, I'm well out of my depth and I wonder if those more experienced with C++ could further my education. This is in reference to MythTV 0.27 failing to build on Mavericks due to (I believe) the switch in standard C++ libraries in XCode 5. http://trac.macports.org/ticket/41371 Initially, the failure was in one of Myth's internal libs. Some web searching suggested that perhaps adding '-stdlib=libstdc++' to the linker flags might help. Doing that, however, leads to the build failing while linking Myth's version of the qjson library, as follows: /usr/bin/clang++ -headerpad_max_install_names -stdlib=libstdc++ -Wl,-dynamic,-search_paths_first -arch x86_64 -single_module -dynamiclib -compatibility_version 0.7 -current_version 0.7.1 -install_name /opt/local/lib/libmythqjson.0.dylib -Xarch_x86_64 -mmacosx-version-min=10.9 -o libmythqjson.0.7.1.dylib json_parser.o json_scanner.o parser.o parserrunnable.o qobjecthelper.o serializer.o serializerrunnable.o moc_parserrunnable.o moc_serializerrunnable.o -F/opt/local/Library/Frameworks -F/opt/local/lib -L/opt/local/lib -F/opt/local/Library/Frameworks -F/opt/local/lib -framework QtCore Undefined symbols for architecture x86_64: "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: std::__1::basic_ostream >& std::__1::operator<< >(std::__1::basic_ostreamstd::__1::char_traits >&, char const*) in json_parser.o I vaguely understand the issue based on a posting by Ryan the other day: At 6:42 PM -0600 11/26/13, Ryan Schmidt wrote: What version of OSX? If Mavericks, you may be having the problem that you cannot mix software compiled with libc++ (i.e. anything compiled with clang) with software compiled with libstdc++ (i.e. anything compiled with FSF GCC). Myth links with 13 libraries provided by MacPorts[1] and includes its own copies of 7 other libraries[2]. The error message above relates to Myth's copy of qjson which only links with qt4-mac (AFAIK). Does this mean that if there is a mismatch in the standard C++ libs anywhere in the chain of recursive dependencies, it is going to go boom?!? If so, that is an enormous problem for any sizable project, no? Please help me understand this issue better. Bonus points if you can point me towards a solution for Myth! Craig [1] Dependencies provided by MacPorts: bzip2 faac freetype lame libass libcdio libiconv libxml2 openssl qt4-mac taglib x264 zlib [2] Dependencies provided with Myth FFmpeg libhdhomerun libmythbluray libsamplerate nzmqt qjson zeromq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Certificate Authorities: curl-ca-bundle, certsync, keychain
Howdy All --
certsync is tested and works on 10.6+, and is building successfully on all the
buildbots, and a MacPorts update has now shipped with support for auto-loading
certsync's startup item. I've been running certsync since May without any
noticed ill-effects.
I would like to propose that we move to using certsync by default, as a
replacement for curl-ca-bundle. To briefly rehash the benefits of certsync:
- Uses the CAs Apple provides -- that way MacPorts doesn't have to be
in the business of distributing CA certificates.
- Also includes any custom CAs that the user has added. This is the
case for many people who use internal CAs to sign certificates for their
corporate (or personal) services.
- Automatically updates when the System Keychain(s) or trust settings
are modified.
Thoughts?
-landonf
On May 13, 2013, at 21:39 , Landon Fuller wrote:
> Howdy,
>
> Over the weekend I whipped up (and added a port for) 'certsync'; it's a small
> tool that fetches all trusted certificates from the Mac OS X system keychain,
> and then spits them out as OpenSSL-readable pem-encode certificate bundle.
>
> The goal was to provide a replacement for curl-ca-bundle with the following
> benefits:
> - Uses the CAs Apple provides -- that way MacPorts doesn't have to be
> in the business of distributing CA certificates.
> - Also includes any custom CAs that the user has added. This is the
> case for many people who use internal CAs to sign certificates for their
> corporate (or personal) services.
> - Automatically updates (if the launchd item is loaded) when the System
> Keychain(s) or trust settings are modified.
>
> There are a few gotchas that I could use input on, however:
> - curl-ca-bundle currently lays claim to
> ${prefix}/etc/openssl/cacerts.pem. This conflicts with certsync, and there's
> no way to have both installed at the same time.
> - A small number of ports directly depend on curl-ca-bundle to ensure
> that valid CA certificates are available.
> - certsync can only keep the cert.pem file up-to-date if the launchd
> item is enabled. Ideally that would be done by default, but that's not
> currently supported.
>
> Any thoughts on how to proceed?
>
> I'm currently using certsync locally; to install, you'll have to:
> sudo port -f deactivate curl-ca-bundle
> sudo port install certsync
>
> -landonf
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
revision bumps after geos update (r110191)?
Hi developers,
I was getting my older box up to date and noticed the following problem:
{{{
---> Scanning binaries for linking errors: 48.0%
Could not open /opt/local/lib/libgeos-3.4.1.dylib: Error opening or reading
file (referenced from
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyspatialite/_spatialite.so)
---> Scanning binaries for linking errors: 100.0%
---> Found 3 broken file(s), matching files to ports
---> Found 3 broken port(s), determining rebuild order
---> Rebuilding in order
py26-spatialite @2.6.2
py27-matplotlib-basemap @1.0.6
py27-spatialite @2.6.2
}}}
I guess, these ports and other dependents (also `qgis` for me). Should have
been revision bumped after r110191 and probably this applies to other
dependents. But now this commit is 3 months old.
So how to proceed?
(1) ignoring (because of the 3 months and not very relevant) or file a ticket?
(2) Which port against? The affected ports or the one causing the issue?
Thanks!
~petr
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
